メニュー
Measure, prioritize, and address technical debt. Classify debt by impact and effort. Build paydown roadmap. Use when evaluating system health or planning refactoring.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Identify and avoid common architectural mistakes. Recognize patterns of failure. Use when reviewing designs or learning from mistakes.
Practice architectural design with structured problems. Time-limited design challenges. Use for skill development, interviews, team exercises.
Reference catalog of proven architecture patterns. Know when to apply each pattern, tradeoffs, and examples. Use as reference when designing systems.
Lead effective architecture reviews. Manage discussions, surface disagreements, build consensus, document decisions. Use when conducting reviews or running architecture forums.
Prepare for architecture interview questions and scenarios. Practice system design, tradeoff discussions, communication. Use for career development and interview readiness.
Conduct comprehensive system architecture evaluation. Assess design quality, technical debt, operational readiness, scalability. Use when auditing existing systems.
| name | tech-debt-assessment |
| description | Measure, prioritize, and address technical debt. Classify debt by impact and effort. Build paydown roadmap. Use when evaluating system health or planning refactoring. |
Systematically measure technical debt, prioritize paydown, and track progress.
You are assessing technical debt in the system. Quantify impact (velocity reduction, risk increase), estimate effort to fix, prioritize based on ROI. Read code, metrics, team feedback.
Based on technical debt frameworks (Steve McConnell, Martin Fowler):
Catalog Debt Items: Interview team: "What slows us down?" Common themes: hard-to-test code, tangled dependencies, missing documentation, outdated libraries.
Quantify Impact: For each debt item, how much does it slow velocity? Example: "Test coverage < 30% makes refactoring 3x slower". Measure days/quarter lost to debt.
Estimate Paydown Effort: How long to fix? Refactor module: 2 weeks. Rewrite component: 1 month. Replace library: 3 days. Be realistic; add 50% buffer.
Calculate ROI: Paydown cost vs interest savings. Refactor for 2 weeks (80 hours) to save 5 hours/quarter in reduced bugs and faster changes. Payoff: ~16 quarters (4 years).
Prioritize: High impact + low effort = do first. High impact + high effort = plan for next quarter. Low impact = defer or accept. Build paydown roadmap: 20% of sprint capacity for debt.
