---

name: product-manager description: Organizing features and complex work into manageable/logical tasks compatibility: opencode

Product Manager

This guide teaches AI agents how to decompose complex work into manageable, dependency-aware tasks using Task Master and proven decomposition methodologies.

Task Structure

Copy# Task ID: <id>
# Title: <title>
# Status: <status>
# Dependencies: <comma-separated list of dependency IDs>
# Priority: <priority>
# Description: <brief description>
# Details:
<detailed implementation notes>

# Test Strategy:
<verification approach>

Task Decomposition Method

This template teaches you (AI or human) how to create structured, dependency-aware PRDs using the RPG methodology from Microsoft Research. The key insight: separate WHAT (functional) from HOW (structural), then connect them with explicit dependencies.

Core Principles

1. Dual-Semantics: Think functional (capabilities) AND structural (code organization) separately, then map them
2. Explicit Dependencies: Never assume - always state what depends on what
3. Topological Order: Build foundation first, then layers on top
4. Progressive Refinement: Start broad, refine iteratively

How to Use This Template

• Follow the instructions in each <instruction> block
• Look at <example> blocks to see good vs bad patterns
• Fill in the content sections with your project details
• The AI reading this will learn the RPG method by following along
• Task Master will parse the resulting PRD into dependency-aware tasks

Technology Stack

[Languages, frameworks, key libraries, databases, etc.]

---

Step 1: Identify high-level capability domains

• Think: "What major things does this system do?"
• Examples: Data Management, Core Processing, Presentation Layer

Step 2: For each capability, enumerate specific features

• Use explore-exploit strategy:
  • Exploit: What features are REQUIRED for core value?
  • Explore: What features make this domain COMPLETE?

Step 3: For each feature, define:

• Description: What it does in one sentence
• Inputs: What data/context it needs
• Outputs: What it produces/returns
• Behavior: Key logic or transformations

Capability: Validation Feature: Make sure data is good (Problem: Too vague. No inputs/outputs. Not actionable.)

Capability Tree

Capability: [Name]

[Brief description of what this capability domain covers]

Feature: [Name]

• Description: [One sentence]
• Inputs: [What it needs]
• Outputs: [What it produces]
• Behavior: [Key logic]

Feature: [Name]

• Description:
• Inputs:
• Outputs:
• Behavior:

Capability: [Name]

...

---

Rules:

1. Each capability maps to a module (folder or file)
2. Features within a capability map to functions/classes
3. Use clear module boundaries - each module has ONE responsibility
4. Define what each module exports (public interface)

The goal: Create a clear mapping between "what it does" (functional) and "where it lives" (structural).

Exports:

• validateSchema(data, schema)
• validateRules(data, rules)

Capability: Data Validation → Maps to: src/validation/everything.js (Problem: One giant file. Features should map to separate files for maintainability.)

Repository Structure

Copyproject-root/
├── src/
│   ├── [module-name]/       # Maps to: [Capability Name]
│   │   ├── [file].js        # Maps to: [Feature Name]
│   │   └── index.js         # Public exports
│   └── [module-name]/
├── tests/
└── docs/

Module Definitions

Module: [Name]

• Maps to capability: [Capability from functional decomposition]
• Responsibility: [Single clear purpose]
• File structure:

  Copymodule-name/
  ├── feature1.js
  ├── feature2.js
  └── index.js
  

• Exports:
  • functionName() - [what it does]
  • ClassName - [what it does]

---

Define explicit dependencies between modules. This creates the topological order for task execution.

Rules:

1. List modules in dependency order (foundation first)
2. For each module, state what it depends on
3. Foundation modules should have NO dependencies
4. Every non-foundation module should depend on at least one other module
5. Think: "What must EXIST before I can build this module?"

Data Layer:

• schema-validator: Depends on [base-types, error-handling]
• data-ingestion: Depends on [schema-validator, config-manager]

Core Layer:

• algorithm-engine: Depends on [base-types, error-handling]
• pipeline-orchestrator: Depends on [algorithm-engine, data-ingestion]

• user-auth: Depends on everything (Problem: Too many dependencies. Should be more focused.)

Dependency Chain

Foundation Layer (Phase 0)

No dependencies - these are built first.

• [Module Name]: [What it provides]
• [Module Name]: [What it provides]

[Layer Name] (Phase 1)

• [Module Name]: Depends on [[module-from-phase-0], [module-from-phase-0]]
• [Module Name]: Depends on [[module-from-phase-0]]

[Layer Name] (Phase 2)

• [Module Name]: Depends on [[module-from-phase-1], [module-from-foundation]]

[Continue building up layers...]

---

Each phase should:

1. Have clear entry criteria (what must exist before starting)
2. Contain tasks that can be parallelized (no inter-dependencies within phase)
3. Have clear exit criteria (how do we know phase is complete?)
4. Build toward something USABLE (not just infrastructure)

Phase ordering follows topological sort of dependency graph.

Phase 1: Data Layer Entry: Phase 0 complete Tasks: - Implement schema validator (uses: base types, error handling) - Build data ingestion pipeline (uses: validator, config) Exit: End-to-end data flow from input to validated output

Development Phases

Phase 0: [Foundation Name]

Goal: [What foundational capability this establishes]

Entry Criteria: [What must be true before starting]

Tasks:

• [Task name] (depends on: [none or list])

  • Acceptance criteria: [How we know it's done]
  • Test strategy: [What tests prove it works]

• [Task name] (depends on: [none or list])

Exit Criteria: [Observable outcome that proves phase complete]

Delivers: [What can users/developers do after this phase?]

---

Phase 1: [Layer Name]

Goal:

Entry Criteria: Phase 0 complete

Tasks:

• [Task name] (depends on: [[tasks-from-phase-0]])
• [Task name] (depends on: [[tasks-from-phase-0]])

Exit Criteria:

Delivers:

---

[Continue with more phases...]

---

NOTE: THE CLI IS NOT CURRENTLY IMPLEMENTED. THE CLI DESCRIBED BELOW IS NOT CURRENTLY AVAILABLE. SORRY

When you run pm parse-prd <file>.txt, the parser:

1. Extracts capabilities → Main tasks

   • Each ### Capability: becomes a top-level task

2. Extracts features → Subtasks

   • Each #### Feature: becomes a subtask under its capability

3. Parses dependencies → Task dependencies

   • Depends on: [X, Y] sets task.dependencies = ["X", "Y"]

4. Orders by phases → Task priorities

   • Phase 0 tasks = highest priority
   • Phase N tasks = lower priority, properly sequenced

5. Uses test strategy → Test generation context

   • Feeds test scenarios to Surgical Test Generator during implementation

Result: A dependency-aware task graph that can be executed in topological order.

Why RPG Structure Matters

Traditional flat PRDs lead to:

• ❌ Unclear task dependencies
• ❌ Arbitrary task ordering
• ❌ Circular dependencies discovered late
• ❌ Poorly scoped tasks

RPG-structured PRDs provide:

• ✅ Explicit dependency chains
• ✅ Topological execution order
• ✅ Clear module boundaries
• ✅ Validated task graph before implementation

Tips for Best Results

1. Spend time on dependency graph - This is the most valuable section for Task Master
2. Keep features atomic - Each feature should be independently testable
3. Progressive refinement - Start broad, use task-master expand to break down complex tasks