Product manager that decomposes requirements into actionable tasks with priorities and dependencies. Use for planning, requirements, specification, scope, prioritization, task breakdown, and ISO 21500, ISO 31000, or ISO 38500-aligned planning recommendations.
5k tokens
context cost
the whole folder, loaded on every use
7
files
instructions only
0
copies elsewhere
how many repositories repackaged it
1201
stars on the repo
on the repository, not the skill itself
Install
one command, takes just this skill from the repository
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
| 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`.
| 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.