pm-planning
Skill112 starsChanged 2 months agoMITView on GitHub
Decomposition methodology for pm agent — turns an approved ARCH document into a Beads task list with explicit dependencies, time-boxes, and acceptance criteria. The pipeline can only orchestrate work it can see; this skill defines what "seeable work" looks like.
In this repository35 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- aesthetic-instrumentSkill
- anti-patternsSkill
- anydesignSkill
- archetype-review-baseSkill
- brainstormingSkill
- build-speedSkill
- codex-hostSkill
- committed-aestheticSkill
- cost-modelSkill
- crystallizeSkill
- decision-evalSkill
- deploy-landedSkill
- discoverySkill
- done-blockedSkill
- great_ctoSkill
- lifecycle-messagingSkill
- migration-ready-schemaSkill
- observability-baselineSkill
- opportunity-solution-treeSkill
- outcome-roadmapSkill
- pre-mortemSkill
- product-economicsSkill
- prose-styleSkill
- quant-validationSkill
- secrets-rotationSkill
- signing-preflightSkill
- skeptical-triageSkill
- stack-baselineSkill
- test-strategySkill
- ui-ux-pro-maxSkill
- vertical-onboardingSkill
- verticalsSkill
- well-architectedSkill
The file
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 5 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈5
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 53
If a task produces multiple unrelated artefacts, split it.
- Distinctive: line 57
When task B requires task A's output:
- Distinctive: line 73
Every task description ends with a bulleted "Done when:" section.
- Distinctive: line 89
If 3 tasks can run in parallel, mark each with the agent it goes to.
- Distinctive: line 90
Don't bundle them.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
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-devThe 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/<area>/<feature>.test.ts` covers all 4 cases
- [ ] `npm test` passesSenior-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 agentThe 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 devopsWhen 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.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

