critique · git:20261018.a9f0143 · 2026-10-18 · sha256 64f1d1a60970577b
critique git:20261018.a9f0143B
Immutable. This exact content never changes and is served at /api/v1/blob/64f1d1a60970577b.
--- description: Run a critic lens on the quality of a project's documents — bare = lens roster argument-hint: "[lens] [artefact|path] [project-slug]" --- Critic lenses live as `.claude/agents/critic-<lens>.md` — one isolated agent per lens, each defined by what it reads, said in its `description`; the roster is the scan of those files. Adding a lens means adding an agent file from `templates/critic-definition.md`; this command does not change (who creates a lens, and when: CLAUDE.md, Isolated reviewers). Shared behaviour: the contract skill named in each lens file's front-matter (CLAUDE.md, Isolated reviewers). Like `/check`, the lens agent writes nothing: it returns its report and this command files it. This command chooses the lens, passes the target, files the report and presents it. **Bare `/critique` — the roster.** List the available lenses (scan `.claude/agents/critic-*.md`) and recommend which fits the project's state, by the fit each lens states in its `description`. A recommendation, never a gate. No lens runs at a save; what a release offers is `/release`'s (`.claude/skills/release/SKILL.md`); every run is the principal's word. **`/critique <lens> [artefact|path] [slug]` — run it.** The target is an artefact named as `/forge` names it, or any file of the project by its path (CLAUDE.md, Isolated reviewers); how it narrows the run is the lens file's. Invoke the `critic-<lens>` subagent on the project (infer it from context; if ambiguous, ask), naming the target if given. Pass only the project path and the target, nothing else (CLAUDE.md, Isolated reviewers). When it returns: 1. File the report. Write it into the project as `reviews/YYYY-MM-DD-critique-<lens>.md`, suffix `-2` if one exists for today: the agent's text word for word, its front-matter included, nothing added, dropped or reworded but the IDs: the next free `FND.NNNN` of the project's sequence, in tens, set at the head of each new finding and listed in the delta summary's New line. Then the ledger: a row per new finding in the Findings table (severity and category from the finding, state `open`, source review = this file); a finding the report has as reopened back to `open`, as newly obsolete to `obsolete`; the document states refreshed. Reports of several reviewers on one project are filed one after another, never at once, so that no ID is given twice. 2. Present the delta summary to the principal in the conversation language (`CLAUDE.local.md`): new findings (with severity), verified resolved, still open, newly obsolete, and what awaits his verdict. For `essence`, the distillations first — they are what the findings rest on. 3. End by offering a **walkthrough** of the open findings (`.claude/skills/walkthrough/SKILL.md`, the one owner of its shape and of the verdict words). What `accept` writes here: an iteration of the artefact concerned, through `/forge`, state `resolved`. The other verdicts are the walkthrough's. If he declines the walkthrough, the findings wait.