diff --git a/skills/ralph-tui-create-beads-rust/EXAMPLES.md b/skills/ralph-tui-create-beads-rust/EXAMPLES.md
new file mode 100644
index 00000000..bbc691a4
--- /dev/null
+++ b/skills/ralph-tui-create-beads-rust/EXAMPLES.md
@@ -0,0 +1,109 @@
+# Examples
+
+## Full PRD-to-Beads Conversion Example
+
+**Input PRD:**
+```markdown
+# PRD: Friends Outreach
+
+Add ability to mark investors as "friends" for warm outreach.
+
+## Quality Gates
+
+These commands must pass for every user story:
+- `pnpm typecheck` - Type checking
+- `pnpm lint` - Linting
+
+For UI stories, also include:
+- Verify in browser using dev-browser skill
+
+## User Stories
+
+### US-001: Add investorType field to investor table
+**Description:** As a developer, I need to categorize investors as 'cold' or 'friend'.
+
+**Acceptance Criteria:**
+- [ ] Add investorType column: 'cold' | 'friend' (default 'cold')
+- [ ] Generate and run migration successfully
+
+### US-002: Add type toggle to investor list rows
+**Description:** As Ryan, I want to toggle investor type directly from the list.
+
+**Acceptance Criteria:**
+- [ ] Each row has Cold | Friend toggle
+- [ ] Switching shows confirmation dialog
+- [ ] On confirm: updates type in database
+
+### US-003: Filter investors by type
+**Description:** As Ryan, I want to filter the list to see just friends or cold.
+
+**Acceptance Criteria:**
+- [ ] Filter dropdown: All | Cold | Friend
+- [ ] Filter persists in URL params
+```
+
+**Output beads:**
+```bash
+# Create epic (link back to source PRD)
+br create --type=epic \
+  --title="Friends Outreach Track" \
+  --description="$(cat <<'EOF'
+Warm outreach for deck feedback
+EOF
+)" \
+  --external-ref="prd:./tasks/friends-outreach-prd.md"
+
+# US-001: No deps (first - creates schema)
+br create --parent=ralph-tui-abc \
+  --title="US-001: Add investorType field to investor table" \
+  --description="$(cat <<'EOF'
+As a developer, I need to categorize investors as 'cold' or 'friend'.
+
+## Acceptance Criteria
+- [ ] Add investorType column: 'cold' | 'friend' (default 'cold')
+- [ ] Generate and run migration successfully
+- [ ] pnpm typecheck passes
+- [ ] pnpm lint passes
+EOF
+)" \
+  --priority=1
+
+# US-002: UI story (gets browser verification too)
+br create --parent=ralph-tui-abc \
+  --title="US-002: Add type toggle to investor list rows" \
+  --description="$(cat <<'EOF'
+As Ryan, I want to toggle investor type directly from the list.
+
+## Acceptance Criteria
+- [ ] Each row has Cold | Friend toggle
+- [ ] Switching shows confirmation dialog
+- [ ] On confirm: updates type in database
+- [ ] pnpm typecheck passes
+- [ ] pnpm lint passes
+- [ ] Verify in browser using dev-browser skill
+EOF
+)" \
+  --priority=2
+
+# Add dependency: US-002 depends on US-001
+br dep add ralph-tui-002 ralph-tui-001
+
+# US-003: UI story
+br create --parent=ralph-tui-abc \
+  --title="US-003: Filter investors by type" \
+  --description="$(cat <<'EOF'
+As Ryan, I want to filter the list to see just friends or cold.
+
+## Acceptance Criteria
+- [ ] Filter dropdown: All | Cold | Friend
+- [ ] Filter persists in URL params
+- [ ] pnpm typecheck passes
+- [ ] pnpm lint passes
+- [ ] Verify in browser using dev-browser skill
+EOF
+)" \
+  --priority=3
+
+# Add dependency: US-003 depends on US-002
+br dep add ralph-tui-003 ralph-tui-002
+```
diff --git a/skills/ralph-tui-create-beads-rust/REFERENCE.md b/skills/ralph-tui-create-beads-rust/REFERENCE.md
new file mode 100644
index 00000000..7119553d
--- /dev/null
+++ b/skills/ralph-tui-create-beads-rust/REFERENCE.md
@@ -0,0 +1,11 @@
+# Reference
+
+## Differences from beads (Go version)
+
+| Command | beads (`bd`) | beads-rust (`br`) |
+|---------|--------------|-------------------|
+| Create | `bd create` | `br create` |
+| Dependencies | `bd dep add` | `br dep add` |
+| Sync | `bd sync` | `br sync --flush-only` |
+| Close | `bd close` | `br close` |
+| Storage | `.beads/beads.jsonl` | `.beads/*.db` + JSONL export |
diff --git a/skills/ralph-tui-create-beads-rust/SKILL.md b/skills/ralph-tui-create-beads-rust/SKILL.md
index 7aa0c34e..a0ca933d 100644
--- a/skills/ralph-tui-create-beads-rust/SKILL.md
+++ b/skills/ralph-tui-create-beads-rust/SKILL.md
@@ -76,44 +76,13 @@ EOF
 
 ## Story Size: The #1 Rule
 
