Technology Evaluation skill for Claude Code
Pick tools with evidence, a PoC and an exit plan. Claude fixes requirements and weights before naming candidates, eliminates options with pass/fail gates, and scores the shortlist with evidence pulled from docs, release history and repo health rather than memory. A time-boxed PoC targets the riskiest assumption, TCO and exit cost are priced, a sensitivity check exposes close calls, and the result lands as an ADR.
- name
technology-evaluation - size163 lines · ≈1,850 tokens
- files1
- licenseMIT
- updated
What Claude sees before loading it
This description is the only part of the skill that sits in context all the time. Claude reads it to decide when to load the full playbook below.
description: Evaluates and selects libraries, frameworks, databases, SaaS vendors, and developer tools with a weighted criteria matrix, must-have gates, evidence from docs, repos, and release history, a time-boxed proof of concept with pass/fail criteria, total cost of ownership, risk and exit analysis, and a decision record. Use when asked to compare tools, choose between X and Y, pick a vendor, run a build-vs-buy analysis, evaluate a new dependency, or write an architecture decision record for a technology choice.Try asking
- Compare Temporal, Inngest and a plain job queue for our background workflows and recommend one
- We need a feature-flag vendor, run a proper evaluation with a PoC plan
- Is this npm package healthy enough to depend on? Check maintenance and security
Use it when
- You must choose between libraries, frameworks, databases or vendors
- A build-vs-buy decision needs a defensible write-up
- You are adding a significant new dependency
- Leadership wants a recommendation with costs and risks
Skip it when
- You only need to record a decision already made — use adr-records
- You need to prototype one option to answer a technical unknown — use technical-spike
How to check the result
Weights were recorded before scoring, every matrix cell links to evidence, and the winner survives a plus-or-minus 10 point change to the top two weights or the closeness is stated.
The common mistake it prevents
Writing the criteria after picking a favorite, so the matrix rationalizes a decision instead of making it.
Done well means: the requirements and weights were fixed before looking at candidates, must-haves eliminated options early, scores cite evidence (a doc page, a benchmark you ran, a repo metric), the PoC tested the riskiest assumption rather than the happy path, and the decision record states what would make you revisit it.
Hard rules
- Requirements and weights first, candidates second. Writing criteria after you have a favorite produces a matrix that justifies the favorite.
- Every score cites evidence. Claims about features, licenses, pricing, limits, and
compliance come from current official docs or your own test, with the date checked.
Mark anything from memory as
unverifiedand verify before deciding. - Do not invent benchmark numbers, GitHub stats, or pricing. Fetch them or leave the cell empty.
- Keep the shortlist to 2-4 options. Evaluating eight tools in depth wastes the time the PoC needs.
- The status quo (do nothing / keep current tool) and build-it-yourself are always candidates.
Workflow
- [ ] 1. Problem statement and constraints
- [ ] 2. Criteria: must-haves (gates) and weighted wants
- [ ] 3. Long list -> shortlist via gates
- [ ] 4. Desk evaluation with evidence
- [ ] 5. Proof of concept on the riskiest assumptions
- [ ] 6. TCO, risk, and exit analysis
- [ ] 7. Decision record and adoption plan1. Problem statement
One paragraph: what job the technology must do, scale (requests, data volume, users, team size), timeline, hard constraints (language, cloud, license policy, data residency, compliance such as SOC 2, HIPAA, GDPR), and who will operate it.
2. Criteria
Gates (pass/fail) remove options outright: license compatible, runs in our environment, meets a compliance requirement, supports a required integration.
Weighted criteria (weights sum to 100, agreed with stakeholders before scoring):
| Criterion | Typical weight | Evidence to collect |
|---|---|---|
| Functional fit | 20-30 | Map each requirement to a doc page or PoC result |
| Performance at our scale | 10-20 | Our own benchmark in the PoC, not vendor charts |
| Operability | 10-15 | Deploy model, observability hooks, upgrade path, backup/restore |
| Developer experience | 10-15 | Time to first working example, docs quality, type support, error messages |
| Maturity and maintenance | 10-15 | Release cadence, open issue response, maintainers/bus factor, breaking-change history |
| Ecosystem and community | 5-10 | Integrations, plugins, Stack Overflow/GitHub discussions activity, hiring pool |
| Security posture | 5-15 | CVE history and response time, SBOM/signing, security policy, audit reports |
| Cost (TCO) | 10-20 | See step 6 |
| Lock-in / exit cost | 5-10 | Data export formats, open standards, migration path |
Scoring scale: 1 (fails need), 3 (meets), 5 (exceeds with evidence). Use whole numbers; a 3.7 implies precision nobody has.
3-4. Evidence gathering
Open-source dependency health (gather, do not guess):
gh repo view owner/repo --json stargazerCount,forkCount,pushedAt,licenseInfo,isArchived
gh release list -R owner/repo --limit 10 # cadence and recency
gh issue list -R owner/repo --state open --limit 1 --json number # plus sample a few for response time
gh api repos/owner/repo/contributors --paginate -q '.[].login' | head -20 # bus factor
npm view <pkg> time --json | tail -5 # publish history (npm)
curl -s https://pypistats.org/api/packages/<pkg>/recent # downloads (PyPI)Also check: OpenSSF Scorecard (scorecard --repo=github.com/owner/repo or the
deps.dev page), deps.dev for dependency tree and advisories, OSV for known
vulnerabilities, the CHANGELOG for breaking changes per major, and the license file
itself (not just the repo badge).
Vendors and SaaS: pricing page (archive it), SLA and its credits, status page history, data processing agreement, SOC 2 Type II or ISO 27001 report availability, SSO/SCIM availability and which tier, API rate limits, data export, and contract terms (auto-renewal, price increase caps).
Stars and downloads measure popularity, not quality. Use them only as a tie-breaker signal for ecosystem size.
5. Proof of concept
Time-box it (1-5 days). Test what could kill the option, not what the demo already shows.
## PoC plan: <option>
Riskiest assumptions: 1) handles 5k writes/s with p99 < 50 ms on our schema; 2) works with our SSO
Scenarios: load test with production-shaped data; failover; upgrade one minor version; integrate with auth
Pass/fail criteria (decided now): p99 < 50 ms at 5k/s; zero data loss on node kill; SSO login works with groups
Out of scope: UI polish, full migration
Time box: 3 days; stop early if a gate failsRun the same scenarios against each finalist. Record results with commands, versions, and hardware so they can be reproduced.
6. TCO, risk, exit
TCO over 3 years: licenses/subscription (at projected scale, not today’s), infrastructure, engineering time to integrate and migrate, ongoing operations (on-call, upgrades), training, and exit cost. Self-hosted “free” software is rarely the cheapest once operations time is counted.
Risk register per finalist:
| Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|
| Vendor raises price or changes license (open core relicensing) | M | H | Contract cap; abstraction layer; known fork |
| Single maintainer abandons project | M | M | Fork plan; budget to sponsor |
| Missing feature X needed in 12 months | L | H | Roadmap commitment in writing, or workaround tested in PoC |
Exit plan: how data and configuration leave, in what format, and roughly how long a migration would take.
7. Decision record
# ADR-0NN: Choose <option> for <problem>
Status: Accepted (2025-10-14) Deciders: ...
Context: problem, constraints, scale
Options considered: A, B, C, status quo (gates each failed or passed)
Decision matrix: criteria x options with weighted totals; evidence links per cell
PoC results: pass/fail per criterion with links to scripts and data
Decision: <option>, because <the 2-3 criteria that decided it>
Consequences: what gets easier, what gets harder, new operational duties
Risks and mitigations
Revisit if: e.g., cost exceeds $X/month, p99 regresses beyond Y, project is archived
Adoption plan: pilot team, migration steps, rollback pathStore it with the project’s ADRs (see adr-records for numbering and format).
Sensitivity check
Before finalizing, change the top two weights by +/-10 points each. If the winner changes, the decision is close: say so explicitly and let the riskiest-assumption PoC results or exit cost break the tie, rather than presenting a narrow weighted win as decisive.
Gotchas
- Vendor benchmarks use their best case; your PoC with your data is the only number that counts.
- Feature checklists hide tier gating: SSO, audit logs, and SLAs often require the enterprise plan. Price the tier that has the features.
- Open-source license changes (to source-available) have hit several popular infrastructure projects; check the current license and governance, not last year’s.
- Recency bias: a new tool’s lack of open issues may mean lack of users.
- A strong opinion from one senior engineer is evidence about developer experience, not about every criterion.
About this skill
Written and maintained by the Claude Skills editors to the same editorial standard as every skill in the directory: a selective trigger, a real workflow, known pitfalls and a verification step. First published , last updated . MIT licensed.