From coding-skills
AI-era technology decision framework for tech selection, architecture choices, and build-vs-buy analysis. This skill should be used when comparing frameworks, services, tools, or libraries, evaluating architecture approaches (monorepo vs multi-repo, SSR vs SSG), deciding build vs buy, or assessing whether to upgrade or stay. Trigger phrases: "which should I use", "A vs B", "should I switch to", "build or buy", "upgrade or stay", "compare X and Y", "what is the best option for". Do NOT use for pure implementation tasks where the technology choice is already made.
How this skill is triggered — by the user, by Claude, or both
Slash command
/coding-skills:decisionThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
AI (Claude Opus, etc.) has solved most of the difficulty in writing code. **"Can we build it?"** and **"Is it hard?"** are no longer the primary factors in technology selection.
AI (Claude Opus, etc.) has solved most of the difficulty in writing code. "Can we build it?" and "Is it hard?" are no longer the primary factors in technology selection.
The real cost comes later: maintenance, migration, security patches, rewrites after a technology dies. Decisions should optimize for lowest long-term total cost.
| Scenario | Apply? |
|---|---|
| Choosing a framework, service, tool, or library | Yes |
| Architecture approach comparison (monorepo vs multi-repo, SSR vs SSG...) | Yes |
| Evaluating whether to introduce a new dependency | Yes |
| Third-party service selection (SaaS, PaaS, API provider) | Yes |
| Build vs buy decisions | Yes |
| Upgrade vs stay on current version | Yes |
| Technology already decided, just implementing | No — just build |
| Bug fix | No — use /diagnose or /fix |
| Code-level design (interface, pattern) | No — use /principles or /spec |
List all candidate approaches. One sentence each.
Before evaluating, explicitly list all implicit assumptions:
Assumptions:
1. [assumption] — evidence: [what supports this] | risk: [what if wrong]
2. [assumption] — evidence: [what supports this] | risk: [what if wrong]
...
Challenge each assumption: Is it based on data or gut feeling? When was it last verified?
Evaluate each option across four dimensions:
| Dimension | Option A | Option B | Option C |
|---|---|---|---|
| Tech debt | ? | ? | ? |
| Extensibility | ? | ? | ? |
| Security | ? | ? | ? |
| Survival risk | ? | ? | ? |
Score: Low / Medium / High risk. Add/remove option columns as needed. For Dimension 4 (Survival Risk), map tiers: open standards through community OSS = Low, mature commercial = Medium, startup through abandoned = High.
Scoring criteria for each dimension follow below.
Will this choice become a burden in 6 months?
| Factor | Low | Medium | High |
|---|---|---|---|
| API stability | Strict semver, migration guides | Occasional breaking changes with workarounds | Frequent breaking changes, no migration path |
| Abstraction leakage | Clean boundaries, swappable | Some coupling, replaceable with effort | Deep coupling throughout the project |
| Upgrade path | Incremental (codemod, compat layer) | Major version requires partial rewrite | Full rewrite needed |
| Community maintenance | Active PRs/issues, regular releases | Slower cadence but still maintained | Last release > 6 months ago |
Can it naturally extend when requirements change? Or does it require a rewrite?
| Factor | Low | Medium | High |
|---|---|---|---|
| Plugin / extension mechanism | Official plugin API or middleware | Community plugins, some gaps | Monolithic, must fork to change behavior |
| Composability | Works with other tools freely | Some integration friction | Requires full ecosystem buy-in |
| Data portability | Standard formats (JSON, SQL, OpenAPI) | Export available but limited | Proprietary format, export restricted |
| Scale adaptation | Works from small to large | Works at current scale, uncertain beyond | Only fits a specific scale |
Does this introduce unnecessary attack surface?
| Factor | Low | Medium | High |
|---|---|---|---|
| Dependency count | Few (< 10 direct deps) | Moderate (10-30 direct deps) | Many (huge dependency tree) |
| Known vulnerabilities | npm audit / pip audit clean | Minor/moderate issues, fixable | Unpatched critical/high CVEs |
| Permission scope | Minimal (only needed scopes) | Some extra permissions required | Demands admin/broad access |
| Data flow transparency | Clear where data goes | Some telemetry, documented | Opaque tracking/telemetry |
If this technology/company disappeared tomorrow, what's the migration cost?
| Tier | Survival Risk | Examples |
|---|---|---|
| Open standards | Lowest | HTML, CSS, SQL, HTTP, WebSocket |
| Big-corp-backed open source | Low | React (Meta), TypeScript (Microsoft), Go (Google) |
| Mature community-driven open source | Medium-low | Astro, Tailwind CSS, PostgreSQL, Linux |
| Mature commercial services | Medium | Stripe, AWS, Cloudflare, GitHub |
| Startup services | High | Pre-Series B, < 3 years old, single product |
| Personal/abandoned projects | Highest | Last commit > 1 year, maintainer vanished |
Startup service extra checklist:
[ ] Company older than 3 years?
[ ] Profitable or Series B+ funding?
[ ] Viable alternatives exist? (acceptable migration cost?)
[ ] Core functionality replaceable with open-source self-hosted?
[ ] Data export straightforward? (no lock-in?)
If 3+ items are "No" — mark as high risk, must include an exit plan.
Assume this decision has failed spectacularly in 6 months. What went wrong?
Focus on the top 2-3 contenders:
Format:
Pre-Mortem for [Option X]:
1. [failure mode] — likelihood: [likely/possible/unlikely] | blast radius: [minor/major/critical]
2. [failure mode] — likelihood: [likely/possible/unlikely] | blast radius: [minor/major/critical]
3. [failure mode] — likelihood: [likely/possible/unlikely] | blast radius: [minor/major/critical]
Based on lowest long-term total cost, give a recommendation:
Recommendation: Option X
Reason: [one sentence]
Biggest risk: [the single largest risk]
Exit plan: [what to do if migration is needed]
Migration cost: [hours / days / weeks / full rewrite]
| Pitfall | Correct Thinking |
|---|---|
| "This one is easier" | AI makes implementation difficulty roughly equal — difficulty should not be a deciding factor |
| "Use this for now, switch later" | Calculate the real cost of "switching later" — usually 3-5x higher than estimated |
| "Everyone uses it" | Popularity != stability — check actual maintenance status |
| "It's free" | What's the business model of the free service? Are you the product or the customer? |
| "Most features" | More features = larger attack surface + more deps + harder upgrades — only pick what you need |
| "It's the newest" | New != good — check if it's stable (v1.0+ / GA / production-ready) |
| "AI recommended it" | AI training data has a recency bias — verify current status, not just what was popular during training |
npx claudepluginhub bouob/claude-plugins --plugin coding-skillsGuides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.