plan-em
Skill6 starsChanged 4 months agoMITView on GitHub
Engineering Manager skill. Reads an approved PRD, runs pre-flight checks against AHA.md, GLOSSARY.md and ARCHITECTURE.md, auto-runs plan-review certification inline (no ask), picks the specialist agents (it asks to approve the roster only when the roster is unusual for the project), spins them up to write engineering sections directly into the PRD, then prints a short digest. Never builds automatically: every run stops after the plan half and asks "Start the build now?"; No ends the run and a later /plan-em resumes at the build half. The PRD's intake grade picks the check before the build: a mechanical plan-shape check on a medium PRD, the eng certification on a large one. An Opus orchestrator engineer decomposes each half into file-disjoint, model-tiered packets fanned out to leaf eng subagents. Refuses without a referenced PRD .md path.
The file
We split this skill into the rules it gives an agent
1 rule. About 0 are common, 0 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈0
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 92
Follow refs/protocol-em.md end-to-end — it owns the steps, their order, their scripts, and their outputs.
≈ “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
plan-em
This file is a router. The five-step protocol lives in refs/protocol-em.md and the team-lane fan-out in refs/protocol-team.md — neither is restated here.
Usage
Invoke: /plan-em <prd-path>. The PRD path is a .md file inside a PRD folder in any lane — features/{planned,wip,done}/prd-[n]-[slug]/ or the legacy flat features/prd-[n]-[slug]/.
- Slash command:
/plan-em· natural language: "engineering plan for<PRD>", "scope this PRD", "spin up eng agents" · context: a path to an existing approved PRD.mdfile, typically passed forward fromplan-pmorplan-review - Progress messages are always on, every 5 minutes (
../shared/refs/status-heartbeat.md) /plan-em <prd-path> --review— run the plan-review eng check at the end of the plan half, this run only.--review on/--review off(or "always review the plan") — save it for the project:.claude/scripts/script-policy-set.py --file devkit/policy.json --set policies.plan_em.review=<true|false>No
devkit/policy.json(a project set up before the file existed) → say/msg --updateadds it, and use the value for this run only. Absent = off: the closing message suggests/plan-reviewinstead. The certification gate still runs plan-review on an uncertified PRD either way.
Hard refusals:
- Invocation without a PRD path: refuse. State that
plan-emrequires an existing PRD. Offer two paths: run/plan-pmto create one, or supply a path to an existing PRD.mdfile. - PRD path does not exist or does not match a lane-lifecycle path —
features/{planned,wip,done}/prd-*/prd-*.md(top-level) orfeatures/{planned,wip,done}/prd-*/prd-*/prd-*.md(nested sub-PRD, perplan-pm's § Sub-PRD mode) — or the legacy flatfeatures/prd-*/prd-*.md/features/prd-*/prd-*/prd-*.md: refuse. State the expected location.
Execution mode
plan-em always runs the team lane and never names the lane to the user. At Step 4 it
spawns one orchestrator engineer agent on Opus per half, backgrounded and watched, which
decomposes the half into file-disjoint, model-tiered packets for leaf eng subagents
(refs/protocol-team.md). A hidden --solo flag (maintainers and debugging) runs one
leaf per roster stack for that run only; it is never saved (refs/protocol-em.md Step 0).
Run shape and size tier
plan-em never builds automatically. Every run plans, prints a short summary, and asks
"Start the build now?". Yes → the build half runs in the same run. No → the run ends;
a later /plan-em on the same PRD resumes at the build half. A run that dies resumes the
same way.
The size tier, resolved once from the intake complexity grade (refs/protocol-em.md
Step 1e — no flag, no question), picks the check before the build half. Both sizes run
the product certification before planning. C: < 8 or unresolvable ⇒ medium: a
mechanical plan-shape check. C: ≥ 8 ⇒ large: the plan-review eng certification.
Inputs
| Name | Format | Source |
| PRD file path | .md file path matching features/{planned,wip,done}/prd-*/prd-*.md (or legacy flat features/prd-*/prd-*.md) | User message at invocation, or handoff from plan-pm / plan-review |
| Clarification answers | AskUserQuestion selections | Human during ambiguity resolution and an unusual-roster approval |
Outputs
| Name | Format | Destination |
| Pre-flight report | Markdown findings file — written only when the scan found something; a clean run emits one inline line and no file | features/prd-[n]-[slug]/preflight.md |
| Engineering sections | Structured markdown per agent | Appended to the PRD file |
| Run digest | Built · Branch · Review · Findings lines, Critical findings listed below | Emitted inline above the closing message |
| Stage timing log | Append-only TSV, one line per stage boundary | features/prd-[n]-[slug]/reports/timings-<date>.log |
No separate engineering plan files — all output lives in the PRD. The pre-flight
report is the one exception, and it sits inside the PRD's own folder. [n] is the first
numeric segment of the input PRD's parent directory name; [slug] is the remainder.
Resolve the actual matched directory once at Step 1 and write every artifact relative to
it — do not reconstruct a bare features/prd-[n]/ path.
Step-by-step protocol
Follow refs/protocol-em.md end-to-end — it owns the steps, their order, their scripts, and their outputs. Step 4 hands each half to the orchestrator whose protocol is refs/protocol-team.md.
Closing message (every outcome): end with the closing message per ../shared/refs/closing-message.md — the last chat output, after Step 5's digest. Take the next step from the registry's plan-em row; never compose it, never invoke it.
Harness incidents (both lanes): log unexpected script failures, tool errors, retries, and missed writes to devkit/DOCTOR.md per ../shared/refs/doctor-logging.md — logging never changes what the run does next.
References
refs/protocol-em.md— end-to-end execution protocol (Step 0 mode resolve + five steps); followed from § Step-by-step protocolrefs/protocol-team.md— the Opus orchestrator engineer's protocol, spawned at Step 4 ·refs/template-exec-table.md— execution-table shape + concern checklist (Step 3)../shared/refs/—closing-message.md·doctor-logging.md·status-heartbeat.md.claude/skills/eng/SKILL.md— eng agent entry point; Step 4 subagents read this and run--planor--buildmode ·.claude/skills/eng/refs/plan/template-todo.md— the todo ticket schema consumed by build agents
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.