Turn the Working Brief Into a Reusable Module
The morning brief you just built follows a pattern you can use for everything
In the previous chapter you built a morning brief. You decided what outcome you wanted, which sources the assistant should read, what shape the output should take, and what the assistant should never do without your approval. You probably did most of that thinking inside the conversation, correcting the assistant's guesses until the output matched your expectations.
That process is the reusable pattern. Every in this book, from an email to a to a , starts the same way: a rough wish refined through a small set of questions until it becomes a specification the assistant can build from reliably.
This chapter names that pattern so you can use it deliberately. Once you see the structure, building new modules takes five minutes of self-interview instead of an hour of trial and error.
Seven questions turn a vague wish into a the assistant can build
Every in this book starts the same way. You have a rough idea: 'I want a morning brief' or 'I want help with email' or 'I want to track my decisions.' That idea is not a prompt yet. It becomes a prompt after you run it through seven questions.
You do not need to answer all seven before you start. The more you answer, the better the assistant's first draft. The questions you skip are the ones the assistant will have to guess about, which means you will spend time correcting guesses instead of reviewing useful work.
The self-interview catches gaps you would discover the hard way later
The most common failure in building an assistant is skipping the question about what should happen when something goes wrong. Without that question, the assistant will guess. It might invent when a source is missing. It might skip a section silently. It might take an action you did not authorize.
The second most common failure is skipping the question about approval boundaries. Without that boundary, the assistant treats everything as authorized. An email that can send replies without your review is a module that will eventually send a reply you would never have approved.
These failures are predictable, and the self-interview prevents them. Every time you answer 'what should happen when something goes wrong' and 'what needs my approval,' you are building a that is safe to reuse. Every time you skip those questions, you are building a you will need to supervise manually.
The self-interview is a called
What you did in the morning brief chapter, and what the seven questions formalize, has a name: . You interview yourself about what you want before you ask the assistant to build it. The answers become the prompt.
is useful because it separates two kinds of thinking. One kind is deciding what you want: outcomes, sources, boundaries, review criteria. The other kind is telling the assistant how to build it: the prompt itself. When you mix these together in a single conversation, you spend most of your time correcting the assistant's guesses about what you wanted. When you separate them, the assistant's first draft is closer to useful because the specification was clear from the start.
The is the document that captures all seven answers
When you write down the answers to the seven questions, the result is a . This is the portable specification you can hand to any assistant, any coding agent, or any scheduled routine. It contains everything needed to build or run the without you re-explaining the .