receive-brief

# Skill: receive-brief Receive an existing product brief — a PRD, a solution handoff, a packet of work product handed from someone else — and route it into delivery when the user is ready. 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, **mark it Ready** when the human gate passes, and **scaffold** only each confirmed slice. The brief becomes a live tracker whose coverage rolls up from the specs it spawned. ## Output rendering Table — When presenting several items that share the same fields, render a Markdown table. Cap at ~5 columns; beyond that, switch to a per-item detail list. Right-align numeric columns. Key–value / one record — For a single record's fields, use an aligned key: value list, not a two-row table. ## 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...