메뉴
Detect, classify, and prune stale source stores in the Mall — define what stale means and how to remove gracefully without breaking downstream consumers.
How the Plugin Mall scans, scores, and prunes itself. The Mall is a self-curating repo; this skill is its operational playbook for the weekly catalog refresh and trust scoring. Use when working on the scan pipeline, debugging a stuck weekly PR, or onboarding to Mall internals.
Consolidate session learning into permanent architecture — extract patterns into skills, instructions, prompts, or memory
Maintain the source registry in sources/supported-stores.json — add a new third-party plugin store, retire one, refresh metadata, validate the schema. Use when proposing a registry change, after the weekly cron flags a source as unhealthy, or when a candidate store needs evaluation before adding.
Evaluate a proposed store for inclusion in Alex_ACT_Plugin_Mall using a quality scorecard
Comprehensive brain file review — external freshness, internal consistency, semantic accuracy — stamp only after full assessment
This skill should be used when building agent evaluation systems: deterministic checks, regression suites, multi-dimensional rubrics, quality gates, production monitoring, baseline comparison, and outcome measurement for agent pipelines.
| name | staleness-discipline |
| description | Detect, classify, and prune stale source stores in the Mall — define what stale means and how to remove gracefully without breaking downstream consumers. |
| lastReviewed | "2026-05-29T00:00:00.000Z" |
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.
/prune-source invocationAn 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 |
| 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 is always reversible by re-add. The two-step removal (comment-out → observe → delete) is the safety net. Run via /prune-source.
sources/supported-stores.json and add // pruned-pending: YYYY-MM-DD reason: <reason> above it[behaviour] prune source (pending): <name> — <reason>catalog/stores/catalog/index.json[behaviour] prune source (delete): <name>docs/curation-log.mdIf a pruned store revives (un-archived, link restored, license clarified):
/add-sourcedocs/curation-log.md| 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 |
**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">
This skill is wrong if any of the following occur by 2026-08-29 (90 days):
Track outcomes in docs/curation-log.md tagged [STALENESS].
/prune-source prompt