Code Review
This skill runs in two phases. The review workflow finds and verifies high-signal issues; delivery optionally publishes them to GitLab. Each phase has its own reference — read it as you enter the phase, so its detail is fresh when you act on it. This file is the router: it picks the mode, lists the stages, and states the rules that hold in every mode. The detailed procedure lives in the references, not here.
Pick a mode
- Delivery mode — the runtime has merge-request context (
Scope.MERGE_REQUESTwith amerge_request_id) and the platform is GitLab. The review is delivered as inline discussions on specific lines plus one top-level summary discussion, posted via thegitlabtool. Delivery requires thegitlabtool: if it's not loaded,tool_searchfor it; if it can't be loaded (or returns 403 on the discussion endpoint), demote to interactive mode. The pick is provisional:gitlab-delivery.mdStep 1 re-confirms thatmerge_request_id, the project, and the SHA triplet are all present and demotes to interactive if any is missing. - Interactive mode — anything else: a local diff, a referenced MR/PR with no runtime context, a GitHub PR, or ambiguous scope. The review is returned as a markdown final message; the harness handles delivery.
Run the review
- Read
references/review-workflow.mdand follow it. It walks scope → Stage 0 (per-repo review rules) → Stage 1 (detector fan-out) → Stage 2 (merge + adversarial verification) → severity, and hands off the verified findings. - Interactive mode: render the survivors using the interactive output protocol at the end of
review-workflow.md, and return it as the final message. Done. - Delivery mode: once the workflow hands off verified findings, read
references/gitlab-delivery.mdand follow it to post them. Read it before posting anything — the marker, anchor, and dedup machinery is not reconstructable from memory.
Non-negotiables (every mode)
- Precision over recall. Adversarially refute every finding; over-pruning is acceptable. Present only confirmed survivors — no strikethrough, no "on closer reading this is fine."
- Never post style, formatting, whitespace, or import-ordering findings. That's a linter's or formatter's job.
- Detectors run as
cr-*subagents, nevergeneral-purpose. Ageneral-purposedispatch returns prose with nofindingsarray and breaks the merge. If acr-*type didn't load, skip it and report the gap in the status line — never substitute. - Never compute markers or anchors by hand.
scripts/marker.pyis the only source of markers, anchors, and note parsing; hand-rolling them silently breaks dedup across reruns. - In delivery mode the posted comments are the deliverable. Do not also return the review markdown after a successful post.
- Never re-invoke the
skilltool to restart the review. On a tool failure, switch to an alternative and continue — each phase reference lists its fallbacks.
References
references/review-workflow.md— the review itself (scope, detect, verify, severity, interactive output). Required reading every run.references/gitlab-delivery.md— posting to GitLab (markers, dedup, inline + summary, pending replies, status line). Required in delivery mode.references/principles.md,references/few-shot-examples.md— the why behind a finding and how short a useful comment can be; open a section when a finding's framing is unclear.references/marker-format.md,examples/example-review-output.md— marker field semantics and a complete delivery example; open during delivery if a field's purpose is unclear or you need the output shape.