after-coding

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.