diff --git a/.planning/config.json.example b/.planning/config.json.example
deleted file mode 100644
index e763297d9..000000000
--- a/.planning/config.json.example
+++ /dev/null
@@ -1,14 +0,0 @@
-{
-  "model_profile": "balanced",
-  "commit_docs": true,
-  "search_gitignored": false,
-  "branching_strategy": "none",
-  "phase_branch_template": "gsd/phase-{phase}-{slug}",
-  "milestone_branch_template": "gsd/{milestone}-{slug}",
-  "workflow": {
-    "research": true,
-    "plan_check": true,
-    "verifier": true
-  },
-  "parallelization": true
-}
\ No newline at end of file
diff --git a/.work/001-map-gsd-deps/001-PROMPT.md b/.work/001-map-gsd-deps/001-PROMPT.md
deleted file mode 100644
index a31b159d6..000000000
--- a/.work/001-map-gsd-deps/001-PROMPT.md
+++ /dev/null
@@ -1,34 +0,0 @@
-# 001: Map dependencies for @commands/gsd/new-project.md
-
-## Objective
-List **all** files that are loaded/referenced when running the command `@commands/gsd/new-project.md` in this repo. The output must be exhaustive and user-facing.
-
-## Context
-Repo: `claude-code-resources/get-shit-done`.
-We need a dependency map for the `@commands/gsd/new-project.md` command. This includes any files it directly references and any files referenced transitively by workflows/templates it invokes. The final list should be presented in the SUMMARY.
-
-Constraints:
-- Do not guess. Trace actual references.
-- Include paths for every file referenced/loaded.
-- If a file is included conditionally, still list it and note the condition.
-- If the command invokes a workflow that in turn references templates or other files, include those as well.
-
-## Process
-1. Open `commands/gsd/new-project.md` and identify explicit references (workflows, templates, other commands, include directives).
-   - Validation: list all direct references with file paths.
-
-2. Follow each referenced file and enumerate any additional files it loads/references (e.g., workflows → templates → references).
-   - Validation: for each file, list its outbound references.
-
-3. Produce a complete, de-duplicated list of all files involved in the execution path.
-   - Validation: no referenced file omitted; no paths outside repo unless explicitly referenced.
-
-4. Write `001-SUMMARY.md` with the full list and a short explanation of how you derived it.
-
-## Verification
-- Re-open each referenced file to ensure no dependencies missed.
-
-## Success Criteria
-- [ ] SUMMARY includes a complete list of every file loaded/referenced by `@commands/gsd/new-project.md`.
-- [ ] Conditional references are noted.
-- [ ] No guesses; each item is traceable to a reference in files.
diff --git a/BUG_REPORT.md b/BUG_REPORT.md
deleted file mode 100644
index 9ead3fa06..000000000
--- a/BUG_REPORT.md
+++ /dev/null
@@ -1,268 +0,0 @@
-# Bug Report - Get Shit Done Codebase Review
-
-**Date:** 2026-01-31
-**Reviewer:** Claude Code Agent
-**Scope:** Full codebase review for bugs, logic errors, and edge cases
-
----
-
-## Critical Bugs (High Priority)
-
-### 1. Missing error handling in statusline.js for file system operations
-
-**File:** `hooks/gsd-statusline.js:51-54`
-**Severity:** High
-**Type:** Runtime error / crash
-
-**Issue:**
-The statusline reads the todos directory without error handling. If there's a permission issue or a race condition where a file gets deleted between `readdirSync` and `statSync`, the statusline will crash.
-
-**Current code:**
-```javascript
-if (session && fs.existsSync(todosDir)) {
-  const files = fs.readdirSync(todosDir)  // Can throw on permission errors
-    .filter(f => f.startsWith(session) && f.includes('-agent-') && f.endsWith('.json'))
-    .map(f => ({ name: f, mtime: fs.statSync(path.join(todosDir, f)).mtime }))  // Can throw if file deleted
-    .sort((a, b) => b.mtime - a.mtime);
-```
-
-The try-catch at line 57 only wraps the JSON.parse, not the directory operations.
-
-**Fix:**
-Wrap the entire directory reading block in try-catch:
-```javascript
-if (session && fs.existsSync(todosDir)) {
-  try {
-    const files = fs.readdirSync(todosDir)
-      .filter(f => f.startsWith(session) && f.includes('-agent-') && f.endsWith('.json'))
-      .map(f => ({ name: f, mtime: fs.statSync(path.join(todosDir, f)).mtime }))
-      .sort((a, b) => b.mtime - a.mtime);
-
-    if (files.length > 0) {
-      try {
-        const todos = JSON.parse(fs.readFileSync(path.join(todosDir, files[0].name), 'utf8'));
-        const inProgress = todos.find(t => t.status === 'in_progress');
-        if (inProgress) task = inProgress.activeForm || '';
-      } catch (e) {}
-    }
-  } catch (e) {
-    // Silently fail - don't break statusline on file system errors
-  }
-}
-```
-
----
-
-### 2. Fragile JSON parsing in bash workflows
-
-**Files:**
-- `get-shit-done/workflows/execute-phase.md:20`
-- `commands/gsd/execute-phase.md:45`
-- `get-shit-done/workflows/execute-phase.md:62`
-- `agents/gsd-executor.md:47`
-
-**Severity:** High
-**Type:** Logic error / silent failure
-
-**Issue:**
-The workflows use fragile grep/sed patterns to extract JSON values instead of proper JSON parsing. These patterns will fail silently if JSON formatting varies.
-
-**Examples:**
-```bash
-# Fragile - fails if JSON is minified or has different spacing
-MODEL_PROFILE=$(cat .planning/config.json 2>/dev/null | grep -o '"model_profile"[[:space:]]*:[[:space:]]*"[^"]*"' | grep -o '"[^"]*"$' | tr -d '"' || echo "balanced")
-
-COMMIT_PLANNING_DOCS=$(cat .planning/config.json 2>/dev/null | grep -o '"commit_docs"[[:space:]]*:[[:space:]]*[^,}]*' | grep -o 'true\|false' || echo "true")
-
-BRANCHING_STRATEGY=$(cat .planning/config.json 2>/dev/null | grep -o '"branching_strategy"[[:space:]]*:[[:space:]]*"[^"]*"' | sed 's/.*:.*"\([^"]*\)"/\1/' || echo "none")
-```
-
-**Problems:**
-- Fails if JSON is minified (no spaces)
-- Fails if values aren't quoted (e.g., `true` vs `"true"`)
-- Fails if there are escaped quotes in the value
-- Fails if spacing is different than expected
-
-**Fix:**
-Use `jq` for robust JSON parsing:
-```bash
-# Robust JSON parsing
-MODEL_PROFILE=$(jq -r '.model_profile // "balanced"' .planning/config.json 2>/dev/null || echo "balanced")
-
-COMMIT_PLANNING_DOCS=$(jq -r '.commit_docs // true' .planning/config.json 2>/dev/null | grep -o 'true\|false' || echo "true")
-
-BRANCHING_STRATEGY=$(jq -r '.branching_strategy // "none"' .planning/config.json 2>/dev/null || echo "none")
-
-PHASE_BRANCH_TEMPLATE=$(jq -r '.phase_branch_template // "gsd/phase-{phase}-{slug}"' .planning/config.json 2>/dev/null || echo "gsd/phase-{phase}-{slug}")
-```
-
-**Impact:**
-Without this fix, configuration settings may silently fall back to defaults even when explicitly configured, leading to unexpected behavior.
-
----
-
-### 3. Violation of stated git commit rules
-
-**File:** `commands/gsd/execute-phase.md:94`
-**Severity:** Medium
-**Type:** Inconsistency with documented rules
-
-**Issue:**
-The workflow uses `git add -u` which violates the explicitly stated rule "NEVER use git add . or git add -A or git add src/".
-
-**Current code:**
-```bash
-git add -u && git commit -m "fix({phase}): orchestrator corrections"
-```
-
-**Fix:**
-Either:
-1. Remove this step if orchestrator corrections shouldn't happen
-2. Explicitly enumerate the files to stage:
-```bash
-# List modified files and stage individually
-git status --porcelain | grep '^ M' | cut -c4- | while read file; do
-  git add "$file"
-done
-git commit -m "fix({phase}): orchestrator corrections"
-```
-
-Or better yet, avoid making corrections at the orchestrator level.
-
----
-
-## Medium Priority Issues
-
-### 4. Missing hex color validation in install.js
-
-**File:** `bin/install.js:437-441`
-**Severity:** Medium
-**Type:** Data validation
-
-**Issue:**
-The code accepts hex color values without validation:
-
-```javascript
-} else if (colorValue.startsWith('#')) {
-  // Already hex, keep as is
-  newLines.push(line);
-}
-```
-
-**Fix:**
-Add validation for hex color format:
-```javascript
-} else if (colorValue.startsWith('#')) {
-  // Validate hex color format (#RGB or #RRGGBB)
-  if (/^#[0-9A-Fa-f]{3}$|^#[0-9A-Fa-f]{6}$/.test(colorValue)) {
-    newLines.push(line);
-  }
-  // Skip invalid hex colors
-}
-```
-
----
-
-### 5. Potential issue with branch variable expansion
-
-**File:** `get-shit-done/workflows/execute-phase.md:100-103`
-**Severity:** Low
-**Type:** Shell safety
-
-**Issue:**
-Phase name is used in shell variable without proper quoting in some places:
-
-```bash
-PHASE_NAME=$(basename "$PHASE_DIR" | sed 's/^[0-9]*-//')
-```
-
-The variable is properly quoted, but the subsequent sed operations should also be reviewed for edge cases with special characters in phase names.
-
-**Fix:**
-Ensure all variable expansions are properly quoted, especially in sed operations.
-
----
-
-### 6. Missing CONTEXT.md reference documentation
-
-**File:** `agents/gsd-executor.md:69`
-**Severity:** Low
-**Type:** Documentation gap
-
-**Issue:**
-The executor mentions that plans can reference CONTEXT.md but doesn't explain how it should be passed or read.
-
-**Current text:**
-```markdown
-**If plan references CONTEXT.md:** The CONTEXT.md file provides the user's vision for this phase — how they imagine it working, what's essential, and what's out of scope. Honor this context throughout execution.
-```
-
-**Fix:**
-Add clarity about how CONTEXT.md is accessed:
-```markdown
-**If plan references CONTEXT.md:** Read .planning/phases/{phase}/CONTEXT.md for the user's vision. Honor this context throughout execution. The file provides how they imagine it working, what's essential, and what's out of scope.
-```
-
----
-
-## Low Priority / Code Quality Issues
-
-### 7. Inconsistent error handling patterns
-
-**Files:** Multiple
-**Severity:** Low
-**Type:** Code quality
-
-**Issue:**
-Error handling is inconsistent across different files:
-- Some functions have comprehensive try-catch blocks
-- Others rely on optional chaining or existence checks
-- Some fail silently, others propagate errors
-
-**Recommendation:**
-Establish consistent error handling patterns across the codebase, especially for:
-- File system operations
-- JSON parsing
-- Git operations
-- External command execution
-
----
-
-### 8. Hardcoded paths in multiple locations
-
-**Files:** Multiple
-**Severity:** Low
-**Type:** Maintainability
-
-**Issue:**
-Paths like `~/.claude/`, `.planning/`, etc. are hardcoded in many places. Changes to directory structure would require updates in multiple files.
-
-**Examples:**
-- `hooks/gsd-statusline.js:49` - hardcoded `~/.claude/todos`
-- `hooks/gsd-check-update.js:12` - hardcoded `~/.claude/`
-- Multiple workflow files reference `.planning/`
-
-**Recommendation:**
-Consider centralizing path constants in a shared configuration module.
-
----
-
-## Summary
-
-**Total bugs found:** 8
-
-**By severity:**
-- Critical: 3 (statusline error handling, JSON parsing, git rules violation)
-- Medium: 3 (color validation, variable expansion, documentation)
-- Low: 2 (error handling patterns, hardcoded paths)
-
-**Recommended immediate actions:**
-1. Fix statusline.js error handling (prevents crashes)
-2. Replace grep/sed JSON parsing with jq (prevents silent configuration failures)
-3. Fix or document the git add -u usage (consistency with stated rules)
-
-**Next steps:**
-- Prioritize fixes based on user impact
-- Add unit tests for critical paths (especially JSON parsing and file operations)
-- Consider adding integration tests for workflow orchestration
-- Establish error handling and coding standards documentation
diff --git a/FIXES_APPLIED.md b/FIXES_APPLIED.md
deleted file mode 100644
index 49959df46..000000000
--- a/FIXES_APPLIED.md
+++ /dev/null
@@ -1,198 +0,0 @@
-# Fixes Applied - Bug Report Follow-up
-
-**Date:** 2026-01-31
-**Related:** BUG_REPORT.md
-
----
-
-## Critical Bugs Fixed
-
-### 1. ✅ Fixed: Missing error handling in statusline.js
-
-**File:** `hooks/gsd-statusline.js`
-**Change:** Wrapped directory reading operations in try-catch block
-
-**Before:**
-```javascript
-if (session && fs.existsSync(todosDir)) {
-  const files = fs.readdirSync(todosDir)  // Could crash
-    .filter(...)
-    .map(f => ({ name: f, mtime: fs.statSync(...).mtime }))  // Could crash
-```
-
-**After:**
-```javascript
-if (session && fs.existsSync(todosDir)) {
-  try {
-    const files = fs.readdirSync(todosDir)
-      .filter(...)
-      .map(f => ({ name: f, mtime: fs.statSync(...).mtime }))
-    // ... rest of logic
-  } catch (e) {
-    // Silently fail on file system errors - don't break statusline
-  }
-}
-```
-
-**Impact:** Prevents statusline crashes from file system permission issues or race conditions.
-
----
-
-### 2. ✅ Fixed: Hex color validation in install.js
-
-**File:** `bin/install.js`
-**Change:** Added validation for hex color format
-
-**Before:**
-```javascript
-} else if (colorValue.startsWith('#')) {
-  // Already hex, keep as is
-  newLines.push(line);
-}
-```
-
-**After:**
-```javascript
-} else if (colorValue.startsWith('#')) {
-  // Validate hex color format (#RGB or #RRGGBB)
-  if (/^#[0-9a-f]{3}$|^#[0-9a-f]{6}$/i.test(colorValue)) {
-    // Already hex and valid, keep as is
-    newLines.push(line);
-  }
-  // Skip invalid hex colors
-}
-```
-
-**Impact:** Prevents invalid hex color values from being written to config files.
-
----
-
-### 3. ✅ Fixed: Git add rules violation in execute-phase.md
-
-**File:** `commands/gsd/execute-phase.md`
-**Change:** Replaced `git add -u` with individual file staging
-
-**Before:**
-```bash
-git add -u && git commit -m "fix({phase}): orchestrator corrections"
-```
-
-**After:**
-```bash
-# Stage each modified file individually (never use git add -u, git add ., or git add -A)
-git status --porcelain | grep '^ M' | cut -c4- | while read file; do
-  git add "$file"
-done
-git commit -m "fix({phase}): orchestrator corrections"
-```
-
-**Impact:** Maintains consistency with documented git commit rules and prevents accidental staging of unwanted files.
-
----
-
-## Known Issues Remaining
-
-### Fragile JSON Parsing (High Priority - Not Fixed)
-
-**Status:** ⚠️ Documented but not fixed
-**Reason:** Requires more extensive refactoring to use `jq` or alternative JSON parser
-**Location:** Multiple workflow files
-
-**Files affected:**
-- `get-shit-done/workflows/execute-phase.md:20, 62, 76-77`
-- `commands/gsd/execute-phase.md:45, 100`
-- `agents/gsd-executor.md:47`
-
-**Current approach:**
-```bash
-MODEL_PROFILE=$(cat .planning/config.json 2>/dev/null | grep -o '"model_profile"[[:space:]]*:[[:space:]]*"[^"]*"' | grep -o '"[^"]*"$' | tr -d '"' || echo "balanced")
-```
-
-**Recommended fix:**
-```bash
-MODEL_PROFILE=$(jq -r '.model_profile // "balanced"' .planning/config.json 2>/dev/null || echo "balanced")
-```
-
-**Workaround for users:**
-- Ensure `.planning/config.json` is properly formatted with consistent spacing
-- Always quote string values in JSON
-- Avoid special characters in configuration values
-
-**Next steps:**
-- Evaluate if `jq` can be a required dependency
-- Or create a Node.js helper script for JSON parsing that workflows can call
-- Or document the JSON formatting requirements clearly for users
-
----
-
-## Testing Recommendations
-
-### 1. Statusline Error Handling
-**Test case:** Delete files while statusline is reading them
-```bash
-# Terminal 1: Watch statusline
-while true; do node hooks/gsd-statusline.js; sleep 1; done
-
-# Terminal 2: Create and delete files rapidly
-mkdir -p ~/.claude/todos
-while true; do
-  touch ~/.claude/todos/test-file.json
-  sleep 0.1
-  rm ~/.claude/todos/test-file.json
-  sleep 0.1
-done
-```
-
-**Expected:** Statusline continues working without crashes
-
-### 2. Color Validation
-**Test case:** Invalid hex colors in frontmatter
-```markdown
----
-color: #ZZZ
----
-```
-**Expected:** Invalid color is skipped during installation
-
-### 3. Git Operations
-**Test case:** Verify individual file staging
-```bash
-# Create some changes
-touch file1.txt file2.txt
-git add file1.txt file2.txt
-git commit -m "test files"
-
-echo "change" > file1.txt
-echo "change" > file2.txt
-
-# Run the orchestrator commit logic
-# Should stage each file individually
-```
-
-**Expected:** Files are staged one at a time, not in bulk
-
----
-
-## Future Improvements
-
-1. **Centralize JSON parsing**: Create a helper utility for all JSON config reading
-2. **Add unit tests**: Test critical paths like statusline, installer, config parsing
-3. **Establish error handling patterns**: Document and enforce consistent error handling
-4. **Path constants**: Centralize hardcoded paths in a configuration module
-5. **Integration tests**: Test full workflow orchestration end-to-end
-
----
-
-## Changelog Entry
-
-```markdown
-## [Unreleased]
-
-### Fixed
-- **hooks/gsd-statusline.js**: Added error handling for file system operations to prevent crashes
-- **bin/install.js**: Added validation for hex color values to prevent invalid config
-- **commands/gsd/execute-phase.md**: Fixed git staging to use individual files instead of git add -u
-
-### Known Issues
-- JSON config parsing uses fragile grep/sed patterns - will be addressed in future release
-```
diff --git a/MAINTAINERS.md b/MAINTAINERS.md
deleted file mode 100644
index 8460b80ce..000000000
--- a/MAINTAINERS.md
+++ /dev/null
@@ -1,147 +0,0 @@
-# GSD Maintainer Guide
-
-Quick reference for release workflows and maintenance tasks.
-
-## Release Workflow
-
-### Standard Release
-
-```bash
-/gsd-publish-version
-```
-
-The command walks you through:
-1. Check uncommitted changes
-2. Generate changelog from commits
-3. Review and approve changelog
-4. Update CHANGELOG.md
-5. Bump version (`npm version patch|minor|major`)
-6. Push to GitHub with tags
-
-GitHub Actions then:
-- Creates GitHub Release from CHANGELOG.md
-- Publishes to npm
-
-### Pre-release (Experimental Features)
-
-For risky features, ship as alpha first:
-
-```bash
-# Bump to alpha
-npm version prerelease --preid=alpha
-
-# Push
-git push origin main --tags
-```
-
-Pre-release tags (`v1.10.0-alpha.0`) don't trigger npm publish or GitHub Release creation. Users opt-in explicitly.
-
-If it works, promote to stable:
-```bash
-npm version minor  # or patch
-git push origin main --tags
-```
-
-If it fails, delete the tag and move on.
-
-### Hotfix
-
-Production broken? Skip changelog ceremony:
-
-```bash
-# Fix the issue
-git add . && git commit -m "fix(install): handle Windows UNC paths"
-
-# Bump and push
-npm version patch
-git push origin main --tags
-```
-
-## Version Cadence
-
-| Type | When | Example |
-|------|------|---------|
-| MAJOR | Breaking changes | Command removed, format changed |
-| MINOR | New features | New command, new capability |
-| PATCH | Bug fixes | Batch weekly, or immediately if critical |
-
-## Changelog Format
-
-Follow [Keep a Changelog](https://keepachangelog.com/):
-
-```markdown
-## [1.10.0] - 2025-01-22
-
-### Added
-- New `/gsd:whats-new` command
-
-### Changed
-- Improved parallel execution
-
-### Fixed
-- STATE.md progress calculation
-
-### Removed
-- **BREAKING:** Deprecated ISSUES.md system
-```
-
-## Dependency Policy
-
-Before adding dependencies:
-1. Check bundle size impact
-2. Evaluate if it's worth the weight
-3. Consider if the functionality can be implemented without it
-
-The codebase intelligence system was removed partly because sql.js added 21MB.
-
-## Recovery Procedures
-
-### Broken npm Release
-
-Within 72 hours:
-```bash
-npm unpublish get-shit-done-cc@1.9.5
-```
-
-After 72 hours: Publish a fix as new patch version.
-
-### Wrong Tag
-
-```bash
-# Delete local and remote
-git tag -d v1.9.5
-git push origin :refs/tags/v1.9.5
-
-# Recreate correctly
-git tag -a v1.9.5 -m "Release v1.9.5"
-git push origin v1.9.5
-```
-
-### Missing Changelog Entry
-
-Either amend the release commit or add a follow-up commit with the missing content.
-
-## CI/CD Setup
-
-### Required Secrets
-
-In GitHub repo settings → Secrets → Actions:
-
-- `NPM_TOKEN`: npm automation token with publish access
-
-`GITHUB_TOKEN` is provided automatically.
-
-### Branch Protection (Optional)
-
-Settings → Branches → Add rule for `main`:
-- Require status checks: `test`, `lint`
-- Disable force pushes
-
-## Reviewing Contributor PRs
-
-Checklist:
-- [ ] Follows conventional commit format
-- [ ] No enterprise patterns or filler
-- [ ] CHANGELOG.md updated for user-facing changes
-- [ ] No unnecessary dependencies
-- [ ] Tested on Windows if touching paths
diff --git a/assets/gsd-logo-2000-transparent.png b/assets/gsd-logo-2000-transparent.png
new file mode 100644
index 000000000..b4584cc6a
Binary files /dev/null and b/assets/gsd-logo-2000-transparent.png differ
diff --git a/assets/gsd-logo-2000-transparent.svg b/assets/gsd-logo-2000-transparent.svg
new file mode 100644
index 000000000..d9f61c16e
--- /dev/null
+++ b/assets/gsd-logo-2000-transparent.svg
@@ -0,0 +1,17 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 2000 2000" width="2000" height="2000">
+  <defs>
+    <style>
+      .logo { font-family: 'SF Mono', 'Fira Code', 'JetBrains Mono', 'Courier New', monospace; fill: #7dcfff; }
+    </style>
+  </defs>
+
+  <!-- GSD ASCII Logo - centered -->
+  <g transform="translate(1000, 1000)">
+    <text class="logo" font-size="108" text-anchor="middle" y="-225" xml:space="preserve">  ██████╗ ███████╗██████╗ </text>
+    <text class="logo" font-size="108" text-anchor="middle" y="-105" xml:space="preserve"> ██╔════╝ ██╔════╝██╔══██╗</text>
+    <text class="logo" font-size="108" text-anchor="middle" y="15" xml:space="preserve"> ██║  ███╗███████╗██║  ██║</text>
+    <text class="logo" font-size="108" text-anchor="middle" y="135" xml:space="preserve"> ██║   ██║╚════██║██║  ██║</text>
+    <text class="logo" font-size="108" text-anchor="middle" y="255" xml:space="preserve"> ╚██████╔╝███████║██████╔╝</text>
+    <text class="logo" font-size="108" text-anchor="middle" y="375" xml:space="preserve">  ╚═════╝ ╚══════╝╚═════╝ </text>
+  </g>
+</svg>
diff --git a/commands/gsd/new-project.md.bak b/commands/gsd/new-project.md.bak
new file mode 100644
index 000000000..c1801bce4
--- /dev/null
+++ b/commands/gsd/new-project.md.bak
@@ -0,0 +1,1041 @@
+---
+name: gsd:new-project
+description: Initialize a new project with deep context gathering and PROJECT.md
+allowed-tools:
+  - Read
+  - Bash
+  - Write
+  - Task
+  - AskUserQuestion
+---
+
+<objective>
+
+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 command takes you from idea to ready-for-planning.
+
+**Creates:**
+
+- `.planning/PROJECT.md` — project context
+- `.planning/config.json` — workflow preferences
+- `.planning/research/` — domain research (optional)
+- `.planning/REQUIREMENTS.md` — scoped requirements
+- `.planning/ROADMAP.md` — phase structure
+- `.planning/STATE.md` — project memory
+
+**After this command:** Run `/gsd:plan-phase 1` to start execution.
+
+</objective>
+
+<execution_context>
+
+@~/.claude/get-shit-done/references/questioning.md
+@~/.claude/get-shit-done/references/ui-brand.md
+@~/.claude/get-shit-done/templates/project.md
+@~/.claude/get-shit-done/templates/requirements.md
+
+</execution_context>
+
+<process>
+
+## Phase 1: Setup
+
+**MANDATORY FIRST STEP — Execute these checks before ANY user interaction:**
+
+1. **Abort if project exists:**
+
+   ```bash
+   [ -f .planning/PROJECT.md ] && echo "ERROR: Project already initialized. Use /gsd:progress" && exit 1
+   ```
+
+2. **Initialize git repo in THIS directory** (required even if inside a parent repo):
+
+   ```bash
+   if [ -d .git ] || [ -f .git ]; then
+       echo "Git repo exists in current directory"
+   else
+       git init
+       echo "Initialized new git repo"
+   fi
+   ```
+
+3. **Detect existing code (brownfield detection):**
+
+   ```bash
+   CODE_FILES=$(find . -name "*.ts" -o -name "*.js" -o -name "*.py" -o -name "*.go" -o -name "*.rs" -o -name "*.swift" -o -name "*.java" 2>/dev/null | grep -v node_modules | grep -v .git | head -20)
+   HAS_PACKAGE=$([ -f package.json ] || [ -f requirements.txt ] || [ -f Cargo.toml ] || [ -f go.mod ] || [ -f Package.swift ] && echo "yes")
+   HAS_CODEBASE_MAP=$([ -d .planning/codebase ] && echo "yes")
+   ```
+
+   **You MUST run all bash commands above using the Bash tool before proceeding.**
+
+## Phase 2: Brownfield Offer
+
+**If existing code detected and .planning/codebase/ doesn't exist:**
+
+Check the results from setup step:
+
+- If `CODE_FILES` is non-empty OR `HAS_PACKAGE` is "yes"
+- AND `HAS_CODEBASE_MAP` is NOT "yes"
+
+Use AskUserQuestion:
+
+- header: "Existing Code"
+- question: "I detected existing code in this directory. Would you like to map the codebase first?"
+- options:
+  - "Map codebase first" — Run /gsd:map-codebase to understand existing architecture (Recommended)
+  - "Skip mapping" — Proceed with project initialization
+
+**If "Map codebase first":**
+
+```
+Run `/gsd:map-codebase` first, then return to `/gsd:new-project`
+```
+
+Exit command.
+
+**If "Skip mapping":** Continue to Phase 3.
+
+**If no existing code detected OR codebase already mapped:** Continue to Phase 3.
+
+## Phase 3: Deep Questioning
+
+**Display stage banner:**
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+ GSD ► 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.
+
+## Phase 4: Write PROJECT.md
+
+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
+git add .planning/PROJECT.md
+git commit -m "$(cat <<'EOF'
+docs: initialize project
+
+[One-liner from PROJECT.md What This Is section]
+EOF
+)"
+```
+
+## Phase 5: Workflow Preferences
+
+**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: "Model Profile",
+    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
+git add .planning/config.json
+git commit -m "$(cat <<'EOF'
+chore: add project config
+
+Mode: [chosen mode]
+Depth: [chosen depth]
+Parallelization: [enabled/disabled]
+Workflow agents: research=[on/off], plan_check=[on/off], verifier=[on/off]
+EOF
+)"
+```
+
+**Note:** Run `/gsd:settings` anytime to update these preferences.
+
+## Phase 5.5: Resolve Model Profile
+
+Read model profile for agent spawning:
+
+```bash
+MODEL_PROFILE=$(cat .planning/config.json 2>/dev/null | grep -o '"model_profile"[[:space:]]*:[[:space:]]*"[^"]*"' | grep -o '"[^"]*"$' | tr -d '"' || echo "balanced")
+```
+
+Default to "balanced" if not set.
+
+**Model lookup table:**
+
+| Agent                    | quality | balanced | budget |
+| ------------------------ | ------- | -------- | ------ |
+| gsd-project-researcher   | opus    | sonnet   | haiku  |
+| gsd-research-synthesizer | sonnet  | sonnet   | haiku  |
+| gsd-roadmapper           | opus    | sonnet   | sonnet |
+
+Store resolved models for use in Task calls below.
+
+## Phase 6: Research Decision
+
+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:
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+ GSD ► 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 gsd-project-researcher agents with rich context:
+
+```
+Task(prompt="First, read ~/.claude/agents/gsd-project-researcher.md for your role and instructions.
+
+<research_type>
+Project Research — Stack dimension for [domain].
+</research_type>
+
+<milestone_context>
+[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.
+</milestone_context>
+
+<question>
+What's the standard 2025 stack for [domain]?
+</question>
+
+<project_context>
+[PROJECT.md summary - core value, constraints, what they're building]
+</project_context>
+
+<downstream_consumer>
+Your STACK.md feeds into roadmap creation. Be prescriptive:
+- Specific libraries with versions
+- Clear rationale for each choice
+- What NOT to use and why
+</downstream_consumer>
+
+<quality_gate>
+- [ ] Versions are current (verify with Context7/official docs, not training data)
+- [ ] Rationale explains WHY, not just WHAT
+- [ ] Confidence levels assigned to each recommendation
+</quality_gate>
+
+<output>
+Write to: .planning/research/STACK.md
+Use template: ~/.claude/get-shit-done/templates/research-project/STACK.md
+</output>
+", subagent_type="general-purpose", model="{researcher_model}", description="Stack research")
+
+Task(prompt="First, read ~/.claude/agents/gsd-project-researcher.md for your role and instructions.
+
+<research_type>
+Project Research — Features dimension for [domain].
+</research_type>
+
+<milestone_context>
+[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?
+</milestone_context>
+
+<question>
+What features do [domain] products have? What's table stakes vs differentiating?
+</question>
+
+<project_context>
+[PROJECT.md summary]
+</project_context>
+
+<downstream_consumer>
+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)
+</downstream_consumer>
+
+<quality_gate>
+- [ ] Categories are clear (table stakes vs differentiators vs anti-features)
+- [ ] Complexity noted for each feature
+- [ ] Dependencies between features identified
+</quality_gate>
+
+<output>
+Write to: .planning/research/FEATURES.md
+Use template: ~/.claude/get-shit-done/templates/research-project/FEATURES.md
+</output>
+", subagent_type="general-purpose", model="{researcher_model}", description="Features research")
+
+Task(prompt="First, read ~/.claude/agents/gsd-project-researcher.md for your role and instructions.
+
+<research_type>
+Project Research — Architecture dimension for [domain].
+</research_type>
+
+<milestone_context>
+[greenfield OR subsequent]
+
+Greenfield: How are [domain] systems typically structured? What are major components?
+Subsequent: How do [target features] integrate with existing [domain] architecture?
+</milestone_context>
+
+<question>
+How are [domain] systems typically structured? What are major components?
+</question>
+
+<project_context>
+[PROJECT.md summary]
+</project_context>
+
+<downstream_consumer>
+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)
+</downstream_consumer>
+
+<quality_gate>
+- [ ] Components clearly defined with boundaries
+- [ ] Data flow direction explicit
+- [ ] Build order implications noted
+</quality_gate>
+
+<output>
+Write to: .planning/research/ARCHITECTURE.md
+Use template: ~/.claude/get-shit-done/templates/research-project/ARCHITECTURE.md
+</output>
+", subagent_type="general-purpose", model="{researcher_model}", description="Architecture research")
+
+Task(prompt="First, read ~/.claude/agents/gsd-project-researcher.md for your role and instructions.
+
+<research_type>
+Project Research — Pitfalls dimension for [domain].
+</research_type>
+
+<milestone_context>
+[greenfield OR subsequent]
+
+Greenfield: What do [domain] projects commonly get wrong? Critical mistakes?
+Subsequent: What are common mistakes when adding [target features] to [domain]?
+</milestone_context>
+
+<question>
+What do [domain] projects commonly get wrong? Critical mistakes?
+</question>
+
+<project_context>
+[PROJECT.md summary]
+</project_context>
+
+<downstream_consumer>
+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
+</downstream_consumer>
+
+<quality_gate>
+- [ ] Pitfalls are specific to this domain (not generic advice)
+- [ ] Prevention strategies are actionable
+- [ ] Phase mapping included where relevant
+</quality_gate>
+
+<output>
+Write to: .planning/research/PITFALLS.md
+Use template: ~/.claude/get-shit-done/templates/research-project/PITFALLS.md
+</output>
+", subagent_type="general-purpose", model="{researcher_model}", description="Pitfalls research")
+```
+
+After all 4 agents complete, spawn synthesizer to create SUMMARY.md:
+
+```
+Task(prompt="
+<task>
+Synthesize research outputs into SUMMARY.md.
+</task>
+
+<research_files>
+Read these files:
+- .planning/research/STACK.md
+- .planning/research/FEATURES.md
+- .planning/research/ARCHITECTURE.md
+- .planning/research/PITFALLS.md
+</research_files>
+
+<output>
+Write to: .planning/research/SUMMARY.md
+Use template: ~/.claude/get-shit-done/templates/research-project/SUMMARY.md
+Commit after writing.
+</output>
+", subagent_type="gsd-research-synthesizer", model="{synthesizer_model}", description="Synthesize research")
+```
+
+Display research complete banner and key findings:
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+ GSD ► 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 Phase 7.
+
+## Phase 7: Define Requirements
+
+Display stage banner:
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+ GSD ► 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.
+
+**Present features by category:**
+
+```
+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 name]"
+- 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:**
+
+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
+git add .planning/REQUIREMENTS.md
+git commit -m "$(cat <<'EOF'
+docs: define v1 requirements
+
+[X] requirements across [N] categories
+[Y] requirements deferred to v2
+EOF
+)"
+```
+
+## Phase 8: Create Roadmap
+
+Display stage banner:
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+ GSD ► CREATING ROADMAP
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+◆ Spawning roadmapper...
+```
+
+Spawn gsd-roadmapper agent with context:
+
+```
+Task(prompt="
+<planning_context>
+
+**Project:**
+@.planning/PROJECT.md
+
+**Requirements:**
+@.planning/REQUIREMENTS.md
+
+**Research (if exists):**
+@.planning/research/SUMMARY.md
+
+**Config:**
+@.planning/config.json
+
+</planning_context>
+
+<instructions>
+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.
+</instructions>
+", subagent_type="gsd-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 ...]
+
+---
+```
+
+**CRITICAL: Ask for approval before committing:**
+
+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="
+  <revision>
+  User feedback on roadmap:
+  [user's notes]
+
+  Current ROADMAP.md: @.planning/ROADMAP.md
+
+  Update the roadmap based on feedback. Edit files in place.
+  Return ROADMAP REVISED with changes made.
+  </revision>
+  ", subagent_type="gsd-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):**
+
+```bash
+git add .planning/ROADMAP.md .planning/STATE.md .planning/REQUIREMENTS.md
+git commit -m "$(cat <<'EOF'
+docs: create roadmap ([N] phases)
+
+Phases:
+1. [phase-name]: [requirements covered]
+2. [phase-name]: [requirements covered]
+...
+
+All v1 requirements mapped to phases.
+EOF
+)"
+```
+
+## Phase 10: Done
+
+Present completion with next steps:
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+ GSD ► 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`      |
+
+**[N] phases** | **[X] requirements** | Ready to build ✓
+
+───────────────────────────────────────────────────────────────
+
+## ▶ Next Up
+
+**Phase 1: [Phase Name]** — [Goal from ROADMAP.md]
+
+/gsd:discuss-phase 1 — gather context and clarify approach
+
+<sub>/clear first → fresh context window</sub>
+
+---
+
+**Also available:**
+- /gsd:plan-phase 1 — skip discussion, plan directly
+
+───────────────────────────────────────────────────────────────
+```
+
+</process>
+
+<output>
+
+- `.planning/PROJECT.md`
+- `.planning/config.json`
+- `.planning/research/` (if research selected)
+  - `STACK.md`
+  - `FEATURES.md`
+  - `ARCHITECTURE.md`
+  - `PITFALLS.md`
+  - `SUMMARY.md`
+- `.planning/REQUIREMENTS.md`
+- `.planning/ROADMAP.md`
+- `.planning/STATE.md`
+
+</output>
+
+<success_criteria>
+
+- [ ] .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**
+- [ ] gsd-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 `/gsd:discuss-phase 1`
+
+**Atomic commits:** Each phase commits its artifacts immediately. If context is lost, artifacts persist.
+
+</success_criteria>
diff --git a/get-shit-done/references/decimal-phase-calculation.md b/get-shit-done/references/decimal-phase-calculation.md
new file mode 100644
index 000000000..15bca5567
--- /dev/null
+++ b/get-shit-done/references/decimal-phase-calculation.md
@@ -0,0 +1,59 @@
+# Decimal Phase Calculation
+
+Calculate the next decimal phase number for urgent insertions.
+
+## Find Existing Decimals
+
+For a given integer phase, find all existing decimal phases:
+
+```bash
+# Find decimal phases after integer phase N (e.g., 06.1, 06.2)
+AFTER_PHASE=$1  # e.g., 6
+
+# Pad to 2 digits
+PADDED=$(printf "%02d" "$AFTER_PHASE")
+
+# Find existing decimals
+EXISTING=$(ls -d .planning/phases/${PADDED}.*-* 2>/dev/null | \
+  xargs -I{} basename {} | \
+  grep -oE '^[0-9]+\.[0-9]+' | \
+  sort -V)
+```
+
+## Calculate Next Decimal
+
+Find the highest decimal suffix and increment:
+
+```bash
+if [ -z "$EXISTING" ]; then
+  # No decimals exist, start at .1
+  NEXT_DECIMAL="1"
+else
+  # Get highest decimal suffix
+  MAX_SUFFIX=$(echo "$EXISTING" | tail -1 | grep -oE '\.[0-9]+$' | tr -d '.')
+  NEXT_DECIMAL=$((MAX_SUFFIX + 1))
+fi
+
+# Format: 06.1, 06.2, etc.
+DECIMAL_PHASE="${PADDED}.${NEXT_DECIMAL}"
+```
+
+## Examples
+
+| Existing Phases | Next Phase |
+|-----------------|------------|
+| 06 only | 06.1 |
+| 06, 06.1 | 06.2 |
+| 06, 06.1, 06.2 | 06.3 |
+
+## Directory Naming
+
+Decimal phase directories use the full decimal number:
+
+```bash
+SLUG=$(echo "$DESCRIPTION" | tr '[:upper:]' '[:lower:]' | sed 's/[^a-z0-9]/-/g' | sed 's/--*/-/g' | sed 's/^-//;s/-$//')
+PHASE_DIR=".planning/phases/${DECIMAL_PHASE}-${SLUG}"
+mkdir -p "$PHASE_DIR"
+```
+
+Example: `.planning/phases/06.1-fix-critical-auth-bug/`
diff --git a/get-shit-done/references/git-planning-commit.md b/get-shit-done/references/git-planning-commit.md
new file mode 100644
index 000000000..e53584de5
--- /dev/null
+++ b/get-shit-done/references/git-planning-commit.md
@@ -0,0 +1,50 @@
+# Git Planning Commit
+
+Check whether to commit planning artifacts, then commit if enabled.
+
+## Check Configuration
+
+```bash
+# Check config.json first
+COMMIT_PLANNING_DOCS=$(cat .planning/config.json 2>/dev/null | grep -o '"commit_docs"[[:space:]]*:[[:space:]]*[^,}]*' | grep -o 'true\|false' || echo "true")
+
+# Auto-detect gitignored (overrides config)
+git check-ignore -q .planning 2>/dev/null && COMMIT_PLANNING_DOCS=false
+```
+
+Default: `true` if not set or config missing.
+
+## Conditional Commit
+
+Only run git operations if `COMMIT_PLANNING_DOCS=true`:
+
+```bash
+if [ "$COMMIT_PLANNING_DOCS" = "true" ]; then
+  git add .planning/STATE.md .planning/ROADMAP.md
+  git commit -m "$(cat <<'EOF'
+docs({scope}): {description}
+
+{optional body}
+
+Co-Authored-By: Claude <noreply@anthropic.com>
+EOF
+)"
+fi
+```
+
+## Commit Message Patterns
+
+| Command | Scope | Example |
+|---------|-------|---------|
+| plan-phase | phase | `docs(phase-03): create authentication plans` |
+| execute-phase | phase | `docs(phase-03): complete authentication phase` |
+| new-milestone | milestone | `docs: start milestone v1.1` |
+| remove-phase | chore | `chore: remove phase 17 (dashboard)` |
+| insert-phase | phase | `docs: insert phase 16.1 (critical fix)` |
+| add-phase | phase | `docs: add phase 07 (settings page)` |
+
+## When to Skip
+
+- `commit_docs: false` in config
+- `.planning/` is gitignored
+- No changes to commit (check with `git status --porcelain .planning/`)
diff --git a/get-shit-done/references/model-profile-resolution.md b/get-shit-done/references/model-profile-resolution.md
new file mode 100644
index 000000000..6b7481b41
--- /dev/null
+++ b/get-shit-done/references/model-profile-resolution.md
@@ -0,0 +1,32 @@
+# Model Profile Resolution
+
+Resolve model profile once at the start of orchestration, then use it for all Task spawns.
+
+## Resolution Pattern
+
+```bash
+MODEL_PROFILE=$(cat .planning/config.json 2>/dev/null | grep -o '"model_profile"[[:space:]]*:[[:space:]]*"[^"]*"' | grep -o '"[^"]*"$' | tr -d '"' || echo "balanced")
+```
+
+Default: `balanced` if not set or config missing.
+
+## Lookup Table
+
+@~/.claude/get-shit-done/references/model-profiles.md
+
+Look up the agent in the table for the resolved profile. Pass the model parameter to Task calls:
+
+```
+Task(
+  prompt="...",
+  subagent_type="gsd-planner",
+  model="{resolved_model}"  # e.g., "opus" for quality profile
+)
+```
+
+## Usage
+
+1. Resolve once at orchestration start
+2. Store the profile value
+3. Look up each agent's model from the table when spawning
+4. Pass model parameter to each Task call
diff --git a/get-shit-done/references/phase-argument-parsing.md b/get-shit-done/references/phase-argument-parsing.md
new file mode 100644
index 000000000..b992c52db
--- /dev/null
+++ b/get-shit-done/references/phase-argument-parsing.md
@@ -0,0 +1,58 @@
+# Phase Argument Parsing
+
+Parse and normalize phase arguments for commands that operate on phases.
+
+## Extraction
+
+From `$ARGUMENTS`:
+- Extract phase number (first numeric argument)
+- Extract flags (prefixed with `--`)
+- Remaining text is description (for insert/add commands)
+
+## Normalization
+
+Zero-pad integer phases to 2 digits. Preserve decimal suffixes.
+
+```bash
+# Normalize phase number
+if [[ "$PHASE" =~ ^[0-9]+$ ]]; then
+  # Integer: 8 → 08
+  PHASE=$(printf "%02d" "$PHASE")
+elif [[ "$PHASE" =~ ^([0-9]+)\.([0-9]+)$ ]]; then
+  # Decimal: 2.1 → 02.1
+  PHASE=$(printf "%02d.%s" "${BASH_REMATCH[1]}" "${BASH_REMATCH[2]}")
+fi
+```
+
+## Auto-Detection
+
+When no phase number provided, detect the next unplanned phase:
+
+```bash
+# Find phases without PLAN.md files
+for dir in .planning/phases/*/; do
+  if ! ls "$dir"/*-PLAN.md 2>/dev/null | head -1 >/dev/null; then
+    PHASE=$(basename "$dir" | grep -oE '^[0-9.]+')
+    break
+  fi
+done
+```
+
+## Validation
+
+After normalization, verify phase exists in ROADMAP.md:
+
+```bash
+grep -q "### Phase ${PHASE}:" .planning/ROADMAP.md || {
+  echo "ERROR: Phase ${PHASE} not found in roadmap"
+  exit 1
+}
+```
+
+## Directory Lookup
+
+Find the phase directory using the normalized phase number:
+
+```bash
+PHASE_DIR=$(ls -d .planning/phases/${PHASE}-* 2>/dev/null | head -1)
+```
diff --git a/get-shit-done/workflows/research-phase.md b/get-shit-done/workflows/research-phase.md
new file mode 100644
index 000000000..4ad6aa776
--- /dev/null
+++ b/get-shit-done/workflows/research-phase.md
@@ -0,0 +1,72 @@
+<purpose>
+Research how to implement a phase. Spawns gsd-phase-researcher with phase context.
+
+Standalone research command. For most workflows, use `/gsd:plan-phase` which integrates research automatically.
+</purpose>
+
+<process>
+
+## Step 0: Resolve Model Profile
+
+@~/.claude/get-shit-done/references/model-profile-resolution.md
+
+Resolve model for:
+- `gsd-phase-researcher`
+
+## Step 1: Normalize and Validate Phase
+
+@~/.claude/get-shit-done/references/phase-argument-parsing.md
+
+```bash
+grep -A5 "Phase ${PHASE}:" .planning/ROADMAP.md 2>/dev/null
+```
+
+If not found: Error and exit.
+
+## Step 2: Check Existing Research
+
+```bash
+ls .planning/phases/${PHASE}-*/RESEARCH.md 2>/dev/null
+```
+
+If exists: Offer update/view/skip options.
+
+## Step 3: Gather Phase Context
+
+```bash
+grep -A20 "Phase ${PHASE}:" .planning/ROADMAP.md
+cat .planning/REQUIREMENTS.md 2>/dev/null
+cat .planning/phases/${PHASE}-*/*-CONTEXT.md 2>/dev/null
+grep -A30 "### Decisions Made" .planning/STATE.md 2>/dev/null
+```
+
+## Step 4: Spawn Researcher
+
+```
+Task(
+  prompt="<objective>
+Research implementation approach for Phase {phase}: {name}
+</objective>
+
+<context>
+Phase description: {description}
+Requirements: {requirements}
+Prior decisions: {decisions}
+Phase context: {context_md}
+</context>
+
+<output>
+Write to: .planning/phases/${PHASE}-{slug}/${PHASE}-RESEARCH.md
+</output>",
+  subagent_type="gsd-phase-researcher",
+  model="{researcher_model}"
+)
+```
+
+## Step 5: Handle Return
+
+- `## RESEARCH COMPLETE` — Display summary, offer: Plan/Dig deeper/Review/Done
+- `## CHECKPOINT REACHED` — Present to user, spawn continuation
+- `## RESEARCH INCONCLUSIVE` — Show attempts, offer: Add context/Try different mode/Manual
+
+</process>