Pull Request Review
Staff-engineer-style PR review. Loads PR context, walks a per-file diff, applies a safety/quality checklist, and posts a structured summary. Requires a GitHub-connected project on a feature branch.
Steps
Entry step: load-pr. Each step names the specialist role it wants; the full working prompt is expandable.
- Load PR contextreviewerentry
Resolve which PR to review (current branch's open PR by default) and fetch its metadata + the unified diff. Writes pr.number, pr.title, pr.head into the task notes.
Show working prompt
**For this task you are a reviewer, not an author.** Your job here is to read changes and post feedback — NOT to write new code. If your default persona is a developer/builder, set the ship-the-scaffold instinct aside for this task. You won't `writeFile` for this craftbook; you'll read PRs and post comments. **Your first action this turn:** call `github_pr_list` (no args). The result tells you which PR to review. 1. If the user's chat message names a PR number, skip the list and use that. 2. Otherwise, take the first PR from `github_pr_list`. If multiple match the current branch, call `ask_user_question` to disambiguate. 3. Once you have the number, call `run_script({ name: "pr-context", input: { number } })` — it stamps the PR metadata + diff into the run output. 4. `write_task_note({ ref, content })` with the PR title + URL so the next step has the anchor. Do NOT call `read_task_notes` to find the procedure — it's right here in this prompt. The notes only carry user input + prior step output; the **what to do** is in this step. - Scan diffreviewer
Walk the diff applying the safety/quality checklist. The diff-scan script returns a structured findings array.
Show working prompt
Run the `diff-scan` script. It fetches the PR diff via `github_pr_diff` and applies a pattern-based first-pass — SQL safety, unguarded `any`, console.log left in, secrets-in-source-shaped strings, missing test coverage for new files. Read its output carefully. Then do your own pass: use `github_pr_files` to walk individual files and apply judgment for things the pattern scan can't catch — naming, abstraction quality, error handling, edge cases. Take notes via `write_task_note`. At the end of this step, you should know: did you find issues worth surfacing? Set `findings: <number>` in your output.
- Raise findingsreviewer
Surface concrete issues with file:line citations. Use `github_pr_comment` to post the structured summary to the PR.
Show working prompt
For each finding, write a short paragraph: - **What** (one sentence describing the issue) - **Where** (file:line — the model citation hyperlink form, file_path:line) - **Why it matters** (one sentence) - **Suggested fix** (one line or a small diff) Group findings by severity: must-fix (correctness, security, data-loss risk), should-fix (clarity, edge cases, missing tests), nit (style, naming). Post the summary via `github_pr_comment` with the PR number from step 1. Then advance to summary.
- Summaryreviewer
Stamp a final summary into the task notes for the user.
Show working prompt
Write a one-paragraph summary of the review to the task notes via `write_task_note`. Include: - The PR (#number — title) - The verdict (approved | needs changes) - The number of findings broken down by severity - A link to the posted PR comment Then report DONE.
- Approvereviewer
Clean PR — write a brief approval note. Don't gold-plate.
Show working prompt
The diff scan came up clean. Write a one-paragraph approval note: what the PR does, why it looks good, anything worth flagging as 'consider for a follow-up' (but not blocking). Post via `github_pr_comment`. Advance to summary.
Triggers
Phrases that suggest this craftbook to a crew.
- review this pr
- code review
- check my diff
- review the changes
Toolsets
- [object Object]
Source
View this craftbook on GitHub · MIT license