create-brieflisted

## What a product brief is (read first) A **product brief** is a short (1–2 page) human-authored narrative that anchors a project by stating, *before* committing to a solution: the **problem**, the **people who have it**, the **outcome that counts as success**, and the **boundaries of scope**. It is a decision-anchoring orientation doc and a scope contract — **not** a PRD (detailed requirements/user stories), **not** a vision doc (multi-year aspiration, no boundaries), and **not** an engineering spec (interfaces, schemas, sequencing). It anchors work in **both modes**. In human mode the Requirements Analyst reads it first and drives the Requirement Definition interview from it, reconciling any requirement that conflicts with the brief. In autonomous mode the Product Owner expands this brief into `docs/product/vision.md` and then answers every "is this in scope?" question against it. **Anything left implicit in the brief becomes an unbounded guess for an autonomous team that cannot ask hallway follow-ups.** The brief must be *self-sufficient*: every scope / YAGNI decision the team will face should be resolvable from the problem, the falsifiable metrics, the explicit non-goals, the stated constraints, and the priorities. Deeper rationale, sources, and the section-by-section quality bar live in [references/brief-best-practices.md](references/brief-best-practices.md). The fill-in skeleton lives in [references/brief-template.md](references/brief-template.md). ## Inputs - Oper