An agent can make a convincing interface while missing the task that matters. A useful brief connects the work to something a person can actually check.
Start with the outcome. “Build a reading list” leaves many decisions open. “Let a person save a link, find it later, and remove it” describes the job. Add the smallest example that makes success observable.
Describe the result
Write one sentence about who does what, followed by a concrete example:
A reader can save a URL with a title, search their saved links, and remove an entry. Saving the same URL twice should keep one entry.
This is an illustrative brief. It is not a statement that a reading-list product has been built or tested.
State the boundaries
Say what the first version includes and where the work must stop. For this example, the list could stay in the current browser. Account sync, team sharing, and a browser extension would need separate decisions. Name an existing storage or framework choice if the project already has one.
Include operational boundaries too: which files may change, which existing user edits must remain, and which external actions require the owner. A working credential does not explain how it may be used.
Give the agent observable acceptance steps
- Save a valid URL and title. The new entry appears once.
- Save the same URL again. The list does not gain a duplicate.
- Search a word in the title. Matching entries remain visible.
- Search a word with no match. The page explains how to clear the search.
- Reload. Previously saved entries remain, under the chosen storage policy.
- Remove an entry. It disappears and stays removed after reload.
These are acceptance examples, not a prescription to create a new automated test for every line. Use the project’s existing checks and add protection where an important behavior needs it.
Ask for a useful handoff
Request four things: what visibly changed, what was actually checked, the shortest way to try it, and what remains uncertain. A build passing is evidence about the build. It does not establish that an external service, device, or production account works.
Copy this brief
Outcome:
Who should be able to do what?
Example:
Describe one real input and the expected result.
Scope and constraints:
What belongs in this version? What existing behavior must remain?
Allowed actions:
Name the workspace and the external actions, if any, that are authorized.
Acceptance:
Give a few observable steps and their expected results.
Handoff:
Explain the visible change, actual checks, shortest acceptance steps,
and material untested or blocked areas.