Initialize a new project through unified flow: questioning, research (optional), requirements, roadmap. This is the most leveraged moment in any project — deep questioning here means better plans, better execution, better outcomes. One workflow takes you from idea to ready-for-planning.
Read all files referenced by the invoking prompt's execution_context before starting.
@~/.claude/pan-wizard-core/references/guardrails.md
## Phase 0 — Clarify (MANDATORY, do not skip)
Before scaffolding or coding anything, confirm with the user:
1. **What problem will this solve?** — Core purpose, not the implementation
2. **What does success look like?** — Concrete, measurable outcomes
3. **What's in scope vs out of scope?** — Boundary definition
4. **Constraints?** — Tech stack, dependencies, deadlines, runtime support requirements
**Do NOT proceed** until the user has answered. Do not assume, research, or fill in blanks yourself. The user's intent drives everything — skipping this step leads to wasted scaffolding and mis-aligned implementation.
Save answers to `.planning/requirements.md` (or update if exists). Confirm with the user before scaffolding.
> **Auto mode exception:** If `--auto` is set with a provided idea document (see `` below), the document IS the Phase 0 answer. Read it carefully and extract problem / success / scope / constraints from its contents.
## Auto Mode Detection
Check if `--auto` flag is present in $ARGUMENTS.
**If auto mode:**
- Skip brownfield mapping offer (assume greenfield)
- Skip deep questioning (extract context from provided document)
- Config: YOLO mode is implicit (skip that question), but ask depth/git/agents FIRST (Step 2a)
- After config: run Steps 6-9 automatically with smart defaults:
- Research: Always yes
- Requirements: Include all table stakes + features from provided document
- Requirements approval: Auto-approve
- Roadmap approval: Auto-approve
**Document requirement:**
Auto mode requires an idea document — either:
- File reference: `/pan:new-project --auto @prd.md`
- Pasted/written text in the prompt
If no document content provided, error:
```
Error: --auto requires an idea document.
Usage:
/pan:new-project --auto @your-idea.md
/pan:new-project --auto [paste or write your idea here]
The document should describe what you want to build.
```
## 1. Setup
**MANDATORY FIRST STEP — Execute these checks before ANY user interaction:**
```bash
INIT=$(node ./.claude/pan-wizard-core/bin/pan-tools.cjs init new-project)
```
Parse JSON for: `researcher_model`, `synthesizer_model`, `roadmapper_model`, `commit_docs`, `project_exists`, `has_codebase_map`, `planning_exists`, `has_existing_code`, `has_package_file`, `is_brownfield`, `needs_codebase_map`, `has_git`, `project_path`.
**If `project_exists` is true:** Error — project already initialized. Use `/pan:progress`.
**If `has_git` is false:** Initialize git:
```bash
git init
```
## 2. Brownfield Offer
**If auto mode:** Skip to Step 4 (assume greenfield, synthesize project.md from provided document).
**If `needs_codebase_map` is true** (from init — existing code detected but no codebase map):
Use AskUserQuestion:
- header: "Codebase"
- question: "I detected existing code in this directory. Would you like to map the codebase first?"
- options:
- "Map codebase first" — Run /pan:map-codebase to understand existing architecture (Recommended)
- "Skip mapping" — Proceed with project initialization
**If "Map codebase first":**
```
Run `/pan:map-codebase` first, then return to `/pan:new-project`
```
Exit command.
**If "Skip mapping" OR `needs_codebase_map` is false:** Continue to Step 3.
## 2a. Auto Mode Config (auto mode only)
**If auto mode:** Apply defaults silently — do NOT call AskUserQuestion. The whole point of `--auto` is non-interactive execution; asking questions here blocks autonomous runs (P-1301 fix, v3.7.2).
**Auto-mode defaults (applied without asking):**
| Setting | Default | Override via |
|---------|---------|--------------|
| Depth | `quick` (3-5 phases, 1-3 plans each) | idea.md frontmatter `planning_depth: standard\|comprehensive` |
| Execution | `parallel` | idea.md frontmatter `parallelization: false` to switch to sequential |
| Git Tracking | `yes` (commit_planning_docs: true) | idea.md frontmatter `commit_planning_docs: false` |
| Research | `yes` (each phase researched before planning) | idea.md frontmatter `research_enabled: false` |
| Plan Check | `yes` (verify plans before exec) | idea.md frontmatter `plan_checker_enabled: false` |
| Verifier | `yes` (verify work after each phase) | idea.md frontmatter `verifier_enabled: false` |
| AI Models | `balanced` profile | idea.md frontmatter `model_profile: quality\|budget` |
**To use a non-default value in auto mode, embed it in the idea.md frontmatter:**
```yaml
---
title: "..."
runtime_preference: claude
budget: 30
priority: medium
# Optional auto-mode overrides:
planning_depth: standard
parallelization: false
research_enabled: false
model_profile: quality
---
```
**Read the idea.md frontmatter once, apply the defaults, log them, proceed.** No AskUserQuestion in this block. If frontmatter is missing/silent on a setting, use the table default.
Create `.planning/config.json` with mode set to "yolo":
```json
{
"mode": "yolo",
"depth": "[selected]",
"parallelization": true|false,
"commit_docs": true|false,
"model_profile": "quality|balanced|budget",
"workflow": {
"research": true|false,
"plan_check": true|false,
"verifier": true|false,
"auto_advance": true
}
}
```
**If commit_docs = No:** Add `.planning/` to `.gitignore`.
**Commit config.json:**
```bash
mkdir -p .planning
node ./.claude/pan-wizard-core/bin/pan-tools.cjs commit "chore: add project config" --files .planning/config.json
```
**Persist auto-advance to config (survives context compaction):**
```bash
node ./.claude/pan-wizard-core/bin/pan-tools.cjs config-set workflow.auto_advance true
```
Proceed to Step 4 (skip Steps 3 and 5).
## 3. Deep Questioning
**If auto mode:** Skip (already handled in Step 2a). Extract project context from provided document instead and proceed to Step 4.
**Display stage banner:**
```
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
PAN ► QUESTIONING
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
```
**Open the conversation:**
Ask inline (freeform, NOT AskUserQuestion):
"What do you want to build?"
Wait for their response. This gives you the context needed to ask intelligent follow-up questions.
**Follow the thread:**
Based on what they said, ask follow-up questions that dig into their response. Use AskUserQuestion with options that probe what they mentioned — interpretations, clarifications, concrete examples.
Keep following threads. Each answer opens new threads to explore. Ask about:
- What excited them
- What problem sparked this
- What they mean by vague terms
- What it would actually look like
- What's already decided
Consult `questioning.md` for techniques:
- Challenge vagueness
- Make abstract concrete
- Surface assumptions
- Find edges
- Reveal motivation
**Check context (background, not out loud):**
As you go, mentally check the context checklist from `questioning.md`. If gaps remain, weave questions naturally. Don't suddenly switch to checklist mode.
**Decision gate:**
When you could write a clear project.md, use AskUserQuestion:
- header: "Ready?"
- question: "I think I understand what you're after. Ready to create project.md?"
- options:
- "Create project.md" — Let's move forward
- "Keep exploring" — I want to share more / ask me more
If "Keep exploring" — ask what they want to add, or identify gaps and probe naturally.
Loop until "Create project.md" selected.
## 4. Write project.md
**If auto mode:** Synthesize from provided document. No "Ready?" gate was shown — proceed directly to commit.
Synthesize all context into `.planning/project.md` using the template from `templates/project.md`.
**For greenfield projects:**
Initialize requirements as hypotheses:
```markdown
## Requirements
### Validated
(None yet — ship to validate)
### Active
- [ ] [Requirement 1]
- [ ] [Requirement 2]
- [ ] [Requirement 3]
### Out of Scope
- [Exclusion 1] — [why]
- [Exclusion 2] — [why]
```
All Active requirements are hypotheses until shipped and validated.
**For brownfield projects (codebase map exists):**
Infer Validated requirements from existing code:
1. Read `.planning/codebase/architecture.md` and `stack.md`
2. Identify what the codebase already does
3. These become the initial Validated set
```markdown
## Requirements
### Validated
- ✓ [Existing capability 1] — existing
- ✓ [Existing capability 2] — existing
- ✓ [Existing capability 3] — existing
### Active
- [ ] [New requirement 1]
- [ ] [New requirement 2]
### Out of Scope
- [Exclusion 1] — [why]
```
**Key Decisions:**
Initialize with any decisions made during questioning:
```markdown
## Key Decisions
| Decision | Rationale | Outcome |
|----------|-----------|---------|
| [Choice from questioning] | [Why] | — Pending |
```
**Last updated footer:**
```markdown
---
*Last updated: [date] after initialization*
```
Do not compress. Capture everything gathered.
**Commit project.md:**
```bash
mkdir -p .planning
node ./.claude/pan-wizard-core/bin/pan-tools.cjs commit "docs: initialize project" --files .planning/project.md
```
## 5. Workflow Preferences
**If auto mode:** Skip — config was collected in Step 2a. Proceed to Step 5.5.
**Check for global defaults** at `~/.pan-wizard-core/defaults.json`. If the file exists, offer to use saved defaults:
```
AskUserQuestion([
{
question: "Use your saved default settings? (from ~/.pan-wizard-core/defaults.json)",
header: "Defaults",
multiSelect: false,
options: [
{ label: "Yes (Recommended)", description: "Use saved defaults, skip settings questions" },
{ label: "No", description: "Configure settings manually" }
]
}
])
```
If "Yes": read `~/.pan-wizard-core/defaults.json`, use those values for config.json, and skip directly to **Commit config.json** below.
If "No" or `~/.pan-wizard-core/defaults.json` doesn't exist: proceed with the questions below.
**Round 1 — Core workflow settings (4 questions):**
```
questions: [
{
header: "Mode",
question: "How do you want to work?",
multiSelect: false,
options: [
{ label: "YOLO (Recommended)", description: "Auto-approve, just execute" },
{ label: "Interactive", description: "Confirm at each step" }
]
},
{
header: "Depth",
question: "How thorough should planning be?",
multiSelect: false,
options: [
{ label: "Quick", description: "Ship fast (3-5 phases, 1-3 plans each)" },
{ label: "Standard", description: "Balanced scope and speed (5-8 phases, 3-5 plans each)" },
{ label: "Comprehensive", description: "Thorough coverage (8-12 phases, 5-10 plans each)" }
]
},
{
header: "Execution",
question: "Run plans in parallel?",
multiSelect: false,
options: [
{ label: "Parallel (Recommended)", description: "Independent plans run simultaneously" },
{ label: "Sequential", description: "One plan at a time" }
]
},
{
header: "Git Tracking",
question: "Commit planning docs to git?",
multiSelect: false,
options: [
{ label: "Yes (Recommended)", description: "Planning docs tracked in version control" },
{ label: "No", description: "Keep .planning/ local-only (add to .gitignore)" }
]
}
]
```
**Round 2 — Workflow agents:**
These spawn additional agents during planning/execution. They add tokens and time but improve quality.
| Agent | When it runs | What it does |
|-------|--------------|--------------|
| **Researcher** | Before planning each phase | Investigates domain, finds patterns, surfaces gotchas |
| **Plan Checker** | After plan is created | Verifies plan actually achieves the phase goal |
| **Verifier** | After phase execution | Confirms must-haves were delivered |
All recommended for important projects. Skip for quick experiments.
```
questions: [
{
header: "Research",
question: "Research before planning each phase? (adds tokens/time)",
multiSelect: false,
options: [
{ label: "Yes (Recommended)", description: "Investigate domain, find patterns, surface gotchas" },
{ label: "No", description: "Plan directly from requirements" }
]
},
{
header: "Plan Check",
question: "Verify plans will achieve their goals? (adds tokens/time)",
multiSelect: false,
options: [
{ label: "Yes (Recommended)", description: "Catch gaps before execution starts" },
{ label: "No", description: "Execute plans without verification" }
]
},
{
header: "Verifier",
question: "Verify work satisfies requirements after each phase? (adds tokens/time)",
multiSelect: false,
options: [
{ label: "Yes (Recommended)", description: "Confirm deliverables match phase goals" },
{ label: "No", description: "Trust execution, skip verification" }
]
},
{
header: "AI Models",
question: "Which AI models for planning agents?",
multiSelect: false,
options: [
{ label: "Balanced (Recommended)", description: "Sonnet for most agents — good quality/cost ratio" },
{ label: "Quality", description: "Opus for research/roadmap — higher cost, deeper analysis" },
{ label: "Budget", description: "Haiku where possible — fastest, lowest cost" }
]
}
]
```
Create `.planning/config.json` with all settings:
```json
{
"mode": "yolo|interactive",
"depth": "quick|standard|comprehensive",
"parallelization": true|false,
"commit_docs": true|false,
"model_profile": "quality|balanced|budget",
"workflow": {
"research": true|false,
"plan_check": true|false,
"verifier": true|false
}
}
```
**If commit_docs = No:**
- Set `commit_docs: false` in config.json
- Add `.planning/` to `.gitignore` (create if needed)
**If commit_docs = Yes:**
- No additional gitignore entries needed
**Commit config.json:**
```bash
node ./.claude/pan-wizard-core/bin/pan-tools.cjs commit "chore: add project config" --files .planning/config.json
```
**Note:** Run `/pan:settings` anytime to update these preferences.
## 5.5. Resolve Model Profile
Use models from init: `researcher_model`, `synthesizer_model`, `roadmapper_model`.
## 6. Research Decision
**If auto mode:** Default to "Research first" without asking.
Use AskUserQuestion:
- header: "Research"
- question: "Research the domain ecosystem before defining requirements?"
- options:
- "Research first (Recommended)" — Discover standard stacks, expected features, architecture patterns
- "Skip research" — I know this domain well, go straight to requirements
**If "Research first":**
Display stage banner:
```
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
PAN ► RESEARCHING
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Researching [domain] ecosystem...
```
Create research directory:
```bash
mkdir -p .planning/research
```
**Determine milestone context:**
Check if this is greenfield or subsequent milestone:
- If no "Validated" requirements in project.md → Greenfield (building from scratch)
- If "Validated" requirements exist → Subsequent milestone (adding to existing app)
Display spawning indicator:
```
◆ Spawning 4 researchers in parallel...
→ Stack research
→ Features research
→ Architecture research
→ Pitfalls research
```
Spawn 4 parallel pan-project-researcher agents with path references:
```
Task(prompt="First, read ./.claude/agents/pan-project-researcher.md for your role and instructions.
Project Research — Stack dimension for [domain].
[greenfield OR subsequent]
Greenfield: Research the standard stack for building [domain] from scratch.
Subsequent: Research what's needed to add [target features] to an existing [domain] app. Don't re-research the existing system.
What's the standard 2025 stack for [domain]?
- {project_path} (Project context and goals)
Your stack.md feeds into roadmap creation. Be prescriptive:
- Specific libraries with versions
- Clear rationale for each choice
- What NOT to use and why
- [ ] Versions are current (verify with Context7/official docs, not training data)
- [ ] Rationale explains WHY, not just WHAT
- [ ] Confidence levels assigned to each recommendation
", subagent_type="general-purpose", model="{researcher_model}", description="Stack research")
Task(prompt="First, read ./.claude/agents/pan-project-researcher.md for your role and instructions.
Project Research — Features dimension for [domain].
[greenfield OR subsequent]
Greenfield: What features do [domain] products have? What's table stakes vs differentiating?
Subsequent: How do [target features] typically work? What's expected behavior?
What features do [domain] products have? What's table stakes vs differentiating?
- {project_path} (Project context)
Your features.md feeds into requirements definition. Categorize clearly:
- Table stakes (must have or users leave)
- Differentiators (competitive advantage)
- Anti-features (things to deliberately NOT build)
- [ ] Categories are clear (table stakes vs differentiators vs anti-features)
- [ ] Complexity noted for each feature
- [ ] Dependencies between features identified
", subagent_type="general-purpose", model="{researcher_model}", description="Features research")
Task(prompt="First, read ./.claude/agents/pan-project-researcher.md for your role and instructions.
Project Research — Architecture dimension for [domain].
[greenfield OR subsequent]
Greenfield: How are [domain] systems typically structured? What are major components?
Subsequent: How do [target features] integrate with existing [domain] architecture?
How are [domain] systems typically structured? What are major components?
- {project_path} (Project context)
Your architecture.md informs phase structure in roadmap. Include:
- Component boundaries (what talks to what)
- Data flow (how information moves)
- Suggested build order (dependencies between components)
- [ ] Components clearly defined with boundaries
- [ ] Data flow direction explicit
- [ ] Build order implications noted
", subagent_type="general-purpose", model="{researcher_model}", description="Architecture research")
Task(prompt="First, read ./.claude/agents/pan-project-researcher.md for your role and instructions.
Project Research — Pitfalls dimension for [domain].
[greenfield OR subsequent]
Greenfield: What do [domain] projects commonly get wrong? Critical mistakes?
Subsequent: What are common mistakes when adding [target features] to [domain]?
What do [domain] projects commonly get wrong? Critical mistakes?
- {project_path} (Project context)
Your pitfalls.md prevents mistakes in roadmap/planning. For each pitfall:
- Warning signs (how to detect early)
- Prevention strategy (how to avoid)
- Which phase should address it
- [ ] Pitfalls are specific to this domain (not generic advice)
- [ ] Prevention strategies are actionable
- [ ] Phase mapping included where relevant
", subagent_type="general-purpose", model="{researcher_model}", description="Pitfalls research")
```
After all 4 agents complete, spawn synthesizer to create summary.md:
```
Task(prompt="
Synthesize research outputs into summary.md.
- .planning/research/stack.md
- .planning/research/features.md
- .planning/research/architecture.md
- .planning/research/pitfalls.md
", subagent_type="pan-research-synthesizer", model="{synthesizer_model}", description="Synthesize research")
```
Display research complete banner and key findings:
```
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
PAN ► RESEARCH COMPLETE ✓
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
## Key Findings
**Stack:** [from summary.md]
**Table Stakes:** [from summary.md]
**Watch Out For:** [from summary.md]
Files: `.planning/research/`
```
**If "Skip research":** Continue to Step 7.
## 7. Define Requirements
Display stage banner:
```
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
PAN ► DEFINING REQUIREMENTS
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
```
**Load context:**
Read project.md and extract:
- Core value (the ONE thing that must work)
- Stated constraints (budget, timeline, tech limitations)
- Any explicit scope boundaries
**If research exists:** Read research/FEATURES.md and extract feature categories.
**If auto mode:**
- Auto-include all table stakes features (users expect these)
- Include features explicitly mentioned in provided document
- Auto-defer differentiators not mentioned in document
- Skip per-category AskUserQuestion loops
- Skip "Any additions?" question
- Skip requirements approval gate
- Generate requirements.md and commit directly
**Present features by category (interactive mode only):**
```
Here are the features for [domain]:
## Authentication
**Table stakes:**
- Sign up with email/password
- Email verification
- Password reset
- Session management
**Differentiators:**
- Magic link login
- OAuth (Google, GitHub)
- 2FA
**Research notes:** [any relevant notes]
---
## [Next Category]
...
```
**If no research:** Gather requirements through conversation instead.
Ask: "What are the main things users need to be able to do?"
For each capability mentioned:
- Ask clarifying questions to make it specific
- Probe for related capabilities
- Group into categories
**Scope each category:**
For each category, use AskUserQuestion:
- header: "[Category]" (max 12 chars)
- question: "Which [category] features are in v1?"
- multiSelect: true
- options:
- "[Feature 1]" — [brief description]
- "[Feature 2]" — [brief description]
- "[Feature 3]" — [brief description]
- "None for v1" — Defer entire category
Track responses:
- Selected features → v1 requirements
- Unselected table stakes → v2 (users expect these)
- Unselected differentiators → out of scope
**Identify gaps:**
Use AskUserQuestion:
- header: "Additions"
- question: "Any requirements research missed? (Features specific to your vision)"
- options:
- "No, research covered it" — Proceed
- "Yes, let me add some" — Capture additions
**Validate core value:**
Cross-check requirements against Core Value from project.md. If gaps detected, surface them.
**Generate requirements.md:**
Create `.planning/requirements.md` with:
- v1 Requirements grouped by category (checkboxes, REQ-IDs)
- v2 Requirements (deferred)
- Out of Scope (explicit exclusions with reasoning)
- Traceability section (empty, filled by roadmap)
**REQ-ID format:** `[CATEGORY]-[NUMBER]` (AUTH-01, CONTENT-02)
**Requirement quality criteria:**
Good requirements are:
- **Specific and testable:** "User can reset password via email link" (not "Handle password reset")
- **User-centric:** "User can X" (not "System does Y")
- **Atomic:** One capability per requirement (not "User can login and manage profile")
- **Independent:** Minimal dependencies on other requirements
Reject vague requirements. Push for specificity:
- "Handle authentication" → "User can log in with email/password and stay logged in across sessions"
- "Support sharing" → "User can share post via link that opens in recipient's browser"
**Present full requirements list (interactive mode only):**
Show every requirement (not counts) for user confirmation:
```
## v1 Requirements
### Authentication
- [ ] **AUTH-01**: User can create account with email/password
- [ ] **AUTH-02**: User can log in and stay logged in across sessions
- [ ] **AUTH-03**: User can log out from any page
### Content
- [ ] **CONT-01**: User can create posts with text
- [ ] **CONT-02**: User can edit their own posts
[... full list ...]
---
Does this capture what you're building? (yes / adjust)
```
If "adjust": Return to scoping.
**Commit requirements:**
```bash
node ./.claude/pan-wizard-core/bin/pan-tools.cjs commit "docs: define v1 requirements" --files .planning/requirements.md
```
## 8. Create Roadmap
Display stage banner:
```
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
PAN ► CREATING ROADMAP
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ Spawning roadmapper...
```
Spawn pan-roadmapper agent with path references:
```
Task(prompt="
- .planning/project.md (Project context)
- .planning/requirements.md (v1 Requirements)
- .planning/research/summary.md (Research findings - if exists)
- .planning/config.json (Depth and mode settings)
Create roadmap:
1. Derive phases from requirements (don't impose structure)
2. Map every v1 requirement to exactly one phase
3. Derive 2-5 success criteria per phase (observable user behaviors)
4. Validate 100% coverage
5. Write files immediately (roadmap.md, state.md, update requirements.md traceability)
6. Return ROADMAP CREATED with summary
Write files first, then return. This ensures artifacts persist even if context is lost.
", subagent_type="pan-roadmapper", model="{roadmapper_model}", description="Create roadmap")
```
**Handle roadmapper return:**
**If `## ROADMAP BLOCKED`:**
- Present blocker information
- Work with user to resolve
- Re-spawn when resolved
**If `## ROADMAP CREATED`:**
Read the created roadmap.md and present it nicely inline:
```
---
## Proposed Roadmap
**[N] phases** | **[X] requirements mapped** | All v1 requirements covered ✓
| # | Phase | Goal | Requirements | Success Criteria |
|---|-------|------|--------------|------------------|
| 1 | [Name] | [Goal] | [REQ-IDs] | [count] |
| 2 | [Name] | [Goal] | [REQ-IDs] | [count] |
| 3 | [Name] | [Goal] | [REQ-IDs] | [count] |
...
### Phase Details
**Phase 1: [Name]**
Goal: [goal]
Requirements: [REQ-IDs]
Success criteria:
1. [criterion]
2. [criterion]
3. [criterion]
**Phase 2: [Name]**
Goal: [goal]
Requirements: [REQ-IDs]
Success criteria:
1. [criterion]
2. [criterion]
[... continue for all phases ...]
---
```
**If auto mode:** Skip approval gate — auto-approve and commit directly.
**CRITICAL: Ask for approval before committing (interactive mode only):**
Use AskUserQuestion:
- header: "Roadmap"
- question: "Does this roadmap structure work for you?"
- options:
- "Approve" — Commit and continue
- "Adjust phases" — Tell me what to change
- "Review full file" — Show raw roadmap.md
**If "Approve":** Continue to commit.
**If "Adjust phases":**
- Get user's adjustment notes
- Re-spawn roadmapper with revision context:
```
Task(prompt="
User feedback on roadmap:
[user's notes]
- .planning/roadmap.md (Current roadmap to revise)
Update the roadmap based on feedback. Edit files in place.
Return ROADMAP REVISED with changes made.
", subagent_type="pan-roadmapper", model="{roadmapper_model}", description="Revise roadmap")
```
- Present revised roadmap
- Loop until user approves
**If "Review full file":** Display raw `cat .planning/roadmap.md`, then re-ask.
**Commit roadmap (after approval or auto mode):**
```bash
node ./.claude/pan-wizard-core/bin/pan-tools.cjs commit "docs: create roadmap ([N] phases)" --files .planning/roadmap.md .planning/state.md .planning/requirements.md
```
## 8.5. Standards Recommendation
**After roadmap is committed, offer standards selection based on project type.**
```bash
RECOMMEND=$(node ./.claude/pan-wizard-core/bin/pan-tools.cjs standards recommend)
```
If the command succeeds (project.md exists and project types detected):
Parse JSON for `project_types` and `recommendations` arrays.
**If auto mode (P-1601 v3.7.5):** Auto-select ONLY `priority: "high"` recommendations. These are recommendations from explicitly-detected non-general project types (e.g., a recognized `web` or `ai` project). For `general` fallback projects with no explicit type signal, **skip auto-selection entirely** — leave `standards.md` absent rather than impose unrelated standards.
```bash
HIGH_IDS=$(echo "$RECOMMEND" | jq -r '.recommendations[] | select(.priority=="high") | .id')
if [ -n "$HIGH_IDS" ]; then
for id in $HIGH_IDS; do
node ./.claude/pan-wizard-core/bin/pan-tools.cjs standards select "$id"
done
node ./.claude/pan-wizard-core/bin/pan-tools.cjs commit "docs: add recommended standards" --files .planning/standards.md
fi
```
Skipping auto-select when the project is `general` keeps `.planning/` minimal for trivial CLIs / scripts and avoids inflating agent context with irrelevant compliance checklists.
**If interactive mode:**
Present recommendations:
```
## Industry Standards
Based on your project type ([types]), these standards are recommended:
| Standard | Category | Why |
|----------|----------|-----|
| [name] | [category] | [description] |
| [name] | [category] | [description] |
```
Use AskUserQuestion:
- header: "Standards"
- question: "Which standards would you like to apply? (advisory — guides agents, doesn't block)"
- multiSelect: true
- options: (from recommendations, max 4)
- "[standard name]" — [description]
For each selected standard:
```bash
node ./.claude/pan-wizard-core/bin/pan-tools.cjs standards select [id]
```
If any selected, commit:
```bash
node ./.claude/pan-wizard-core/bin/pan-tools.cjs commit "docs: add project standards" --files .planning/standards.md
```
Display:
```
Standards applied. Agents will reference these during planning and verification.
Run /pan:health --standards to check compliance anytime.
```
**If command fails** (no project.md or no recommendations): Skip silently — standards are optional.
## 8.9. Safety-Net Commit (P-EXP-001 fix)
**MANDATORY in auto mode, optional in interactive.** Defensive sweep — if any prior commit step was skipped (auto mode hit context budget early, interactive user dismissed a prompt, etc.), fold any uncommitted `.planning/` artifacts into a single bundle commit so the next workflow run starts from a clean tree.
```bash
if [ "$(git status --porcelain .planning/ 2>/dev/null)" ]; then
node ./.claude/pan-wizard-core/bin/pan-tools.cjs commit "docs: bundle remaining .planning artifacts (safety-net)" --files .planning/
fi
```
**Why:** the `whoocache` experiment (2026-05-02) finished new-project with all artifacts on disk (`project.md`, `requirements.md`, `roadmap.md`, src code) but ZERO commits — the autonomous loop reached natural completion before any per-stage `pan-tools commit` invocation. This safety-net catches that pattern.
## 9. Done
Present completion summary:
```
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
PAN ► PROJECT INITIALIZED ✓
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
**[Project Name]**
| Artifact | Location |
|----------------|-----------------------------|
| Project | `.planning/project.md` |
| Config | `.planning/config.json` |
| Research | `.planning/research/` |
| Requirements | `.planning/requirements.md` |
| Roadmap | `.planning/roadmap.md` |
| Standards | `.planning/standards.md` |
**[N] phases** | **[X] requirements** | Ready to build ✓
```
**If auto mode:**
```
╔══════════════════════════════════════════╗
║ AUTO-ADVANCING → DISCUSS PHASE 1 ║
╚══════════════════════════════════════════╝
```
Exit skill and invoke SlashCommand("/pan:discuss-phase 1 --auto")
**If interactive mode:**
```
───────────────────────────────────────────────────────────────
## ▶ Next Up
**Phase 1: [Phase Name]** — [Goal from roadmap.md]
/pan:discuss-phase 1 — gather context and clarify approach
/clear first → fresh context window
---
**Also available:**
- /pan:plan-phase 1 — skip discussion, plan directly
───────────────────────────────────────────────────────────────
```
- [ ] .planning/ directory created
- [ ] Git repo initialized
- [ ] Brownfield detection completed
- [ ] Deep questioning completed (threads followed, not rushed)
- [ ] project.md captures full context → **committed**
- [ ] config.json has workflow mode, depth, parallelization → **committed**
- [ ] Research completed (if selected) — 4 parallel agents spawned → **committed**
- [ ] Requirements gathered (from research or conversation)
- [ ] User scoped each category (v1/v2/out of scope)
- [ ] requirements.md created with REQ-IDs → **committed**
- [ ] pan-roadmapper spawned with context
- [ ] Roadmap files written immediately (not draft)
- [ ] User feedback incorporated (if any)
- [ ] roadmap.md created with phases, requirement mappings, success criteria
- [ ] state.md initialized
- [ ] requirements.md traceability updated
- [ ] User knows next step is `/pan:discuss-phase 1`
**Atomic commits:** Each phase commits its artifacts immediately. If context is lost, artifacts persist.