Identify the review type from the user's request and artifact.
- Examples: code, docs, design-doc, spec, architecture, ux, skills, integrator, deslop.
- If ambiguous, ask one clarifying question before reviewing.
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 the sibling dependency at ../sc/SKILL.md 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 the sibling dependency at ../specy/SKILL.md.
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.
- 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.
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 possible.
Keep the review concise; avoid restating large sections of the input.

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-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.

dev.review

dev.review

Workflow