You built two thirds of a settings page. The layout is roughly right, one section is stubbed, and you know the parts that still need work. Now you want an agent to finish it. If you paste a vague paragraph like "make this look better and wire up the save button," you get back guesswork and a wasted turn.
The fix is a fixed structure you fill in every time. Three parts: what the screen looks like now, what it should look like when done, and the rules the agent must not break. Capture each part as an item in a single review, publish once, and hand over the link. The agent reads the clean markdown version of that same review and works from your actual screen instead of imagining it.
Why three parts, and why one review
An agent needs a starting point, a target, and boundaries. Drop any one of those and it fills the gap on its own. Skip current state and it re-derives the layout from scratch. Skip intended state and it changes the wrong things. Skip constraints and it swaps your component library or renames your fields.
Putting all three in one review keeps them together. You get a public link, a PDF or Word doc if a person needs to sign off first, and markdown the agent reads directly. That combined output is the point of a human-to-agent handoff: one artifact that serves both the reviewer and the machine. Start it at a fresh review and add items in order.
The template
Item 1: Current state
Capture the screen as it is right now. Click Capture screen, share the tab, and crop to the section you are handing over. Add one comment that describes what exists and what is unfinished. Be literal.
Settings page, Notifications tab. The email toggle and SMS toggle render and hold state. The "Quiet hours" block below is a placeholder div with hardcoded text. The Save button exists but does nothing on click.
Use numbered pins to point at the exact elements you mention. Pin 1 on the placeholder, pin 2 on the dead Save button. That removes the "which button" round trip. The agent maps each pin to a spot on the still, so the words "pin 2" mean something concrete.
Item 2: Intended state
This is the target. If you have a design mockup open, capture it as a second screenshot so the agent sees before and after side by side. If you only have it in your head, make a free-floating comment with no screenshot and describe the finished behavior.
Quiet hours should be a real control: a start-time and end-time picker, both saving to user_settings.quiet_start and quiet_end. Save should POST all three settings to /api/notifications and show a success toast. Match the spacing of the toggles above.
Name real fields, real endpoints, real component names. "quiet_start" is actionable. "the time thing" is not. If you would rather talk than type, dictate the comment with the browser's built-in speech recognition in Chrome or Edge, then clean up the field names afterward.
Item 3: Constraints
The rules that keep the agent from breaking things you already decided. This is where you protect the two thirds that already work.
Use the existing Toggle and Button components from /components/ui. Do not add a date library; use the native time input. Do not touch the email or SMS toggles, they are done. Keep the current Tailwind spacing scale.
Constraints are the part people skip, and it is the part that costs the most when it is missing. An agent that reaches for a new dependency or restyles your working section turns a fifteen-minute fix into a review headache. Spelling out what stays fixed is how you avoid wasting a turn on a UI change.
When to adjust each part
The three parts are fixed. What goes in them shifts with the job.
| Situation | What changes |
|---|---|
| Pure visual fix, no logic | Current and intended states carry the weight. Constraints can be one line about the component library. |
| New behavior on a static screen | Intended state grows: name endpoints, payloads, and success and error states. |
| Handing off a fragile section | Constraints grow: list every file and component the agent must leave alone. |
| Multiple screens in one flow | Add a current-state item per screen, one intended-state item per screen, one shared constraints item. |
For a screen with several separate problems, add more current-state items rather than cramming everything into one comment. One item per issue keeps the agent's work in order and lets you mark each one resolved as it lands. Anyone with the link can comment on an individual item, so if a teammate spots a fourth thing, it attaches to the right spot instead of a group chat.
Publish and hand it over
Hit Publish and you get a short URL at /r/<slug>. Send that to a person. Send /r/<slug>/markdown, or paste it, to the agent. No install, no extension, no signup, and free to use. If you published without an account, the review sticks around for 30 days and you can claim it later by signing in.
The same structure works past the first handoff. When the agent returns its changes, capture the new screen, and your current-state item for the next round is already half written. That back-and-forth is the feedback loop that gets a build shipped. For teams that hand off often, keep this saved as your standard shape the way you would keep a reusable how-to template everyone copies.
Next time you stop halfway on a screen, open a review before you close the tab. Current state, intended state, constraints. Publish, share the link, and let the agent read exactly what you meant.