メニュー
Quantifies exact trade-offs when switching between architecture options
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/navraj007in/architecture-cowork-plugin --skill tradeoff-analysisコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
Identifies missing prerequisites (blockers) for each /architect: command based on _state.json field requirements
Tracks actual infrastructure costs against estimated costs and alerts when spend drifts from projection
Defines when and how commands must log architecture decisions to _state.json decisions[] for auditability
SKILL.md を表示中
SOC 職業分類に基づく
| name | tradeoff-analysis |
| description | Quantifies exact trade-offs when switching between architecture options |
Quantifies exact trade-offs when switching between architecture options. Shows users precisely what they gain and lose when choosing Option A over Option B.
Use this skill to help users decide between options by showing:
Provide two architecture options:
{
"option_a": {
"name": "baseline",
"cost_monthly": 4200,
"latency_p99_ms": 300,
"complexity_score": 6,
"team_ramp_weeks"
A trade-off comparison matrix:
{
"option_a": "baseline",
"option_b": "performance-optimized",
"trade_offs": [
{
"dimension": "cost_monthly",
"option_a_value": 4200,
"option_b_value": 8500,
"difference": 4300,
"percent_change": "+102%",
"winner": "option_a (cheaper)",
"interpretation": "Option B costs 2× more per month ($102k/year extra)"
},
{
"dimension": "latency_p99_ms",
"option_a_value": 300,
"option_b_value": 50,
"difference": -250,
"percent_change": "-83%",
"winner": "option_b (faster)",
"interpretation": "Option B is 6× faster (300ms → 50ms). Noticeable for user experience."
},
{
"dimension": "complexity_score",
"option_a_value": 6,
"option_b_value": 8,
"difference": 2,
"percent_change": "+33%",
"winner": "option_a (simpler)",
"interpretation": "Option B is significantly more complex (Kubernetes, caching layers, multi-region)"
},
{
"dimension": "team_ramp_weeks",
"option_a_value": 3,
"option_b_value": 5,
"difference": 2,
"percent_change": "+67%",
"winner": "option_a (faster)",
"interpretation": "Option B takes 2 extra weeks for team to ramp up on complex stack"
},
{
"dimension": "ops_burden_hrs_per_week",
"option_a_value": 4,
"option_b_value": 8,
"difference": 4,
"percent_change": "+100%",
"winner": "option_a (less work)",
"interpretation": "Option B doubles ops burden (4 hrs/week vs. 8 hrs/week for small team)"
},
{
"dimension": "max_dau",
"option_a_value": 100000,
"option_b_value": 1000000,
"difference": 900000,
"percent_change": "+900%",
"winner": "option_b (scales further)",
"interpretation": "Option B scales to 10× more users (100k → 1M). Option A hits limits sooner."
}
],
"decision_matrix": {
"choose_option_a_if": [
"Budget is primary constraint",
"Expected DAU < 100k",
"Latency < 300ms acceptable",
"Team small and inexperienced",
"Want to launch fastest"
],
"choose_option_b_if": [
"Performance is critical",
"Expect scale (100k+ DAU)",
"Can afford 2× cost",
"Team experienced with Kubernetes",
"Long-term growth > short-term speed"
]
},
"breakeven_analysis": {
"cost": "Never breaks even (B is always 2× more expensive)",
"performance": "If you need <100ms latency, B pays for itself (performance critical)",
"team_productivity": "After month 3, B team more productive (complex stack becomes easier). ROI: 6-12 months"
}
}
Comparison:
When it matters:
When it doesn't matter:
Comparison:
When it matters:
When it doesn't matter:
What increases complexity:
Impact:
Complexity 3-5: Junior engineers comfortable, 1-2 week ramp
Complexity 5-7: Mid-level engineers needed, 2-4 week ramp
Complexity 7-9: Senior/principal engineers needed, 4-8 week ramp
Complexity 9-10: Very specialized (requires hiring expert)
When it matters:
Components:
Typical paths:
Simple stack (Vercel + managed DB): 1-2 weeks
Standard stack (Node + PostgreSQL): 2-3 weeks
Moderate complexity (Kubernetes): 4-5 weeks
High complexity (custom infrastructure): 6-8 weeks
When it matters:
What requires ops work:
By stack:
Fully managed (Vercel + Firebase): 1-2 hrs/week
Managed services (Railway + Neon): 2-4 hrs/week
Self-hosted with containers: 4-8 hrs/week
Full infrastructure (Kubernetes): 8-16 hrs/week
When it matters:
Definitions:
Typical limits:
Baseline option: 100k DAU (then add read replicas or caching)
Performance option: 1M+ DAU (multi-region, advanced caching)
Enterprise option: 10M+ DAU (sharded, specialized databases)
When it matters:
When it doesn't matter:
If latency is critical (real-time, e-commerce): YES
→ performance matters more than cost
If latency is nice-to-have (content, reporting): NO
→ cost is better use of money
If you're unsure: Start with cheaper, upgrade if customers complain
→ latency complaints usually visible in metrics/reviews
If you have dedicated ops/DevOps: YES
→ they can handle complex stack
If ops shared among engineers: NO
→ ops burden steals feature development time
If you can hire ops person: MAYBE
→ adds $100k+ headcount cost (calculate ROI)
If you're unsure: Start simple, hire ops person if needed
→ ops burden grows over time anyway
If growth guaranteed (pre-sold, series A funded): YES
→ build for scale from start, cheaper than rearchitect
If growth uncertain (early MVP): NO
→ start simple, rearchitect when you hit limits
→ simpler architecture also easier to pivot
If rearchitecting easy (good abstractions, tests): MAYBE
→ depends on your codebase quality
Gains:
Loses:
ROI: Saves $2,100 initially, but costs $50k in rearchitecting if you scale
Gains:
Loses:
ROI: Costs $51k/year, but enables $500k+ customers (breaks even at 1-2 enterprise customers)
Cost-Optimized:
- $2,100/mo
- 4-week launch
- Limited scale (10k DAU)
- Junior-friendly
Baseline:
- $4,200/mo
- 8-week launch
- Can scale to 100k DAU
- Worth it if you expect growth
Decision: Cost-Optimized for MVP (prove market fit)
→ If customers come, rearchitect to Baseline (6-week rearchitect cost acceptable)
Baseline:
- $4,200/mo
- Can serve startups (SMB market)
- Cannot serve enterprises (no redundancy, no SLAs)
- Limited growth past $1M ARR
Enterprise:
- $12,000/mo
- Can serve enterprises ($100k+ contracts)
- Premium positioning
- Can grow to $10M+ ARR
Decision: Choose based on target market
- SMB only? → Baseline
- Enterprise customers? → Enterprise (higher LTV justifies higher cost)
Baseline (300ms latency):
- $4,200/mo
- Playable but not competitive
- Users notice delay in real-time games
- Will lose to competitors with lower latency
Performance-Optimized (50ms latency):
- $8,500/mo
- Competitive latency
- Professional esports viable
- Users will choose this over competitors
Decision: Performance mandatory (game is unplayable with 300ms)
→ The $4,300/mo difference is non-negotiable
For each dimension (cost, speed, scale, complexity, ops, risk):
1. Rate importance: CRITICAL | HIGH | MEDIUM | LOW | IRRELEVANT
2. Identify winner: Option A or Option B
3. Quantify gap: 10% | 50% | 100% | 10×
If CRITICAL dimension:
→ Choose option that wins that dimension (all else secondary)
If HIGH dimension and gap is 10× or 100%:
→ Still heavily weight winner
If HIGH dimension and gap is 10-50%:
→ Acceptable trade-off, weigh against other dimensions
If MEDIUM/LOW dimension:
→ Can ignore or use as tiebreaker
Example:
Cost (CRITICAL): A wins by 50%
Latency (HIGH): B wins by 6×
Complexity (MEDIUM): A wins by 33%
→ Choose A: cost critical and A wins there
(latency not critical enough to justify 2× cost)
/architect:blueprint-variants// When showing 4 options, analyze trade-offs:
For each pair of adjacent options:
- Generate trade-off analysis
- Show in "trade-offs" section
- Help user understand cost of upgrading
/architect:cost-estimate// When user asks "can we go cheaper?"
- Find cost-optimized option
- Show cost difference
- Show what scales/ops/quality they lose
- Help them decide if worth it
/architect:trade-offs/architect:trade-offs --option1 baseline --option2 performance
→ Detailed trade-off analysis between two specific options
constraint-solver/ — helps pick option that fits constraintsblueprint-variants/ — generates options to comparecost-optimizer/ — helps reduce costs while maintaining quality