Dev.review

dev.review

Workflow

1. Identify the review type from the user's request and artifact.
   • Examples: code, docs, design-doc, spec, simplify-spec, architecture, ux, skills, integrator, deslop, dead-code.
   • Use simplify-spec when the user asks to radically simplify a spec or its proposed implementation, narrow the solution, or find an 80/20 approach.
   • Use spec for correctness, approved-scope completeness, ownership, safety, and implementation readiness; leave design minimization to simplify-spec.
   • If ambiguous, ask one clarifying question before reviewing.
2. Load the matching workflow from ./references/workflow-[review-type].md.
   • If the workflow file does not exist, ask the user for the prompt to add and pause the review.
   • For skills reviews, use $sc for the local skill-authoring contract.
   • For docs reviews, use ./references/workflow-docs.md; when reviewing OpenClaw docs and $openclaw-docs is available, apply its guidance as domain-specific context.
   • For integrator, default input artifacts are outputs from ag-learn and adjacent retrospectives.
   • For code reviews that require flow docs, use $specy.
3. Route every top-level review request through the trigger:loop shortcut from dev.shortcuts.
   • If the user request already contains trigger:..., resolve it through dev.shortcuts.
   • If no shortcut trigger is present, invoke trigger:loop with the resolved review instruction, for example trigger:loop review the current diff with $dev.review.
   • Give the loop reviewer the review type, workflow file, artifact paths, current diff, and review scope.
   • Routing a plain review request through trigger:loop does not grant edit authorization. In that case, require the reviewer pass and parent classification, but stop after reporting any blocker or major findings; do not start a fixer pass without user authorization.
   • An explicit trigger:loop invocation, explicit review-and-fix request, or edit task authorizes the shortcut's scoped fixer passes. Follow the full reviewer/classifier/fixer loop for those requests.
   • When this skill is already running inside a trigger:loop reviewer pass, apply the workflow directly to the material and produce the review instead of nesting another loop.
   • When this skill is already running as a read-only reviewer subagent for trigger:spec, apply the selected workflow directly; do not redispatch the parent shortcut or start a nested review/fixer loop.
4. For PR or CI-backed review loops, keep going until the remote exit condition is met.
   • Completion is remote-state based, not patch based: current head SHA is known, relevant CI is green, unresolved non-outdated review threads are zero, and actionable comments are addressed or explicitly routed to the user.
   • Before saying the loop is finished, run a final PR gate query and report head SHA, failing/pending check count, unresolved thread count, and actionable comment count.
   • If any required check is failed/pending or any actionable review item remains, the loop is not finished; continue fixing or report the exact blocker.

Output

• Lead with findings ordered by severity (blocker/major/minor) or by impact if severity is unclear.
• Prefer concrete, actionable feedback over generic commentary.
• Call out assumptions, risks, and unclear ownership/abstractions.
• Propose simplifications when the selected workflow owns simplification.
• Keep the review concise; avoid restating large sections of the input.
• For code reviews, include both the Simplicity Audit and Test Audit checklists required by ./references/workflow-code.md; never check an item without inspected evidence or report a clean review with either audit incomplete.
• Give every added or modified test a keep, merge, or delete disposition. Treat tests without distinct production-behavior evidence as major findings; remove or consolidate them when edits are authorized, or report them without changing files during a review-only request.
• Treat materially avoidable duplicate ownership, parallel implementations, and implementation-coupled test machinery as major when a concrete smaller design preserves approved capabilities, security, and supported compatibility.
• If blocker or major findings remain in a review-only request, report them as unresolved and state that no fixer pass ran because edits were not authorized.

Workflows

• ./references/workflow-code.md for code review.
• ./references/workflow-docs.md for developer documentation, user guides, API references, CLI references, quickstarts, READMEs, and troubleshooting docs.
• ./references/workflow-design-doc.md for design doc review.
• ./references/workflow-spec.md for product, implementation, or test spec review.
• ./references/workflow-simplify-spec.md for reducing a spec to the smallest complete implementation that satisfies its current goal.
• ./references/workflow-architecture.md for architecture and system-boundary review.
• ./references/workflow-ux.md for UX review.
• ./references/workflow-skills.md for reviewing SKILL.md files and bundled skill resources.
• ./references/workflow-integrator.md for integrating learnings into skill/code/project changes.
• ./references/workflow-deslop.md for anti-slop code review focused on excess complexity, patch size, and unnecessary helper extraction.
• ./references/workflow-dead-code.md for dead-code review that accounts for every new class, function, method, variable, constant, option, config field, and other named artifact introduced by a PR.