creating-briefslisted

# Creating Briefs A brief transforms an unstructured request into a bounded, verifiable specification that the executing agent can work from without clarification questions — and that the requester can read and say "yes, this is what I meant". Briefing is orchestrator-owned: it depends on the full conversation context, so write the brief yourself rather than delegating it. Skip when the task is trivial, already well-specified, or purely exploratory with undefined outcomes. ## Principles - **Outcomes, not solutions** — define WHAT to achieve, let the executor determine HOW. Prescribe method only when a real constraint requires it. - **Context is never assumed** — the executor hasn't read the conversation, previous work, or project history. If background matters, state it in the brief. - **Fit for purpose AND audience** — name who will use the deliverable; it shapes requirements and tone. ## Workflow ### 1. Clarify the request Extract: core intent (the outcome behind the literal words), purpose (WHY it matters — without it the executor can do technically correct work that serves the wrong goal), scope boundaries, audience, and any assumptions you're making. If critical information is missing, ask targeted questions — don't guess. ### 2. Identify applicable standards The 1–3 skills or guides that govern quality for this artefact type: `writing-skills` for skills, `conducting-research` for research, style guides for documents. Multiple standards can apply to one brief.