TMDb: Skill for Claude Code

Review Knowledge

Audit knowledge/ and .claude/ against reality. Both are a cache of currently-true facts (knowledge/README.md → Maintenance & retention), and caches go stale silently: writes are engineered here (/capture-knowledge, /deliver's capture phase) but retirements are not, so truth decays exactly where the code moves fastest — Makefile, .github/workflows/ci.yml, Package.swift, target layout, toolchain pins.

Four independent adversarial auditors — an accuracy lens and a structure lens over each of the two trees — audit them, cross-examine each other's findings within their tree, and converge on a consensus. You adjudicate only what survives disputed.

The base's own entries are the thing under suspicion. An entry that reads confidently and cites a file is exactly the kind that goes stale unnoticed — confidence is not currency here. Verify against the tree or drop the claim.

Agent Behaviour Contract

The point of this skill: do these by default, without being reminded.

1. Two lenses × two trees, one Workflow. Run the embedded Workflow below. It fans out four auditors in parallel — each lens against each tree — every one pinned to the opus model, then runs a cross-examination round paired within each tree, so the two lenses challenge each other on the same material. Invoking this skill is itself the opt-in to call Workflow. A tree whose pair doesn't both return is reported unreconciled, never as consensus. The cross-examination stays on fable — do not unify the two tiers. The rounds are not symmetric: a refutation is written to the permanent refutation memory (item 2) and silently suppresses that finding on every later audit, so a weak refuter costs far more than a weak auditor. An audit miss, by contrast, is re-derivable next run. See ADR-0020.
2. Consult the refutation memory first. Before reporting, grep knowledge/skill-improvement-log.md for · refuted entries and drop any finding already settled there whose Reconsider when condition is unmet. Say in the report how many you dropped this way. Re-deriving a settled refutation costs a full audit cycle and buys nothing.
3. Verify, never trust the prose. Every finding must be checked against the actual tree (Read/Grep/Bash) and cite file:line. A finding sourced only from reading the knowledge base itself is inadmissible — that is the failure mode being audited.
4. Critics are read-only. They audit and report. They do not edit knowledge/, do not fix anything, and do not open PRs. Applying is the conductor's job, after the user approves.
5. "Nothing needs changing" is a real, respectable outcome. A critic that finds a file accurate must say so and name what it checked. Do not manufacture findings to look thorough — a padded audit trains the next one to be ignored.
6. Adjudicate only genuine deadlock. After cross-examination, findings both critics confirm are consensus and need no debate from you. Resolve only what remains disputed, with a stated rationale grounded in the tree.
7. Report before you fix. Present the consensus, get the user's go-ahead, then apply. Never silently rewrite the knowledge base on the strength of an audit.