staleness-discipline
Skill5 starsChanged 4 months agoMITView on GitHub
Detect, classify, and prune stale source stores in the Mall — define what stale means and how to remove gracefully without breaking downstream consumers.
In this repository6 other files it gives its agents.
- .github/copilot-instructions.mdCopilot instructions
- currency-auditSkill
- mall-self-curationSkill
- meditationSkill
- source-inventorySkill
- store-evaluationSkill
The file
We split this skill into the rules it gives an agent
6 rules. About 0 are common, 4 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 51
Wait one weekly cron cycle and verify the catalog-refresh PR shows:
- Distinctive: line 54
No other unintended diffs
- Very specific: line 55
After a clean cycle, delete the commented-out entry and commit [behaviour] prune source (delete): <name>
- Distinctive: line 60
If a pruned store revives (un-archived, link restored, license clarified):
- Distinctive: line 62
Run full store-evaluation — past acceptance does not transfer
- Very specific: line 63
If it passes, add a fresh entry via /add-source
≈ “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
Staleness Discipline
Define what "stale" means for a source store in the Mall, and how to remove an entry from sources/supported-stores.json without breaking downstream consumers.
The Mall is read-mostly: downstream agents install from upstream at pinned refs. Pruning a source from the registry stops new catalog entries from that source but does not retroactively break existing installs (those still resolve to their pinned SHA). The discipline below keeps the catalog honest.
When to Use
- Weekly catalog-refresh PR shows a store with degraded signals (no recent commits, broken license signal, archived upstream)
- A reviewer flags a store as no longer fit during PR review
/prune-sourceinvocation
What "stale" means
An entry is stale if any of these apply:
| Signal | Threshold | Where it shows up |
| Remote unreachable | bootstrap-sources.cjs clone fails in 2+ consecutive cron runs | Workflow log |
| Upstream archived | fetch-github-stats.cjs returns archived: true | scoring/github-stats.json |
| No upstream activity | last_commit older than 18 months | scoring/github-stats.json + maintenance signal = 0 |
| License changed unfavorably | SPDX id changed to NOASSERTION or to a more restrictive license | scoring/github-stats.json license field |
| Replaced by superior alternative | Another source covers the same domain better with higher trust scores | Per-store trust delta in scoring/trust-audit.md |
| Persistent scan failure | scan-sources.cjs produces 0 plugins for 2+ consecutive runs after previously producing >0 | catalog/stores/<name>.json plugins array shrinks to 0 |
| Schema or shape drift | normalize-frontmatter.cjs warns or errors on >50% of plugins from that source | Normalize log |
Classification
| Stale signal | Action |
| Remote unreachable, but upstream still alive on GitHub | Refresh — fix remote URL, don't prune |
| Upstream archived but plugins still valuable | Keep (note archived in PR review); catalog continues to surface them with degraded maintenance score |
| Upstream archived + no activity for years | Prune |
| License changed to unclear or restrictive | Surface in PR review; user decides whether to keep with degraded license signal or prune |
| Replaced by superior alternative | Prune the worse entry; downstream consumers can opt into the better one via --from-store override |
| Persistent scan failure with no clear cause | Investigate pluginDir first — upstream may have renamed the folder. Only prune after fix attempts fail. |
Pruning procedure
Pruning is always reversible by re-add. The two-step removal (comment-out → observe → delete) is the safety net. Run via /prune-source.
- Confirm at least one staleness signal above fires
- Comment out the entry in
sources/supported-stores.jsonand add// pruned-pending: YYYY-MM-DD reason: <reason>above it - Commit
[behaviour] prune source (pending): <name> — <reason> - Wait one weekly cron cycle and verify the catalog-refresh PR shows:
- The store missing from
catalog/stores/ - Plugin count drops by the right amount in
catalog/index.json - No other unintended diffs
- The store missing from
- After a clean cycle, delete the commented-out entry and commit
[behaviour] prune source (delete): <name> - Record the decision in
docs/curation-log.md
Re-add procedure
If a pruned store revives (un-archived, link restored, license clarified):
- Run full store-evaluation — past acceptance does not transfer
- If it passes, add a fresh entry via
/add-source - Record the re-add in
docs/curation-log.md
Pruning anti-patterns
| Anti-pattern | Correction |
| Hard-deleting the entry in one commit | Always use the two-step (comment-out → observe → delete) so the catalog refresh PR can verify the impact cleanly |
| Skipping the observation cycle | Without one clean cron run, you don't know whether the catalog-refresh PR will surface only the expected diffs |
| Pruning multiple stores in one commit | Each prune is a decision; bundle wastes the audit trail and makes one bad prune undoable without reverting the others |
| Pruning for "I don't like the maintainer" or subjective reasons | The staleness signals are the bar; the commit message must cite the firing signal |
Pruning plugin-mall itself | Constitutional to this Mall — would break the catalog's ability to surface first-party plugins |
Output template (PR comment for a prune proposal)
**Prune candidate: `<store-name>`**
Staleness signals firing:
- [x] <signal 1>: <evidence from workflow log / github-stats / trust-audit>
- [ ] ...
Action: comment-out now, delete after one clean cron cycle.
Downstream impact: <known consumers, if any; otherwise "no known consumers; downstream agents that depend on this store can pin to a specific SHA before deletion">Falsifiability
This skill is wrong if any of the following occur by 2026-08-29 (90 days):
- Pruned stores are re-added within 30 days ≥2 times in a quarter (staleness signals miscalibrated — pruning prematurely)
- A store flagged as stale by these signals is still being actively used by a known downstream consumer (signals threshold too aggressive)
- The two-step procedure causes a registry-vs-catalog drift that ships ≥1 time (the reversible pattern is leaking)
Track outcomes in docs/curation-log.md tagged [STALENESS].
Related
- source-inventory — adding and editing registry entries
- store-evaluation — gate for re-add
- mall-self-curation — the pipeline this discipline keeps clean
- mall-maintenance-rules — always-on routing
/prune-sourceprompt
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.