“Make onboarding feel less janky” identifies a concern, but it leaves the team to decide which users are affected, what is wrong, and what success would look like. Make those decisions explicit before the coding agent builds.
The input
A rough request and whatever prompted it. Illustrative examples include:
- “New customers get stuck inviting their teammates.”
- “People cannot tell whether their import finished.”
- “The empty dashboard does not explain what to do next.”
You can start without research. Mark what you suspect as an assumption and keep it separate from what you observed.
The flow
1. Preserve the original ask. In your product’s Intents list, choose New Intent and save the request as a brief. Include the relevant text, not only a link. Saving the brief does not approve a build.
2. Clarify the problem with the team. Name the affected user, the moment they struggle, and why it matters. For teammate invitations, distinguish “the button is hard to find” from “the invitation email never arrives.” They need different changes.
3. Define an observable result. For example: “After sending an invitation, the inviter can see its delivery state and retry a failed delivery.” If you want a numerical improvement, establish the baseline and choose a target; do not let a draft invent either.
4. Ask the coding agent for a proposal. Give the original request and these decisions to the teammate who runs the agent. Have it identify constraints, failure cases, and remaining questions from the repository, then attach the original request to the connected proposal.
5. Review and approve the revision. Compare what the agent understood with the result you want. Request corrections, review the changed proposal, and use Authorize implementation when the whole revision is ready. A quality score is not a substitute for this decision.
The output
- An objective that names the problem and why it matters.
- Observable outcomes with checks the engineer can run.
- Scope and hard boundaries agreed with the team.
- Evidence linked to the claims it supports, with assumptions labeled.
- Open questions that still need a decision.
Try it with one request
Take a request you have been meaning to clarify. Finish these sentences: “This affects…”, “They struggle when…”, and “After the change, they can…”. Give those answers and the original wording to your engineer for the proposal review.
Related
Bring this workflow to your team.
Keep the evidence, decisions, and follow-up work together in your product.
Start with Pathmode