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/

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