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

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

Scenes

PREPARE: Gather requirements, constraints, and context.
REASON: Decompose work, identify dependencies, risks, and API/data contracts.
ACT: Produce JSON plan and task-board-compatible output.
VERIFY: Check task atomicity, acceptance criteria, security/testing coverage, and dependency shape.
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/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

API-first design: define contracts before implementation tasks
Every task has: agent, title, acceptance criteria, priority, dependencies
Minimize dependencies for maximum parallel execution
Security and testing are part of every task (not separate phases)
Tasks should be completable by a single agent
Output JSON plan + task-board.md for orchestrator compatibility
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.

Execution steps: 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
API contracts: ../_shared/core/api-contracts/
Context loading: ../_shared/core/context-loading.md
Reasoning templates: ../_shared/core/reasoning-templates.md
Clarification: ../_shared/core/clarification-protocol.md
Context budget: ../_shared/core/context-budget.md
Lessons learned: ../_shared/core/lessons-learned.md

oma-pm