/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` using the injected session ID. Write the run-scoped report from the shared memory/result contract.

Resource scope

| Scope | Resource target | |-------|-----------------| | `MEMORY` | Requirements, assumptions, dependencies | | `LOCAL_FS` | `.agents/results/plan-{sessionId}.json`, injected claim path and task/run-scoped report | | `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. 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 publ