Menu
Use when completing tasks, implementing major features, or before merging to verify work meets requirements
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use when the user provides a GitHub PR link with a "deep review" trigger inside a locally cloned repo, to perform a thorough multi-dimensional code review grounded in ARCS DAG context, AGENTS.md conventions, and optional codegraph coupling analysis, then post findings as inline GitHub review comments under explicit user gate
Use when you have a written implementation plan to execute in a separate session with review checkpoints
Use when initializing a new ARCS project — bootstrapping a repo into the DAG with metadata, docs, and structural knowledge entries. Covers gather → present summary → init → codegraph ingestion → fan-out analysis across typed sub-agents.
Use when implementing any feature or bugfix, before writing implementation code
Use when you have a spec or requirements for a multi-step task, before touching code
Use when capturing a knowledge entry, before writing its body — to author a substantive per-kind body, not a summary-only stub
| name | requesting-code-review |
| description | Use when completing tasks, implementing major features, or before merging to verify work meets requirements |
After completing a task, major feature, or before merge. Dispatch arcs:code-reviewer subagent.
flowchart TD
A[Work complete] --> B[Get BASE_SHA and HEAD_SHA]
B --> C[Gather project conventions]
C --> D[Fill code-reviewer.md template]
D --> E[Dispatch arcs:code-reviewer subagent]
E --> F{Review results}
F -->|CRITICAL| G[Fix immediately]
F -->|HIGH| H[Fix before proceeding]
F -->|MEDIUM/LOW| I[Note for later]
G --> E
H --> E
{WHAT_WAS_IMPLEMENTED} — what you built{PLAN_OR_REQUIREMENTS} — what it should do{BASE_SHA} / {HEAD_SHA} — commit range{PROJECT_CONVENTIONS} — CLAUDE.md / linter configs / style guides (gather once per session, reuse across dispatches)When gathering conventions, also pull what the DAG already knows so the reviewer checks against settled patterns, not just static config: arcs knowledge search <slug> "<changed-area keywords>" --lean --json, filtering for kind=pattern and kind=gotcha. Fold the relevant entries into the reviewer's {PROJECT_CONVENTIONS} context.
Mandatory: after major features, before merge to main.
Already scheduled: when executing-plans parallel mode drives the loop, its pipeline dispatches this review as stage 2 (code-quality-reviewer applies this template's checklist but returns the parallel-mode JSON envelope) — do not schedule it twice for the same task.
Optional: when stuck, before refactoring, after complex bugfix.
See template at: requesting-code-review/code-reviewer.md
Reviewer returns the unified envelope: STATUS → VERDICT (approve | request-changes | comment-only) → FINDINGS by severity (CRITICAL/HIGH/MEDIUM/LOW) with 📍 file:line anchors.
When a finding recurs — the same class of issue flagged more than once, or a convention the codebase keeps violating — propose it as durable knowledge so future reviews and implementers inherit it: arcs knowledge upsert <slug> "<title>" --kind=<pattern|gotcha> --summary="<the recurring issue and the fix convention>" --keywords="<k1,k2>" --source-files="<path,...>" --json. Upsert is idempotent by title.