/skill-prune

name: skill-prune
description: Identify and remove negative-ROI skill content — orphan files, never-read entries, duplicates, content reintroducing challenge-specific lore. Inverse of /skill-update. Use during quarterly maintenance or after the linter flags issues.

Skill Prune

Inverse of `/skill-update`. Removes content rather than adding it. Run during quarterly maintenance, after engagements, or when `scripts/skill_linter.py` reports orphans / duplicates.

When to invoke

• Quarterly cadence.
• After `scripts/skill_linter.py --check-orphans` reports orphan reference files.
• After a SKILL.md or reference file grows past its cap and needs trimming.
• After a de-specialization sweep, to drop content tied to retired challenges.

Prune criteria (the four signals — same shape as /skill-update, inverted)

A reference / scenario / line is a **prune candidate** when it satisfies any of:

1. **Orphan** — not linked from any SKILL.md or other reference file in the last 60 days. 2. **Referenced only by failed engagements** — appeared in `attack-chain.md` of runs that ended `status=BLOCKED`, never in a successful chain. 3. **Contradicted by newer content** — a later scenario / pattern supersedes it; the older entry no longer reflects current technique. 4. **Redundant with newer content** — same technique covered more clearly elsewhere.

Removing content fails any of these → keep it.

Safety rules

• **Never** prune a file with `<!-- KEEP: <reason> -->` annotation.
• **Never** prune content cited in a still-open engagement's `OUTPUT_DIR/attack-chain.md`.
• **Never** prune the canonical-home file for a single-owner rule (brute-force, output-discipline, env-reader, skill-update).
• Bias toward keeping technique-rich content over operational lore.

Procedure

1. Run `scripts/skill_linter.py --check-orphans` to surface orphans. 2. For each candidate file or block, evaluate the four signals. 3. Build a deletion plan — show files / lines to remove with one-line rationale per item. 4. Apply deletions only after the plan is approved (skill-prune does not auto-delete during invocation). 5. Re-run `scripts/skill_linter.py` to confirm the change broke no other links and didn't reintroduce duplicates.

Output

Concise change report:

• **Removed.** File or block + one-line rationale per item.
• **Kept (flagged for follow-up).** Items that failed all four signals but are worth revisiting next quarter.
• **No prunes.** State explicitly when nothing warranted removal.

Anti-Patterns

• Pruning content because it's old — age alone is not a signal; relevance is.
• Pruning a reference because its parent SKILL.md is bloated — fix the SKILL.md instead.
• Removing a single-owner canonical file (brute-force / output-discipline / env-reader).
• Pruning during an active engagement that may still cite the content.