review

Files (1)

• SKILL.md

SKILL.md (first lines)

# Review

Argument: $ARGUMENTS

## Criteria

Report only problems that matter: bugs, acceptance not met, security issues, changes outside the scope, missing tests for new behaviour. Don't report style preferences or problems that were already there. Approve when nothing should block merging.

## 1. Find the level

- A number, or a URL containing `/pull/`: pull request level.
- Otherwise, `bd show <id> --json`: `issue_type: epic` is epic level; a task with children (`bd list --parent <id> --all --limit 0 --json`) is parent task level; anything else is task level.

## 2. Task

Diff: `git diff <metadata.dispatch_base>...<metadata.dispatch_branch>`, from `bd show <id> --json`. Run it in the task's worktree — `finish-task.py` already starts you there; otherwise find it with `wt list --format json` and the branch.
Reviewed against: the task's `description`, `acceptance_criteria`, `metadata.scope` (when set) and `metadata.verify`.

Read the diff and whatever code you need to judge it against the criteria above and the task's acceptance, scope (when set) and verify command.

Then run `${CLAUDE_PLUGIN_ROOT}/scripts/metrics.sh --changed <the base above>` in the worktree. A touched function with a non-empty `over` is a requested change: "`<file>:<start> <function>` has ccn <after.ccn>, limit <`bd config get custom.dispatch.ccn`, default 15>: <the concrete step, e.g. extract the branch on X into its own function>", or the same with `nloc`/`custom.dispatch.function_length` (default 100) when `over` names `length` instead. A touched function whose `after` is worse than `before` but `over` is empty is a note in the verdict, not a requested change. A function the task didn't touch is never mentioned. If it exits 2, `lizard` isn't installed: skip this step and say so in one line.

## 3. Parent task

Read-only: children merge on their own, so there's no branch to gate.

Diff: the combined commits of its children — `bd list --parent <id> --all --limit 0 --json` for the children, then each closed child's merge commit on the base it merged into.
Reviewed against: the parent's `acceptance_criteria`, checking that nothing fell between the children.

## 4. Epic

Diff: `git diff <target>...<epic-branch>`.
Reviewed against: the epic's `description` and `acceptance_criteria`.

Runs before integration, from `metadata.review` on the epic (agent or human), applied by the integration task's `finish-task.py` to the epic diff.

## 5. Second opinion from roborev

Task and epic levels, when `roborev` is on PATH and `.roborev.toml` exists at the root of the checkout you're reviewing in. Otherwise skip this step without mentioning it.

Run, with a Bash timeout of 600000 ms, in the same checkout:

```bash
roborev review --local --branch=<branch> --base <base>
```

`<base>` and `<branch>` are the two sides of the diff above, so it reviews the same `<base>...<branch>`. `--local` runs roborev's configured review agent directly, without its daemon, and prints the findings.

Its findings are candidates, not verdicts: check each one against the code, and keep only those that hold and meet the criteria above, as your own findings. Map its severities `critical` to blocker, `high` to major, the rest to minor. If it fails or times out, say so in one line and go on without it.

## 6. Pull request

Diff: the pull request's diff (`gh pr diff <pr>`) and its review comments (`gh pr view <pr> --json comments,reviews`).
Reviewed against: the epic.

Either post a review with `gh pr review <pr> --approve|--request-changes --body "..."`, or, if the pull request already carries reviewer comments, read them and turn them into `bd comments add` on the relevant task instead of reviewing it yourself.

## 7. Verdict

**A person, while a human review gate waits** (`bd show <id> --json` has `metadata.dispatch_review_gate`, and that gate is open): use AskUserQuestion.
1. Summarize the diff against the acceptance.
2. Show the verify command's result, the roborev findings you kept, and any earlier agent findings: `metadata.dispatch_review*` and `bd comments <id>`.
3. Ask for the verdict:
   - **approve:** `bd gate resolve <gate>`
   - **request changes:** ask what to change, `bd comments add <id> "<the changes>"`, then `bd gate resolve <gate>`

   `resume-reviewed.sh` resumes the worker once the gate resolves.

**Otherwise** (no gate — `review=agent`'s headless run, a parent task, or AskUserQuestion isn't available): state your verdict as your final answer — approve or request changes, a short summary, and any findings (file, line, severity, problem, fix). Don't touch `bd`; the caller records the verdict.

From Igosuki/agentic-sdlc, MIT.

More from Igosuki/agentic-sdlc