# Framework Fit Analysis

> 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.

- Skill: `aibot88/framework-fit-analysis` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add aibot88/framework-fit-analysis`
- Raw SKILL.md: https://api.skillmd.com/api/skills/aibot88/framework-fit-analysis/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Design & Media
- License: MIT
- Author: aibot88 (https://skillmd.com/u/aibot88)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/aibot88/framework-fit-analysis

---


# 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

1. State the job the technology must do.
2. List hard constraints: runtime, hosting, data, compliance, team, budget, timeline.
3. Define evaluation criteria and weights qualitatively: must-have, important, nice-to-have.
4. Compare credible options, including staying put.
5. Assess migration and exit costs.
6. Identify operational ownership and failure modes.
7. Recommend one path with accepted tradeoffs.
8. 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`](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.

## Verification

- [ ] The recommendation is tied to explicit project constraints
- [ ] "Do nothing" or "keep current stack" was considered when real
- [ ] Migration and exit costs are named
- [ ] Operational ownership is named
- [ ] Performance and security claims are evidence-backed or marked uncertain
- [ ] The decision can be reversed only with known cost
- [ ] Follow-up ADR is proposed for durable choices

## 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. |