Talk through a phase before planning. Identifies gray areas and captures your decisions.
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.
Before ANY tool calls, display this banner:
╔══════════════════════════════════════════════════════════════╗
║ PLAN-BUILD-RUN ► DISCUSSION ║
╚══════════════════════════════════════════════════════════════╝
Then proceed to Step 1.
References: @references/questioning.md, @references/ui-brand.md
Reference: skills/shared/context-budget.md for the universal orchestrator rules.
Reference: skills/shared/context-loader-task.md for efficient context loading patterns.
You are running the skill. Your job is to help the user think through a phase BEFORE planning begins. You identify gray areas where the user's preference matters, ask structured questions, and capture every decision in a CONTEXT.md file that the planner must honor.
This skill runs inline (no Task delegation).
Before any phase-modifying operations (writing CONTEXT.md, updating STATE.md), acquire a claim:
acquireClaim(phaseDir, sessionId)
If the claim fails (another session owns this phase), display: "Another session owns this phase. Use /pbr:progress to see active claims."
On completion or error (including all exit paths), release the claim:
releaseClaim(phaseDir, sessionId)
Decisions made here are LOCKED. The planner cannot override them, even if research suggests a different approach. The planner must implement the locked decision and may note the discrepancy, but must follow the user's choice exactly.
CRITICAL (hook-enforced): Write .active-skill NOW. Write the text "discuss" to .planning/.active-skill using the Write tool.
Parse $ARGUMENTS:
--project: enter PROJECT mode (see Step 1-project below). Skip Steps 2-8.--auto is present in $ARGUMENTS: set auto_mode = true. Log: "Auto mode enabled — batching gray area questions"| Argument | Meaning |
|---|---|
3 | Discuss phase 3 |
3 --auto | Discuss phase 3 with auto mode — batch all gray areas into a single presentation |
--project | Discuss project-level cross-cutting decisions |
Validation (PHASE mode):
3.1)/pbr:progress to see available phases."Phase directory resolution:
.planning/phases/{NN}-* where NN matches the phase number╔══════════════════════════════════════════════════════════════╗
║ ERROR ║
╚══════════════════════════════════════════════════════════════╝
Phase {N} not found.
**To fix:** Run `/pbr:progress` to see available phases.
Check for existing plans (after resolving the phase directory):
PLAN.md or PLAN-*.md files in the phase directory/pbr:plan-phase {N} after."When invoked with --project, discuss project-level cross-cutting decisions.
This mode writes to .planning/PROJECT.md ## Context section (project-level), NOT a phase directory.
Check for existing project context:
.planning/PROJECT.md and check if it has a ## Context section.skills/shared/gate-prompts.md):
question: "PROJECT.md already has a ## Context section. How should we handle it?"
options: Overwrite | Append | Cancel.planning/CONTEXT.md exists (legacy), read it as the existing context source for Append mode, then write merged result to PROJECT.md ## Context.Load project context:
.planning/PROJECT.md (if exists) — project vision, scope, and context (## Context section).planning/REQUIREMENTS.md (if exists) — requirements for constraint awareness.planning/CONTEXT.md exists, read from the legacy fileRun gray areas for project-level decisions (Steps 2.5-5 pattern):
Write project context to PROJECT.md:
Read ${CLAUDE_SKILL_DIR}/templates/project-CONTEXT.md.tmpl
Fill in from discussion decisions:
If Append mode: merge new decisions with existing PROJECT.md ## Context content CRITICAL: Write the discussion results to PROJECT.md NOW.
Write to .planning/PROJECT.md under the ## Context section with subsections:
### Locked Decisions### User Constraints### Deferred IdeasUpdate STATE.md pointer: Add under Accumulated Context:
Project context: .planning/PROJECT.md ## Context ({N} locked decisions, {N} deferred, {N} discretion)
After writing: Auto-sync to CLAUDE.md is handled by the post-write-dispatch hook.
Display: ✓ Project context written to PROJECT.md — locked decisions will auto-sync to CLAUDE.md
Skip to Cleanup step. Do NOT run Steps 2-8 of the phase flow.
Reference: skills/shared/context-loader-task.md for efficient context loading patterns.
Read the following files to understand what this phase needs to accomplish:
ROADMAP.md — Find the phase entry. Extract:
Prior SUMMARY.md files — Scan .planning/phases/ for phases with lower numbers that have SUMMARY.md files. Read their frontmatter to understand:
provides field)tech_stack field)patterns field)key_decisions field)REQUIREMENTS.md (if exists) — Read project requirements relevant to this phase. CRITICAL: After reading, display to the user which specific requirements map to this phase. Flag any requirements that could constrain decisions. If the user's discussion decisions later contradict a stated requirement, surface the contradiction immediately — don't wait until planning.
CONTEXT.md (if exists in the phase directory) — Check if a prior discussion already happened
skills/shared/gate-prompts.md:
question: "Phase {N} already has a CONTEXT.md from a prior discussion. How should we handle it?"Handle responses:
Before jumping into specific gray areas, give the user space to share their mental model unprompted.
Present the phase goal (from ROADMAP.md) and ask an open question:
Follow the user's response with 2-3 domain-aware follow-ups from skills/shared/domain-probes.md:
Surface implications from what the user shared:
Let the conversation reveal gray areas naturally. The user's responses here often surface the real gray areas better than top-down analysis. Carry any themes, concerns, or preferences forward into Step 3.
Analyze the phase goal, requirements, and what's already built. Identify 3-4 gray areas where the user's preference matters. Gray areas fall into these categories:
Read ${CLAUDE_SKILL_DIR}/templates/decision-categories.md for the category reference table.
How to identify gray areas:
Important: Do NOT identify gray areas that are purely implementation details (e.g., variable naming, file organization). Focus on areas that affect user experience, system behavior, or long-term maintainability.
Smart batching (auto_mode): When auto_mode is true, collect ALL gray areas and present them in a single batch rather than one at a time. Present all gray areas together with their options so the user can respond to everything at once. This reduces interaction rounds while still capturing user decisions. After the user responds, proceed to Step 5 with all decisions.
Standard mode (auto_mode is false or absent):
CRITICAL -- DO NOT SKIP: Present the following choice to the user via AskUserQuestion before proceeding:
Present each gray area to the user using the gray-area-option pattern from skills/shared/gate-prompts.md. For each gray area:
Use AskUserQuestion: question: "Gray Area {N}: {Title} — {Why this matters}" header: "Decision" options: (generate 2-4 concrete options from analysis, each with pros/cons in the description) - label: "{Option A}" description: "{Pros: ..., Cons: ...}" - label: "{Option B}" description: "{Pros: ..., Cons: ...}" - ...up to 4 options total, with "Let Claude decide" always as the last option - label: "Let Claude decide" description: "Mark as Claude's Discretion" multiSelect: false
If more than 3 concrete options exist for a gray area, present only the top 3 plus "Let Claude decide" (max 4 total). Mention the omitted option(s) in the question text.
Rules for presenting options:
If any gray area involves a technology choice (library selection, framework decision, architecture pattern) and the user expresses uncertainty or asks "which is better?", spawn a focused research agent:
Task({
subagent_type: "pbr:advisor-researcher",
prompt: "<files_to_read>
1. .planning/PROJECT.md — project context and constraints
2. .planning/CONTEXT.md — existing locked decisions (if exists)
</files_to_read>
Decision area: {gray area title}
Context: {project constraints, existing stack}
Options to compare: {options from Step 4}
Return a structured comparison table with recommendation."
})
After the advisor returns, present the comparison table to the user and let them make the final decision. The user's choice becomes the locked decision — the advisor's recommendation is advisory only.
Skip this step if: No gray areas involve technology choices, or the user already made confident decisions in Step 4.
For each gray area where the user made a decision (not "Let Claude decide"), ask 4 follow-up questions to fully capture their intent.
CRITICAL — STOP: Do NOT skip ANY of the 4 follow-up areas below. All 4 MUST be asked for each gray area where the user made a decision.
Follow-up question types:
CRITICAL — STOP: Do NOT skip this follow-up area.
CRITICAL — STOP: Do NOT skip this follow-up area. 2. Quality level: "How polished should this be?" Do NOT use AskUserQuestion — this is freeform. Let the user describe their quality expectations in their own words.
CRITICAL — STOP: Do NOT skip this follow-up area. 3. Integration: "How should this interact with {existing component}?" Do NOT use AskUserQuestion — this is freeform. The answer depends on the specific component and context.
CRITICAL — STOP: Do NOT skip this follow-up area. 4. Future-proofing: "Should we design this to support {potential future need}, or keep it simple?" CRITICAL -- DO NOT SKIP: Present the following choice to the user via AskUserQuestion before proceeding: Use the yes-no pattern: question: "Design {feature} to support {future need}, or keep it simple for now?" options: - label: "Future-proof" description: "Add extensibility for {future need}" - label: "Keep simple" description: "Build only what's needed now"
Rules for follow-ups:
Completion check: After all follow-up questions for all gray areas, verify that all 4 follow-up areas produced output for each decided gray area. If any area was missed, go back and ask it before proceeding to Step 6.
Reference: The deferred section prevents scope creep in downstream planning. See CONTEXT.md template.
During the conversation, the user may mention ideas they want but not in this phase. Track these separately:
Before creating the CONTEXT.md artifact, confirm readiness with the user per @references/questioning.md decision gate pattern:
AskUserQuestion:
question: "I think I have a clear picture of your decisions for this phase. Ready to capture them in CONTEXT.md?"
header: "Ready?"
options:
- label: "Yes, proceed" description: "Write CONTEXT.md with captured decisions"
- label: "Keep exploring" description: "I want to share more or discuss further"
If "Keep exploring" -- ask what they want to add or identify gaps and probe naturally. Loop until "Yes, proceed" is selected.
Freeform rule: If the user selects "Keep exploring" and responds with freeform text (not selecting an option), switch to plain text conversation per @references/questioning.md freeform rule. Do NOT present another AskUserQuestion until you have processed their freeform response.
CRITICAL — DO NOT SKIP: Write CONTEXT.md NOW. This file is the sole output of the discuss skill. Skipping it means all decisions are lost. Write the CONTEXT.md file to the phase directory:
Path: .planning/phases/{NN}-{phase-name}/CONTEXT.md
Content:
Read ${CLAUDE_SKILL_DIR}/templates/CONTEXT.md.tmpl for the template structure.
Placeholders to fill:
{N} -- the phase number{ISO date} -- today's date in ISO format{Decision title} / {User's exact choice and reasoning} -- from Step 4-5 decisions{Idea} / {Why deferred} -- from Step 6 deferred ideas{Area} / {What Claude can choose} -- items marked "Let Claude decide"{2-3 sentences} -- user's vision summary from the conversation{Concern} / {Context} -- concerns raised during discussion<specifics> -- concrete technical details, patterns, or conventions from the conversation<code_context> -- relevant files and modules referenced during discussionDecision Summary generation: The ## Decision Summary section at the top of CONTEXT.md is a compact digest (~300 tokens) of all decisions. For each locked decision, write only the title and the user's choice in one phrase (no scope/quality/integration details). List deferred and discretion items as comma-separated titles only. This summary is injected into agent prompts by the plan skill -- keep it concise.
Downstream awareness: The CONTEXT.md written here is consumed by:
/pbr:plan-phase -- planner reads locked decisions as constraints/pbr:execute-phase -- executor receives decisions via planner's plan/pbr:verify-work -- verifier checks deliverables against phase intentEnsure all locked decisions are written clearly enough for mechanical consumption.
CRITICAL — DO NOT SKIP: Update STATE.md pointer to new CONTEXT.md NOW.
Update .planning/STATE.md's ## Accumulated Context section to add a reference to the new CONTEXT.md:
Add under the ### Decisions subsection:
Phase {N} discussion: .planning/phases/{NN}-{slug}/CONTEXT.md ({count} locked, {count} deferred, {count} discretion)
This creates a pointer so /pbr:resume-work and progress-tracker.js know that phase-specific decisions exist and where to find them.
Write .planning/phases/{NN}-{slug}/DISCUSSION-LOG.md as an audit trail of the discussion. This file is NOT consumed by agents — it's for human audit only.
Read ${CLAUDE_PLUGIN_ROOT}/templates/DISCUSSION-LOG.md.tmpl for the format.
For each decision area discussed:
This log is separate from CONTEXT.md (which is the implementation artifact for agents). The discussion log preserves the alternatives considered, not just the final decisions.
If planning.commit_docs is true, include in the next commit.
After writing CONTEXT.md, display branded output per @references/ui-brand.md:
╔══════════════════════════════════════════════════════════════╗
║ PLAN-BUILD-RUN ► DISCUSSION CAPTURED ✓ ║
╚══════════════════════════════════════════════════════════════╝
**Phase {N}: {name}**
✓ Decisions: {count} locked, {count} deferred, {count} discretion
╔══════════════════════════════════════════════════════════════╗
║ ▶ NEXT UP ║
╚══════════════════════════════════════════════════════════════╝
**Plan this phase** — your decisions will be honored
`/pbr:plan-phase {N}`
<sub>`/clear` first → fresh context window</sub>
**Also available:**
- `/pbr:progress` — see project status
- `/pbr:explore` — explore ideas further
Cleanup: Delete .planning/.active-skill before finishing. This must happen on all paths (success, cancel, and error).
These come from:
The planner MUST:
These come from:
The planner MUST NOT:
These come from:
The planner MAY:
skills/shared/gate-prompts.md (same as Step 2)/pbr:discuss-phase {N+1}."Reference: skills/shared/error-reporting.md for error output patterns.
If any step fails (file read error, directory not found, write failure):
error-reporting.md.planning/.active-skill before exitingThis skill updates STATE.md's Accumulated Context section with a pointer to the phase CONTEXT.md file. It does NOT change the project position (current phase/plan). STATE.md position is updated when /pbr:plan-phase runs.
Reference: skills/shared/commit-planning-docs.md for the standard commit pattern.
If planning.commit_docs: true in config.json:
docs(planning): capture phase {N} discussion decisionsMemory capture: Reference skills/shared/memory-capture.md — check researcher output for <memory_suggestion> blocks and save any reusable knowledge discovered during research.