Reviewing and iterating
Getting value out of Gentlybot isn’t just asking well — it’s reading the result and steering the next step. A thread is a conversation you can correct, tighten, and re-run, right up to a reviewed pull request.
Reading a plan
A plan is your cheapest checkpoint — it exists before any code does. Skim it for four things, then approve, edit, or send it back with notes.
Is it solving the thing you actually asked for — no more, no less? If it’s ballooned, say “just the toast, leave the worker alone.”
The apps, services, routes, and files the change would touch. A surprise here (“why is it editing auth?”) is worth catching before code exists.
What could break, what’s ambiguous, what assumptions it’s making. Push back on anything that reads as a guess.
How it plans to prove the change works. Add cases it missed — “also cover the empty export” — before you approve.
Approving a plan promotes the same thread to Implement — you never re-explain what you already agreed on.
Reading the proof
An Implement run produces evidence, not just a diff. Here’s what lands in the thread and how to read it.
The live preview
Implement runs get a sandbox URL running your real stack — same routes, same permissions. Click through the change yourself; it’s your actual app, not a mockup.
Screenshots and recordings
When a change is worth proving, Gentlybot opens the app in a real browser, walks the changed flow, and captures it. Approving means watching it work, not trusting a diff.
The stages
Lint, test, commit, push, and PR each report real status in the thread. A red stage is a real failure you can see and ask Gentlybot to fix — not something swept under the result.
The pull request
The run ends in a PR carrying the context, the checks, and the evidence — landing where your reviewers already look, so review fits your existing process.
Steering with follow-ups
The thread is the unit of work, not a single message. When the result isn’t quite right, reply — don’t restart. Everything Gentlybot already learned about your app carries forward.
Correct a wrong turn
If it worked on the wrong thing, name the mismatch precisely: “that’s the admin export — I mean the one customers download from Reports.” The thread keeps everything else it learned.
That’s the admin export. I meant the customer-facing one on the Reports page.
Tighten the scope
When a change reaches further than you want, pull it back in a reply. You don’t lose the good parts.
Drop the worker refactor — just keep the notification change and re-open the PR.
Ask for more proof
If the evidence doesn’t cover what you care about, ask for the specific thing you want to see.
Also show me the empty state, and check it in dark mode before I review.
Request a different approach
Don’t like how it solved it? Ask for the alternative. It’s cheaper to redirect in-thread than to review a PR you’ll reject.
Use the existing toast component instead of a new banner — match how #312 did it.
Landing the change
The end of a Gentlybot run is the start of your normal review. The PR arrives with its context and evidence attached; your engineers review and merge it exactly as they would any other pull request. Gentlybot never merges on its own — the whole point is that people stay in the loop, and now they’re reviewing something they can watch work.
Keep the trail in one place
Prompts, decisions, screenshots, recordings, checks, and review notes all live in the one thread. When you hand it to a teammate — or come back in three weeks — the reasoning is right there. That trail is what lets product, QA, and support contribute without bypassing engineering review.