Menu
Comprehensive brain file review — external freshness, internal consistency, semantic accuracy — stamp only after full assessment
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.
Detect, classify, and prune stale source stores in the Mall — define what stale means and how to remove gracefully without breaking downstream consumers.
Evaluate a proposed store for inclusion in Alex_ACT_Plugin_Mall using a quality scorecard
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 | currency-audit |
| description | Comprehensive brain file review — external freshness, internal consistency, semantic accuracy — stamp only after full assessment |
| lastReviewed | "2026-05-26T00:00:00.000Z" |
Full assessment: external freshness + internal consistency + semantic accuracy. Stamp only when all pass.
brain-qa.cjs checks the date mechanically (the lastReviewed field). This skill defines the full review that earns that date. A re-stamp means both "content matches external reality" AND "content is internally consistent."
Every audit item must pass through critical thinking — not just mechanical verification. Apply these disciplines throughout:
| Discipline | Application to Currency Audit |
|---|---|
| Alternative hypotheses | "This API exists" isn't enough — is the usage correct? Could the documented pattern be outdated even if the API isn't? |
| Missing data | What's NOT in the file that should be? Missing caveats, undocumented prerequisites, absent error handling? |
| Evidence quality | Is the file's advice based on official docs, or a single blog post from 2021? |
| Self-report skepticism | "Best practice" claims — verified against what source? "Works on current versions" — actually tested? |
| Bias detection | Anchoring on the file's current content. Challenge: would you write this the same way from scratch today? |
| Falsifiability | What would prove this advice wrong? If nothing could, the claim may be unfalsifiable hand-waving |
| Materiality gate | If this item were stale, would it cause real harm? Prioritize fixes that affect decisions over cosmetic accuracy |
The key question at every checklist item: "Am I verifying this is correct, or am I assuming it's correct because it looks plausible?"
lastReviewed dates| Step | Action | Outcome |
|---|---|---|
| Triage | Run node scripts/brain-qa.cjs, read the stale-file output | Ordered work list |
| Research | Check latest docs, changelogs, releases for the file's domain | Delta list |
| Compare | Diff current content against latest practices | Stale advice identified |
| Audit | Check terminology, cross-references, claims, process logic | Internal consistency verified |
| Update | Fix stale content, wrong terms, broken references, contradictions | Full assessment complete |
| Stamp | Set lastReviewed: YYYY-MM-DD to today in frontmatter | Pass restored |
| Verify | Re-run brain-qa, confirm file passes | Clean output |
Run brain-qa and read the stale-file output:
node scripts/brain-qa.cjs
brain-qa surfaces files whose lastReviewed exceeds the 180/365-day thresholds (warn/fail). Work the failures first, then the warnings, oldest first.
Batch size: 10-15 files per session. Larger batches cause quality drift.
For each file, work through this checklist:
lastReviewed field exists and is a valid YYYY-MM-DD datedescription accurately reflects current content (not stale summary)applyTo patterns still match the intended activation scopetype, application, tier, currency, inheritance, lifecycle) — see scripts/brain-qa.cjs for the canonical drop listStamp only after ALL checklist sections pass — frontmatter, freshness, semantic consistency, and structural. A partial review does not earn a date stamp.
lastReviewed: YYYY-MM-DD in frontmatter to today's datedescription changed meaning, update itRe-run brain-qa to confirm the file now passes:
node scripts/brain-qa.cjs --stdout | grep "filename"
# PowerShell: node scripts/brain-qa.cjs --stdout | Select-String "filename"
| Check | What to Verify |
|---|---|
| Domain accuracy | Does the skill reflect current state of its domain? |
| Trifecta link | If workflow skill, does matching .instructions.md exist and align? |
| Reference files | Are references/ or scripts/ subdirectories still accurate? |
| Examples | Do code examples work with current tool versions? |
| Check | What to Verify |
|---|---|
| Routing accuracy | Does applyTo glob match when this instruction should load? |
| Skill reference | If instruction references a skill, is the skill still current? |
| Rule validity | Are the rules still correct given current tooling? |
| Check | What to Verify |
|---|---|
| Model availability | Is the specified model still available and appropriate? |
| Tool references | Do referenced tools still exist in the extension? |
| Handoff targets | Do handoff agent names match actual agent files? |
| Check | What to Verify |
|---|---|
| Agent reference | Does the agent field point to an existing agent? |
| Workflow steps | Are the prompted steps still valid for current tools? |
| Check | What to Verify |
|---|---|
| Runtime compatibility | Does the script run without errors on current Node.js? |
| Dependencies | Are @requires dependencies still available? |
| Output format | Does the output match what consumers expect? |
| Dead code | Variables computed but never stored/used? Branches that can never match? Fields extracted but never displayed? |
For auditing many files efficiently:
| Finding | Fix |
|---|---|
| Deprecated API method | Replace with current equivalent, cite migration guide |
| Stale version pin | Update to current stable version |
| Dead URL | Find new canonical URL or remove reference |
| Outdated best practice | Revise to current recommendation with rationale |
| Redundant Mermaid diagram | Replace with concise prose description |
Missing lastReviewed field | Add field with today's date after completing review |
Legacy frontmatter field (tier, currency, type, application, inheritance, lifecycle) | Drop it; see scripts/cleanup-frontmatter.cjs for the canonical drop list |
When a file's currency stamp is expired or missing, decide before acting:
| Condition | Content Changed? | Action | Stamp? |
|---|---|---|---|
| Stamp expired, content still accurate | No | Re-stamp unchanged | Yes — review confirmed validity |
| Stamp expired, minor drift (terminology, links) | Yes — minor | Edit then re-stamp | Yes — after fixes land |
| Stamp expired, material staleness (deprecated APIs, wrong patterns) | Yes — major | Full rewrite of stale sections, then stamp | Yes — after full review |
| Stamp missing, file is active and current | N/A | Add stamp with today's date | Yes — review confirms currency |
| Stamp expired, file covers a dead domain (sunset API, retired tool) | N/A | Add a ## Deprecated section + docs/deprecations.md row + supersededBy link if a successor exists | No — deprecated files don't get stamped |
| Stamp expired, file is historical record (plan, ADR, postmortem) | N/A | Re-stamp with long reviewEvery (or exempt via doc-hygiene convention) | Yes — stamp means "confirmed intentionally historical" |
| Stamp expired, file documents an upstream-dependent capability (SDK, MCP server, external API) | Check upstream | Research latest upstream docs before deciding; record the pinned upstream version in the file body | Only after upstream verification |
Rule: Never re-stamp without reviewing. A stamp is an attestation, not a date bump.
Revisit this skill by 2026-08-26 (90 days) or sooner if any of the following fires:
lastReviewed threshold defaults (currently 180-day warn / 365-day fail) — re-tune the 90-day audit cadence accordinglyTrack these in docs/ledgers/curation-log.md tagged [CURRENCY-AUDIT-DRIFT].