Conciseness

The body is dense with project-specific, non-obvious knowledge (no explanations of concepts Claude already knows), but the core deletion-not-archive rationale is repeated five times (intro paragraph, Rule 1, Mindset bullet 1, Anti-Pattern 1, Scripts note) and the 2026-07-31 audit date appears in three sections. Anchor 3 fits: mostly efficient but could be tightened; not 4 because the repetition goes beyond minor instances.

Actionability

Concrete guidance throughout: exact file paths, specific row-derivation steps ('the new row's # is that value + 1'), the exact command 'scripts/validate-tech-debt-schema.sh', and a concrete troubleshooting table. Mostly executable with minor gaps: no inline worked-example row (delegated to references/area-taxonomy-and-row-schema.md and the template), which keeps it below anchor 5.

Workflow Clarity

Both workflows are numbered with explicit validation ('Run scripts/validate-tech-debt-schema.sh before committing (the pre-commit hook runs it too...)') and due-diligence checkpoints before the destructive delete step ('Confirm the fix didn't reveal a real cost or risk'), plus error-recovery guidance for bounced commits. The destructive-operation cap does not apply: validation checkpoints are present.

Progressive Disclosure

References are one level deep, well signaled ('RECOMMENDED reading before filing or resolving a row: see [Area Taxonomy and Row Schema](references/area-taxonomy-and-row-schema.md)'), backed by a When-to-Use table, and every referenced path (references/area-taxonomy-and-row-schema.md, assets/templates/tech-debt-row-template.yaml, assets/schemas/tech-debt-row.schema.json, scripts/validate-tech-debt-schema.sh) exists. Anchor 4 rather than 5: the ~180-line body retains some content (repeated rationale, the relationship-to-risk-register discussion) that could be consolidated, a minor organization gap.

Specificity

Concrete actions are present via the when-clauses ('a lint/format/style violation slips past an existing gate', 'a filed item is fixed and needs removing') and boundary scoping, but the headline verb 'Maintain docs/TECH_DEBT.md' is itself generic. It sits above anchor 3 (only 1-2 concrete actions) because multiple specific operations are covered, but below anchor 5 (comprehensive list of concrete actions).

Completeness

Explicitly answers what ("the living list of code-level cleanup that isn't a risk, a shortcut, or an open decision") and when ("Use when a lint/format/style violation slips past an existing gate, a small known cleanup is noticed..., or a filed item is fixed and needs removing"), plus explicit DO-NOT-USE exclusions with concrete trigger phrases. Matches the anchor-5 example structure exactly.

Trigger Term Quality

A dedicated trigger list of natural user phrasings with synonyms: "'add to tech debt', 'log this as cleanup', 'track this lint violation', 'mark tech-debt item #N fixed', 'what's on the tech debt list". These are phrases a user would naturally say, covering add, track, resolve, and query. Not below 5: no common variation is obviously missing for this domain; file extensions don't apply to a doc-maintenance skill.

Distinctiveness Conflict Risk

Clear niche with explicit disambiguation: "that's the risk-register skill's job", "that's ROADMAP.md's job", "use risk-register instead", "already lifecycle-managed in .aislop/baseline.json". Triggers ('add to tech debt', 'track this lint violation') are distinct from the neighboring skills' vocabulary, so mis-trigger risk is minimal.