How Commands Execute Chained Skills in pm-skills: A Technical Deep Dive

Commands in pm-skills execute chained skills by parsing markdown workflow files to extract ordered skill references, loading each skill's definition from its respective SKILL.md file, and sequentially invoking LLM prompts where the output of each skill becomes the input context for the next.

The phuryn/pm-skills repository implements a unique markdown-driven orchestration system where product management workflows are defined as executable documents. Understanding how commands execute chained skills requires examining the relationship between command definitions, skill specifications, and the validation layer that ensures workflow integrity.

Understanding the Command Architecture

Command Files as Markdown Workflows

In pm-skills, a command is not a traditional script or binary but a markdown file that describes a multi-step workflow. These files reside in structured directories such as pm-market-research/commands/ and contain natural language descriptions interspersed with executable directives.

The system treats these markdown files as declarative orchestration documents. When you run a command, the execution engine reads the file sequentially, identifying specific skill invocations through standardized markdown formatting rather than complex syntax.

Skill References and Syntax

Skills are invoked within command files using bold markdown syntax: **skill-name**. This convention allows the parser to extract skill references while maintaining human-readable documentation. For example, the research-users.md command contains explicit calls such as:

Apply the **user-personas** skill:
Apply the **user-segmentation** and **market-segments** skills:
Apply the **customer-journey-map** skill:

(See lines 35-38, 46-48 of pm-market-research/commands/research-users.md【/cache/repos/github.com/phuryn/pm-skills/main/pm-market-research/commands/research-users.md#L35-L48】)

The Four-Step Execution Pipeline

Step 1: Parsing the Command Markdown

The execution engine begins by reading the command markdown file and extracting every **skill-name** reference in order of appearance. This sequential extraction determines the execution order, creating a list of skill invocations that must be satisfied. The parser identifies these references through pattern matching, ensuring that only properly formatted skill calls are recognized as executable steps.

Step 2: Loading Skill Definitions

Each referenced skill must exist as a SKILL.md file located under pm-<area>/skills/<skill-name>/. When the engine encounters a skill reference, it loads the corresponding definition file to retrieve:

• The expected input format and context requirements
• The output format specification
• The prompt template that will be sent to the LLM

For instance, the user-personas skill definition in pm-market-research/skills/user-personas/SKILL.md specifies that the output must contain structured personas with fields for name, role, JTBD, pains, gains, behavioral pattern, and prevalence (See lines 1-12)【/cache/repos/github.com/phuryn/pm-skills/main/pm-market-research/skills/user-personas/SKILL.md#L1-L12】.

Step 3: Invoking the LLM

With the skill definition loaded, the engine constructs a prompt by combining the skill's template with the current execution context. The context contains all data produced by previous skills in the chain. The engine then calls the LLM (or any registered executor) with this constructed prompt.

The LLM processes the request according to the skill's specifications and returns structured output. This output is validated against the skill's declared output format before being accepted into the workflow context.

Step 4: Chaining Results Between Skills

The output of each skill execution is stored in the context dictionary under the skill name. This chaining mechanism ensures that when the engine proceeds to the next skill in the sequence, the previous results are available as input data. The process repeats iteratively until the final skill completes, at which point the engine assembles the command's final report from the accumulated context.

This context-passing architecture enables complex multi-stage workflows where later skills build upon the analysis performed by earlier ones, creating cohesive deliverables from discrete AI operations.

Validation and Safety Checks

Before execution occurs, the validate_plugins.py script enforces workflow integrity by verifying that every **skill-name** referenced in a command actually exists as a corresponding SKILL.md file. This validation occurs at lines 182-190 of the validator【/cache/repos/github.com/phuryn/pm-skills/main/validate_plugins.py#L182-L190】, preventing runtime failures from broken skill references.

The validator ensures that:

• All bold references in command files resolve to existing skill directories
• No orphaned skill calls exist in workflow definitions
• The command-to-skill dependency graph remains intact

Real-World Example: The research-users Command

The research-users.md command demonstrates a complete chained execution flow across four distinct stages:

1. Data Ingestion: Accepts raw research data as initial context
2. Persona Generation: Calls the user-personas skill to create 3-4 distinct personas from the data
3. Segmentation Analysis: Simultaneously invokes user-segmentation and market-segments skills to build behavioral segments and map them to the previously generated personas
4. Journey Mapping: Applies the customer-journey-map skill to produce a comprehensive journey map across product stages, utilizing all previously generated context

Each skill in this chain depends on the output of the previous steps. The persona data feeds into the segmentation logic, which then informs the journey mapping, creating a coherent analytical pipeline from raw data to strategic deliverable.

You can execute this workflow using the CLI:

# Run a command (the CLI reads the markdown and executes the workflow)

pm-skills run /pm-market-research/commands/research-users.md \
    --input "survey_results.csv"

The underlying execution logic follows this simplified pattern:

# Simplified pseudo-code of the executor

def run_command(command_path):
    steps = parse_markdown(command_path)          # → list of skill names in order

    context = {}
    for skill_name in steps:
        skill_md = load_skill_md(skill_name)      # e.g. user-personas/SKILL.md

        prompt = build_prompt(skill_md, context)
        result = call_llm(prompt)                 # LLM generates output

        context[skill_name] = result               # feed to next step

    return assemble_final_report(context)

Summary

• Command Structure: Commands are markdown files that use bold syntax (**skill-name**) to declare executable workflow steps
• Skill Location: Each skill definition resides in pm-<area>/skills/<skill-name>/SKILL.md with input/output specifications and LLM prompts
• Context Chaining: The execution engine maintains a context dictionary that passes the output of each skill as input to the next, enabling sequential data transformation
• Validation Layer: validate_plugins.py prevents broken workflows by verifying all skill references exist before execution (lines 182-190)
• Execution Order: Skills execute in the order they appear in the markdown file, creating a declarative pipeline from raw inputs to final reports

Frequently Asked Questions

What file format does pm-skills use for commands?

Commands in pm-skills are standard markdown files that combine human-readable documentation with executable directives. The system parses these files to extract skill references while preserving the document's value as workflow documentation. This format allows product managers to read and modify workflows without writing traditional code.

How does the execution engine pass data between skills?

The engine maintains a context dictionary that accumulates results throughout the workflow. When a skill completes, its output is stored in this context under the skill name. Subsequent skills receive the entire context object, allowing them to reference previous outputs by name. This implicit data passing eliminates the need for explicit variable assignments while maintaining clear data lineage.

What prevents broken skill references in commands?

The validate_plugins.py validator scans all command files before execution to ensure every bold skill reference matches an existing SKILL.md file in the skills directory. This static analysis catches missing dependencies at validation time rather than runtime, preventing workflow interruptions due to missing skill definitions (see lines 182-190 of the validator source).

Can skills be executed independently of commands?

While skills are designed to function as composable units within command chains, the repository structure suggests they are primarily invoked through the command execution engine. Each skill's SKILL.md contains the complete prompt and format specifications necessary for standalone execution, though the typical usage pattern involves orchestration through command files that provide the initial context and sequential ordering.

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