brieflisted

# brief The brief is the product-level document: what is being built, for whom, what is in and out, how success is measured, and why the rejected ideas were rejected. team-planner writes it in the CEO's words from a brainstorm or from a document the CEO brought. It says what, never how (no stack, schema or library — ADR material) and feature detail (a flow, a screen, an API) only in the appendix, in the CEO's words verbatim — the spec (docs/specs/) is written from it at /kickoff, so nothing the CEO said about a feature is cut. 2–4 pages; link, never paste. It is not injected into sessions: docs/CHARTER.md (under 60 lines) is derived from it and is the injected yardstick. ## Slots — the completeness check, asked after the brainstorm, never before 1. Who has the problem, and how they cope today 2. What changes for them when this exists; why now 3. Decided — the MVP capabilities, one line each (3–7) 4. Later, and Rejected with the reason 5. Non-goals — at least three, concrete ("no multi-tenancy", "not real-time") 6. First milestone, and the kill criterion (what would make the CEO stop) 7. Constraints: language/runtime, deployment target, integrations, data/security/regulation, cost ceiling, deadline 8. Success metric — a number or an observable fact; if it cannot be measured, ask again 9. Riskiest assumption and the cheapest way to test it; why existing tools do not solve it 10. Quality bar stricter than the default; existing assets to reuse; areas the CEO decides personally