Source Inventory

Maintain sources/supported-stores.json — the single source of truth for which upstream plugin repos the Mall scans.

The Mall does NOT keep persistent local clones of source repos. The weekly cron clones each registered source into a workflow temp directory ($SOURCES_DIR), scans it, scores it, and discards the clone. The registry file is the only persistent record.

When to Use

• Proposing a new source store (run store-evaluation first)
• Retiring a source store (run staleness-discipline first; use /prune-source)
• A weekly cron PR flags a source as unhealthy (broken remote, archived, license drift)
• Schema validation after editing supported-stores.json

The registry: sources/supported-stores.json

{
  "$schema": "./supported-stores.schema.json",
  "schema_version": "2.0",
  "stores": [
    {
      "name": "plugin-mall",                       // unique kebab-case; matches catalog/stores/<name>.json
      "remote": "https://github.com/<org>/<repo>", // upstream URL (informational; not cloned for plugin-mall)
      "pluginDir": "plugins",                      // where plugins live in the upstream repo
      "quality": "first-party",                    // tier tag — see § Quality tiers
      "provenance": true,                          // true ONLY for plugin-mall (drives +50 trust signal)
      "license": "PolyForm-Noncommercial-1.0.0",   // SPDX id, or null if unknown
      "added_at": "2026-05-29"
    },
    {
      "name": "awesome-copilot",
      "remote": "https://github.com/github/awesome-copilot",
      "pluginDir": "skills",
      "quality": "official",
      "provenance": false,
      "license": "MIT",
      "added_at": "2026-04-15"
    }
  ]
}

Required fields

Optional fields

Quality tiers

The quality tier is informational — it does NOT directly affect the trust score. Trust is computed from the six published signals (provenance, maintenance, adoption, license, frontmatter, README). Quality tier helps reviewers triage; the signals do the scoring.

Adding a new source

Use the /add-source prompt. Sequence:

1. Run store-evaluation first (scorecard ≥ 7 required)
2. Determine name, pluginDir, quality, license
3. Add the entry to supported-stores.json (alphabetical by name)
4. Run node scripts/scan-sources.cjs locally with SOURCES_DIR pointing at a temp dir
5. Verify the new store produces a plausible catalog/stores/<name>.json
6. Commit [behaviour] add source: <name> and let Monday's cron produce the first full catalog refresh

Retiring a source

Use the /prune-source prompt. Sequence:

1. Run staleness-discipline to confirm a staleness signal fires
2. Add a // pruned-pending: YYYY-MM-DD reason: <reason> line above the entry and comment the entry out
3. Commit [behaviour] prune source (pending): <name>
4. Wait one weekly cron cycle to verify the catalog refresh PR shows the expected removal cleanly
5. Delete the commented-out entry in the next commit
6. Commit [behaviour] prune source (delete): <name>

Health checks (run during PR review)

When reviewing a weekly catalog-refresh PR, sanity-check each store:

Anti-Patterns

Falsifiability

This skill is wrong if any of the following occur by 2026-08-29 (90 days):

• A registry entry that passed /add-source review gets pruned within 30 days (scorecard bar too lax)
• A pruned store gets re-added within 30 days (staleness signals miscalibrated)
• The schema lets through an invalid entry that breaks the workflow ≥1 time
• The quality-tier taxonomy needs revision ≥2 times in a quarter (taxonomy is wrong shape)

Track outcomes in docs/curation-log.md tagged [SOURCE-INVENTORY].

Related

• store-evaluation — gate before adding
• staleness-discipline — gate before pruning
• mall-self-curation — the pipeline this registry feeds
• /add-source prompt
• /prune-source prompt
• sources/supported-stores.schema.json — JSON schema