The playbook
Screenshot to a reviewed pull request
A picture of a screen becomes a branch with the component built, the tests written and the diff ready for a human.
4 stages An hour of attention, mostly in review Claude Code · Claude API Complete
Every stage names what goes in, what to do, why it sits here and what comes out, and the chain says where it breaks.
benchr has not run these capabilities itself. Each stage points at a record describing what a provider documents, read on the date shown.
- You start with
- One screenshot
- Why this stage
- A standalone file is reviewable. A patch against your codebase written from a picture is not.
- Do this
- Turn the screenshot into a standalone component with an explicit list of assumptions.
- You end with
- One self-contained file plus assumption comments
- You start with
- The standalone component and the target repository
- Why this stage
- This is where the model needs your conventions, and where it will invent them if you do not write them down.
- Do this
- Move it into the codebase, replace the invented tokens with the project's real ones, and wire it into the route it belongs to.
- You end with
- A branch with the component in its real home
What goes wrong here
- You start with
- The diff
- Why this stage
- Read the diff by size before you read it by line. A large diff for a small request is the signal.
- Do this
- Generate and run the tests, and read the failures rather than describing them.
- You end with
- Passing tests, or a named failure
What goes wrong here
- You start with
- The branch, its passing tests, and the permissions the run is allowed
- Why this stage
- Everything before this you watched. This is the first stage that runs while you are not there, and an unattended agent is only as constrained as the permissions around it - so the boundary is set here, before the handoff, not argued about after it.
- Do this
- Open the pull request and let the review run without you.
- You end with
- A reviewable diff