pm-planning
About
The pm-planning skill decomposes an approved architecture document into a detailed Beads task list with dependencies, time estimates, and acceptance criteria. It is used specifically when a project manager needs to convert an ARCH document into an executable PLAN and a set of claimable tasks for developers. This skill defines the structured, "seeable work" required for the pipeline to orchestrate development.
Quick Install
Claude Code
Recommendednpx skills add avelikiy/great_cto -a claude-code/plugin add https://github.com/avelikiy/great_ctogit clone https://github.com/avelikiy/great_cto.git ~/.claude/skills/pm-planningCopy and paste this command in Claude Code to install this skill
Documentation
PM planning — decompose ARCH into tasks
The pm agent's job is to take the architect's ARCH document and produce 2 things:
- A
PLAN-<feature>.mdfor humans - A sequence of
bd createtasks for senior-dev to claim
The plan is good if a fresh senior-dev (no prior context) can pick up the bd tasks and ship without coming back for clarification.
The decomposition rules
Rule 1. Tasks ≤ 4 hours
Anything bigger gets split. If the task is "build the auth system", split into:
- Schema migration for user table
- Signup endpoint with hashing
- Login endpoint with JWT issuance
- Logout / token revocation
- Tests
Each ≤ 4h. If you can't split, the task is unclear — go back to ARCH and clarify.
Rule 2. Single output artefact per task
Each task produces ONE of:
- A code file (new or modified)
- A database migration
- A test file
- A documentation update
- A config change
If a task produces multiple unrelated artefacts, split it.
Rule 3. Explicit dependencies via --blocks
When task B requires task A's output:
bd create "Task A: schema migration" -p P1
# returns id: my-proj-001-abc
bd create "Task B: signup endpoint" -p P1 \
--blocks-on my-proj-001-abc \
--label senior-dev
The pipeline orchestrator reads bd ready --assignee senior-dev to know
what's claimable. Tasks blocked on incomplete predecessors don't appear.
Rule 4. Acceptance criteria — what does "done" mean?
Every task description ends with a bulleted "Done when:" section.
## Done when:
- [ ] POST /signup returns 201 with user_id on success
- [ ] Bad email returns 400 with "invalid_email"
- [ ] Duplicate email returns 409 with "email_taken"
- [ ] Password is hashed with argon2 (no plaintext in DB)
- [ ] Unit test in `tests/auth/signup.test.ts` covers all 4 cases
- [ ] `npm test` passes
Senior-dev knows EXACTLY what to ship and when to stop.
Rule 5. Owners and parallelism
If 3 tasks can run in parallel, mark each with the agent it goes to. Don't bundle them.
bd create "..." --label senior-dev
bd create "..." --label senior-dev # parallel
bd create "..." --label devops # parallel, different agent
The PLAN-*.md template
# PLAN — <feature>
Date: <ISO>
Architect ARCH: docs/architecture/ARCH-<feature>.md
Owner: pm
## Summary
2-3 sentences. What problem, what solution. Reference ARCH for detail.
## Cost estimate
(Follow skill: cost-model)
## Tasks
1. **<title>** [P1, ≤2h, senior-dev]
- Goal: <one-sentence>
- Done when: <bulleted criteria>
- bd id: <ID after create>
2. **<title>** [P1, ≤4h, senior-dev]
- Blocked on: 1
- Goal: ...
- Done when: ...
3. **<title>** [P2, ≤1h, qa-engineer]
- Blocked on: 1, 2
## Pre-mortem
(Follow skill: pre-mortem)
## Gates
(Follow GATES_BY_ARCHETYPE for this archetype + project_size)
- [ ] gate:plan — after pm finishes, before senior-dev starts
- [ ] gate:qa — after qa-engineer, before ship
- [ ] gate:ship — after security-officer, before devops
When pm should push back instead of plan
The pm agent is allowed — and EXPECTED — to refuse a plan if the ARCH is incomplete. Specifically:
❌ ARCH is missing acceptance criteria for the feature itself. Push back: "ARCH says 'build webhook handler' but doesn't specify what counts as success. Re-architect with explicit success criteria."
❌ ARCH doesn't specify the failure mode. Push back: "ARCH says 'handle errors gracefully' but doesn't say what 'graceful' means. Define: log + ack? log + retry? log + alert?"
❌ ARCH conflicts with existing ADRs. Push back: "ARCH proposes Postgres but ADR-005 mandated DynamoDB. Resolve before plan."
Push-back goes to the architect with bd update + label re-arch. The
plan is BLOCKED until ARCH is refined.
Anti-patterns
❌ Tasks named after components, not goals. "Build UserService" is ambiguous. "Add POST /signup endpoint that hashes password with argon2" is clear.
❌ No dependencies declared. Two tasks editing the same file with
no --blocks-on will conflict. Always declare.
❌ Estimating without doing one task. If you genuinely don't know how long task 1 takes, ask senior-dev to do task 1 first and report back. THEN estimate 2–N.
❌ Tasks > 8 hours. Split. No exceptions.
GitHub Repository
Related Skills
content-collections
MetaThis skill provides a production-tested setup for Content Collections, a TypeScript-first tool that transforms Markdown/MDX files into type-safe data collections with Zod validation. Use it when building blogs, documentation sites, or content-heavy Vite + React applications to ensure type safety and automatic content validation. It covers everything from Vite plugin configuration and MDX compilation to deployment optimization and schema validation.
polymarket
MetaThis skill enables developers to build applications with the Polymarket prediction markets platform, including API integration for trading and market data. It also provides real-time data streaming via WebSocket to monitor live trades and market activity. Use it for implementing trading strategies or creating tools that process live market updates.
creating-opencode-plugins
MetaThis skill helps developers create OpenCode plugins that hook into 25+ event types like commands, files, and LSP operations. It provides the plugin structure, event API specifications, and implementation patterns for JavaScript/TypeScript modules. Use it when you need to intercept, monitor, or extend the OpenCode AI assistant's lifecycle with custom event-driven logic.
sglang
MetaSGLang is a high-performance LLM serving framework that specializes in fast, structured generation for JSON, regex, and agentic workflows using its RadixAttention prefix caching. It delivers significantly faster inference, especially for tasks with repeated prefixes, making it ideal for complex, structured outputs and multi-turn conversations. Choose SGLang over alternatives like vLLM when you need constrained decoding or are building applications with extensive prefix sharing.
