| name | after-coding |
| description | Review a completed implementation before raising a PR. Verifies before-coding ran, checks code against project rules, compares against the implementation guide, and produces execution-report.md. Run after all code is written and tests pass. |
Review the implementation before the PR is raised. Confirm before-coding ran, check
the written code against project conventions and non-negotiables, compare what was
built against the implementation guide, then produce
context/features/<feature-name>/execution-report.md. Stage the report and hand
off to the engineer.
Fail fast if before-coding was skipped
List directories under context/features/. A candidate is one that has
implementation-guide.md but no execution-report.md yet. If no candidate exists,
stop: "No implementation guide found. Run /before-coding with your ticket
description first." If multiple candidates exist, ask which feature is being
completed and wait.
Load context before reviewing
Read context/features/<feature-name>/implementation-guide.md, CLAUDE.md, and
context/conventions.md. Note missing files and continue — derive review criteria
from whatever is available.
Read the actual code changes
Use git diff HEAD and git diff --staged to see what changed. Read all changed
source files in full. If neither produces output, read the files referenced in the
implementation guide directly.
Checklist comes from the project, not general principles
Derive every checklist item from context/conventions.md and the non-negotiables
in CLAUDE.md. Check each item against the written code. Assign PASS, FAIL [BLOCK],
FAIL [FLAG], or N/A.
BLOCK vs FLAG
BLOCK violations must be fixed before the PR is raised: silently dropped errors,
wrong error-wrapping style, wrong HTTP error shape, naming violations listed as
non-negotiable, illegal global state, panic in handlers, or anything the project
marks as "must never be violated."
FLAG violations are advisory: missing tests on new public functions, undocumented
schema changes, logging style inconsistencies, any convention not marked
non-negotiable.
BLOCK violations gate progression
If any BLOCK violations exist, report them and say: "Fix the BLOCK violations above
before continuing. Re-run /after-coding after fixing them." Do not proceed to
deviation analysis.
Material vs non-material deviations
For each interface, function, or handler specified in the implementation guide,
check whether it was built as specified. A deviation is material if it changes the
external contract, error behavior, or test coverage. A deviation is non-material
if it is an internal detail invisible to callers. List them separately.
Write the report directly and stage it
Do not display the full execution-report.md content in chat. Write it to
context/features/<feature-name>/execution-report.md, then run
git add context/features/<feature-name>/execution-report.md.
Report covers: what was built (per component with signatures), what changed from
the plan (material and non-material deviations), checklist results (BLOCK/FLAG/PASS
counts), and how to run it (exact commands from zero).
Hand off clearly
Report file produced, checklist summary (N PASS, N BLOCK, N FLAG), deviation
summary (N material, N non-material). Tell the engineer: commit the report alongside
code changes, then raise the PR.