-**Each story must be completable in ONE ralph-tui iteration (~one agent context window).**
-
-ralph-tui spawns a fresh agent instance per iteration with no memory of previous work. If a story is too big, the agent runs out of context before finishing.
-
-### Right-sized stories:
-- Add a database column + migration
-- Add a UI component to an existing page
-- Update a server action with new logic
-- Add a filter dropdown to a list
-
-### Too big (split these):
-- "Build the entire dashboard" → Split into: schema, queries, UI components, filters
-- "Add authentication" → Split into: schema, middleware, login UI, session handling
-- "Refactor the API" → Split into one story per endpoint or pattern
-
-**Rule of thumb:** If you can't describe the change in 2-3 sentences, it's too big.
-
----
-
-## Story Ordering: Dependencies First
-
-Stories execute in dependency order. Earlier stories must not depend on later ones.
-
-**Correct order:**
-1. Schema/database changes (migrations)
-2. Server actions / backend logic
-3. UI components that use the backend
-4. Dashboard/summary views that aggregate data
-
-**Wrong order:**
-1. ❌ UI component (depends on schema that doesn't exist yet)
-2. ❌ Schema change
+Each story must be completable in ONE ralph-tui iteration. Right-sized: single column/component/endpoint. Too big: entire dashboard/auth system (split these).
 
 ---
 
 ## Dependencies with `br dep add`
 
-Use the `br dep add` command to specify which beads must complete first:
+Stories execute in dependency order (schema → backend → UI). Use `br dep add` to specify which beads must complete first:
 
 ```bash
 # Create the beads first
@@ -128,35 +97,13 @@ br dep add ralph-tui-003 ralph-tui-002  # US-003 depends on US-002
 
 **Syntax:** `br dep add <issue> <depends-on>` — the issue depends on (is blocked by) depends-on.
 
-ralph-tui will:
-- Show blocked beads as "blocked" until dependencies complete
-- Never select a bead for execution while its dependencies are open
-- Include dependency context in the prompt when working on a bead
-
-**Correct dependency order:**
-1. Schema/database changes (no dependencies)
-2. Backend logic (depends on schema)
-3. UI components (depends on backend)
-4. Integration/polish (depends on UI)
+ralph-tui will show blocked beads as "blocked" until dependencies complete and include dependency context in the prompt when working on a bead.
 
 ---
 
 ## Acceptance Criteria: Quality Gates + Story-Specific
 
-Each bead's description should include acceptance criteria with:
-1. **Story-specific criteria** from the PRD (what this story accomplishes)
-2. **Quality gates** from the PRD's Quality Gates section (appended at the end)
-
-### Good criteria (verifiable):
-- "Add `investorType` column to investor table with default 'cold'"
-- "Filter dropdown has options: All, Cold, Friend"
-- "Clicking toggle shows confirmation dialog"
-
-### Bad criteria (vague):
-- ❌ "Works correctly"
-- ❌ "User can do X easily"
-- ❌ "Good UX"
-- ❌ "Handles edge cases"
+Each bead's description should include story-specific acceptance criteria from the PRD, plus quality gates appended from the Quality Gates section.
 
 ---
 
@@ -164,12 +111,11 @@ Each bead's description should include acceptance criteria with:
 
 1. **Extract Quality Gates** from PRD first
 2. **Each user story → one bead**
-3. **First story**: No dependencies (creates foundation)
-4. **Subsequent stories**: Depend on their predecessors (UI depends on backend, etc.)
-5. **Priority**: Based on dependency order, then document order (0=critical, 2=medium, 4=backlog)
-6. **All stories**: `status: "open"`
-7. **Acceptance criteria**: Story criteria + quality gates appended
-8. **UI stories**: Also append UI-specific gates (browser verification)
+3. **Dependencies**: Schema/database → backend → UI → integration (use `br dep add` after creating beads)
+4. **Priority**: Based on dependency order, then document order (0=critical, 2=medium, 4=backlog)
+5. **All stories**: `status: "open"`
+6. **Acceptance criteria**: Story criteria + quality gates appended
+7. **UI stories**: Also append UI-specific gates (browser verification)
 
 ---
 
@@ -196,111 +142,7 @@ Each is one focused change that can be completed and verified independently.
 
 ## Example
 
-**Input PRD:**
-```markdown
-# PRD: Friends Outreach
-
-Add ability to mark investors as "friends" for warm outreach.
-
-## Quality Gates
-
-These commands must pass for every user story:
-- `pnpm typecheck` - Type checking
-- `pnpm lint` - Linting
-
-For UI stories, also include:
-- Verify in browser using dev-browser skill
-
-## User Stories
-
-### US-001: Add investorType field to investor table
-**Description:** As a developer, I need to categorize investors as 'cold' or 'friend'.
-
-**Acceptance Criteria:**
-- [ ] Add investorType column: 'cold' | 'friend' (default 'cold')
-- [ ] Generate and run migration successfully
-
-### US-002: Add type toggle to investor list rows
-**Description:** As Ryan, I want to toggle investor type directly from the list.
-
-**Acceptance Criteria:**
-- [ ] Each row has Cold | Friend toggle
-- [ ] Switching shows confirmation dialog
-- [ ] On confirm: updates type in database
-
-### US-003: Filter investors by type
-**Description:** As Ryan, I want to filter the list to see just friends or cold.
-
-**Acceptance Criteria:**
-- [ ] Filter dropdown: All | Cold | Friend
-- [ ] Filter persists in URL params
-```
-
-**Output beads:**
-```bash
-# Create epic (link back to source PRD)
-br create --type=epic \
-  --title="Friends Outreach Track" \
-  --description="$(cat <<'EOF'
-Warm outreach for deck feedback
-EOF
-)" \
-  --external-ref="prd:./tasks/friends-outreach-prd.md"
-
-# US-001: No deps (first - creates schema)
-br create --parent=ralph-tui-abc \
-  --title="US-001: Add investorType field to investor table" \
-  --description="$(cat <<'EOF'
-As a developer, I need to categorize investors as 'cold' or 'friend'.
-
-## Acceptance Criteria
-- [ ] Add investorType column: 'cold' | 'friend' (default 'cold')
-- [ ] Generate and run migration successfully
-- [ ] pnpm typecheck passes
-- [ ] pnpm lint passes
-EOF
-)" \
-  --priority=1
-
-# US-002: UI story (gets browser verification too)
-br create --parent=ralph-tui-abc \
-  --title="US-002: Add type toggle to investor list rows" \
-  --description="$(cat <<'EOF'
-As Ryan, I want to toggle investor type directly from the list.
-
-## Acceptance Criteria
-- [ ] Each row has Cold | Friend toggle
-- [ ] Switching shows confirmation dialog
-- [ ] On confirm: updates type in database
-- [ ] pnpm typecheck passes
-- [ ] pnpm lint passes
-- [ ] Verify in browser using dev-browser skill
-EOF
-)" \
-  --priority=2
-
-# Add dependency: US-002 depends on US-001
-br dep add ralph-tui-002 ralph-tui-001
-
-# US-003: UI story
-br create --parent=ralph-tui-abc \
-  --title="US-003: Filter investors by type" \
-  --description="$(cat <<'EOF'
-As Ryan, I want to filter the list to see just friends or cold.
-
-## Acceptance Criteria
-- [ ] Filter dropdown: All | Cold | Friend
-- [ ] Filter persists in URL params
-- [ ] pnpm typecheck passes
-- [ ] pnpm lint passes
-- [ ] Verify in browser using dev-browser skill
-EOF
-)" \
-  --priority=3
-
-# Add dependency: US-003 depends on US-002
-br dep add ralph-tui-003 ralph-tui-002
-```
+See [EXAMPLES.md](EXAMPLES.md) for a complete PRD-to-beads conversion.
 
 ---
 
@@ -329,34 +171,15 @@ ralph-tui run --tracker beads-rust --epic ralph-tui-abc
 ralph-tui run --tracker beads-rust
 ```
 
-ralph-tui will:
-1. Work on beads within the specified epic (or select the best available task)
-2. Close each bead when complete
-3. Close the epic when all children are done
-4. Output `<promise>COMPLETE</promise>` when epic is done
+ralph-tui will work on beads, close each when complete, and output `<promise>COMPLETE</promise>` when the epic is done.
+
+See [REFERENCE.md](REFERENCE.md) for differences from the Go version of beads.
 
 ---
 
 ## Checklist Before Creating Beads
 
