check git:20261019.2b9222eB

Immutable. This exact content never changes and is served at /api/v1/blob/55a0966462fafc3d.

---
description: Run a check on the conformance of a project or the engine with the conventions — bare = check roster
argument-hint: "[check] [project-slug]"
---

Checks live as `.claude/agents/check-<name>.md` — one isolated agent
per check, each defined by what it verifies, said in its
`description`; the roster is the scan of those files. Adding a check
means adding an agent file from `templates/check-definition.md`; this command
does not change (who creates a check, and when: CLAUDE.md, Isolated
reviewers).

Shared behaviour: the contract skill named in each check file's
front-matter (CLAUDE.md, Isolated reviewers). Like the critic and the
challenger, a check agent writes nothing: it returns its report and this
command files it. This command chooses the check, passes the target,
files the report and presents it.

**Bare `/check` — the roster.** List the available checks (scan
`.claude/agents/check-*.md`, their `description` fields — each says
when it fits) and recommend which fits the moment; what a save or a
release runs is `/save`'s and `/release`'s to say. A recommendation,
never a gate; no check runs on Claude's own judgement.

**`/check <name> [slug]` — run it.** The target is a project by its
slug (the engine's own project is `forge`) or the engine root; which
of the two a check takes, and what a missing or an added slug means
to it, is its Lens section's to say — read it there. Typed, that is
`/check engine` (the engine root, no slug) or `/check light forge`
(the forge's own project). First remake the
target's ledger, `python scripts/forge-ledger.py <slug>` (for the engine `forge`), so
that the agent reads a current file; then invoke the
`check-<name>` subagent (Agent tool, session model) with the target
path and nothing else (CLAUDE.md, Isolated reviewers). More than one
check on one target may be launched at once and awaited together.

When it returns:
1. File the report, when it has findings. Write it into the target
   project (for the engine `projects/forge`) as
   `reviews/YYYY-MM-DD-check-<name>.md`: a front-matter of `date`,
   `project`, `check`, `target` and `reviewer: check <name> (isolated
   context)`, then the agent's text word for word — nothing added,
   dropped or reworded but the ID, the next free `FND.NNNN` of the
   project's sequence, in tens, set at the head of each new finding;
   then `python scripts/forge-report.py <path>`; the printed name is
   the one the ledger cites. Then `python scripts/forge-ledger.py
   <slug>`: how the report becomes rows is `templates/ledger.md`'s
   (Findings). A library has no `reviews/` until its first finding:
   create the directory then. Reports of several checks on one
   target are filed one after another, never at once, so that no ID
   is given twice. A report that says "conforms" is filed nowhere.
2. Present the report to the principal as it came: the one-line
   verdict, then the findings in their ranking with their IDs,
   compactly.
3. Offer at once every finding marked "immediate fix" as one step
   (CLAUDE.md, Working methods, Step by step); apply on his word,
   state `resolved`.
4. End by offering a **walkthrough** of the remaining findings
   (`.claude/skills/walkthrough/SKILL.md`, the one owner of its
   shape and of the verdict words). What `accept` writes here: the
   fix, agreed here and written once at the round's end, state
   `resolved`; a rule worth changing goes to the intent. The other
   verdicts are the walkthrough's. Nothing blocks (POS.0430): a
   release may proceed with a finding parked.

Do not judge substance or document quality — that is `/critique` and
`/challenge` territory. A check verifies conformance only.