メニュー
Agents should invoke this skill when identifying, categorizing, prioritizing, or planning technical debt work, debt sprints, cleanup backlogs, TODO consolidation, or long-term maintainability risks. Tracks debt with severity/effort.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Creates polished self-contained HTML explanation reports for complex, multi-step topics using overview tables, evidence cards, adaptive graphs or diagrams, meaningful SVG/media, and accessible tabs for long pages. Use when the user requests a browser-readable diagnostic report, technical guide, decision analysis, implementation plan, investigation, or research synthesis as HTML.
Agents should invoke this skill to create, migrate, inspect, apply, verify, or roll back versioned PATCH.md v2 lifecycle packages with machine-readable manifests, deterministic plans, drift detection, and transactional safety.
Safely inspect, search, render, edit, diff, validate, and commit Microsoft Word DOCX files with the dedicated docx_* tools. Use for DOCX/DOTX/DOCM/DOTM document work; enforces dry-run-first edits, active-content refusal, preservation checks, and save-as by default.
Agents should invoke this skill for high-stakes or complex research needing multi-source evidence, scientific/technical fact-checking, decision traces, or rigorous verification. Runs deterministic two-phase research with schema/policy validation.
Use when inspecting, reading, rendering, editing, formatting, diffing, or validating local .xlsx and .xlsm Excel workbooks. Provides fail-closed workbook tools with dry-run planning, SHA-256 conflict protection, PNG previews, and byte-identity checks for VBA and other protected OOXML parts. Do not use for CSV-only work or for executing/editing VBA.
Reference for writing and editing skills well — the vocabulary and principles that make a skill predictable.
| name | tech-debt-tracker |
| description | Agents should invoke this skill when identifying, categorizing, prioritizing, or planning technical debt work, debt sprints, cleanup backlogs, TODO consolidation, or long-term maintainability risks. Tracks debt with severity/effort. |
Systematic tracking and management of technical debt. Debt is not inherently bad — it's a trade-off. The problem is untracked debt that compounds silently.
When debt is identified (during reviews, development, or ad-hoc):
MEMORY.md| Category | Description | Examples |
|---|---|---|
| Architecture | Structural issues that affect the whole system | Missing module boundaries, circular dependencies, wrong abstraction level |
| Code | Local code quality issues | Code smells, duplicated logic, overly complex functions, dead code |
| Test | Missing or inadequate test coverage | No tests for critical paths, brittle tests, missing edge case coverage |
| Documentation | Missing or outdated documentation | Undocumented public APIs, stale README, missing architecture docs |
| Dependency | Outdated or problematic dependencies | Deprecated libraries, unpatched CVEs, abandoned packages, version conflicts |
| Severity | Meaning | Impact |
|---|---|---|
| Critical | Blocks progress or causes recurring incidents | Developers work around it daily, causes bugs |
| High | Causes ongoing friction and slows development | Every feature touching this area takes longer |
| Medium | Noticeable but manageable | Annoyance, not a blocker. Occasional confusion. |
| Low | Cosmetic or minor | Cleanup opportunity, no functional impact |
| Effort | Time | Scope |
|---|---|---|
| S | < 1 hour | Single function or file change |
| M | 1-4 hours | Multiple files, focused refactoring |
| L | 4-16 hours | Cross-module changes, possible API updates |
| XL | > 16 hours | Major restructuring, migration, or rewrite |
Use severity + effort to determine action:
| Effort S | Effort M | Effort L | Effort XL | |
|---|---|---|---|---|
| Critical | Fix immediately | Fix this sprint | Plan and schedule | Plan, break into phases |
| High | Fix now (quick win) | Fix this sprint | Schedule within 2 weeks | Plan, break into phases |
| Medium | Fix when nearby | Schedule within 2 weeks | Backlog | Backlog (consider living with it) |
| Low | Fix if touching the file | Backlog | Backlog | Accept the debt |
Quick wins (High severity + S effort, or Critical + S/M effort) should be fixed as soon as possible — they deliver the most value per hour of investment.
When adding to the registry in MEMORY.md:
| Field | Description |
|---|---|
| ID | Incremental number (DEBT-001, DEBT-002, ...) |
| Project | Which project/codebase |
| Category | Architecture / Code / Test / Documentation / Dependency |
| Description | What the debt is and why it matters |
| Severity | Critical / High / Medium / Low |
| Effort | S / M / L / XL |
| Status | Open / In Progress / Resolved / Accepted |
| Discovered | Date the debt was identified |
| Resolved | Date it was fixed (if applicable) |
Example entry:
| ID | Project | Category | Description | Severity | Effort | Status | Discovered |
|---|---|---|---|---|---|---|---|
| DEBT-001 | tui-setup | Code | app.rs has cyclomatic complexity 32 in handle_event — needs decomposition | High | M | Open | 2026-02-14 |
| DEBT-002 | tui-setup | Test | No unit tests for parser module — refactoring is risky | High | L | Open | 2026-02-14 |
When asked for a debt status report:
## Tech Debt Summary: [Project]
**Date:** YYYY-MM-DD
**Total items:** N (C critical, H high, M medium, L low)
### Quick Wins Available
[S-effort items with High+ severity — easy fixes with big impact]
| ID | Description | Effort |
|---|---|---|
| DEBT-003 | ... | S |
### Top Priority Items
[Highest severity items regardless of effort]
| ID | Description | Severity | Effort |
|---|---|---|---|
| DEBT-001 | ... | Critical | M |
### Trend
[Is debt growing, shrinking, or stable? Any concerning patterns?]
### Recommendations
1. [Prioritized actions]
MEMORY.md (Tech Debt Registry section)Arc skill — Technical debt tracking and management