How the /discover Command Initiates and Chains Multiple PM Skills

The /discover command orchestrates a seven-step product discovery workflow by dynamically resolving modular skill definitions from the pm-product-discovery/skills/ directory, allowing the Claude plugin engine to chain brainstorming, assumption analysis, and experiment design without hard-coded business logic.

The phuryn/pm-skills repository implements a modular approach to product management automation through composable PM Skills units. When users invoke the /discover command with a product idea, the system executes a carefully sequenced pipeline where each phase references specialized skills stored as independent markdown files, enabling runtime flexibility and extensibility across the discovery process.

Entry Point: Command Definition in discover.md

The workflow originates in pm-product-discovery/commands/discover.md, which defines the command’s description, argument hints, and the seven-step execution script. Rather than embedding business logic directly, this file declares skill names that the underlying Claude plugin engine resolves at runtime. This declarative approach allows the command to remain lightweight while delegating complex operations to dedicated skill modules located in the skills/ directory.

The Seven-Step Skill Chain

The /discover command progresses through a predefined sequence where steps 2 through 5 invoke specific skill files, while steps 6 and 7 handle aggregation and transition. Each skill is a self-contained markdown document describing its context, instructions, and output format.

Step 2: Divergent Ideation with Brainstorm Skills

The command invokes either brainstorm-ideas-existing or brainstorm-ideas-new depending on the product context. These skills, defined in pm-product-discovery/skills/brainstorm-ideas-existing/SKILL.md and its new-product counterpart, generate divergent ideas from three perspectives: Product Manager, Designer, and Engineer. The output typically includes 10 distinct concepts that serve as input for the subsequent validation phase.

Step 3: Risk Surface Mapping with Assumption Identification

Next, the chain calls identify-assumptions-existing or identify-assumptions-new from pm-product-discovery/skills/identify-assumptions-existing/SKILL.md. This skill surfaces risky assumptions across five dimensions: Value, Usability, Viability, Feasibility, and Go-to-Market. By cataloging these uncertainties early, the workflow ensures that subsequent steps focus on the most critical unknowns rather than solved problems.

Step 4: Impact-Risk Prioritization

The workflow then executes prioritize-assumptions as defined in pm-product-discovery/skills/prioritize-assumptions/SKILL.md. This module maps assumptions on an Impact × Risk matrix to identify "leap-of-faith" items—high-impact, high-risk assumptions that require immediate validation. The skill outputs a ranked list that directs the experiment design phase.

Step 5: Validation Experiment Design

For each top-priority assumption, the command invokes brainstorm-experiments-existing or brainstorm-experiments-new from pm-product-discovery/skills/brainstorm-experiments-existing/SKILL.md. This skill generates 1–2 concrete validation experiments per assumption, specifying methodology, success metrics, and required resources to de-risk the concept efficiently.

Steps 6-7: Plan Assembly and Next Steps

Steps 6 and 7 operate without separate skill files. Step 6 aggregates outputs from previous skills stored in temporary variables, formatting them into a structured markdown discovery plan. Step 7 suggests follow-up actions such as PRD creation, interview script generation, or metrics setup, effectively bridging the discovery phase into execution.

Runtime Execution and Checkpoint Handling

The execution flow follows a strict resolution and checkpoint pattern:

1. Invocation – The user types /discover <idea> in the Claude chat interface.
2. Command Parsing – The CLI loads discover.md and begins executing the step-by-step script.
3. Skill Resolution – For each step referencing a skill, the parser looks up the name in pm-product-discovery/skills/, loads the associated SKILL.md definition, and constructs the appropriate LLM prompt.
4. Checkpoint Handling – After each skill execution, the command inserts a checkpoint message (e.g., "Here are 10 ideas…") allowing the user to confirm, skip, or refine outputs before proceeding.
5. Result Aggregation – Outputs accumulate in temporary variables until the final step formats them into Discovery-Plan-[Product-Name].md in the user’s workspace.

This architecture yields a composable workflow where any new skill can be added to the chain by referencing its name in discover.md, and existing skills can be reused by other commands such as /brainstorm or /triage-requests.

Practical Example

# Example invocation

/discover Smart notification system for our project management tool

Typical interaction flow:

Claude: Running /discover – Step 2: Brainstorm Ideas
--- (calls brainstorm-ideas-existing) ---
1️⃣ PM: "Add AI-driven priority suggestions …"
2️⃣ Designer: "Introduce a contextual tooltip system …"
3️⃣ Engineer: "Expose a webhook for external alerts …"

Claude: Here are 10 ideas. Which ones should we stress-test? (Pick 3-5)

User: Keep ideas 1, 3, 5.

Claude: Running /discover – Step 3: Identify Assumptions
--- (calls identify-assumptions-existing) ---
- Value: "Will users actually want AI-driven prioritization?"
- Usability: "Is the tooltip discoverable enough?"

Claude: Here are the riskiest assumptions. Which should we test first?

User: Prioritize the "Value" assumption.

Claude: Running /discover – Step 5: Design Experiments
--- (calls brainstorm-experiments-existing) ---
Experiment 1: A/B test a mockup of the priority UI with 200 power-users…

The final artifact, Discovery-Plan-Smart-Notification.md, contains sections for Ideas Explored, Critical Assumptions, Validation Experiments, and Next Steps.

Summary

• The /discover command is defined in pm-product-discovery/commands/discover.md and executes a seven-step workflow.
• Steps 2–5 dynamically resolve skills from the pm-product-discovery/skills/ directory, including brainstorm-ideas-existing, identify-assumptions-existing, prioritize-assumptions, and brainstorm-experiments-existing.
• Each skill is a self-contained markdown file describing context, instructions, and output format.
• The runtime uses checkpoint handling to allow user validation between steps, storing intermediate results in temporary variables.
• The modular architecture allows extending the chain by adding skill references to discover.md without modifying command logic.

Frequently Asked Questions

What is the difference between the "existing" and "new" skill variants?

The "existing" variants (e.g., brainstorm-ideas-existing) are optimized for product improvements within established markets and user bases, while the "new" variants target greenfield product development where no prior solution exists. The command selects the appropriate variant based on context clues in the user's initial idea or defaults to the existing-product pathway for augmentation scenarios.

How does the Claude plugin engine resolve skill names at runtime?

When the parser encounters a skill reference in discover.md, it searches the pm-product-discovery/skills/ directory for a subdirectory matching the skill name containing a SKILL.md file. The engine loads this markdown file, extracts the prompt template and context instructions, and sends the constructed prompt to the LLM. This resolution happens dynamically at each step, allowing the workflow to adapt based on previous outputs.

Can I customize the /discover workflow to skip specific steps?

Yes, because the workflow is defined declaratively in pm-product-discovery/commands/discover.md, you can modify the step sequence by editing this file. Removing a skill reference eliminates that step from the chain, while adding new skill references extends the workflow. Since skills are modular, you can also substitute alternatives (e.g., replacing prioritize-assumptions with a custom prioritization skill) by changing the referenced name.

Where are the outputs from each skill stored during execution?

The Claude plugin engine maintains temporary variables throughout the command session to store skill outputs. After each checkpoint, confirmed results are accumulated in these variables until the final assembly step, which formats everything into a markdown discovery plan saved to the user's workspace. Intermediate outputs are not persisted to disk unless the user explicitly requests export during a checkpoint interaction.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}