Bot template tutorial
By Šarūnas Vaitkus · about a 5-minute read
A code review tells you the code is fine. It doesn't tell you the page looks right on a phone. Your bot can attach screenshots to every interface change, and a second bot can review them against your design rules and reply PASS or FAIL with fixes. Nothing that changes how a page looks goes live without a PASS. You send the prompts below, in order, and you only look at what passed.
You send a prompt, the bot does the work, and you approve what matters.
Highlighted [brackets] are yours to replace. Copy keeps them in the prompt.
Prompt to send
For every pull request that changes how a page looks, attach before and after screenshots at desktop width and phone width, of every page it touches. Include the menu open on phone if the change touches navigation. No screenshots, no review.
Pictures let anyone judge the change in seconds, without reading code.
Pull requests with paired before and after screenshots for every affected page.
Prompt to send
As the design reviewer, open the preview of the actual pull request in a real browser and review that, not a drawing or a description. Measure what matters: text contrast, tap target sizes, spacing and how the page reflows on a phone.
The real page is the source of truth. Mock-ups hide the problems that only show up in the browser.
Reviews based on the live preview, with measurements instead of opinions.
Prompt to send
Write down the design rules for [your website address] from what's already there: colours, type, spacing, buttons, and what to avoid. Add basic accessibility: readable contrast, tap targets of at least 44 pixels, and a clear focus outline for keyboard users. Show me the rules before you use them.
A reviewer without rules ends up arguing taste. With rules, a FAIL has a reason.
A short rules page the reviewer and the builder both follow.
Prompt to send
Reply to each screen change with PASS or FAIL. For a FAIL, list each problem with the page, what's wrong and a short fix the builder can paste straight into its next step, for example "make the menu links at least 44 pixels tall". Small things that don't block a PASS go in a separate list of nits.
Short, specific fixes are quicker to act on than a long critique.
A clear verdict on every change, with fixes ready to hand back.
Prompt to send
When the design reviewer says FAIL, fix every listed problem in the same pull request, attach new screenshots and ask for a fresh review. Merge only after a PASS and a passing code review.
One pull request, one loop, until it's right.
Changes that reach you only after they've passed both reviews.
Prompt to send
Look at the design reviews from the last month. Turn the problems that came up more than once into a checklist, and save it as a skill the reviewer and builder both use.
If the same note keeps coming back, it belongs in the rules, not in the next review.
A design checklist built from real mistakes.
Prompt to send
From now on, include the design checklist at the start of every brief you give a coding agent for a screen change, and ask it to check its own screenshots against the list before it asks for a review.
The cheapest fix is the one made before the review.
Fewer FAILs, and faster PASSes.
Prefer one prompt? Send this instead.
Prompt to send
Add a design gate to [your repo], in this order: before and after screenshots at desktop and phone width on every screen change, reviews of the real preview, written design and accessibility rules, PASS or FAIL replies with short fixes, fixes and fresh reviews in the same pull request, a checklist built from repeat problems, and that checklist in every brief to a coding agent. Show me the rules before the first review. Ask me before any major design change goes live, before deleting anything, spending money or sending anything outside.
It bundles its questions, so you're not pinged all day.
Start with the screenshot rule. It changes nothing on its own.