Discover

Facilitated Problem Discovery

Guide the user through understanding their problem before jumping to solutions. Each phase is a gate the user controls.

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

If $ARGUMENTS is given, use it as the starting context for Phase 1 rather than asking from scratch, and still confirm the understanding before proceeding. Otherwise begin at Phase 1.

Startup

Session

Follow the shared Session Startup procedure with skill: 'dpm:discover'.

state holds what each phase settled, written as it is settled — this skill's phases build on each other, so a phase recorded only in the conversation is one that has to be re-facilitated after a compaction.

Roster

mcp__plugin_dpm_dpm__list_agent with include_body, for Perspectives in Phases 1 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 discover. Carry what it returns into Phase 5, where constraints meet recorded standards.

Retro awareness

Follow the shared Retro Awareness procedure. The category is what the four rules below key on, so an observation whose category was not resolved cannot be routed to a phase. If incorporated:

• Scope surprises inform Phase 5 — a boundary that surprised someone gets sharper edges here.
• Criteria gaps inform Phase 4 — a category the last round missed is probed explicitly.
• Codebase discoveries inform Phase 5 — a surfaced limitation is a constraint, not context.
• Testing gaps inform Phase 4 — last round's vague outcome is made concrete this round.

Codebase grounding

Survey what already exists — structure, dependency manifests, conventions — and read enough of it to know the technology choices and the domain model. Carry it into every phase; Phase 3 depends on it most directly. A greenfield project has none, which is a finding rather than a failure.

Process

Work through the phases one at a time, one gate per turn, each with AskUserQuestion.

Phase 1: Why

What the user is trying to accomplish and why it matters — the motivation, not the feature request. What problem is being solved, why now, and what happens if it is not.

Perspectives: after the user describes the problem and before Phase 2, follow the shared Perspectives procedure — two or three agents whose expertise bears on it.

Phase 2: Who

Who will use this, what they are trying to accomplish, and how technical they are.

Phase 3: Current State

How this is handled today, what is broken or missing about it, and what tools, code or workarounds are already in play. Ground the answers in the codebase read at startup rather than in what the user recalls of it.

Phase 4: Success Criteria

What "done" looks like: how anyone will know it works, what the happy path is, and which outcomes are measurable.

An outcome nobody can check is worth less than a missing one, because it is recorded and then passes on somebody's impression. Where one cannot be checked, say which, say what about it cannot be, and offer the checkable form. That is a refinement round, not a rejection of the concern.

Phase 5: Constraints

Technical constraints (language, framework, infrastructure), business constraints (budget, timeline, compliance), and what is explicitly out of scope.

This is where constraints are captured for the whole pipeline. dpm:spec reaches back past the product brief to read this phase's section and facilitates only the gaps, so a constraint left out here is one the spec has no reason to ask about.

Perspectives: before finalising, follow the shared Perspectives procedure — two or three agents on scalability, on deployment, on testability.

Phase 6: 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_problem_brief — that call assigns the number, which nothing here works out. 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: Why, Who, Current State, Success Criteria, Constraints, Scope Boundaries.

Then mcp__plugin_dpm_dpm__update_problem_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 discover the artifact is a problem map: the problem at the centre with who it affects, how it is solved today, what constrains a fix, and where the scope boundary falls arranged around it — so which constraint bites which user is visible at a glance, where six sequential sections leave it to be inferred. 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:brief to explore vision, value propositions and key features (recommended for most problems)
• /dpm:spec to go straight to requirements where the solution approach is already clear
• /plan where the scope is small enough to skip planning artefacts entirely

Guidelines

• Facilitate, stay conversational. These are conversations, not forms.
• Build on answers. Each question responds to what the user just said.
• Skip what is already covered. Where the opening description settles a phase, acknowledge it and move on.
• Stay curious. Follow up where an answer is vague or an assumption looks risky.
• One phase at a time, and match depth to the problem.
• Refuse rather than record an outcome nobody can check. Phase 4 turns on this.
• Correct yourself sparingly, per the shared convention.