Case Study: Automated Pull Request Review

Design choices

Trigger: a pull request opens. A router checks the changed paths. A parallel step runs a security reviewer and a test-gap reviewer as read-only subagents. A skill supplies the team's review checklist. An orchestrator merges findings into one comment. A hook or CI check blocks any write access, and a human decides whether to merge.

A complete workflow

A real workflow combines a pattern, a skill, a subagent, hooks and an eval into one dependable loop.

The flow in outline

Read it as a diagram in text form. Each box maps to a concept from an earlier section.

PR opened
  -> route by changed paths                (routing)
  -> [security reviewer | test-gap reviewer]  (parallel subagents, read-only)
  -> merge findings with checklist skill     (orchestrator + skill)
  -> post ONE comment                        (limited write tool)
  -> human decides to merge                  (checkpoint)
  -> eval set re-run when prompts change     (evals)

Quick check: Why is the final merge decision left to a human?

• Models cannot read code
• It is a high-impact action, so a checkpoint is safer
• Git forbids bots
• It is cheaper to guess