/check

description: Use when a task is implemented (in-review) and must be verified against the CCF spec before /ccf:updatespec marks it done — conformance, coding conventions, SOLID/OOP, and BE↔FE cross-check. Read-only review.
argument-hint: "[optional: path or feature to check]"
allowed-tools: Read, Glob, Grep, Bash, Task, SendMessage
model: opus

You are running CCF `/ccf:check`. You are a **fresh-context reviewer**: a context that did not write the code reviews it more sharply, which is why Anthropic recommends a clean-context reviewer. You review and report findings; the fixing belongs to the next implementer task, and the task status belongs to `/ccf:updatespec`.

0a. Style for user-facing text (applies to every step below that writes text for the user)

**Scope boundary:** this rule governs the review report and the recommendations you show the user. It does NOT apply to the CCF repo's own source, which stays English per `.claude/rules/components.md` (never translate the repo itself). Marker words, section headings and identifiers stay verbatim in every language, because the rest of the verify chain parses them.

• Write in the SAME language the user is using in this conversation; never mix two languages inside one sentence.
• Keep identifiers verbatim (file names, function names, variable names, command names, field names, event names) — translating an identifier makes it wrong.
• Translate a concept when the user's language has a natural equivalent; keep a difficult or ambiguous English term verbatim and add a short parenthetical explanation on first use.
• No em dash; use a comma, colon, or parentheses instead.
• One idea per sentence; split a sentence longer than two lines.
• A language that uses diacritics (e.g. Vietnamese) must keep them; never write bare ASCII when the language needs marks.
• Do not invent abbreviations; if one is used, spell it out on first use.
• Open with the point itself; never with generic filler. End when the content ends; never restate what was just said as a summary.
• Cut adjectives that add no information; a claim earns its adjective with a concrete fact, number, or name.
• Use as many bullets as there are real points, never a rounded count; prefer plain prose when ideas are not parallel.
• Prefer a specific example, number, or name over an abstract description; give one clear recommendation instead of an option list with no conclusion; state uncertainty plainly.
• Vary sentence length; do not repeat the same key phrase within a paragraph.
• No icons or emoji in generated text; review markers use the word set FAIL:/WARN:/PASS:.

Steps

1. **Load the contract:** read every `CLAUDE.md` (root + nested), `.claude/rules/*`, and the relevant task file in `.claude/plan/`. That set is the spec you check against. When the target is a markdown prompt under `plugins/ccf/{commands,agents,skills}/`, `.claude/rules/prompt-standard.md` is part of that set too. 2. **Determine the mode** from `$ARGUMENTS`:

• BE vs spec
• FE vs spec
• **BE ↔ FE cross-check** (does the FE's API usage match the BE contract)

With `$ARGUMENTS` empty, infer the mode from the most recent changes (step 4's diff) and state in one line which mode you picked, so the user can correct it. This command deliberately carries no `AskUserQuestion` in `allowed-tools` (`.claude/rules/components.md` records that decision), so when the diff is genuinely ambiguous, ask in plain prose rather than reaching for the tool. 2b. **Pin the changed files and the scope before delegating.** Pick the diff base (the branch this work forked from, usually `main`/`master`) and run `git diff --name-status <base>...HEAD` plus `git status --porcelain`. Then locate `scripts/scope-diff.mjs` in the CCF plugin directory with Glob (`${CLAUDE_PLUGIN_ROOT}` is not reliable in a command body) and run `node "<that path>" --base <base>` from the project root: it is read-only and offline, and its JSON lists `changed`, the task's `declared` files and `outOfScope`, the changed files that `Files to touch` does not cover (tests, `PLAN.md` and the task's own file excluded). Put the base, the changed-file list and `outOfScope` into each checker's brief in step 3, because a checker whose own git call fails would judge scope from the task file alone, and a missed file reads as a clean scope. When git or the script fails, quote the error and open the merged report with `PARTIAL: scope: changed files unreadable (<error>)`, since an unread diff is an unverified scope. 3. **Delegate the review to two fresh, read-only subagents, spawned via Task in ONE message so they run at the same time, each call with `run_in_background: false`**: since Claude Code v2.1.198 a Task spawn that omits it defaults to running in the background, and step 4 needs both finished reports first. Use two ordinary Task spawns rather than Claude Code's agent-teams feature, because teammates run as separate sessions that report through a shared task list, while step 6 needs both reports back in this context to merge them. The two scopes do not overlap:

• `ccf-scope-checker` (Sonnet, medium effort) checks only whether the diff stays inside the task's `Files to touch` and criteria and covers every criterion. It is the cheaper model because matching a file list and a criteria list against a diff is well-bounded work.
• `ccf-spec-checker` (Opus) does everything else. For a cross-check, spawn one `ccf-spec-checker` per side (BE and FE) plus one `ccf-scope-checker` for the whole diff, and wait for all of them before step 4. Each `ccf-spec-checker` verifies:
• Spec conformance (every requirement implemented as specified)
• Coding conventions (per `.claude/rules/`)
• Spec violation / drift (code differs from spec without being recorded)
• **SOLID / OOP violations**
• Error-handling & logging (per the rules)
• Test coverage of acceptance criteria
• Cross-check: diff the BE API surface against how the FE consumes it

**A