# Brief > Facilitated product ideation. Takes a problem brief as input, explores solution approaches, and records vision, value propositions, key features, differentiation and user journeys as a product brief. Triggers on "/dpm:brief". - Skill: `ninthspace/brief-2` (Agent Skill) - Install (CLI): `npx skillmds@latest add ninthspace/brief-2` - Raw SKILL.md: https://api.skillmd.com/api/skills/ninthspace/brief-2/raw - Safety review: pending (external: skill-scanner WARNING, skillspector PASS) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: ninthspace (https://skillmd.com/u/ninthspace) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/ninthspace/brief-2 --- # Facilitated Product Ideation Turn a problem brief into a product brief through guided conversation. The product brief captures *what* is being built and *why this approach* — the bridge between problem discovery and requirements. Everything this skill records is a typed tool call. It composes no markdown, allocates no numbers, names no files, and never reads back what it or another skill wrote. Follow the shared conventions in `dpm/shared/skill-conventions.md` — read that file at startup. This skill uses **Gate Presentation**, **Perspectives**, **Conversational Output**, **Written Deliverable Length**, **Cross-References** and **Artifact Publishing** from it. ## Input Resolve the problem this brief builds on, in this order. 1. If `$ARGUMENTS` names a document — a ULID, or a human reference as another skill printed it — `mcp__plugin_dpm_dpm__read_problem_brief` on it. A reference goes through `mcp__plugin_dpm_dpm__resolve_reference` first, which returns the row it names or refuses; a ULID is already the id and needs no resolving. 2. If `$ARGUMENTS` is a description, use it as the starting context. 3. Otherwise `mcp__plugin_dpm_dpm__list_problem_brief` and offer the results with `AskUserQuestion`, showing each title. **Ask which one; never take the most recent.** Recency answers a different question, and the two diverge the moment a project has more than one line of work. 4. If there are none, ask the user to describe the product. **There is no chain to discover and no slug to match.** A brief either names a problem brief that exists or names none; the id resolved here becomes `parent_id` in Phase 8, and `mcp__plugin_dpm_dpm__read_problem_brief` refusing an id is the only "does it exist" check there is. ## Startup ### Session Follow the shared **Session Startup** procedure with `skill: 'dpm:brief'`. **The resolved problem brief's id belongs in `state`**, because Phase 8 needs it and a run resumed after Phase 1 has no other way back to it. ### Roster `mcp__plugin_dpm_dpm__list_agent` with `include_body`, for **Perspectives** in Phases 2 and 5. The traits are body columns, so without it the roster arrives as names and roles. Use only what the row carries. ### Library Follow the shared **Library Check** procedure with scope keyword `brief`. Carry what it returns into Phases 2 and 6, where approaches and claims meet recorded standards. ### Retro awareness Follow the shared **Retro Awareness** procedure. If incorporated: - **Patterns worth reusing** inform Phase 2 — a proven approach belongs in the candidate set. - **Codebase discoveries** inform Phase 6 — a surfaced strength or limit bounds what can be claimed. - **Scope surprises** inform Phase 5 — a category that ran large is where essential and enhancing need a sharper line. - **Criteria gaps** inform Phase 4 — a value claim that proved untestable is made concrete. ## Process Work through the phases **one at a time**, one gate per turn, each with `AskUserQuestion`. ### Phase 1: Problem recap Summarise the problem from the resolved input and confirm it. From a problem brief this is quick: verify nothing has changed. Read its constraints with `mcp__plugin_dpm_dpm__list_document_section` and `mcp__plugin_dpm_dpm__read_document_section` with `include_body`, and restate them for confirmation rather than asking again — a restatement is a quotation, and the body it quotes is withheld unless asked for. Add whatever has changed since. **Constraints are collected here and nowhere else in this skill**, so anything not surfaced now is lost to the product brief. ### Phase 2: Solution approaches Explore 2–4 distinct approaches, each a plausible path rather than a strawman: what it looks like in practice, its strengths and risks, and how it sits against the constraints. An approach ruled out by a constraint identifies a constraint worth recording — add the deciding one to the set Phase 1 collected, whether or not the problem brief already named it. Converge on a direction rather than locking in every detail. **Perspectives**: after presenting the approaches, follow the shared **Perspectives** procedure — two or three agents whose expertise bears on the choice. ### Phase 3: Vision What the product is, who it is for, and why it matters, in a paragraph. Not a tagline — an articulation of intent that can settle decisions downstream. Present a draft and refine. ### Phase 4: Value propositions Two to four propositions, each answering why someone would use this rather than the alternative. Outcomes, not features. **Each has to be concrete enough to be wrong.** "Saves time" is a promise nobody can hold the product to; "a brief that took two days takes an afternoon" is one they can. Where a proposition cannot be stated that way, say which and offer the form that can be. ### Phase 5: Key features The capabilities that deliver those propositions, grouped as **essential** — required for the first iteration — and **enhancing**. Each feature traces back to at least one proposition; one that traces to none is either a proposition nobody stated or a feature nobody needs, and saying which is the point of asking. **Perspectives**: after the list is drafted, follow the shared **Perspectives** procedure — two or three agents on complexity, testability and priority. ### Phase 6: Differentiation What makes this different from what already exists — in approach, scope, audience, experience or technology, not only in features. Be honest about where an alternative is stronger; a differentiation that concedes nothing is one nobody will believe. ### Phase 7: User journeys Two or three narratives, each from trigger to outcome: who the user is and in what context, what prompts them, what they do — steps rather than screens — and what they end up with. Stories, not flowcharts. ### Phase 8: Summary Render the complete brief in the message body from what the phases settled, then gate: "Approve this brief?" with `Approve` / `Request changes` / `Stop`. On approval, agree a title and a short kebab-case slug and call `mcp__plugin_dpm_dpm__create_product_brief`, passing the problem brief resolved in Input as `parent_id`. That call assigns the number, which nothing here works out. **`parent_id` is the lineage, and it is checked as it is written.** The row carries a `parent_kind` pinned by a composite foreign key, so a brief hung off a spec or a review is refused rather than stored — where a slug that matched the wrong file resolved silently and stayed wrong. A brief with no problem behind it passes no `parent_id` at all; the argument is optional, and an absent parent is a brief that started from a description. Each phase's prose is then one `mcp__plugin_dpm_dpm__create_document_section` row against the id it returned, with its heading and its `position`: *Vision*, *Value Propositions*, *Key Features*, *Constraints*, *Differentiation*, *User Journeys*. Then `mcp__plugin_dpm_dpm__update_product_brief` sets `status` to `complete`. On *Request changes*, return to the phase the change belongs to and leave the status alone. **Write the rows only once the brief is approved.** A brief half-written and then abandoned at the gate is a document a later run will offer as input, and nothing on it says which phases were real. ## Output There is no file to save. The brief is the rows; the document is a projection of them, and a pre-commit check keeps the two from diverging. **Do not tell the user a path.** Building one from a number and a slug is the filename construction this skill does without, and it is wrong the moment the projection moves where a kind renders. An artifact can be published from this output on request — follow the shared **Artifact Publishing** procedure. It is separately confirmed and never the default. For `brief` the artifact is a value-proposition canvas: each proposition set against the user need it answers and the features that serve it — so a proposition nothing delivers shows up as an empty column, and a feature serving nothing shows up as an orphan. The rows state both halves; only the canvas makes the mismatch a shape rather than a cross-reference. If you cannot write the one-line justification for what the visual carries that the prose cannot, it has not earned its place. Record it only once published, with `mcp__plugin_dpm_dpm__create_artifact` carrying its address, title and publication time, then `mcp__plugin_dpm_dpm__create_artifact_document` binding it to this brief — so the rows never claim a visual a reader cannot reach. ### After the brief - `/dpm:architect` to explore architecture and record decisions (recommended for non-trivial products) - `/dpm:spec` to go straight to requirements where the architecture is already clear ## Guidelines - **Facilitate, stay conversational.** These are conversations, not forms. - **Build on answers.** Each question responds to what the user just said. - **Skip what the input already covers**, acknowledge it, and move on. - **One phase at a time**, and match depth to the product. - **Product, not project.** What it is and why it matters — not timelines, teams or delivery. - **Concrete over abstract.** Phases 4 and 6 both turn on this: a proposition has to be falsifiable and a differentiation has to concede something. - **Correct yourself sparingly**, per the shared convention.