Framework Fit Analysis
Coverage
Evaluate technology fit before adoption, replacement, or standardization. Covers requirement fit, constraints, ecosystem maturity, maintenance health, team skill, integration cost, migration path, performance envelope, security posture, operational burden, lock-in, exit cost, and decision recording.
Philosophy
Technology choice is context-dependent. "Best" without constraints is marketing. A good fit analysis makes tradeoffs explicit enough that a team can accept the costs knowingly.
Do not confuse popularity with fit. Do not let a narrow implementation preference choose a durable platform. The right output is a recommendation plus consequences, not a ranking table with fake precision.
Method
- State the job the technology must do.
- List hard constraints: runtime, hosting, data, compliance, team, budget, timeline.
- Define evaluation criteria and weights qualitatively: must-have, important, nice-to-have.
- Compare credible options, including staying put.
- Assess migration and exit costs.
- Identify operational ownership and failure modes.
- Recommend one path with accepted tradeoffs.
- Hand off to
architecture-decision-records if the decision is durable.
Evals
This skill ships a comprehension-eval artifact at examples/evals/framework-fit-analysis.json. The checklist below is the authoring gate for technology-fit decisions; the eval file is the grader surface.
Verification
Do NOT Use When
| Use instead |
When |
dependency-architecture |
You need dependency graph hygiene, package boundaries, duplication control, or supply-chain guardrails. |
architecture-decision-records |
The choice is already made and needs a record. |
performance-engineering |
You need to measure and optimize actual runtime behavior. |
| A framework-specific skill |
The framework is already chosen and the task is implementation. |
1---2name: framework-fit-analysis3description: Use when choosing, replacing, or justifying a framework, library, SDK, runtime, database, UI kit, or platform by fit: constraints, team skill, ecosystem maturity, migration cost, operability, performance, security, and exit cost. Do NOT use for routine dependency hygiene (use `dependency-architecture`), documenting an accepted decision (use `architecture-decision-records`), or framework-specific implementation work.4license: MIT5---6
7# Framework Fit Analysis
8
9## Coverage
10
11Evaluate technology fit before adoption, replacement, or standardization. Covers requirement fit, constraints, ecosystem maturity, maintenance health, team skill, integration cost, migration path, performance envelope, security posture, operational burden, lock-in, exit cost, and decision recording.
12
13## Philosophy
14
15Technology choice is context-dependent. "Best" without constraints is marketing. A good fit analysis makes tradeoffs explicit enough that a team can accept the costs knowingly.
16
17Do not confuse popularity with fit. Do not let a narrow implementation preference choose a durable platform. The right output is a recommendation plus consequences, not a ranking table with fake precision.
18
19## Method
20
211. State the job the technology must do.
222. List hard constraints: runtime, hosting, data, compliance, team, budget, timeline.
233. Define evaluation criteria and weights qualitatively: must-have, important, nice-to-have.
244. Compare credible options, including staying put.
255. Assess migration and exit costs.
266. Identify operational ownership and failure modes.
277. Recommend one path with accepted tradeoffs.
288. Hand off to `architecture-decision-records` if the decision is durable.
29
30## Evals
31
32This skill ships a comprehension-eval artifact at [`examples/evals/framework-fit-analysis.json`](https://github.com/jacob-balslev/skill-graph/blob/main/examples/evals/framework-fit-analysis.json). The checklist below is the authoring gate for technology-fit decisions; the eval file is the grader surface.
33
34## Verification
35
36- [ ] The recommendation is tied to explicit project constraints
37- [ ] "Do nothing" or "keep current stack" was considered when real
38- [ ] Migration and exit costs are named
39- [ ] Operational ownership is named
40- [ ] Performance and security claims are evidence-backed or marked uncertain
41- [ ] The decision can be reversed only with known cost
42- [ ] Follow-up ADR is proposed for durable choices
43
44## Do NOT Use When
45
46| Use instead | When |
47|---|---|
48| `dependency-architecture` | You need dependency graph hygiene, package boundaries, duplication control, or supply-chain guardrails. |
49| `architecture-decision-records` | The choice is already made and needs a record. |
50| `performance-engineering` | You need to measure and optimize actual runtime behavior. |
51| A framework-specific skill | The framework is already chosen and the task is implementation. |
aibot88