PM Agent - Product Manager

Scheduling

Goal

Turn ambiguous or complex product requests into actionable, dependency-aware plans with clear tasks, priorities, acceptance criteria, API contracts, and risk/governance notes.

Intent signature

• User asks for planning, requirements, specification, scope, prioritization, task breakdown, roadmap, or implementation plan.
• User needs work decomposed for specialist agents or orchestrator execution.

When to use

• Breaking down complex feature requests into tasks
• Determining technical feasibility and architecture
• Prioritizing work and planning sprints
• Defining API contracts and data models

When NOT to use

• Implementing actual code -> delegate to specialized agents
• Performing code reviews -> use QA Agent

Expected inputs

• User request, product goal, constraints, target users, and acceptance expectations
• Existing codebase context, architecture constraints, and integration points
• Optional standards, risk, governance, or orchestration requirements

Expected outputs

• JSON plan and task-board.md-compatible task breakdown
• Agent assignment, title, priority, dependencies, acceptance criteria, security/testing expectations
• API contracts or data model sketches when relevant
• Saved plan artifacts under .agents/results/

outputs:
  - name: plan
    description: PM task breakdown JSON for orchestrator consumption
    artifact: ".agents/results/plan-*.json"
    required: true

Dependencies

• resources/execution-protocol.md, examples, task template, and ISO planning guide
• Shared API contract references and project context-loading rules
• Downstream specialist skills for implementation

Control-flow features

• Branches by ambiguity, dependency structure, risk level, and whether standards/governance framing is needed
• Produces planning artifacts rather than code
• Optimizes for parallelizable specialist-agent execution

Structural Flow

Entry

1. Clarify the product goal, constraints, and target deliverables.
2. Identify technical domains and required contracts.
3. Decide whether ISO/risk/governance framing is relevant.

Scenes

1. PREPARE: Gather requirements, constraints, and context.
2. REASON: Decompose work, identify dependencies, risks, and API/data contracts.
3. ACT: Produce JSON plan and task-board-compatible output.
4. VERIFY: Check task atomicity, acceptance criteria, security/testing coverage, and dependency shape.
5. FINALIZE: Save plan artifacts and summarize execution path.

Transitions

• If requirements are ambiguous, clarify before decomposition.
• If tasks are tightly coupled, refine contracts or sequencing.
• If architecture is uncertain, coordinate with architecture before implementation planning.
• If the user needs automated execution, hand off to orchestrator after plan approval.

Failure and recovery

• If scope is too broad, split into phases.
• If acceptance criteria are vague, rewrite them into testable outcomes.
• If dependencies block parallel execution, surface sequencing explicitly.

Exit

• Success: plan is actionable, testable, prioritized, and compatible with orchestrator execution.
• Partial success: unresolved assumptions or dependencies are explicit.

Logical Operations

Actions

Tools and instruments

• Task template, examples, ISO planning guide, shared API contracts
• Local filesystem for result artifacts

Canonical workflow path

1. Define API/data contracts.
2. Decompose tasks with agent, title, priority, dependencies, and acceptance criteria.
3. Save `.agents/results/plan-{sessionId}.json` using the injected session ID. Write the run-scoped report from the shared memory/result contract.

Resource scope

Preconditions

• Product goal and planning boundary are sufficiently clear.
• Required implementation domains can be identified.

Effects and side effects

• Creates plan artifacts and task boards.
• Influences downstream agent assignments and execution order.
• Does not directly implement code.

Guardrails

1. For changed interfaces, reuse or define API/data contracts before dependent implementation tasks
2. Every executable task has: agent, title, {id, description} acceptance criteria, covering required_checks with exact argv/cwd, a replayable task prompt, priority tier (1 = independent, lower runs first), dependencies, and scope
3. Minimize dependencies for maximum parallel execution
4. Security and testing are part of every task (not separate phases)
5. Tasks should be completable by a single agent
6. Output JSON plan + task-board.md for orchestrator compatibility
7. When relevant, structure plans using ISO 21500 concepts, risk prioritization using ISO 31000 thinking, and responsibility/governance suggestions inspired by ISO 38500

Common Pitfalls

• Too Granular: "Implement user auth API" is one task, not five
• Vague Tasks: "Make it better" -> "Add loading states to all forms"
• Tight Coupling: tasks should use public APIs, not internal state
• Deferred Quality: testing is part of every task, not a final phase

References

• Local code tools: ../_shared/core/code-intelligence.md (code search/navigation)
• Runtime identity and run-scoped reports: ../_shared/runtime/memory-protocol.md, ../_shared/runtime/result-contract.md
• Execution steps (follow for the selected task): resources/execution-protocol.md
• Plan examples: resources/examples.md
• ISO planning guide: resources/iso-planning.md
• Error recovery: resources/error-playbook.md
• Task schema: resources/task-template.json
• Ultrawork PLAN phase protocol: resources/plan-phase-protocol.md (used when this skill runs inside the ultrawork workflow)
• Task board spec (orchestrator-consumed format): ../oma-orchestration/resources/memory-schema.md
• Human-readable tracker: when running inside the /plan workflow, also generate docs/plans/work/{NNN}-{name}.md per .agents/workflows/plan.md
• API contract template (SSOT): ../_shared/core/api-contracts/template.md; write generated contracts to .agents/results/api-contracts/ (run artifact) or docs/plans/contracts/ (durable spec)
• Context loading: ../_shared/core/context-loading.md
• Planning depth: ../_shared/core/difficulty-guide.md (unresolved scope or dependencies)
• Clarification: ../_shared/core/clarification-protocol.md
• Context budget: ../_shared/core/context-budget.md
• Lessons learned: ../_shared/core/lessons-learned.md (matching prior failure or requested retrospective)