dispatching-code-review

Dispatching a Code Review

Render before asking. Before any AskUserQuestion, render the decision context as assistant chat text. Content that exists only in a Read result, a subagent/Agent return, or the question/option strings does not count as rendered (the UI shows a compact card) — restate it in chat first.

The companion to dispatching-spec-review. Spec review answers "is what was asked delivered?"; code review answers "is what was delivered any good?". Same fresh-context subagent pattern, different concern set.

When to Invoke

Caller	Scope	Trigger
/ship-execute post-task gate	One task	Optional — fires only when effort: M|L|XL; effort: S skips both spec and code review
/ship-execute wave VERIFY	Wave-level diff	Optional — fires when wave touched security-relevant, financial-domain, or database/persistence code (migrations, schema, queries, repositories)
/ship-review	Sprint or feature	Required before user approval
/ship-quick	Single-change diff	Optional flag (--review)

Code review is more expensive than spec review (broader concern surface). /ship-review runs it mandatorily before approval; the post-task path remains optional and gated on effort.

Inputs

• scope — "task" | "wave" | "feature" | "sprint"
• target_ids — list of task / feature IDs (or null when scope is sprint).
• base_ref / head_ref — diff range.
• concerns — subset of ["security", "bugs", "silent-failures", "patterns", "tests", "observability", "data"]. Default: all. The data concern auto-gates — it produces findings only when the diff touches persistence (migrations, schema, SQL/ORM, repositories, indexes) and no-ops otherwise, so including it by default is free. Caller can narrow (e.g., ["security", "bugs"] for a wave that didn't touch tests), but whenever the diff touches the database, data MUST be among the concerns (it is, under the default). In parallel-split dispatch (see ship-review/references/code-review-orchestration.md), assign data to exactly one subagent so it isn't dropped or duplicated.
• data_dir — literal <SHIPYARD_DATA> path.
• project_rules_path — .claude/rules/*.md paths so the patterns scanner has the project's conventions. Shipyard does not inject its own rules into .claude/rules/; only project-authored rules pass through here.
• quality_standards_path — the literal path to project-files/references/code-quality-standards.md. Always resolved and included, not gated further here — code review is itself effort-gated at the caller (fires only for effort: M|L|XL at the post-task site; unconditionally at /ship-review), so by the time this skill dispatches, the digest is always in scope. Not narrowed by concerns — each of the six general concerns points back at its own §<concern> ▸ Verify half regardless of which subset is active.