Give your coding agent a handoff you can actually review

A request such as “add reminders” leaves several product decisions open. Who receives one? What time does it arrive? What happens when someone changes their mind? Those decisions will still get made during implementation. Writing them down first makes the result easier to review.

Here is a small handoff format you can fill in before opening your coding tool. The reminder feature below is an illustrative example, not a description of a shipped app.

Start with one person and one useful result

“A task app needs notifications” describes an implementation. “A returning customer wants a reminder for tomorrow’s task without setting it up again every day” describes a result. The second version helps you decide which behavior belongs in this change.

Fill in these six fields

1. Reader and problem: who needs this, and what gets in their way today?
2. Starting point: the screen, account state and data already available.
3. Successful path: the actions the person takes and the result they can observe.
4. Decisions: defaults and edge cases you have actually chosen.
5. Boundaries: what this change leaves for later.
6. Acceptance checks: examples that a reviewer can repeat.

A worked reminder brief

Person: A signed-in customer who already has a task.
Start: The task detail screen, with reminders off.
Path: Choose a time, save, then see that time on the task.
Decisions: Show the time zone. Ask before enabling notifications.
           If permission is denied, keep the task and explain how to enable it.
Boundaries: One reminder per task. Recurring schedules come later.
Checks: Saving shows the chosen time; editing changes it;
        deleting the task cancels its reminder;
        denying permission leaves the task usable.

Keep a separate list of unanswered questions. For example, “Should a reminder move with the customer’s time zone?” is a decision to resolve before implementation. Leaving that question visible is more useful than quietly choosing a default for the sake of finishing the document.

Make the checks observable

“Reminders work” is hard to review. “After I change the time from 9:00 to 10:00, the task shows 10:00 and the earlier reminder is cancelled” gives you a concrete check. Add an error case and a cancellation case whenever the feature triggers something outside the screen.

Ask your coding tool to map its proposed change back to these examples. If a check needs a device, a test account or a provider sandbox, identify that dependency before claiming the feature is complete.

Talk through the uncertain parts

If you find it easier to explain a feature aloud, record the discussion and turn its decisions into this brief. Then read the brief once as a reviewer: can you tell what to try, what should happen and what remains undecided?

I also build VoicePlan, a tool for planning by voice. Its voice-planning walkthrough describes a session structure and the MCP handoff to coding tools. The useful artifact is still the same: a set of decisions and checks you can inspect before implementation starts.

For an existing product, start by writing the brief for one small change. Keep it beside the code review, update it when a decision changes, and verify the observable examples before you ship.