review-debt
Skill23 starsChanged 51 days agoMITView on GitHub
Internal tech-debt transform pass of the agentic-workflow review pack — composed in-turn by review-change and product-audit; not a menu entry. Transforms the synthesized findings table into explicit debt items, each with a re-trigger condition; it does not rescan the diff. Findings only; never edits code.
In this repository30 other files it gives its agents.
- AGENTS.mdAGENTS.md
- template/AGENTS.mdAGENTS.md
- audit-docsSkill
- audit-prSkill
- batch-schedulerSkill
- discover-repository-stateSkill
- execute-phaseSkill
- fold-findingsSkill
- init-workspaceSkill
- log-sessionSkill
- orchestration-envelopeSkill
- phase-contractSkill
- pre-execution-reviewSkill
- product-auditSkill
- resolve-repository-stateSkill
- review-a11ySkill
- review-brandSkill
- review-changeSkill
- review-codeSkill
- review-designSkill
- review-implementationSkill
- review-perfSkill
- review-securitySkill
- review-seoSkill
- review-verifySkill
- skill-lintSkill
- triage-issueSkill
- unit-laneSkill
- verification-contractSkill
- workflow-statusSkill
The file
We split this skill into the rules it gives an agent
2 rules. About 0 are common, 1 is distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 79
Every debt-shaped row of the synthesized table was transformed with evidence (file:line) or explicitly marked n/a with the reason.
- Distinctive: line 81
Every debt item carries a trigger.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Review Tech Debt (internal)
Composed by review-change / product-audit within their conversation — on any
agent, follow this file inline as the routed step. Findings only; never edits,
never refactors.
Scope
The caller's synthesized findings table (the fused, classified decision
table). This pass does not rescan the diff: debt-shaped findings are already
in the table, and every ownership decision already happened in the finder axes
(review-code, review-verify, …). State the scope — the change the table was
synthesized over — at the top of the returned table.
Transform (evaluate EVERY row — none is optional; n/a must be stated)
Turn the table's tech-debt-shaped rows (TODO/FIXME/HACK, duplication, stale or orphaned abstractions, dead code, complexity hotspots, missing tests, workarounds pinned to upstream fixes) into explicit, payable debt items:
✓ Restate each debt-shaped finding at file:line with what it defers
✓ Attribute it to the axis already recorded in the table — never re-litigate ownership
✓ Confirm every debt item carries a TRIGGER: the condition under which it must be
paid (e.g. "3rd consumer appears", ">100k rows") — a debt item without a
trigger is itself a finding. Scheduled deletions carry their trigger as the
removal condition (S8: review-debt items become scheduled deletions whose
TRIGGER names the removal — executable by a fold batch, not archival prose).
✓ Verify no current-unit debt was mislabeled non-blocking: current-unit work
cannot be postpone/tradeoff/wontfix — a table showing one is flagged back
to the classifier, never reclassified here
✓ Honor the dead-code exception: staged/planned code cross-checked against the
roadmap/SPEC/TASKS is not dead code — mark verify when unsure, never assert
✓ Deletion route. A debt item that proposes removal of a surface carries
route: fix-now (delete), not route: fix-now (repair). The TRIGGER
specifies what proves the surface is safe to remove (e.g. "no consumer in
grep <scope> returns >0").
Return exactly
Sev and Impact are the two published closed sets (BLOCKER | CRITICAL |
WARNING | SUGGESTION and blocking | docs-only | report-only); their meanings
are owned by review-implementation (CLASSIFY.md §Severity ladder) — assign a
token, never a prose grade.
REVIEW TECH DEBT — scope: <scope>
| # | Finding | Sev | Impact | Evidence | Suggested fix |
|---|---------|-----|--------|----------|---------------|
| 1 | <what> | BLOCKER|CRITICAL|WARNING|SUGGESTION | blocking|docs-only|report-only | <file:line> | <trigger + smallest action> |
Rows: <n> transformed, <n> with trigger, <n> findings, <n> n/a (<which + why>)
Summary: <1-2 sentences>
Decision: PASS | FAILFor this pass, the Suggested fix column carries the TRIGGER — the condition under which the debt must be paid — alongside the smallest action.
FAIL if any BLOCKER, CRITICAL or WARNING finding is open; PASS otherwise.
SUGGESTION findings never block — they surface in the caller's report as debt notes.
Done when
- Every debt-shaped row of the synthesized table was transformed with evidence
(
file:line) or explicitly marked n/a with the reason. - Every debt item carries a trigger; no current-unit debt was mislabeled.
- The fixed-format block above is returned — nothing more, nothing less — and no code was changed.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

