author-brief

# Skill: author-brief Turn any unstructured external input into a DoR-compliant product brief, then queue it so `workspace-status` can surface it immediately. `author-brief` stops at **draft** — it does not decompose the brief into specs and does not set `Status: Ready`. Those are `receive-brief`'s job. The two skills have distinct entry points and must stay distinct. ## When to invoke - The user has an email thread, a prose description, a Linear Issue body, or a stakeholder message they want to turn into a brief. - The unit of work is larger than one feature (otherwise use `new-spec`). - The brief does not yet exist as a file in `docs/product/briefs/`. If the input is already a well-formed brief file, go directly to `receive-brief`. If the user wants to record a decision already made, use `new-adr`. ## Procedure ### 1. Ingest Accept whatever the user provides: a pasted email, a prose block, issue text, a verbally-described idea. Do **not** reject partial or messy input — the brief template is a guide, not a form. The goal is to extract enough signal to elicit what is missing. ### 2. Identify Scan the input for DoR fields already present: - **Outcome** — a user-facing or system change the input is trying to achieve; often in the subject or opening sentence. - **Appetite** — a time or effort constraint ("this needs to ship before the conference", "a sprint, not a quarter"). - **Rabbit holes** — named design traps, constraints, or things to avoid ("don't touc...