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.
Review a teammate’s work
You can test and review work someone else started. Open the shared thread to see the original request, the decisions so far, and the latest result.
- Read the context. Check what the feature should do and which cases the latest run checked.
- Open Preview. Try the running app yourself. Check the main flow and the edge cases that matter to your team.
- Add your findings in the thread. Describe what you tried, what you expected, and what happened. Mention the teammate who should take a look.
- Continue the work together. If you need to help run or manage the thread, ask its creator or a shared owner to add you through Share thread. Your workspace’s permissions still apply. Use Watch thread to follow updates.
Test that a courier can accept a route, deliver an order, and mark another delivery as failed. Check the customer emails too.
Keep review feedback in the existing thread so the people continuing the work have the request, evidence, and your findings together.
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.
QA asks
A courier accepts a route, delivers one order, and cannot deliver another. QA needs to check what happens next.
Task prompt
Test that a courier can accept a route, deliver an order, and mark another delivery as failed. Check the customer emails too.
Read the full task prompt
Test that a courier can accept a route, deliver an order, and mark another delivery as failed. Check the customer emails too. Follow-up: Re-test accepting a route, delivering one order, and marking another delivery failed in the browser. Use demo orders with customer email addresses and check both emails. Follow-up: Summarize the completed browser checks and the two verified emails in a short checklist.
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. While Gentlybot is working, choose Steer current run to add guidance to the active work — this is called mid-turn steering. Choose Queue as next task when the message should start fresh after the current run. When a finished result isn’t quite right, reply instead of restarting; 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.