How Skill Chaining Enables Multi-Step Workflows Like /discover in PM-Skills
Skill chaining connects reusable skill modules into sequential workflows where each step's output becomes the next step's input, enabling complex commands like /discover to execute without bespoke glue code.
The phuryn/pm-skills repository implements a modular architecture where skill chaining transforms individual capabilities into comprehensive product management workflows. By treating commands as verbs that orchestrate self-contained skills, the system eliminates code duplication while supporting 42 distinct multi-step workflows across nine plugin domains.
What Is Skill Chaining in PM-Skills?
Skills as Atomic Units
Each skill is the smallest reusable unit of logic, encapsulated in its own directory with a SKILL.md specification file. For example, brainstorm-ideas-new, identify-assumptions-new, and prioritize-assumptions each handle discrete tasks independently. These skills reside in pm-product-discovery/skills/ and expose a standardized interface that accepts context and returns structured results.
Commands as Orchestration Verbs
Commands like /discover and /plan-launch are defined in markdown files under pm-product-discovery/commands/ (e.g., discover.md). According to the architecture specification in CLAUDE.md, a command is explicitly defined as a verb that chains one or more skills. The command markdown contains no executable logic—only a declarative sequence of skill references that the engine resolves at runtime.
How the /discover Command Executes a Skill Chain
When a user invokes /discover Smart notification system for our project-management tool, the engine executes a five-phase pipeline:
- Parse the Command Definition – The system loads
pm-product-discovery/commands/discover.md, which defines the workflow as a sequence of four specific skills. - Execute the First Skill – The engine runs
brainstorm-ideas-new(orbrainstorm-ideas-existingdepending on context), which returns a list of product ideas. - Feed Results Forward – The output from step 2 passes as input to
identify-assumptions-new, which extracts and structures assumptions from the selected ideas. - Iterate Through Remaining Steps – The chain continues with
prioritize-assumptions, followed bybrainstorm-experiments-new, each consuming the previous step's accumulated context. - Aggregate Final Artifacts – After the last skill completes, the command assembles the outputs into a cohesive discovery plan document formatted in Markdown and returns it to the user.
This sequential execution model ensures that complex workflows remain composable and maintainable.
Implementation Architecture
The chaining mechanism relies on a context-passing pattern where each skill updates a shared context dictionary. The pseudo-code in the repository illustrates this flow:
def run_command(command_name, args):
steps = COMMAND_DEFINITIONS[command_name].steps # read from <command>.md
context = {"user_input": args}
for step in steps:
skill = load_skill(step.name) # e.g. "brainstorm-ideas-new"
context = skill.run(context) # each skill returns updated context
return render_output(context) # final discovery plan
Because skills are self-contained and communicate only through the context object, the same skill can participate in multiple command workflows without modification. This architecture supports 42 different chained workflows across nine plugins while maintaining a DRY (Don't Repeat Yourself) codebase.
Key Files and Skill Definitions
The /discover command chains four specific skills defined in the following locations:
pm-product-discovery/commands/discover.md– Defines the four-step workflow orchestration.pm-product-discovery/skills/brainstorm-ideas-new/SKILL.md– Generates initial product ideas from multiple perspectives.pm-product-discovery/skills/identify-assumptions-new/SKILL.md– Extracts underlying assumptions from the generated ideas.pm-product-discovery/skills/prioritize-assumptions/SKILL.md– Ranks assumptions by impact and risk.pm-product-discovery/skills/brainstorm-experiments-new/SKILL.md– Designs validation experiments for high-priority assumptions.
Each skill directory contains a SKILL.md file specifying its inputs, outputs, and internal logic, ensuring clear contracts between chained components.
Summary
- Skill chaining connects discrete, reusable skills into sequential workflows where output from one step becomes input for the next.
- Commands like
/discoverare defined declaratively in markdown files (e.g.,discover.md) that specify skill sequences without containing executable logic. - The
phuryn/pm-skillsrepository implements 42 chained workflows across nine plugins using this architecture. - Skills are self-contained units with standardized interfaces defined in
SKILL.mdfiles, enabling reuse across multiple commands. - Context passing between skills eliminates the need for bespoke glue code while maintaining workflow flexibility.
Frequently Asked Questions
What is the difference between a skill and a command in PM-Skills?
A skill is a self-contained unit of logic that performs a specific task (like generating ideas or prioritizing assumptions), defined in its own SKILL.md file. A command is a user-facing verb (like /discover) that orchestrates multiple skills into a sequential workflow by referencing them in a command markdown file.
How does skill chaining handle data flow between steps?
Each skill receives a shared context dictionary containing the accumulated outputs from previous steps. After execution, the skill returns an updated context with its results appended. The engine passes this updated context to the next skill in the chain, creating a pipeline where data flows transparently without explicit wiring code.
Can I customize the /discover workflow without modifying source code?
Yes. Since command definitions live in markdown files like pm-product-discovery/commands/discover.md, you can reorder, add, or remove skill references by editing the declarative workflow definition. The skills themselves remain unchanged, and the engine automatically resolves the new sequence at runtime.
Where is the skill chaining architecture formally specified?
The architecture is formally defined in CLAUDE.md at the repository root, which specifies that commands are verbs that chain one or more skills. This specification document governs how the 42 workflows across nine plugins are structured and executed.
Have a question about this repo?
These articles cover the highlights, but your codebase questions are specific. Give your agent direct access to the source. Share this with your agent to get started:
curl -s "https://instagit.com/install.md" Maintain an open-source project? Get it listed too →