Turn the Idea Into a Clear Brief

A clear brief explains what a useful result looks like before the assistant starts building. You do not need a formal technical specification. Start with the person using the tool, the task they are trying to finish and the information they need. Then describe the result in terms you can observe. For the enquiry planner, a staff member chooses a category and receives a clear list of suitable follow-up questions.

Add the boundaries. The first version uses fictional information, runs locally and does not submit anything. It must not promise an appointment, invent a price or claim that a repair is available without checking. These limits are part of the product definition, not inconvenient footnotes. They help the assistant choose an implementation that matches the business situation and make it easier for you to reject an impressive feature that would mislead users.

Point to the source of truth. business-facts.md contains the prepared categories and approved example wording. If the brief and an old draft disagree, the assistant should identify the conflict rather than blend the two into a new rule. Current facts are more useful than a large amount of unorganized context. The separate context course explores that idea further; here we use one short source file so the relationship stays visible.

A definition of done describes the checks that make the first version acceptable. The planner should show the right questions for each category, provide clear feedback and remain usable with a keyboard. It should state that no enquiry has been sent. Those are concrete outcomes. Make it amazing is not a definition of done because it gives the assistant no stable way to decide when the task is complete.

You can ask the assistant to repeat the brief in its own words before acting. That reveals misunderstandings early. If it proposes sending messages, ask how that fits the local-only boundary. If it assumes a response-time promise, ask which source supports it. These are ordinary review questions. You do not need to know the underlying code to see when the proposed behavior crosses the scope you agreed.

The activity compares a vague idea with a short, bounded brief. Choose the request that names the user, result and limit. Optional practice is reading the prepared brief and finding its definition of done. There is no document to write from scratch. The goal is to recognize the small amount of clear information that helps an agent begin useful work without filling gaps with unsupported assumptions.