/oma-pm

name: oma-pm
description: Turn product requirements into scoped tasks with dependencies and
  acceptance criteria. Use for implementation planning and prioritization.

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

| Action | SSL primitive | Evidence | |--------|---------------|----------| | Read requirements/context | `READ` | User request and project context | | Select planning structure | `SELECT` | Task template and workflow needs | | Infer tasks and dependencies | `INFER` | Domain decomposition | | Validate acceptance criteria | `VALIDATE` | Checklist and task schema | | Write plan artifacts | `WRITE` | JSON plan and task-board markdown | | Notify plan summary | `NOTIFY` | Final planning report |

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` and `.agents/results/result-pm.md`.

Resource scope

| Scope | Resource target | |-------|-----------------| | `MEMORY` | Requirements, assumptions, dependencies | | `LOCAL_FS` | `.agents/results/plan-{sessionId}.json`, `.agents/results/result-pm.md` | | `CODEBASE` | Optional project context and API/data model references |

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. API-first design: define contracts before implementation tasks 2. Every task has: agent, title, acceptance criteria, priority tier (1 = independent, lower runs first), dependencies, 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)

Save plan to `.agents/resul