-- [ ] Extracted Quality Gates from PRD (or asked user if missing)
-- [ ] Each story is completable in one iteration (small enough)
-- [ ] Stories are ordered by dependency (schema → backend → UI)
-- [ ] Quality gates appended to every bead's acceptance criteria
-- [ ] UI stories have browser verification (if specified in Quality Gates)
-- [ ] Acceptance criteria are verifiable (not vague)
-- [ ] No story depends on a later story (only earlier stories)
+- [ ] Extracted Quality Gates from PRD
+- [ ] Stories ordered by dependency (schema → backend → UI)
 - [ ] Dependencies added with `br dep add` after creating beads
 - [ ] Ran `br sync --flush-only` to export for git tracking
-
----
-
-## Differences from beads (Go version)
-
-| Command | beads (`bd`) | beads-rust (`br`) |
-|---------|--------------|-------------------|
-| Create | `bd create` | `br create` |
-| Dependencies | `bd dep add` | `br dep add` |
-| Sync | `bd sync` | `br sync --flush-only` |
-| Close | `bd close` | `br close` |
-| Storage | `.beads/beads.jsonl` | `.beads/*.db` + JSONL export |
diff --git a/skills/ralph-tui-create-beads/EXAMPLES.md b/skills/ralph-tui-create-beads/EXAMPLES.md
new file mode 100644
index 00000000..1ac8092d
--- /dev/null
+++ b/skills/ralph-tui-create-beads/EXAMPLES.md
@@ -0,0 +1,109 @@
+# Examples
+
+## Full PRD-to-Beads Conversion Example
+
+**Input PRD:**
+```markdown
+# PRD: Friends Outreach
+
+Add ability to mark investors as "friends" for warm outreach.
+
+## Quality Gates
+
+These commands must pass for every user story:
+- `pnpm typecheck` - Type checking
+- `pnpm lint` - Linting
+
+For UI stories, also include:
+- Verify in browser using dev-browser skill
+
+## User Stories
+
+### US-001: Add investorType field to investor table
+**Description:** As a developer, I need to categorize investors as 'cold' or 'friend'.
+
+**Acceptance Criteria:**
+- [ ] Add investorType column: 'cold' | 'friend' (default 'cold')
+- [ ] Generate and run migration successfully
+
+### US-002: Add type toggle to investor list rows
+**Description:** As Ryan, I want to toggle investor type directly from the list.
+
+**Acceptance Criteria:**
+- [ ] Each row has Cold | Friend toggle
+- [ ] Switching shows confirmation dialog
+- [ ] On confirm: updates type in database
+
+### US-003: Filter investors by type
+**Description:** As Ryan, I want to filter the list to see just friends or cold.
+
+**Acceptance Criteria:**
+- [ ] Filter dropdown: All | Cold | Friend
+- [ ] Filter persists in URL params
+```
+
+**Output beads:**
+```bash
+# Create epic (link back to source PRD)
+bd create --type=epic \
+  --title="Friends Outreach Track" \
+  --description="$(cat <<'EOF'
+Warm outreach for deck feedback
+EOF
+)" \
+  --external-ref="prd:./tasks/friends-outreach-prd.md"
+
+# US-001: No deps (first - creates schema)
+bd create --parent=ralph-tui-abc \
+  --title="US-001: Add investorType field to investor table" \
+  --description="$(cat <<'EOF'
+As a developer, I need to categorize investors as 'cold' or 'friend'.
+
+## Acceptance Criteria
+- [ ] Add investorType column: 'cold' | 'friend' (default 'cold')
+- [ ] Generate and run migration successfully
+- [ ] pnpm typecheck passes
+- [ ] pnpm lint passes
+EOF
+)" \
+  --priority=1
+
+# US-002: UI story (gets browser verification too)
+bd create --parent=ralph-tui-abc \
+  --title="US-002: Add type toggle to investor list rows" \
+  --description="$(cat <<'EOF'
+As Ryan, I want to toggle investor type directly from the list.
+
+## Acceptance Criteria
+- [ ] Each row has Cold | Friend toggle
+- [ ] Switching shows confirmation dialog
+- [ ] On confirm: updates type in database
+- [ ] pnpm typecheck passes
+- [ ] pnpm lint passes
+- [ ] Verify in browser using dev-browser skill
+EOF
+)" \
+  --priority=2
+
+# Add dependency: US-002 depends on US-001
+bd dep add ralph-tui-002 ralph-tui-001
+
+# US-003: UI story
+bd create --parent=ralph-tui-abc \
+  --title="US-003: Filter investors by type" \
+  --description="$(cat <<'EOF'
+As Ryan, I want to filter the list to see just friends or cold.
+
+## Acceptance Criteria
+- [ ] Filter dropdown: All | Cold | Friend
+- [ ] Filter persists in URL params
+- [ ] pnpm typecheck passes
+- [ ] pnpm lint passes
+- [ ] Verify in browser using dev-browser skill
+EOF
+)" \
+  --priority=3
+
+# Add dependency: US-003 depends on US-002
+bd dep add ralph-tui-003 ralph-tui-002
+```
diff --git a/skills/ralph-tui-create-beads/SKILL.md b/skills/ralph-tui-create-beads/SKILL.md
index 63e93287..cc86a4e9 100644
--- a/skills/ralph-tui-create-beads/SKILL.md
+++ b/skills/ralph-tui-create-beads/SKILL.md
@@ -76,44 +76,13 @@ EOF
 
 ## Story Size: The #1 Rule
 
