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

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.

• 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

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: first-fluke
• Source: first-fluke/oh-my-agent
• License: MIT
• Homepage: https://firstfluke.com/oh-my-agent/

Install and usage instructions live in the source repository linked above.