receive-brieflisted

# Skill: receive-brief Receive a product brief — a PRD, a solution handoff, a packet of work product handed from someone else — and route it into delivery. A brief spans several features and carries the *what/why*; a spec is one feature and carries the *how*. `new-spec` authors one feature; this skill is the inbox a level above it: **elicit** what the brief is missing, **decompose** it into independently-shippable slices, and **execute** each slice through the normal `new-spec` → `work-loop` pipeline. The brief becomes a live tracker whose coverage rolls up from the specs it spawned. ## When to invoke Invoke when the unit of work that arrives is **bigger than one feature** and authored by someone other than the implementer — product hands engineering a brief. If the user is authoring a single feature themselves, that's `new-spec`, not this skill. If they want to record a decision already made, that's `new-adr`. The tell is multiplicity: one outcome, several features, no home. A brief lives at `docs/product/briefs/<slug>.md`. Copy the bundled template (your installer places a `_template.md` in that directory) and fill what you have. The shape is a guide, not a gate — see the Elicit stage. ## Two shapes, one toggle The only structural choice is whether the brief carries **user stories**: - **Shape A — no stories.** You derive spec boundaries from the Outcome and Scope, and surface the cut for confirmation. Coverage is **spec-granular** ("is `password-reset` shipped?"