-**Each story must be completable in ONE ralph-tui iteration (~one agent context window).**
-
-ralph-tui spawns a fresh agent instance per iteration with no memory of previous work. If a story is too big, the agent runs out of context before finishing.
-
-### Right-sized stories:
-- Add a database column + migration
-- Add a UI component to an existing page
-- Update a server action with new logic
-- Add a filter dropdown to a list
-
-### Too big (split these):
-- "Build the entire dashboard" → Split into: schema, queries, UI components, filters
-- "Add authentication" → Split into: schema, middleware, login UI, session handling
-- "Refactor the API" → Split into one story per endpoint or pattern
-
-**Rule of thumb:** If you can't describe the change in 2-3 sentences, it's too big.
-
----
-
-## Story Ordering: Dependencies First
-
-Stories execute in dependency order. Earlier stories must not depend on later ones.
-
-**Correct order:**
-1. Schema/database changes (migrations)
-2. Server actions / backend logic
-3. UI components that use the backend
-4. Dashboard/summary views that aggregate data
-
-**Wrong order:**
-1. ❌ UI component (depends on schema that doesn't exist yet)
-2. ❌ Schema change
+Each story must be completable in ONE ralph-tui iteration. Right-sized: single column/component/endpoint. Too big: entire dashboard/auth system (split these).
 
 ---
 
 ## Dependencies with `bd dep add`
 
-Use the `bd dep add` command to specify which beads must complete first:
+Stories execute in dependency order (schema → backend → UI). Use `bd dep add` to specify which beads must complete first:
 
 ```bash
 # Create the beads first
@@ -128,35 +97,13 @@ bd dep add ralph-tui-003 ralph-tui-002  # US-003 depends on US-002
 
 **Syntax:** `bd dep add <issue> <depends-on>` — the issue depends on (is blocked by) depends-on.
 
-ralph-tui will:
-- Show blocked beads as "blocked" until dependencies complete
-- Never select a bead for execution while its dependencies are open
-- Include dependency context in the prompt when working on a bead
-
-**Correct dependency order:**
-1. Schema/database changes (no dependencies)
-2. Backend logic (depends on schema)
-3. UI components (depends on backend)
-4. Integration/polish (depends on UI)
+ralph-tui will show blocked beads as "blocked" until dependencies complete and include dependency context in the prompt when working on a bead.
 
 ---
 
 ## Acceptance Criteria: Quality Gates + Story-Specific
 
-Each bead's description should include acceptance criteria with:
-1. **Story-specific criteria** from the PRD (what this story accomplishes)
-2. **Quality gates** from the PRD's Quality Gates section (appended at the end)
-
-### Good criteria (verifiable):
-- "Add `investorType` column to investor table with default 'cold'"
-- "Filter dropdown has options: All, Cold, Friend"
-- "Clicking toggle shows confirmation dialog"
-
-### Bad criteria (vague):
-- ❌ "Works correctly"
-- ❌ "User can do X easily"
-- ❌ "Good UX"
-- ❌ "Handles edge cases"
+Each bead's description should include story-specific acceptance criteria from the PRD, plus quality gates appended from the Quality Gates section.
 
 ---
 
@@ -164,12 +111,11 @@ Each bead's description should include acceptance criteria with:
 
 1. **Extract Quality Gates** from PRD first
 2. **Each user story → one bead**
-3. **First story**: No dependencies (creates foundation)
-4. **Subsequent stories**: Depend on their predecessors (UI depends on backend, etc.)
-5. **Priority**: Based on dependency order, then document order (0=critical, 2=medium, 4=backlog)
-6. **All stories**: `status: "open"`
-7. **Acceptance criteria**: Story criteria + quality gates appended
-8. **UI stories**: Also append UI-specific gates (browser verification)
+3. **Dependencies**: Schema/database → backend → UI → integration (use `bd dep add` after creating beads)
+4. **Priority**: Based on dependency order, then document order (0=critical, 2=medium, 4=backlog)
+5. **All stories**: `status: "open"`
+6. **Acceptance criteria**: Story criteria + quality gates appended
+7. **UI stories**: Also append UI-specific gates (browser verification)
 
 ---
 
@@ -196,111 +142,7 @@ Each is one focused change that can be completed and verified independently.
 
 ## Example
 
-**Input PRD:**
-```markdown
-# PRD: Friends Outreach
-
-Add ability to mark investors as "friends" for warm outreach.
-
-## Quality Gates
-
-These commands must pass for every user story:
-- `pnpm typecheck` - Type checking
-- `pnpm lint` - Linting
-
-For UI stories, also include:
-- Verify in browser using dev-browser skill
-
-## User Stories
-
-### US-001: Add investorType field to investor table
-**Description:** As a developer, I need to categorize investors as 'cold' or 'friend'.
-
-**Acceptance Criteria:**
-- [ ] Add investorType column: 'cold' | 'friend' (default 'cold')
-- [ ] Generate and run migration successfully
-
-### US-002: Add type toggle to investor list rows
-**Description:** As Ryan, I want to toggle investor type directly from the list.
-
-**Acceptance Criteria:**
-- [ ] Each row has Cold | Friend toggle
-- [ ] Switching shows confirmation dialog
-- [ ] On confirm: updates type in database
-
-### US-003: Filter investors by type
-**Description:** As Ryan, I want to filter the list to see just friends or cold.
-
-**Acceptance Criteria:**
-- [ ] Filter dropdown: All | Cold | Friend
-- [ ] Filter persists in URL params
-```
-
-**Output beads:**
-```bash
-# Create epic (link back to source PRD)
-bd create --type=epic \
-  --title="Friends Outreach Track" \
-  --description="$(cat <<'EOF'
-Warm outreach for deck feedback
-EOF
-)" \
-  --external-ref="prd:./tasks/friends-outreach-prd.md"
-
-# US-001: No deps (first - creates schema)
-bd create --parent=ralph-tui-abc \
-  --title="US-001: Add investorType field to investor table" \
-  --description="$(cat <<'EOF'
-As a developer, I need to categorize investors as 'cold' or 'friend'.
-
-## Acceptance Criteria
-- [ ] Add investorType column: 'cold' | 'friend' (default 'cold')
-- [ ] Generate and run migration successfully
-- [ ] pnpm typecheck passes
-- [ ] pnpm lint passes
-EOF
-)" \
-  --priority=1
-
-# US-002: UI story (gets browser verification too)
-bd create --parent=ralph-tui-abc \
-  --title="US-002: Add type toggle to investor list rows" \
-  --description="$(cat <<'EOF'
-As Ryan, I want to toggle investor type directly from the list.
-
-## Acceptance Criteria
-- [ ] Each row has Cold | Friend toggle
-- [ ] Switching shows confirmation dialog
-- [ ] On confirm: updates type in database
-- [ ] pnpm typecheck passes
-- [ ] pnpm lint passes
-- [ ] Verify in browser using dev-browser skill
-EOF
-)" \
-  --priority=2
-
-# Add dependency: US-002 depends on US-001
-bd dep add ralph-tui-002 ralph-tui-001
-
-# US-003: UI story
-bd create --parent=ralph-tui-abc \
-  --title="US-003: Filter investors by type" \
-  --description="$(cat <<'EOF'
-As Ryan, I want to filter the list to see just friends or cold.
-
-## Acceptance Criteria
-- [ ] Filter dropdown: All | Cold | Friend
-- [ ] Filter persists in URL params
-- [ ] pnpm typecheck passes
-- [ ] pnpm lint passes
-- [ ] Verify in browser using dev-browser skill
-EOF
-)" \
-  --priority=3
-
-# Add dependency: US-003 depends on US-002
-bd dep add ralph-tui-003 ralph-tui-002
-```
+See [EXAMPLES.md](EXAMPLES.md) for a complete PRD-to-beads conversion.
 
 ---
 
@@ -327,11 +169,6 @@ ralph-tui will:
 
 ## Checklist Before Creating Beads
 
-- [ ] Extracted Quality Gates from PRD (or asked user if missing)
-- [ ] Each story is completable in one iteration (small enough)
-- [ ] Stories are ordered by dependency (schema → backend → UI)
-- [ ] Quality gates appended to every bead's acceptance criteria
-- [ ] UI stories have browser verification (if specified in Quality Gates)
-- [ ] Acceptance criteria are verifiable (not vague)
-- [ ] No story depends on a later story (only earlier stories)
+- [ ] Extracted Quality Gates from PRD
+- [ ] Stories ordered by dependency (schema → backend → UI)
 - [ ] Dependencies added with `bd dep add` after creating beads
diff --git a/skills/ralph-tui-create-json/ANTI_PATTERNS.md b/skills/ralph-tui-create-json/ANTI_PATTERNS.md
new file mode 100644
index 00000000..7fb60595
--- /dev/null
+++ b/skills/ralph-tui-create-json/ANTI_PATTERNS.md
@@ -0,0 +1,67 @@
+# Schema Anti-Patterns
+
+The following patterns are INVALID and will cause validation errors:
+
+## ❌ WRONG: Wrapper object
+
+```json
+{
+  "prd": {
+    "name": "...",
+    "userStories": [...]
+  }
+}
+```
+
+This wraps everything in a "prd" object. **DO NOT DO THIS.** The "name" and "userStories" fields must be at the ROOT level.
+
+## ❌ WRONG: Using "tasks" instead of "userStories"
+
+```json
+{
+  "name": "...",
+  "tasks": [...]
+}
+```
+
+The array is called **"userStories"**, not "tasks".
+
+## ❌ WRONG: Complex nested structures
+
+```json
+{
+  "metadata": {...},
+  "overview": {...},
+  "migration_strategy": {
+    "phases": [...]
+  }
+}
+```
+
+Even if the PRD describes phases/milestones/sprints, you MUST flatten these into a single "userStories" array.
+
+## ❌ WRONG: Using "status" instead of "passes"
+
+```json
+{
+  "userStories": [{
+    "id": "US-001",
+    "status": "open"  // WRONG!
+  }]
+}
+```
+
+Use `"passes": false` for incomplete stories, `"passes": true` for completed.
+
+## ✅ CORRECT: Flat structure at root
+
+```json
+{
+  "name": "Android Kotlin Migration",
+  "branchName": "ralph/kotlin-migration",
+  "userStories": [
+    {"id": "US-001", "title": "Create Scraper interface", "passes": false, "dependsOn": []},
+    {"id": "US-002", "title": "Implement WeebCentralScraper", "passes": false, "dependsOn": ["US-001"]}
+  ]
+}
+```
diff --git a/skills/ralph-tui-create-json/EXAMPLES.md b/skills/ralph-tui-create-json/EXAMPLES.md
new file mode 100644
index 00000000..b94878e5
--- /dev/null
+++ b/skills/ralph-tui-create-json/EXAMPLES.md
@@ -0,0 +1,100 @@
+# Examples
+
+## Full PRD-to-JSON Conversion Example
+
+**Input PRD:**
+```markdown
+# PRD: Task Priority System
+
+Add priority levels to tasks.
+
+## Quality Gates
+
+These commands must pass for every user story:
+- `pnpm typecheck` - Type checking
+- `pnpm lint` - Linting
+
+For UI stories, also include:
+- Verify in browser using dev-browser skill
+
+## User Stories
+
+### US-001: Add priority field to database
+**Description:** As a developer, I need to store task priority.
+
+**Acceptance Criteria:**
+- [ ] Add priority column: 1-4 (default 2)
+- [ ] Migration runs successfully
+
+### US-002: Display priority badge on task cards
+**Description:** As a user, I want to see task priority at a glance.
+
+**Acceptance Criteria:**
+- [ ] Badge shows P1/P2/P3/P4 with colors
+- [ ] Badge visible without hovering
+
+### US-003: Add priority filter dropdown
+**Description:** As a user, I want to filter tasks by priority.
+
+**Acceptance Criteria:**
+- [ ] Filter dropdown: All, P1, P2, P3, P4
+- [ ] Filter persists in URL
+```
+
+**Output prd.json:**
+```json
+{
+  "name": "Task Priority System",
+  "branchName": "ralph/task-priority",
+  "description": "Add priority levels to tasks",
+  "userStories": [
+    {
+      "id": "US-001",
+      "title": "Add priority field to database",
+      "description": "As a developer, I need to store task priority.",
+      "acceptanceCriteria": [
+        "Add priority column: 1-4 (default 2)",
+        "Migration runs successfully",
+        "pnpm typecheck passes",
+        "pnpm lint passes"
+      ],
+      "priority": 1,
+      "passes": false,
+      "notes": "",
+      "dependsOn": []
+    },
+    {
+      "id": "US-002",
+      "title": "Display priority badge on task cards",
+      "description": "As a user, I want to see task priority at a glance.",
+      "acceptanceCriteria": [
+        "Badge shows P1/P2/P3/P4 with colors",
+        "Badge visible without hovering",
+        "pnpm typecheck passes",
+        "pnpm lint passes",
+        "Verify in browser using dev-browser skill"
+      ],
+      "priority": 2,
+      "passes": false,
+      "notes": "",
+      "dependsOn": ["US-001"]
+    },
+    {
+      "id": "US-003",
+      "title": "Add priority filter dropdown",
+      "description": "As a user, I want to filter tasks by priority.",
+      "acceptanceCriteria": [
+        "Filter dropdown: All, P1, P2, P3, P4",
+        "Filter persists in URL",
+        "pnpm typecheck passes",
+        "pnpm lint passes",
+        "Verify in browser using dev-browser skill"
+      ],
+      "priority": 3,
+      "passes": false,
+      "notes": "",
+      "dependsOn": ["US-002"]
+    }
+  ]
+}
+```
diff --git a/skills/ralph-tui-create-json/SKILL.md b/skills/ralph-tui-create-json/SKILL.md
index ad783841..07b9bdfd 100644
--- a/skills/ralph-tui-create-json/SKILL.md
+++ b/skills/ralph-tui-create-json/SKILL.md
@@ -9,7 +9,7 @@ Converts PRDs to prd.json format for ralph-tui autonomous execution.
 
 > **Note:** This skill is bundled with ralph-tui's JSON tracker plugin. Future tracker plugins (Linear, GitHub Issues, etc.) will bundle their own task creation skills.
 
-> **⚠️ CRITICAL:** The output MUST be a FLAT JSON object with "name" and "userStories" at the ROOT level. DO NOT wrap content in a "prd" object or use "tasks" array. See "Schema Anti-Patterns" section below.
+> **⚠️ CRITICAL:** The output MUST be a FLAT JSON object with "name" and "userStories" at the ROOT level. DO NOT wrap content in a "prd" object or use "tasks" array. See [ANTI_PATTERNS.md](ANTI_PATTERNS.md) for common mistakes.
 
 ---
 
@@ -49,7 +49,7 @@ Extract:
 
 ## Output Format
 
-The JSON file MUST be a FLAT object at the root level:
+The JSON file MUST be a FLAT object at the root level with "name" and "userStories":
 
 ```json
 {
@@ -93,139 +93,32 @@ The JSON file MUST be a FLAT object at the root level:
 
 ---
 
-## CRITICAL: Schema Anti-Patterns (DO NOT USE)
-
-The following patterns are INVALID and will cause validation errors:
-
-### ❌ WRONG: Wrapper object
-
-```json
-{
-  "prd": {
-    "name": "...",
-    "userStories": [...]
-  }
-}
-```
-
-This wraps everything in a "prd" object. **DO NOT DO THIS.** The "name" and "userStories" fields must be at the ROOT level.
-
-### ❌ WRONG: Using "tasks" instead of "userStories"
-
-```json
-{
-  "name": "...",
-  "tasks": [...]
-}
-```
-
-The array is called **"userStories"**, not "tasks".
-
-### ❌ WRONG: Complex nested structures
-
-```json
-{
-  "metadata": {...},
-  "overview": {...},
-  "migration_strategy": {
-    "phases": [...]
-  }
-}
-```
-
-Even if the PRD describes phases/milestones/sprints, you MUST flatten these into a single "userStories" array.
-
-### ❌ WRONG: Using "status" instead of "passes"
-
-```json
-{
-  "userStories": [{
-    "id": "US-001",
-    "status": "open"  // WRONG!
-  }]
-}
-```
-
-Use `"passes": false` for incomplete stories, `"passes": true` for completed.
-
-### ✅ CORRECT: Flat structure at root
-
-```json
-{
-  "name": "Android Kotlin Migration",
-  "branchName": "ralph/kotlin-migration",
-  "userStories": [
-    {"id": "US-001", "title": "Create Scraper interface", "passes": false, "dependsOn": []},
-    {"id": "US-002", "title": "Implement WeebCentralScraper", "passes": false, "dependsOn": ["US-001"]}
-  ]
-}
-```
-
----
-
 ## Story Size: The #1 Rule
 
-**Each story must be completable in ONE ralph-tui iteration (~one agent context window).**
-
-Ralph-tui spawns a fresh agent instance per iteration with no memory of previous work. If a story is too big, the agent runs out of context before finishing.
-
-### Right-sized stories:
-- Add a database column + migration
-- Add a UI component to an existing page
-- Update a server action with new logic
-- Add a filter dropdown to a list
-
-### Too big (split these):
-- "Build the entire dashboard" → Split into: schema, queries, UI components, filters
-- "Add authentication" → Split into: schema, middleware, login UI, session handling
-- "Refactor the API" → Split into one story per endpoint or pattern
-
-**Rule of thumb:** If you can't describe the change in 2-3 sentences, it's too big.
+Each story must be completable in ONE ralph-tui iteration. Right-sized: single column/component/endpoint. Too big: entire dashboard/auth system (split these).
 
 ---
 
 ## Dependencies with `dependsOn`
 
-Use the `dependsOn` array to specify which stories must complete first:
+Use the `dependsOn` array to specify which stories must complete first. Ralph-tui will show stories as "blocked" until dependencies complete.
 
 ```json
 {
   "id": "US-002",
   "title": "Create API endpoints",
-  "dependsOn": ["US-001"],  // Won't be selected until US-001 passes
+  "dependsOn": ["US-001"],
   ...
 }
 ```
 
-Ralph-tui will:
-- Show US-002 as "blocked" until US-001 completes
-- Never select US-002 for execution while US-001 is open
-- Include "Prerequisites: US-001" in the prompt when working on US-002
-
-**Correct dependency order:**
-1. Schema/database changes (no dependencies)
-2. Backend logic (depends on schema)
-3. UI components (depends on backend)
-4. Integration/polish (depends on UI)
+**Correct dependency order:** Schema/database → backend → UI → integration.
 
 ---
 
 ## Acceptance Criteria: Quality Gates + Story-Specific
 
-Each story's acceptance criteria should include:
-1. **Story-specific criteria** from the PRD (what this story accomplishes)
-2. **Quality gates** from the PRD's Quality Gates section (appended at the end)
-
-### Good criteria (verifiable):
-- "Add `status` column to tasks table with default 'open'"
-- "Filter dropdown has options: All, Open, Closed"
-- "Clicking delete shows confirmation dialog"
-
-### Bad criteria (vague):
-- ❌ "Works correctly"
-- ❌ "User can do X easily"
-- ❌ "Good UX"
-- ❌ "Handles edge cases"
+Each story's acceptance criteria should include story-specific criteria from the PRD, plus quality gates appended from the Quality Gates section.
 
 ---
 
@@ -258,102 +151,7 @@ ralph-tui run --prd ./path/to/prd.json
 
 ## Example
 
-**Input PRD:**
-```markdown
-# PRD: Task Priority System
-
-Add priority levels to tasks.
-
-## Quality Gates
-
-These commands must pass for every user story:
-- `pnpm typecheck` - Type checking
-- `pnpm lint` - Linting
-
-For UI stories, also include:
-- Verify in browser using dev-browser skill
-
-## User Stories
-
-### US-001: Add priority field to database
-**Description:** As a developer, I need to store task priority.
-
-**Acceptance Criteria:**
-- [ ] Add priority column: 1-4 (default 2)
-- [ ] Migration runs successfully
-
-### US-002: Display priority badge on task cards
-**Description:** As a user, I want to see task priority at a glance.
-
-**Acceptance Criteria:**
-- [ ] Badge shows P1/P2/P3/P4 with colors
-- [ ] Badge visible without hovering
-
-### US-003: Add priority filter dropdown
-**Description:** As a user, I want to filter tasks by priority.
-
-**Acceptance Criteria:**
-- [ ] Filter dropdown: All, P1, P2, P3, P4
-- [ ] Filter persists in URL
-```
-
-**Output prd.json:**
-```json
-{
-  "name": "Task Priority System",
-  "branchName": "ralph/task-priority",
-  "description": "Add priority levels to tasks",
-  "userStories": [
-    {
-      "id": "US-001",
-      "title": "Add priority field to database",
-      "description": "As a developer, I need to store task priority.",
-      "acceptanceCriteria": [
-        "Add priority column: 1-4 (default 2)",
-        "Migration runs successfully",
-        "pnpm typecheck passes",
-        "pnpm lint passes"
-      ],
-      "priority": 1,
-      "passes": false,
-      "notes": "",
-      "dependsOn": []
-    },
-    {
-      "id": "US-002",
-      "title": "Display priority badge on task cards",
-      "description": "As a user, I want to see task priority at a glance.",
-      "acceptanceCriteria": [
-        "Badge shows P1/P2/P3/P4 with colors",
-        "Badge visible without hovering",
-        "pnpm typecheck passes",
-        "pnpm lint passes",
-        "Verify in browser using dev-browser skill"
-      ],
-      "priority": 2,
-      "passes": false,
-      "notes": "",
-      "dependsOn": ["US-001"]
-    },
-    {
-      "id": "US-003",
-      "title": "Add priority filter dropdown",
-      "description": "As a user, I want to filter tasks by priority.",
-      "acceptanceCriteria": [
-        "Filter dropdown: All, P1, P2, P3, P4",
-        "Filter persists in URL",
-        "pnpm typecheck passes",
-        "pnpm lint passes",
-        "Verify in browser using dev-browser skill"
-      ],
-      "priority": 3,
-      "passes": false,
-      "notes": "",
-      "dependsOn": ["US-002"]
-    }
-  ]
-}
-```
+See [EXAMPLES.md](EXAMPLES.md) for a complete PRD-to-JSON conversion example.
 
 ---
 
@@ -364,23 +162,10 @@ After creating prd.json:
 ralph-tui run --prd ./tasks/prd.json
 ```
 
-Ralph-tui will:
-1. Load stories from prd.json
-2. Select the highest-priority story with `passes: false` and no blocking dependencies
-3. Generate a prompt with story details + acceptance criteria
-4. Run the agent to implement the story
-5. Mark `passes: true` on completion
-6. Repeat until all stories pass
-
 ---
 
 ## Checklist Before Saving
 
-- [ ] Extracted Quality Gates from PRD (or asked user if missing)
-- [ ] Each story completable in one iteration
+- [ ] Extracted Quality Gates from PRD
 - [ ] Stories ordered by dependency (schema → backend → UI)
 - [ ] `dependsOn` correctly set for each story
-- [ ] Quality gates appended to every story's acceptance criteria
-- [ ] UI stories have browser verification (if specified in Quality Gates)
-- [ ] Acceptance criteria are verifiable (not vague)
-- [ ] No circular dependencies
diff --git a/skills/ralph-tui-prd/EXAMPLES.md b/skills/ralph-tui-prd/EXAMPLES.md
new file mode 100644
index 00000000..5eb4a03d
--- /dev/null
+++ b/skills/ralph-tui-prd/EXAMPLES.md
@@ -0,0 +1,123 @@
+# Examples
+
+## Full Conversation Flow Example
+
+**User:** Create a PRD for adding dark mode to the TUI
+
+**Assistant:** I'll help you create a PRD for dark mode. Let me ask a few questions:
+
+1. What is the primary goal?
+   A. Reduce eye strain for long sessions
+   B. Match system theme preference
+   C. Provide visual customization
+   D. Other
+
+2. Should the setting persist?
+   A. Yes, save to config file
+   B. No, session only
+   C. Follow system preference
+
+**User:** 1A, 2A
+
+**Assistant:** Great! A couple more questions:
+
+3. Which components need dark mode support?
+   A. All TUI components
+   B. Only the main execution view
+   C. Main view + settings
+   D. Other
+
+4. What quality commands must pass for each story?
+   A. pnpm typecheck && pnpm lint
+   B. npm run typecheck && npm run lint
+   C. bun run typecheck
+   D. Other: [specify]
+
+5. For UI stories, include browser verification?
+   A. Yes, use dev-browser skill
+   B. No, automated tests sufficient
+
+**User:** 3A, 4A, 5A
+
+**Assistant:** Perfect, I have enough to generate the PRD.
+
+[PRD]
+# PRD: Dark Mode for Ralph TUI
+
+## Overview
+Add dark mode support to ralph-tui to reduce eye strain during long orchestration sessions. The feature will apply to all TUI components and persist the user's preference in the config file.
+
+## Goals
+- Provide a comfortable viewing experience in low-light environments
+- Persist theme preference across sessions
+- Apply consistent styling to all TUI components
+
+## Quality Gates
+
+These commands must pass for every user story:
+- `pnpm typecheck` - Type checking
+- `pnpm lint` - Linting
+
+For UI stories, also include:
+- Verify in browser using dev-browser skill
+
+## User Stories
+
+### US-001: Add theme configuration
+**Description:** As a user, I want to set my preferred theme (light/dark) so that it persists across sessions.
+
+**Acceptance Criteria:**
+- [ ] Add `theme` field to `.ralph-tui.yaml` schema
+- [ ] Support values: "light", "dark", "system"
+- [ ] Default to "light" for backwards compatibility
+
+### US-002: Create dark theme color palette
+**Description:** As a user, I want a soft-contrast dark theme that's easy on the eyes.
+
+**Acceptance Criteria:**
+- [ ] Define dark palette with gray tones (not pure black)
+- [ ] Ensure sufficient contrast ratios (WCAG AA)
+- [ ] Colors work well for all UI states (selected, hover, disabled)
+
+### US-003: Apply theme to TUI components
+**Description:** As a user, I want all TUI components to respect my theme preference.
+
+**Acceptance Criteria:**
+- [ ] Header component uses theme colors
+- [ ] Task list uses theme colors
+- [ ] Detail panels use theme colors
+- [ ] Progress bar uses theme colors
+- [ ] Dialogs use theme colors
+
+### US-004: Add theme toggle in settings
+**Description:** As a user, I want to toggle themes from within the TUI settings.
+
+**Acceptance Criteria:**
+- [ ] Theme option visible in settings view
+- [ ] Changes apply immediately without restart
+- [ ] Changes persist to config file
+
+## Functional Requirements
+- FR-1: Theme setting must be readable from `.ralph-tui.yaml`
+- FR-2: Theme must apply on TUI startup
+- FR-3: Theme changes in settings must apply immediately
+- FR-4: All text must maintain readability in both themes
+
+## Non-Goals
+- System theme auto-detection (future enhancement)
+- Custom color schemes beyond light/dark
+- Per-component theme overrides
+
+## Technical Considerations
+- Use existing OpenTUI theming capabilities if available
+- Consider creating a ThemeContext for React components
+- Minimize re-renders when theme changes
+
+## Success Metrics
+- All components render correctly in dark mode
+- No accessibility contrast issues
+- Theme persists across sessions
+
+## Open Questions
+- Should we detect system theme preference automatically in v2?
+[/PRD]
diff --git a/skills/ralph-tui-prd/SKILL.md b/skills/ralph-tui-prd/SKILL.md
index a23a04e9..f08b9d6a 100644
--- a/skills/ralph-tui-prd/SKILL.md
+++ b/skills/ralph-tui-prd/SKILL.md
@@ -41,30 +41,17 @@ Ask questions one set at a time. Each answer should inform your next questions.
    B. Increase user retention
    C. Reduce support burden
    D. Other: [please specify]
-
-2. Who is the target user?
-   A. New users only
-   B. Existing users only
-   C. All users
-   D. Admin users only
 ```
 
-This lets users respond with "1A, 2C" for quick iteration.
-
 ### Quality Gates Question (REQUIRED)
 
-Always ask about quality gates - these are project-specific:
+Always ask what quality commands must pass - these are project-specific:
 
 ```
 What quality commands must pass for each user story?
    A. pnpm typecheck && pnpm lint
    B. npm run typecheck && npm run lint
-   C. bun run typecheck && bun run lint
-   D. Other: [specify your commands]
-
-For UI stories, should we include browser verification?
-   A. Yes, use dev-browser skill to verify visually
-   B. No, automated tests are sufficient
+   C. Other: [specify your commands]
 ```
 
 ### Adaptive Questioning
@@ -89,7 +76,7 @@ Brief description of the feature and the problem it solves.
 Specific, measurable objectives (bullet list).
 
 ### 3. Quality Gates
-**CRITICAL:** List the commands that must pass for every user story.
+**CRITICAL:** List the commands that must pass for every user story. This section is extracted by conversion tools and appended to each story's acceptance criteria.
 
 ```markdown
 ## Quality Gates
@@ -102,8 +89,6 @@ For UI stories, also include:
 - Verify in browser using dev-browser skill
 ```
 
-This section is extracted by conversion tools (ralph-tui-create-json, ralph-tui-create-beads) and appended to each story's acceptance criteria.
-
 ### 4. User Stories
 Each story needs:
 - **Title:** Short descriptive name
@@ -190,125 +175,7 @@ The PRD will be executed by AI coding agents via ralph-tui. Therefore:
 
 ## Example Conversation Flow
 
-**User:** Create a PRD for adding dark mode to the TUI
-
-**Assistant:** I'll help you create a PRD for dark mode. Let me ask a few questions:
-
-1. What is the primary goal?
-   A. Reduce eye strain for long sessions
-   B. Match system theme preference
-   C. Provide visual customization
-   D. Other
-
-2. Should the setting persist?
-   A. Yes, save to config file
-   B. No, session only
-   C. Follow system preference
-
-**User:** 1A, 2A
-
-**Assistant:** Great! A couple more questions:
-
-3. Which components need dark mode support?
-   A. All TUI components
-   B. Only the main execution view
-   C. Main view + settings
-   D. Other
-
-4. What quality commands must pass for each story?
-   A. pnpm typecheck && pnpm lint
-   B. npm run typecheck && npm run lint
-   C. bun run typecheck
-   D. Other: [specify]
-
-5. For UI stories, include browser verification?
-   A. Yes, use dev-browser skill
-   B. No, automated tests sufficient
-
-**User:** 3A, 4A, 5A
-
-**Assistant:** Perfect, I have enough to generate the PRD.
-
-[PRD]
-# PRD: Dark Mode for Ralph TUI
-
-## Overview
-Add dark mode support to ralph-tui to reduce eye strain during long orchestration sessions. The feature will apply to all TUI components and persist the user's preference in the config file.
-
-## Goals
-- Provide a comfortable viewing experience in low-light environments
-- Persist theme preference across sessions
-- Apply consistent styling to all TUI components
-
-## Quality Gates
-
-These commands must pass for every user story:
-- `pnpm typecheck` - Type checking
-- `pnpm lint` - Linting
-
-For UI stories, also include:
-- Verify in browser using dev-browser skill
-
-## User Stories
-
-### US-001: Add theme configuration
-**Description:** As a user, I want to set my preferred theme (light/dark) so that it persists across sessions.
-
-**Acceptance Criteria:**
-- [ ] Add `theme` field to `.ralph-tui.yaml` schema
-- [ ] Support values: "light", "dark", "system"
-- [ ] Default to "light" for backwards compatibility
-
-### US-002: Create dark theme color palette
-**Description:** As a user, I want a soft-contrast dark theme that's easy on the eyes.
-
-**Acceptance Criteria:**
-- [ ] Define dark palette with gray tones (not pure black)
-- [ ] Ensure sufficient contrast ratios (WCAG AA)
-- [ ] Colors work well for all UI states (selected, hover, disabled)
-
-### US-003: Apply theme to TUI components
-**Description:** As a user, I want all TUI components to respect my theme preference.
-
-**Acceptance Criteria:**
-- [ ] Header component uses theme colors
-- [ ] Task list uses theme colors
-- [ ] Detail panels use theme colors
-- [ ] Progress bar uses theme colors
-- [ ] Dialogs use theme colors
-
-### US-004: Add theme toggle in settings
-**Description:** As a user, I want to toggle themes from within the TUI settings.
-
-**Acceptance Criteria:**
-- [ ] Theme option visible in settings view
-- [ ] Changes apply immediately without restart
-- [ ] Changes persist to config file
-
-## Functional Requirements
-- FR-1: Theme setting must be readable from `.ralph-tui.yaml`
-- FR-2: Theme must apply on TUI startup
-- FR-3: Theme changes in settings must apply immediately
-- FR-4: All text must maintain readability in both themes
-
-## Non-Goals
-- System theme auto-detection (future enhancement)
-- Custom color schemes beyond light/dark
-- Per-component theme overrides
-
-## Technical Considerations
-- Use existing OpenTUI theming capabilities if available
-- Consider creating a ThemeContext for React components
-- Minimize re-renders when theme changes
-
-## Success Metrics
-- All components render correctly in dark mode
-- No accessibility contrast issues
-- Theme persists across sessions
-
-## Open Questions
-- Should we detect system theme preference automatically in v2?
-[/PRD]
+See [EXAMPLES.md](EXAMPLES.md) for a complete example of the question-and-answer flow leading to a finished PRD.
 
 ---
 
@@ -318,10 +185,6 @@ Before outputting the PRD:
 
 - [ ] Asked clarifying questions with lettered options
 - [ ] Asked about quality gates (REQUIRED)
-- [ ] Asked follow-up questions when needed
-- [ ] Quality Gates section included with project-specific commands
+- [ ] Quality Gates section included
 - [ ] User stories are small and independently completable
-- [ ] User stories do NOT include quality gate commands (they're in the Quality Gates section)
-- [ ] Functional requirements are numbered and unambiguous
-- [ ] Non-goals section defines clear boundaries
 - [ ] PRD is wrapped in `[PRD]...[/PRD]` markers