How Do Skills Interact with Each Other in the pm-skills Repository

In the phuryn/pm-skills repository, skills interact through command-driven orchestration where markdown-based commands invoke atomic skills using the Apply the **<skill-name>** syntax, passing data via LLM context variables and conversation state rather than traditional function calls.

The pm-skills repository implements an LLM-native architecture where product management capabilities are modularized as discrete, self-contained units. Understanding how these skills interact with each other is essential for extending workflows or debugging execution chains. Unlike conventional codebases that rely on function imports and API calls, this repository orchestrates capabilities through declarative markdown commands that instruct the LLM to sequentially apply skills and propagate outputs through shared context.

The Two-Layer Architecture

Skills as Atomic Capabilities

Skills are self-contained markdown files located in skill-specific directories (e.g., review-resume/SKILL.md). Each skill defines a declarative description including name, description, and a step-by-step procedure executable by an LLM. These files represent single product-management capabilities such as swot-analysis, north-star-metric, or brainstorm-ideas-existing.

Commands as Orchestrators

Commands reside in */commands/*.md files (e.g., pm-toolkit/commands/review-resume.md) and expose CLI-style entry points like /discover or /plan-launch. These files contain a Workflow section that strings together one or more skills using the Apply the **<skill-name>** directive. The command file serves as the glue layer that sequences skill execution and manages context flow.

Data Flow Mechanisms Between Skills

Context Variables

Skills accept placeholders such as $RESUME, $JOB_POSTING, and $ARGUMENTS. When a command invokes a skill, it binds these placeholders to the current execution context, allowing user inputs to propagate through the workflow without explicit parameter passing.

Implicit Return Values via Conversation State

Rather than returning structured data objects, skills produce formatted markdown responses that persist in the LLM's conversation state. Subsequent skills access previous outputs by reference—for example, instructions like "Use the bullets you just generated" or "Incorporate the assumptions list" enable data sharing without explicit file I/O or memory management.

Checkpoint Prompts

Commands insert explicit user interaction points (e.g., "Checkpoint: Here are 10 ideas. Which ones should we stress-test?"). The user's response becomes the new context for the next skill, creating interactive decision points that determine subsequent execution paths.

Practical Implementation Examples

Single-Skill Command Execution

The /review-resume command demonstrates direct skill invocation without chaining:

# /review-resume – PM Resume Review

...

### Step 2: Evaluate Against 10 Best Practices

Apply the **review-resume** skill:

This command loads pm-toolkit/skills/review-resume/SKILL.md and executes its procedure as an atomic unit.

Multi-Skill Orchestration in Product Discovery

The /discover command in pm-product-discovery/commands/discover.md illustrates complex skill interaction across the discovery workflow:

# /discover – Full Discovery Cycle

...

### Step 2: Brainstorm Ideas

Apply the **brainstorm-ideas-existing** or **brainstorm-ideas-new** skill:

### Step 3: Identify Assumptions

Apply the **identify-assumptions-existing** or **identify-assumptions-new** skill:

### Step 4: Prioritize Assumptions

Apply the **prioritize-assumptions** skill:

### Step 5: Design Experiments

Apply **brainstorm-experiments-existing** or **brainstorm-experiments-new** skill:

Execution flow:

• Step 1: brainstorm-ideas-existing generates ideas stored in LLM state
• Step 2: identify-assumptions-existing consumes those ideas to produce an assumptions table
• Step 3: prioritize-assumptions ranks the assumptions and outputs a prioritized list
• Step 4: brainstorm-experiments-existing receives the ranked list to propose validation experiments

Cross-Domain Skill Chaining

The /plan-launch command demonstrates interaction across different product management domains:

# /plan-launch – Launch Planning

...
Apply the **beachhead-segment** skill:
Apply the **ideal-customer-profile** skill:
Apply the **gtm-strategy** skill:

Here, beachhead-segment identifies the initial market segment, which seeds the ideal-customer-profile skill. The resulting ICP then informs the gtm-strategy skill to build a comprehensive launch plan.

Key Source Files for Skill Interaction

Understanding how skills interact with each other requires referencing these specific implementation files:

• pm-toolkit/skills/review-resume/SKILL.md – Reference skill definition showing atomic capability structure
• pm-toolkit/commands/review-resume.md – Simple command wrapper invoking a single skill
• pm-product-discovery/commands/discover.md – Complex orchestrator chaining multiple discovery skills including brainstorm-ideas-existing and prioritize-assumptions
• pm-product-strategy/commands/market-scan.md – Strategic analysis command demonstrating cross-domain skill usage

Summary

• Skills are atomic markdown procedures stored in */SKILL.md files, each describing a single product management capability like swot-analysis or north-star-metric
• Commands are orchestration layers in */commands/*.md that execute skills using the Apply the **<skill-name>** syntax
• Data flows through context variables ($RESUME, $JOB_POSTING) and implicit returns stored in the LLM's conversation state, eliminating the need for explicit function parameters
• Checkpoints allow interactive user input to guide which skills execute next, creating dynamic, branching workflows
• No code-level dependencies exist between skills; the LLM prompt itself serves as the integration layer, making the system highly composable and language-agnostic

Frequently Asked Questions

How does the pm-skills repository handle data passing between skills?

Data passes via the LLM's conversation state and context variables rather than traditional programming constructs. When a skill completes, its textual output remains in the prompt context, allowing subsequent skills to reference previous results through natural language instructions like "Use the bullets you just generated" or by accessing bound variables such as $ARGUMENTS and $JOB_POSTING.

Can skills in pm-skills call other skills directly?

No, skills do not call other skills directly. According to the source code architecture, skills are atomic units that know nothing about other skills. The Apply the **<skill-name>** directive appears only in command files (*/commands/*.md), which serve as the sole orchestration layer responsible for sequencing skill execution and managing interactions.

What is the difference between a skill and a command in phuryn/pm-skills?

A skill is a reusable capability defined in a SKILL.md file containing procedural steps for the LLM to execute (e.g., review-resume). A command is a user-facing entry point defined in commands/*.md that orchestrates one or more skills to accomplish a broader workflow (e.g., /discover chaining multiple discovery skills sequentially).

Where are skill interactions defined in the codebase?

Skill interactions are defined declaratively in markdown files within the */commands/ directories. For example, pm-product-discovery/commands/discover.md defines how brainstorm-ideas-existing, identify-assumptions-existing, and prioritize-assumptions interact by sequentially listing which skills to apply and how to handle their outputs through checkpoint prompts and context references.

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