oma-pm

# 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/`

### 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
```text
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/current-plan.md`.
```

### Resource scope
| Scope | Resource target |
|-------|-----------------|
| `MEMORY` | Requirements, assumptions, dependencies |
| `LOCAL_FS` | `.agents/results/plan-{sessionId}.json`, `.agents/results/current-plan.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, dependencies
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
Follow `resources/execution-protocol.md` step by step.
See `resources/examples.md` for input/output examples.
Use `resources/iso-planning.md` when the user needs standards-based planning, risk framing, or governance-oriented recommendations.
Save plan to `.agents/results/plan-{sessionId}.json` and `.agents/results/current-plan.md`.
Vendor-specific execution protocols are injected automatically by `oma agent:spawn`.
Source files live under `../_shared/runtime/execution-protocols/{vendor}.md`.
-