code-quality-review

Codex compatibility note:

• Invoke $skill-name: load the registered .agents/skills/<name>/SKILL.md and execute it with Codex tools; no separate Skill tool or Claude mode switch is needed. Author .claude/**; mirrors are generated.
• Track steps before execution and keep progress/evidence current. Explicit skill requests execute their protocol. Use the native question tool for required questions.
• Map foreign tool names to available host capabilities. A name mismatch needs no approval; an actually unavailable required capability stops with its step/evidence and a user question before adaptation.
• Subagent authorization: when a skill is user-invoked or AI-detected and its protocol requires subagents, that skill activation authorizes use of the required spawn_agent subagent(s) for that task.
• Preserve protocol order unless the user approves a deviation. Workflows use $start-workflow: gates stay fixed; other steps may flex with logged reasons and evidence.

[BLOCKING] Execute skill steps in declared order. NEVER skip, reorder, or merge steps without explicit user approval. Inside a workflow run, $start-workflow → Workflow-step mode bounds this rule. [BLOCKING] Before each step or sub-skill call, update todo tracking: set in_progress when step starts, set completed when step ends. [BLOCKING] Every completed/skipped step MUST include brief evidence or explicit skip reason. [BLOCKING] If Task tools are unavailable, create and maintain an equivalent step-by-step plan tracker with the same status transitions.

Quick Summary

Review modes: For review/audit work, standalone defaults to --review-only (--report-only alias); --fix-loop enables review → validate → authorized fix → fresh re-review, default cap 3. --fix-loop --loop-owner=caller returns a read-only pass to the caller that owns fixes/re-review. Create triage, review, validation and re-review todo tasks first; apply the carried review-policy contract for LOW deferral and user-approved bounded extensions. Non-review modes and terminal findings validation keep their own dispatch.

Goal: Verify feedback, request targeted code-reviewer reviews, and gate completion claims so accepted code is correct, easy to change and convention-aligned.

Summary:

• Evaluate feedback, review named code, or verify completion; current/branch diffs route to changes-review. Prepared inputs establish scope, never acceptance.
• Create report → assess blast radius and full-pipeline impact → detect risks, plan compliance and surfaces → review each file → holistic assessment → final result → validate findings → fix validated blockers → full re-review after fixes.
• Direct named-code reviews resolve the requested files and applicable rules, including a conditional domain entity quality task for new or updated entities. Feedback evaluation uses the supplied evidence. Trace consumers/dependents and tests; cite file:line before acceptance.
• Round 1 closes every validated severity; from round 2 CRITICAL/HIGH/MEDIUM block and LOW-only defers. Failed binary gates always block; retain the shared LOW deferral and fresh post-fix evidence rule.

Routing boundary: If the user asks to review current changes, uncommitted work, staged/unstaged diffs, or a branch-to-branch diff, use changes-review instead.

Dispatched as a leaf reviewer (a sub-agent whose brief assigns your scope): review exactly that scope with every review rule in this skill and return the report. Batching, fan-out, validation passes, the fix loop, re-review rounds, user questions and next steps belong to your caller — except the in-batch $why-review --validate-findings over your own report that a batch brief explicitly assigns under the shared adaptive review plan, which you run and record as validated: in-batch. When the scope is too large to review well, say so in your return instead of sampling or spawning reviewers.