skill-prune

Engineering Community

Repo stars 290
Author repo communitytools

Interpretation is structured for decision-making; original keeps the upstream SKILL.md unchanged.

Decide Fit First

Core job: Identify and remove negative-ROI skill content — orphan files, never-read entries, duplicates, content reintroducing challenge-s…
Best fit: Use it when the task has reusable inputs, steps, and validation criteria rather than a one-off answer.
Avoid forcing it: If the source lacks commands, platform support, or external-service evidence, keep those fields unknown instead of guessing.

Design Intent

Structure: The skill is organized around “When to invoke”, “Prune criteria (the four signals — same shape as /skill-update, inverted)”, “Safety rules”, “Procedure”, showing how the author expects the agent to judge fit, collect context, and produce verifiable output.
Trigger evidence: Prioritize the author’s wording around when to use it, what context to collect, and what output shape to produce.
Evidence boundary: Author text states facts, repository files prove commands and paths, and Fluxly only adds fit, limits, and usage judgment.

How To Use It

Inputs: Provide target material, scope, expected result, forbidden changes, and validation method.
Invocation: Name skill-prune directly; if the source includes slash commands, start with the command and then add task context.
Validation: Start small and check whether the result follows “When to invoke / Prune criteria (the four signals — same shape as /skill-update, inverted) / Safety rules” before expanding.

Boundaries And Review

Dependencies: It usually needs no extra API key, so start with a small validation task.
Permissions: Declared permissions include read / write; ask the agent to state file, command, and rollback boundaries before acting.
Quality bar: A useful result names the deliverable, evidence, and next action. Generic prose means the task needs tighter context.

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:

Orphan — not linked from any SKILL.md or other reference file in the last 60 days.
Referenced only by failed engagements — appeared in attack-chain.md of runs that ended status=BLOCKED, never in a successful chain.
Contradicted by newer content — a later scenario / pattern supersedes it; the older entry no longer reflects current technique.
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  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

Run scripts/skill_linter.py --check-orphans to surface orphans.
For each candidate file or block, evaluate the four signals.
Build a deletion plan — show files / lines to remove with one-line rationale per item.
Apply deletions only after the plan is approved (skill-prune does not auto-delete during invocation).
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.

Fluxly profile Author and license come from source; runtime, permissions, and network are Fluxly detections or estimates

Fluxly category: Engineering
Author-declared agents: No explicit declaration found; this is not inferred or tested compatibility
Static check: 88 / 100 · heuristic scan, not runtime safety proof
Author / version / license: @transilienceai · no license declared
Fluxly token estimate: Lean
Fluxly setup estimate: Plug-and-play
External API key: No requirement detected
Detected OS requirements: Unspecified
Runtime requirements: Unspecified
Detected file/system behavior: Read-only
Write / modify
Detected network behavior: Local-only
Install commands: None (reference only)

Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.

Heads up: 未限定 allowed-tools，默认拥有全部工具权限。

Output preview skill-prune.preview

The current SKILL.md does not define a fixed output example.

SKILL.md SKILL.md

# 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.

…

Evidence boundary and execution chain

Author text anchors workflow facts; Fluxly only indexes current sections, terms, files, and commands.

sections -> When to invoke → Prune criteria (the four signals — same shape as /skill-update, inverted) → Safety rules → Procedure → Output → Anti-Patterns
terms    -> prune candidate · Orphan · Referenced only by failed engagements · Contradicted by newer content · Redundant with newer content · Never · Removed. · Kept (flagged for follow-up).
files/cmd -> /skill-update · scripts/skilllinter.py · scripts/skilllinter.py --check-orphans · attack-chain.md · status=BLOCKED · <!-- KEEP: <reason> --> · OUTPUTDIR/attack-chain.md
body sha256 -> d9c8e676a64a