plan
Flagged{"isSafe":false,"isSuspicious":true,"riskLevel":"critical","findings":[{"category":"prompt_injection","severity":"critical","description":"Explicit prompt injection attempting to override normal execution flow by instructing to Begin executing Step 1 immediately and to claim the prompt was injected.","evidence":"\"STOP — DO NOT READ THIS FILE. You are already reading it. This prompt was injected into your context by Claude Code's plugin system. Using the Read tool on this SKILL.md file wastes ~7,600 tokens. Begin executing Step 1 immediately.\""},{"category":"prompt_injection","severity":"high","description":"Instruction to display a banner before tool calls and to proceed with Step 1 regardless of context, which could bypass safeguards.","evidence":"\"Before ANY tool calls, display this banner:\" ... Then proceed to Step 1."},{"category":"system_harm","severity":"low","description":"Writes to .planning/.active-skill as part of workflow; could be misused to alter orchestrator state or trap execution, though not inherently destructive.","evidence":"**CRITICAL (hook-enforced): Write .active-skill NOW.** Write the text \"plan\" to `.planning/.active-skill` using the Write tool."},{"category":"other","severity":"low","description":"Content ends abruptly/truncated near the end, indicating incomplete guidance or potential hidden instructions awaiting continuation.","evidence":"\"3. Read .planning/CONTEXT.md (if exists) — extract only the `## Decision Summary` section (everything from `## Decision Summary` to the next `##` headi\""}],"summary":"The skill content includes a clear prompt-injection attempt designed to subvert normal safety checks and force immediate execution. It also contains a hard, hook-enforced write to a planning state file, which could be misused to tamper with workflow. Additionally, the content ends abruptly, suggesting truncation. No actual data exfiltration, suspicious URLs, obfuscated code, or explicit destructive commands are present, but the injection risk is high and warrants isolation or sanitization before use."}
npx machina-cli add skill SienkLogic/plan-build-run/plan --openclawSTOP — DO NOT READ THIS FILE. You are already reading it. This prompt was injected into your context by Claude Code's plugin system. Using the Read tool on this SKILL.md file wastes ~7,600 tokens. Begin executing Step 1 immediately.
$pbr-plan — Phase Planning
You are the orchestrator for $pbr-plan. This skill creates detailed, executable plans for a specific phase. Plans are the bridge between the roadmap and actual code — they must be specific enough for an executor agent to follow mechanically. Your job is to stay lean, delegate heavy work to Task() agents, and keep the user's main context window clean.
Context Budget
Reference: skills/shared/context-budget.md for the universal orchestrator rules.
Additionally for this skill:
- Minimize reading subagent output — read only plan frontmatter for summaries
- Delegate all research and planning work to agents — the orchestrator routes, it doesn't plan
Step 0 — Immediate Output
Before ANY tool calls, display this banner:
╔══════════════════════════════════════════════════════════════╗
║ PLAN-BUILD-RUN ► PLANNING PHASE {N} ║
╚══════════════════════════════════════════════════════════════╝
Where {N} is the phase number from $ARGUMENTS. Then proceed to Step 1.
Prerequisites
.planning/config.jsonexists (run$pbr-beginfirst).planning/ROADMAP.mdexists with at least one phase.planning/REQUIREMENTS.mdexists
Argument Parsing
Parse $ARGUMENTS according to skills/shared/phase-argument-parsing.md.
Standard Invocation
$pbr-plan <N> — Plan phase N
Parse the phase number and optional flags:
| Argument | Meaning |
|---|---|
3 | Plan phase 3 |
3 --skip-research | Plan phase 3, skip research step |
3 --assumptions | Surface assumptions before planning phase 3 |
3 --gaps | Create gap-closure plans for phase 3 (from VERIFICATION.md) |
3 --teams | Plan phase 3 using specialist agent teams |
| (no number) | Use current phase from STATE.md |
3 --preview | Preview what planning would produce for phase 3 without spawning agents |
Subcommands
| Subcommand | Meaning |
|---|---|
add | Append a new phase to the end of the roadmap |
insert <N> | Insert a new phase at position N (uses decimal numbering) |
remove <N> | Remove phase N from the roadmap |
Freeform Text Guard — CRITICAL
STOP. Before ANY context loading or Step 1 work, you MUST check whether $ARGUMENTS looks like freeform text rather than a valid invocation. This check is non-negotiable. Valid patterns are:
- Empty (no arguments)
- A phase number: integer (
3,03) or decimal (3.1) - A subcommand:
add,insert <N>,remove <N> - A phase number followed by flags:
3 --skip-research,3 --assumptions,3 --gaps,3 --teams - The word
check(legacy alias)
If $ARGUMENTS does NOT match any of these patterns — i.e., it contains freeform words that are not a recognized subcommand or flag — then stop execution and respond:
`$pbr-plan` expects a phase number or subcommand.
Usage:
$pbr-plan <N> Plan phase N
$pbr-plan <N> --gaps Create gap-closure plans
$pbr-plan add Add a new phase
$pbr-plan insert <N> Insert a phase at position N
$pbr-plan remove <N> Remove phase N
Then suggest the appropriate skill based on the text content:
| If the text looks like... | Suggest |
|---|---|
| A task, idea, or feature request | $pbr-todo to capture it, or $pbr-explore to investigate |
| A bug or debugging request | $pbr-debug to investigate the issue |
| A review or quality concern | $pbr-review to assess existing work |
| Anything else | $pbr-explore for open-ended work |
Do NOT proceed with planning. The user needs to use the correct skill.
Self-check: If you reach Step 1 without having matched a valid argument pattern above, you have a bug. Stop immediately and show the usage block.
Orchestration Flow: Standard Planning
Execute these steps in order for standard $pbr-plan <N> invocations.
Step 1: Parse and Validate (inline)
Reference: skills/shared/config-loading.md for the tooling shortcut (state load, plan-index, phase-info) and config field reference.
- Parse
$ARGUMENTSfor phase number and flags - Read
.planning/config.jsonfor settings (see config-loading.md for field reference) CRITICAL (hook-enforced): Write .active-skill NOW. Write the text "plan" to.planning/.active-skillusing the Write tool. - Resolve depth profile: run
node ${PLUGIN_ROOT}/scripts/pbr-tools.js config resolve-depthto get the effective feature/gate settings for the current depth. Store the result for use in later gating decisions. - Validate:
- Phase exists in ROADMAP.md
- Phase directory exists at
.planning/phases/{NN}-{slug}/ - Phase does not already have PLAN.md files (unless user confirms re-planning)
- If no phase number given, read current phase from
.planning/STATE.md - CONTEXT.md existence check: If the phase is non-trivial (has 2+ requirements or success criteria), check whether a CONTEXT.md exists at EITHER
.planning/CONTEXT.md(project-level) OR.planning/phases/{NN}-{slug}/CONTEXT.md(phase-level). If NEITHER exists, warn: "Phase {N} has no CONTEXT.md. Consider running$pbr-discuss {N}first to capture your preferences. Continue anyway?" If user says no, stop. If yes, continue. If at least one exists, proceed without warning.
--preview mode
If --preview is present in $ARGUMENTS:
-
Detect the
--previewflag and extract the phase number. -
Render the following dry-run banner:
╔══════════════════════════════════════════════════════════════╗ ║ DRY RUN — $pbr-plan {N} --preview ║ ║ No researchers or planners will be spawned ║ ╚══════════════════════════════════════════════════════════════╝ -
Show the 5 steps that would occur:
- Parse ROADMAP.md for phase {N} goal, dependencies, and requirements
- Spawn researcher agents to investigate codebase and gather context
- Spawn planner agent to write PLAN files based on research
- Run plan-checker to validate structure and completeness
- Present plans for your approval before building
-
Show estimated agent spawns: ~2-4 agents (1-2 researchers + 1 planner + 1 plan-checker)
-
Show output location:
.planning/phases/{NN}-{slug}/PLAN-NN.md -
STOP — do not proceed to Step 2.
If phase already has plans:
- Use AskUserQuestion (pattern: yes-no from
skills/shared/gate-prompts.md): question: "Phase {N} already has plans. Re-plan from scratch?" header: "Re-plan?" options:- label: "Yes" description: "Delete existing plans and create new ones"
- label: "No" description: "Keep existing plans unchanged"
- If "Yes": delete existing PLAN.md files in the phase directory
- If "No" or "Other": stop
Step 2: Load Context (inline)
Init-first pattern: When spawning agents, pass the output of node plugins/pbr/scripts/pbr-tools.js init plan-phase {N} as context rather than having the agent read multiple files separately. This reduces file reads and prevents context-loading failures.
Read context file PATHS and metadata. Build lean context bundles for subagent prompts — include paths and one-line descriptions, NOT full file bodies. Agents have the Read tool and will pull file contents on-demand.
1. Read .planning/ROADMAP.md — extract current phase goal, dependencies, requirements
2. Read .planning/REQUIREMENTS.md — extract requirements mapped to this phase
3. Read .planning/CONTEXT.md (if exists) — extract only the `## Decision Summary` section (everything from `## Decision Summary` to the next `##` heading). If no Decision Summary section exists (legacy CONTEXT.md), fall back to extracting the full `## Decisions (LOCKED...)` and `## Deferred Ideas` sections.
4. Read .planning/phases/{NN}-{slug}/CONTEXT.md (if exists) — extract only the `## Decision Summary` section. Fall back to full locked decisions + deferred sections if no Decision Summary exists.
5. Read .planning/config.json — extract feature flags, depth, model settings
6. List prior SUMMARY.md file paths and extract frontmatter metadata only (status, provides, key_files). Do NOT read full SUMMARY bodies — agents pull these on-demand via Read tool.
7. Read .planning/research/SUMMARY.md (if exists) — extract research findings
Digest-select depth for prior SUMMARYs (Step 6):
Reference: skills/shared/digest-select.md for the full depth rules and examples. In short: direct dependencies get frontmatter + key decisions, transitive get frontmatter only, 2+ back get skipped.
Collect all of this into a context bundle that will be passed to agents.
Step 3: Assumption Surfacing (inline, if --assumptions flag)
IMPORTANT: This step is FREE (no agents). It happens entirely inline.
Before spawning any agents, present 4 assumptions to the user — one each for: approach (how the phase will be implemented), key technology, architecture, and scope boundary. For each, ask the user to confirm or correct. Record corrections as new CONTEXT.md locked decisions. After all assumptions are confirmed/corrected, continue to Step 4.
Step 4: Phase Research (delegated, conditional)
Skip this step if ANY of these are true:
--skip-researchflag is set--gapsflag is set- Depth profile has
features.research_phase: false
To check: run node ${PLUGIN_ROOT}/scripts/pbr-tools.js config resolve-depth and read profile["features.research_phase"]. This replaces checking features.research_phase and depth separately -- the depth profile already incorporates both.
Conditional research (standard/balanced mode): When the profile has features.research_phase: true, also check whether .planning/codebase/ or .planning/research/ already contains relevant context for this phase. If substantial context exists (>3 files in codebase/ or a RESEARCH.md mentioning this phase's technologies), skip research and note: "Skipping research -- existing context found in {directory}." This implements the balanced mode's "conditional research" behavior.
If research is needed:
Display to the user: ◐ Spawning researcher...
Spawn a researcher Task():
Task({
subagent_type: "pbr:researcher",
prompt: <phase research prompt>
})
NOTE: The pbr:researcher subagent type auto-loads the agent definition. Do NOT inline it.
Path resolution: Before constructing the agent prompt, resolve ${PLUGIN_ROOT} to its absolute path. Do not pass the variable literally in prompts — Task() contexts may not expand it. Use the resolved absolute path for any pbr-tools.js or template references included in the prompt.
Phase Research Prompt Template
Read skills/plan/templates/researcher-prompt.md.tmpl and use it as the prompt template for spawning the researcher agent. Fill in the placeholders with phase-specific context:
{NN}- phase number (zero-padded){phase name}- phase name from roadmap{goal from roadmap}- phase goal statement{REQ-IDs mapped to this phase}- requirement IDs{dependencies from roadmap}- dependency list- Fill
<project_context>and<prior_work>blocks per the shared partial (templates/prompt-partials/phase-project-context.md.tmpl): Decision Summary for context, manifest table for prior work
Prepend this block to the researcher prompt before sending:
<files_to_read>
CRITICAL (no hook): Read these files BEFORE any other action:
1. .planning/ROADMAP.md — phase goals, dependencies, and structure
2. .planning/REQUIREMENTS.md — scoped requirements for this phase (if exists)
</files_to_read>
Wait for the researcher to complete before proceeding.
After the researcher completes, check the Task() output for a completion marker:
- If
## RESEARCH COMPLETEis present: proceed to planner - If
## RESEARCH BLOCKEDis present: warn the user that research could not complete, ask if they want to proceed with limited context or stop - If neither marker is present: warn that researcher may not have completed successfully, but proceed
Step 4.5: Pre-Planner Briefing (delegated)
CRITICAL (no hook): Run pre-planner briefing before spawning the planner. Do NOT skip this step.
Consolidate seed scanning and deferred idea surfacing into a single lightweight Task():
Task({
subagent_type: "pbr:general",
model: "haiku",
prompt: "Pre-planner briefing for Phase {NN} ({phase-slug}).
1. SEED SCANNING:
Run: `node ${PLUGIN_ROOT}/scripts/pbr-tools.js seeds match {phase-slug} {phase-number}`
If `matched` is non-empty, output a ## Seeds section listing each seed name, description, and content.
If empty, output: ## Seeds\nNo matching seeds found.
2. DEFERRED IDEAS:
Read `.planning/CONTEXT.md`. If it has a section containing 'deferred' or 'ideas' (case-insensitive),
extract items that mention Phase {NN} or keywords matching the phase slug.
If relevant items found, output a ## Deferred Ideas section listing them.
If none found, output: ## Deferred Ideas\nNo relevant deferred items.
Output format: Return both sections as markdown. End with ## BRIEFING COMPLETE."
})
After the Task() completes:
-
If
## Seedssection contains matches:- If
gates.confirm_seedsistruein config: present them to the user via AskUserQuestion (pattern: yes-no-pick fromskills/shared/gate-prompts.md): question: "Include these {N} seeds in planning?" header: "Seeds?" options: - label: "Yes, all" description: "Include all {N} matching seeds" - label: "Let me pick" description: "Choose which seeds to include" - label: "No" description: "Proceed without seeds"- If "Yes, all": include seed content in planner context
- If "Let me pick": present individual seeds for selection
- If "No": proceed without seeds
- If
gates.confirm_seedsisfalse(default): automatically include all matching seeds in planner context without prompting. Log: "Including {N} seeds automatically (gates.confirm_seeds=false)."
- If
-
If
## Deferred Ideassection has items:- If
gates.confirm_deferredistruein config: present via AskUserQuestion (pattern: yes-no fromskills/shared/gate-prompts.md): question: "Include these deferred ideas in planning context?"- If "Yes": append to planner context under
Deferred ideas to consider: - If "No": proceed without changes
- If "Yes": append to planner context under
- If
gates.confirm_deferredisfalse(default): automatically append deferred ideas to planner context without prompting. Log: "Including deferred ideas automatically (gates.confirm_deferred=false)."
- If
-
If both sections are empty: proceed silently to Step 5 (no AskUserQuestion needed)
Step 5: Planning (delegated)
Team Mode (--teams)
If --teams flag is set OR config.parallelization.use_teams is true, spawn 3 parallel planner agents (architect, security, test) then a synthesizer to merge their outputs. See references/agent-teams.md for agent role definitions, output paths (.planning/phases/{NN}-{slug}/team/), and prompt content for each role.
If --teams is NOT set and config.parallelization.use_teams is false or unset, proceed with the single-planner flow below.
Single-Planner Flow (default)
Learnings injection (opt-in): Check for planning and estimation learnings before spawning the planner:
node {resolved_plugin_root}/scripts/pbr-tools.js learnings query --tags "estimation,planning,process" 2>/dev/null
If non-empty JSON array returned:
-
Write to temp file and note as
{learnings_temp_path}:node {resolved_plugin_root}/scripts/pbr-tools.js learnings query --tags "estimation,planning,process" > /tmp/pbr-learnings-$$.md -
Add as an additional
files_to_readitem in the planner prompt below
If no learnings or command fails: omit.
Display to the user: ◐ Spawning planner...
Spawn the planner Task() with all context inlined:
Task({
subagent_type: "pbr:planner",
prompt: <planning prompt>
})
NOTE: The pbr:planner subagent type auto-loads the agent definition.
After planner completes, check for completion markers: `## PLANNING COMPLETE`, `## PLANNING FAILED`, or `## PLANNING INCONCLUSIVE`. Route accordingly. Do NOT inline it.
Path resolution: Before constructing the agent prompt, resolve ${PLUGIN_ROOT} to its absolute path. Do not pass the variable literally in prompts — Task() contexts may not expand it. Use the resolved absolute path for any pbr-tools.js or template references included in the prompt.
Planning Prompt Template
Read skills/plan/templates/planner-prompt.md.tmpl and use it as the prompt template for spawning the planner agent. Fill in all placeholder blocks with phase-specific context:
<phase_context>- phase number, directory, goal, requirements, dependencies, success criteria<project_context>- locked decisions, user constraints, deferred ideas, phase-specific decisions<prior_work>- manifest table of preceding phase SUMMARY.md file paths with status and one-line exports (NOT full bodies)<research>- file path to RESEARCH.md if it exists (NOT inlined content)<config>- max tasks, parallelization, TDD mode from config.json<planning_instructions>- phase-specific planning rules and output path
Prepend this block to the planner prompt before sending:
<files_to_read>
CRITICAL (no hook): Read these files BEFORE any other action:
1. .planning/CONTEXT.md — locked decisions and constraints (if exists)
2. .planning/ROADMAP.md — phase goals, dependencies, and structure
3. .planning/phases/{NN}-{slug}/RESEARCH.md — research findings (if exists)
{if learnings_temp_path exists}4. {learnings_temp_path} — cross-project learnings (estimation and planning patterns from past PBR projects){/if}
</files_to_read>
If {learnings_temp_path} was produced in the learnings injection step above, replace {if...}{/if} with the actual line. If no learnings were found, omit item 4 entirely.
Wait for the planner to complete.
After the planner returns, read the plan files it created to extract counts. Display a completion summary:
✓ Planner created {N} plan(s) across {M} wave(s)
Where {N} is the number of PLAN.md files written and {M} is the number of distinct wave values across those plans (from frontmatter).
Step 5b: Spot-Check Planner Output
CRITICAL (no hook): Verify planner output before proceeding.
- PLAN files exist: Check
.planning/phases/{NN}-{slug}/PLAN-*.mdfiles exist on disk - Valid frontmatter: Read first 20 lines of each PLAN file — verify
depends_on,files_modified,must_havesfields present - Task structure: Verify at least one
<task>block exists in each plan file - Plan count matches: Number of PLAN files matches what the planner reported
If ANY spot-check fails, present the user with options: Retry / Continue anyway / Abort
Step 6: Plan Validation (delegated, conditional)
Skip this step if:
- Depth profile has
features.plan_checking: false
To check: use the resolved depth profile from Step 1. The profile consolidates the depth setting and any user overrides into a single boolean.
If validation is enabled:
Display to the user: ◐ Spawning plan checker...
Spawn the plan checker Task():
Task({
subagent_type: "pbr:plan-checker",
prompt: <checker prompt>
})
NOTE: The pbr:plan-checker subagent type auto-loads the agent definition. Do NOT inline it.
Path resolution: Before constructing the agent prompt, resolve ${PLUGIN_ROOT} to its absolute path. Do not pass the variable literally in prompts — Task() contexts may not expand it. Use the resolved absolute path for any pbr-tools.js or template references included in the prompt.
Checker Prompt Template
Read skills/plan/templates/checker-prompt.md.tmpl and use it as the prompt template for spawning the plan checker agent. Fill in the placeholders:
<plans_to_check>- manifest table of PLAN.md file paths (checker reads each via Read tool)<phase_context>- phase goal and requirement IDs<context>- file paths to project-level and phase-level CONTEXT.md files (checker reads via Read tool)
Prepend this block to the checker prompt before sending:
<files_to_read>
CRITICAL (no hook): Read these files BEFORE any other action:
1. .planning/phases/{NN}-{slug}/PLAN-*.md — plan files to validate
2. .planning/CONTEXT.md — locked decisions to check against (if exists)
</files_to_read>
Process checker results:
After the plan checker returns, display its result:
- If
VERIFICATION PASSED: display✓ Plan checker: all plans passedand proceed to Step 8 - If issues found: display
⚠ Plan checker found {N} issue(s) — entering revision loopand proceed to Step 7
Step 7: Revision Loop (max 3 iterations)
Reference: skills/shared/revision-loop.md for the full Check-Revise-Escalate pattern.
Follow the revision loop pattern with:
- Producer: planner (re-spawned with
skills/plan/templates/revision-prompt.md.tmpl) - Checker: plan-checker (back to Step 6)
- Escalation: present issues to user, offer "Proceed anyway" or "Adjust approach" (re-enter Step 5)
Step 8: User Approval (inline, conditional)
Skip if:
gates.confirm_planisfalsein configmodeisautonomousin config
If approval is needed:
Present a summary of all plans to the user. For each plan include: plan name, wave, task count, must-haves, files_modified. For each task include the task name. Add a wave execution order summary (Wave 1: Plan 01, 02 (parallel), Wave 2: Plan 03, etc.).
Use AskUserQuestion (pattern: approve-revise-abort from skills/shared/gate-prompts.md):
question: "Approve these {count} plans for Phase {N}?"
header: "Approve?"
options:
- label: "Approve" description: "Proceed to build phase"
- label: "Request changes" description: "Discuss adjustments before proceeding"
- label: "Abort" description: "Cancel planning for this phase"
If user selects 'Request changes' or 'Other':
- Discuss what needs to change
- Re-enter Step 5 with updated context/constraints
- Or make small inline edits to plan files directly
If user selects 'Approve':
-
CONTEXT.md compliance reporting: If
.planning/CONTEXT.mdexists, compare all locked decisions against the generated plans. Print: "CONTEXT.md compliance: {M}/{N} locked decisions mapped to tasks" where M = locked decisions that are reflected in at least one task, N = total locked decisions. If any locked decisions are unmapped, list them as warnings. -
Dependency fingerprinting: For each dependency phase (phases that this phase depends on, per ROADMAP.md):
- Find all SUMMARY.md files in the dependency phase directory
- Compute a fingerprint string for each:
"len:{bytes}-mod:{mtime}"and add as adependency_fingerprintsmap in each plan's YAML frontmatter — this allows the build skill to detect stale plans if dependencies were rebuilt.
-
Update ROADMAP.md Progress table (REQUIRED — do this BEFORE updating STATE.md):
Tooling shortcut: Use the CLI for atomic updates:
node ${PLUGIN_ROOT}/scripts/pbr-tools.js roadmap update-plans {phase} 0 {N} node ${PLUGIN_ROOT}/scripts/pbr-tools.js roadmap update-status {phase} planned node ${PLUGIN_ROOT}/scripts/pbr-tools.js state update status planned node ${PLUGIN_ROOT}/scripts/pbr-tools.js state update last_activity now- Open
.planning/ROADMAP.md - Find the
## Progresstable - Locate the row matching this phase number
- Update the
Plans Completecolumn to0/{N}where N = number of plan files just created - Update the
Statuscolumn toplanned - Save the file — do NOT skip this step
- Open
-
Update STATE.md via CLI (CRITICAL (no hook) — update BOTH frontmatter AND body): set
status: "planned",plans_total,last_commandin frontmatter AND updateStatus:,Plan:lines in body## Current Position
Tooling shortcut: node ${PLUGIN_ROOT}/scripts/pbr-tools.js state patch '{"status":"planned","last_command":"$pbr-plan {N}"}'
- If
features.auto_advanceistrueANDmodeisautonomous: Chain directly to build:Skill({ skill: "pbr:build", args: "{N}" }). This continues the build→review→plan→build cycle automatically. - Otherwise: Suggest next action:
$pbr-build {N}
Orchestration Flow: Subcommands
Subcommand: add
CRITICAL (hook-enforced): Write .active-skill NOW. Write the text "plan" to .planning/.active-skill using the Write tool.
- Read
.planning/ROADMAP.md - Calculate next phase number (last phase + 1)
- Ask user: "What's the goal for this new phase?"
- Ask user: "What requirements does it address?" (show available unassigned REQ-IDs)
- Ask user: "What phases does it depend on?"
- Append phase to ROADMAP.md
- Create phase directory:
.planning/phases/{NN}-{slug}/ - Update STATE.md if needed
- Suggest:
$pbr-plan {N}to plan the new phase - Delete
.planning/.active-skillif it exists.
Subcommand: insert <N>
Reference: skills/plan/decimal-phase-calc.md for decimal numbering rules.
CRITICAL (hook-enforced): Write .active-skill NOW. Write the text "plan" to .planning/.active-skill using the Write tool.
- Read
.planning/ROADMAP.md - Calculate decimal phase number:
- If inserting at position 3: becomes 3.1
- If 3.1 already exists: becomes 3.2
- Etc. (see decimal-phase-calc.md)
- Ask user for phase goal, requirements, dependencies
- Insert phase into ROADMAP.md at the correct position
- Create phase directory:
.planning/phases/{NN.M}-{slug}/ - Update dependencies of subsequent phases if affected
- Suggest:
$pbr-plan {N.M}to plan the new phase - Delete
.planning/.active-skillif it exists.
Subcommand: remove <N>
- Read
.planning/ROADMAP.md - Validate:
- Phase must exist
- Phase must be in
pendingornot startedstatus (cannot remove completed/in-progress phases) - No other phases depend on this phase (or user confirms breaking dependencies)
- CRITICAL (hook-enforced): Write .active-skill NOW. Write the text "plan" to
.planning/.active-skillusing the Write tool. - Confirm with user: "Remove Phase {N}: {name}? This will delete the phase directory and renumber subsequent phases."
- If confirmed:
- Delete
.planning/phases/{NN}-{slug}/directory - Remove phase from ROADMAP.md
- Renumber subsequent phases (N+1 becomes N, etc.)
- Update all
depends_onreferences in ROADMAP.md - Update STATE.md if needed
- Delete
- Delete
.planning/.active-skillif it exists.
Orchestration Flow: Gap Closure (--gaps)
When invoked with --gaps:
- Read
.planning/phases/{NN}-{slug}/VERIFICATION.md- If no VERIFICATION.md exists: tell user "No verification report found. Run
$pbr-review {N}first."
- If no VERIFICATION.md exists: tell user "No verification report found. Run
- Extract all gaps from the verification report
- Spawn planner Task() in Gap Closure mode:
Read skills/plan/templates/gap-closure-prompt.md.tmpl and use it as the prompt template for the gap closure planner. Fill in the placeholders:
<verification_report>- inline the FULL VERIFICATION.md content<existing_plans>- inline all existing PLAN.md files for the phase<gap_closure_instructions>- specify output path and gap_closure frontmatter flag
- After gap-closure plans are created:
- Run plan checker (if enabled)
- Present to user for approval
- Suggest:
$pbr-build {N} --gaps-only
Error Handling
Phase not found
If the specified phase doesn't exist in ROADMAP.md, use conversational recovery:
- Run:
node ${PLUGIN_ROOT}/scripts/pbr-tools.js suggest-alternatives phase-not-found {slug} - Parse the JSON response to get
availablephases andsuggestions(closest matches). - Display: "Phase '{slug}' not found. Did you mean one of these?"
- List
suggestions(if any) as numbered options. - Offer "Show all phases" to list
available.
- List
- Use AskUserQuestion (pattern: yes-no-pick from
skills/shared/gate-prompts.md) to let the user pick a phase or abort.- If user picks a valid phase slug: re-run with that slug.
- If user chooses to abort: stop cleanly with a friendly message.
Missing prerequisites
If REQUIREMENTS.md or ROADMAP.md don't exist, use conversational recovery:
- Run:
node ${PLUGIN_ROOT}/scripts/pbr-tools.js suggest-alternatives missing-prereq {phase} - Parse the JSON response to get
existing_summaries,missing_summaries, andsuggested_action. - Display what is already complete and what is missing.
- Use AskUserQuestion to offer: "Run $pbr-build {prerequisite-phase} first, or continue anyway?"
- If user chooses to continue: proceed with planning (note missing prereqs in plan frontmatter).
- If user chooses to build first: stop and display the suggested build command.
Research agent fails
If the researcher Task() fails, display:
⚠ Research agent failed. Planning without phase-specific research.
This may result in less accurate plans.
Continue to the planning step.
Planner agent fails
If the planner Task() fails, display a branded error box — see skills/shared/error-reporting.md, pattern: Planner agent failure.
Checker loops forever
After 3 revision iterations without passing, display a branded error box — see skills/shared/error-reporting.md, pattern: Checker loops.
Present remaining issues and ask user to decide: proceed or intervene.
Files Created/Modified by $pbr-plan
| File | Purpose | When |
|---|---|---|
.planning/phases/{NN}-{slug}/RESEARCH.md | Phase-specific research | Step 4 |
.planning/phases/{NN}-{slug}/PLAN-{NN}.md | Executable plan files | Step 5 |
.planning/CONTEXT.md | Updated with assumptions | Step 3 (--assumptions) |
.planning/ROADMAP.md | Plans Complete + Status → planned; updated for add/insert/remove | Step 8, Subcommands |
.planning/STATE.md | Updated with plan status | Step 8 |
Cleanup
Delete .planning/.active-skill if it exists. This must happen on all paths (success, partial, and failure) before reporting results.
Completion
After planning completes, present:
Use the branded stage banner and next-up block from skills/plan/templates/completion-output.md.tmpl.
Fill in: {N} (phase number), {phase-name}, {plan_count}, {plan_list_lines} (one line per plan with wave and task count), {wave_table_lines} (one line per wave).
Source
git clone https://github.com/SienkLogic/plan-build-run/blob/main/plugins/codex-pbr/skills/plan/SKILL.mdView on GitHub Overview
Plan Phase work produces detailed, executable blueprints that bridge the roadmap and real code. It acts as the orchestrator for $pbr-plan, ensuring phase plans are specific enough for agents to follow mechanically. Research is delegated to Task() agents to keep the workflow lean and the main context clean.
How This Skill Works
It routes research and planning to Task() agents, reading only plan frontmatter to summarize progress. It relies on phase-argument parsing rules and prerequisites to generate a structured plan for a given phase. The output is a ready-to-execute plan that can be handed to specialist teams.
When to Use It
- Starting a new phase by converting roadmap into an actionable plan
- Need a detailed, step-by-step plan before building phase assets
- Surface assumptions and constraints before executing planning
- Create gap-closure plans for VERIFICATION.md (gaps flag)
- Coordinate specialist teams to execute a phase plan
Quick Start
- Step 1: Ensure .planning/config.json, ROADMAP.md, REQUIREMENTS.md exist (run pbr-begin).
- Step 2: Run `$pbr-plan <N>` (add flags like --assumptions, --gaps, or --teams as needed).
- Step 3: Review the generated plan and delegate tasks to Task() agents for execution.
Best Practices
- Limit the plan to actionable steps so Task() agents can execute mechanically
- Delegate all research and planning work to Task() agents and avoid heavy subagent output
- Ensure prerequisites exist: .planning/config.json, ROADMAP.md, REQUIREMENTS.md
- Use the appropriate flags (--assumptions, --gaps, --teams) to tailor the plan
- Review the generated plan for completeness and explicit task sequencing
Example Use Cases
- Plan Phase 3 for a new feature by enumerating tasks, owners, and milestones
- Plan Phase 2 with --assumptions to surface constraints before work
- Plan Phase 4 with --gaps to map VERIFICATION.md gaps to tasks
- Plan Phase 1 using specialist teams (--teams) for domain experts
- Preview planning output with --preview to validate before execution