@hanzlaa/rcode 2.1.0

package/rihal/skills/actions/2-plan/rihal-create-milestone/steps/step-02-outcomes.md

@@ -0,0 +1,64 @@
+# Step 2: Extract Major Outcomes from PRD
+
+**Progress: Step 2 of 10** — Next: Milestone Sequencing
+
+## STEP GOAL
+
+Parse the approved PRD, extract every named outcome / success metric / scope item, and present them back to the user for confirmation. No grouping into milestones yet — that's step 3.
+
+## MANDATORY RULES
+
+- 🛑 Do NOT invent outcomes not present in the PRD.
+- 🛑 Do NOT skip outcomes you consider "obvious". The user decides what matters.
+- ⏸️ HALT at the A/P/C menu at the end of this step.
+- 🚷 No autonomous bypass — see `../../../_shared/no-autonomous-bypass.md`.
+
+## SEQUENCE
+
+### 1. Re-read the PRD
+
+Load `{inputFile}` (`{planning_artifacts}/prd.md`). Focus on:
+
+- **Scope** section — every in-scope feature.
+- **Success Metrics** / **Goals** — the numbers the product is measured against.
+- **Out of scope** — goes to Backlog in step 7, but note it now so we don't accidentally promote later.
+
+### 2. Build the outcome list
+
+For each outcome, capture:
+
+| Field | Example |
+|-------|---------|
+| ID | O-01 |
+| Name | "Paid subscription tier live" |
+| Source | "PRD §3 Scope, line 12" |
+| Acceptance hint | "Stripe integrated, ≥ 3 paid customers" |
+| Dependencies | O-02 (auth must ship first) |
+
+Order by PRD order — the user can reorder in step 3.
+
+### 3. Present for confirmation
+
+Show a compact table:
+
+```
+Outcomes extracted from PRD ({count}):
+
+  O-01  Paid subscription tier live            (PRD §3)
+  O-02  User authentication                    (PRD §3)
+  O-03  Team workspaces                        (PRD §4)
+  ...
+
+[A] Accept — these are the outcomes, proceed to sequencing
+[P] Propose — I want to add / remove / rename outcomes
+[C] Continue to step 3 (same as A)
+```
+
+If user picks `P`, re-open the extraction with user-supplied additions / removals, re-present until user picks A or C.
+
+### 4. Persist & advance
+
+On A or C:
+- Append the outcomes table to `{outputFile}` under a `## Outcomes (extracted from PRD)` heading.
+- Update frontmatter: add `step-02-outcomes` to `stepsCompleted`.
+- Load `./step-03-sequencing.md`.

package/rihal/skills/actions/2-plan/rihal-create-milestone/steps/step-03-sequencing.md

@@ -0,0 +1,65 @@
+# Step 3: Sequence Outcomes into Milestones
+
+**Progress: Step 3 of 10** — Next: Assign Date Windows
+
+## STEP GOAL
+
+Group the outcome list from step 2 into coherent milestones (M1, M2, M3, ...) and agree the cut lines with the user.
+
+## MANDATORY RULES
+
+- ⏸️ HALT at menu; every milestone grouping is user-confirmed.
+- 🛑 Maximum 6 active milestones per roadmap. If the user insists on more, split into v1/v2 and stop at M6 for v1.
+- 🛑 Every milestone MUST have at least 2 outcomes. A single-outcome milestone is a phase, not a milestone — suggest merging.
+
+## SEQUENCE
+
+### 1. Propose an initial grouping
+
+Based on outcome dependencies and natural clusters (same surface area, same user persona, same delivery cadence):
+
+```
+Proposed milestones:
+
+M1 — MVP (foundation)
+  O-02  User authentication
+  O-04  Basic project CRUD
+  O-07  Single-tenant data model
+
+M2 — Team collaboration
+  O-03  Team workspaces
+  O-05  Roles & permissions
+  O-09  Activity feed
+
+M3 — Monetization
+  O-01  Paid subscription tier
+  O-06  Usage metering
+  O-08  Billing portal
+
+[A] Accept this grouping
+[P] Propose changes (move, split, merge)
+[C] Continue to step 4
+```
+
+### 2. Explain your reasoning
+
+One sentence per milestone:
+- M1 is the tech foundation — everything else depends on it.
+- M2 turns a single-user tool into a team tool.
+- M3 lets Rihal charge money — depends on stable M1 + M2.
+
+### 3. Handle user proposals
+
+If user picks `P`, ask what to change:
+- Move O-X from M_Y to M_Z
+- Split M_X into two milestones
+- Merge M_X + M_Y
+- Rename milestone
+
+Re-present the updated grouping until user picks A or C.
+
+### 4. Persist & advance
+
+- Append the confirmed grouping to `{outputFile}` under `## Milestones (proposed)` heading.
+- Update `stepsCompleted`.
+- Load `./step-04-windows.md`.

package/rihal/skills/actions/2-plan/rihal-create-milestone/steps/step-04-windows.md

@@ -0,0 +1,60 @@
+# Step 4: Assign Date Windows
+
+**Progress: Step 4 of 10** — Next: Kill Criteria
+
+## STEP GOAL
+
+Give each milestone a start / end date. Verify realism with the user using rough capacity math.
+
+## MANDATORY RULES
+
+- 🛑 NEVER invent velocity numbers. If the PRD has "target launch" dates, use those. If not, ASK.
+- 🛑 Windows must not overlap unless the user explicitly says parallel tracks exist.
+- ⏸️ HALT at menu.
+
+## SEQUENCE
+
+### 1. Establish capacity
+
+If the PRD specifies team size / target launch, use those. Otherwise ask:
+
+```
+To size these milestones realistically:
+1. How many devs will work on this? (default: 1)
+2. When is the target launch for M1?
+3. Any hard external deadlines (client commit, event, regulatory)?
+```
+
+Do NOT proceed until numeric answers are on the table (unless `mode: yolo` or `--auto` — see `../../../_shared/no-autonomous-bypass.md`).
+
+### 2. Propose windows
+
+Simple rule of thumb: 6–10 weeks per milestone for a 1–2 person team, 4–6 weeks for a 3–5 person team. Adjust based on outcome complexity from step 2.
+
+```
+Proposed windows:
+
+M1 — MVP                    {start}  →  {start + 8 weeks}  (2026-04-24 → 2026-06-19)
+M2 — Team collaboration    (M1 end) →  +6 weeks           (2026-06-19 → 2026-07-31)
+M3 — Monetization          (M2 end) →  +6 weeks           (2026-07-31 → 2026-09-11)
+
+Total: ~20 weeks / 5 months.
+
+[A] Accept windows
+[P] Propose changes (shift, compress, extend)
+[C] Continue to step 5
+```
+
+### 3. Realism check
+
+Before accepting, briefly call out risks:
+- "M1 at 8 weeks with 1 dev is tight — auth alone is often 3-4 weeks."
+- "M3 monetization after only 14 weeks of combined M1+M2 assumes no pivots on pricing."
+
+The user decides. You surface the risk; you do not refuse the window.
+
+### 4. Persist & advance
+
+- Append windows to each milestone block in `{outputFile}`.
+- Update `stepsCompleted`.
+- Load `./step-05-kill-criteria.md`.

package/rihal/skills/actions/2-plan/rihal-create-milestone/steps/step-05-kill-criteria.md

@@ -0,0 +1,59 @@
+# Step 5: Binary Kill Criteria
+
+**Progress: Step 5 of 10** — Next: Phase Stubs
+
+## STEP GOAL
+
+For each milestone, define **binary** kill criteria — numeric thresholds that, if breached, trigger a pivot or sunset.
+
+## MANDATORY RULES
+
+- 🛑 Kill criteria must be binary (number + threshold), not adjectival.
+  - ❌ "Low user satisfaction"
+  - ✅ "NPS < 10 at 90 days post-launch"
+- 🛑 Every milestone gets at least one kill criterion.
+- 🛑 Every criterion cites a source — PRD success metric, Rihal standard, or user-provided number.
+
+## SEQUENCE
+
+### 1. Extract candidates from PRD
+
+From `{inputFile}`'s Success Metrics section, flag any that naturally invert into kill criteria:
+
+| Success metric | Natural kill criterion |
+|---|---|
+| ≥ 300 paid users in 90 days | MRR < $1,200 at 90 days |
+| ≥ 40% D7 retention | D7 retention < 15% |
+| ≥ 99.5% post-success rate | Success rate < 97% |
+
+### 2. Assign to milestones
+
+Match each kill criterion to the milestone whose outcomes it measures. If a metric is meaningful only post-M3 (e.g. MRR), it applies to M3's kill criterion.
+
+### 3. Propose
+
+```
+Kill criteria (binary — two or more firing = pivot review):
+
+M1 — MVP
+  K1.1  Auth success rate < 99% at 2 weeks post-launch
+  K1.2  Launch slips > 3 weeks past 2026-06-19
+
+M2 — Team collaboration
+  K2.1  < 30% of M1 users activate workspace feature
+  K2.2  Workspace-creation error rate > 1%
+
+M3 — Monetization
+  K3.1  MRR < $1,200 at 90 days
+  K3.2  Paid → churn within 30 days > 25%
+
+[A] Accept
+[P] Propose (add/remove/adjust thresholds)
+[C] Continue
+```
+
+### 4. Persist & advance
+
+- Append criteria to each milestone in `{outputFile}`.
+- Update `stepsCompleted`.
+- Load `./step-06-phase-stubs.md`.

package/rihal/skills/actions/2-plan/rihal-create-milestone/steps/step-06-phase-stubs.md

@@ -0,0 +1,56 @@
+# Step 6: Phase Stubs Under Each Milestone
+
+**Progress: Step 6 of 10** — Next: Backlog parking lot
+
+## STEP GOAL
+
+For each milestone, list the phases it contains as **stubs** (number + name + one-line goal). No plan detail — phases get full plans via `/rihal:plan` later.
+
+## MANDATORY RULES
+
+- 🛑 Phase numbers follow Rihal's NN convention (01, 02, ..., 99, then 999.x for parking lot).
+- 🛑 Do NOT generate plan content here. That's `/rihal:plan-phase`.
+- 🛑 Each phase has one-sentence goal, max.
+- ⏸️ HALT at menu.
+
+## SEQUENCE
+
+### 1. Propose phase stubs
+
+Mirror the outcome-to-milestone mapping from step 3. Each outcome typically becomes 1–2 phases; a milestone typically has 3–6 phases.
+
+```
+Phase stubs:
+
+M1 — MVP (Apr 24 → Jun 19)
+  01  Setup & scaffolding — repo, CI, Vercel, Neon provisioned
+  02  Auth — email/password + Google OAuth
+  03  Project CRUD — list, detail, create, archive
+  04  Data model hardening — migrations, seeds, indexes
+
+M2 — Team collaboration (Jun 19 → Jul 31)
+  05  Workspace model — users-in-workspaces
+  06  Roles & permissions — admin/member/viewer
+  07  Activity feed — who did what, when
+
+M3 — Monetization (Jul 31 → Sep 11)
+  08  Stripe integration — checkout + portal
+  09  Usage metering — event ingestion + aggregation
+  10  Billing UI — plans, invoices, receipts
+
+[A] Accept
+[P] Propose changes (add, remove, rename, renumber)
+[C] Continue
+```
+
+### 2. Cross-check against outcomes
+
+Every outcome from step 2 must be covered by at least one phase stub. If an outcome is uncovered, flag it:
+
+> ⚠ O-11 "Admin audit log" does not appear in any phase. Add to M2 (phase 07)? Move to backlog? Drop?
+
+### 3. Persist & advance
+
+- Append phase stubs to each milestone block in `{outputFile}`.
+- Update `stepsCompleted`.
+- Load `./step-07-backlog.md`.

package/rihal/skills/actions/2-plan/rihal-create-milestone/steps/step-07-backlog.md

@@ -0,0 +1,44 @@
+# Step 7: Backlog Parking Lot
+
+**Progress: Step 7 of 10** — Next: Write ROADMAP.md
+
+## STEP GOAL
+
+Capture everything that is **not** in M1..Mn but was considered. Use Rihal's `999.x` parking-lot convention so items can be promoted later via `/rihal:plant-seed` or `/rihal:review-backlog`.
+
+## MANDATORY RULES
+
+- 🛑 Pull explicit "Out of scope" items from the PRD into the backlog — do not silently drop them.
+- 🛑 Each backlog item gets a one-line reason ("deferred: needs user auth from M1").
+- ⏸️ HALT at menu.
+
+## SEQUENCE
+
+### 1. Collect backlog items
+
+Sources:
+- PRD's explicit "Out of scope" section.
+- Outcomes that got cut in step 3 sequencing.
+- Ideas raised during step 4-6 that did not make it into a milestone.
+
+### 2. Number using 999.x convention
+
+```
+Backlog (999.x — promotable with /rihal:plant-seed):
+
+  999.1  Cross-post to LinkedIn          — deferred: requires LinkedIn OAuth (M2+)
+  999.2  Auto-DM feature                 — deferred: abuse risk, needs rate-limit design
+  999.3  Mobile native app               — deferred: PWA sufficient for launch
+  999.4  Enterprise SSO                  — deferred: no enterprise customers yet
+  999.5  Audit log export                — deferred: nice-to-have for M2
+
+[A] Accept
+[P] Add, remove, re-number
+[C] Continue
+```
+
+### 3. Persist & advance
+
+- Append backlog section to `{outputFile}`.
+- Update `stepsCompleted`.
+- Load `./step-08-write-roadmap.md`.

package/rihal/skills/actions/2-plan/rihal-create-milestone/steps/step-08-write-roadmap.md

@@ -0,0 +1,58 @@
+# Step 8: Write Final ROADMAP.md
+
+**Progress: Step 8 of 10** — Next: State Sync
+
+## STEP GOAL
+
+Assemble everything collected in steps 2–7 into a clean, publication-quality ROADMAP.md. This is the document the user will reference, share, and revisit.
+
+## MANDATORY RULES
+
+- 🛑 Use the canonical ROADMAP.md structure (mirrors `docs/ROADMAP.md` pattern in Rihal Code itself).
+- 🛑 Every milestone: name, window, goal, outcomes, phases, kill criteria.
+- 🛑 Every phase stub: number, name, one-line goal.
+- 🛑 Clean markdown — no debug sections, no "proposed" labels, no step headings.
+
+## SEQUENCE
+
+### 1. Template for each milestone block
+
+```markdown
+## Milestone M{N} — {Name}
+
+**Window:** {start} → {end}
+**Goal:** {one-sentence goal}
+**Status:** {Planned | Active | Complete}
+
+### Outcomes
+- O-{nn} {Outcome name} (PRD §{section})
+
+### Phases
+| # | Name | Goal |
+|---|------|------|
+| {NN} | {phase-name} | {one-line goal} |
+
+### Acceptance
+{1–3 bullet acceptance criteria derived from outcomes}
+
+### Kill criteria (binary)
+- K{N}.{M}: {criterion with numeric threshold}
+
+---
+```
+
+### 2. Assemble
+
+- Top of file: title (project name + "Roadmap"), source PRD reference, hard deadline if any.
+- Then all milestones in order.
+- Then `## Backlog (parking lot)` section with 999.x items.
+- Then a brief `## Kill criteria summary` reminder explaining binary-threshold semantics.
+
+### 3. Overwrite {outputFile}
+
+Replace the step-by-step accumulated content with the clean final version. Do NOT keep the intermediate "proposed" sections. The frontmatter stays and is updated.
+
+### 4. Persist & advance
+
+- Update frontmatter: `stepsCompleted` adds `step-08-write-roadmap`. Add `totalMilestones`, `totalPhases`, `hardDeadline` (if any).
+- Load `./step-09-state-sync.md`.

package/rihal/skills/actions/2-plan/rihal-create-milestone/steps/step-09-state-sync.md

@@ -0,0 +1,62 @@
+# Step 9: Sync ROADMAP into state.json
+
+**Progress: Step 9 of 10** — Next: Completion summary
+
+## STEP GOAL
+
+Call the state-sync CLI so `.rihal/state.json` reflects every milestone and phase we just wrote to `ROADMAP.md`. This closes the drift loophole documented in issue #126 and enforced by `_shared/state-sync-rule.md`.
+
+## MANDATORY RULES
+
+- 🛑 This step MUST run. Skipping it leaves `/rihal:status` and `/rihal:progress` showing stale data.
+- 🛑 Report the sync result (pulled phases, existing phases updated, any errors) to the user.
+
+## SEQUENCE
+
+### 1. Run the sync
+
+```bash
+node .rihal/bin/rihal-tools.cjs state sync --from-disk
+```
+
+### 2. Parse and report
+
+Expected JSON output shape:
+
+```json
+{
+  "ok": true,
+  "synced": true,
+  "milestones_found": 3,
+  "phases_found": 10,
+  "phases_upserted": 10,
+  "epics_found": 0,
+  "roadmap_exists": true,
+  "epics_exists": false
+}
+```
+
+Report to the user:
+
+```
+State sync complete:
+  Milestones:       3
+  Phases:          10
+  Phases upserted: 10 (new)
+  Epics:            0 (none yet — run /rihal:create-epics-and-stories next)
+```
+
+### 3. Verify drift closed
+
+Run a sanity check:
+
+```bash
+node .rihal/bin/rihal-tools.cjs state read | grep -E '"phases":|"name":'
+```
+
+Confirm the phase count matches what ROADMAP.md shows. If not, surface a warning and tell the user to run `state sync --from-disk` again or check for markdown malformation.
+
+### 4. Advance
+
+- Update `stepsCompleted`: add `step-09-state-sync`.
+- Load `./step-10-complete.md`.

package/rihal/skills/actions/2-plan/rihal-create-milestone/steps/step-10-complete.md

@@ -0,0 +1,56 @@
+# Step 10: Completion Summary & Handoff
+
+**Progress: Step 10 of 10** — Final step
+
+## STEP GOAL
+
+Summarize what was produced, mark the workflow complete in frontmatter, and point the user at the next natural command.
+
+## SEQUENCE
+
+### 1. Final frontmatter update
+
+Append `step-10-complete` to `stepsCompleted`. Add `completedAt: {ISO date}`.
+
+### 2. Completion summary to user
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+ RIHAL ► ROADMAP CREATED
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+Source PRD:     {inputFile}
+Roadmap:        {outputFile}
+State:          .rihal/state.json (synced)
+
+Shipped:
+  {N} milestones: M1..M{N}
+  {M} phases:     01..{NN}
+  {K} backlog items: 999.1..999.{K}
+
+Hard deadline:  {deadline or "none specified"}
+
+[{completedAt}]
+```
+
+### 3. Next-step menu (intent-based, mirrors the GSD /progress Route A/B/C pattern)
+
+```
+What's next?
+
+  [A] Decompose M1 into epics + stories
+      → /rihal:create-epics-and-stories
+
+  [B] Plan the first phase in detail
+      → /rihal:plan-phase 01
+
+  [C] Review the roadmap with the team
+      → /rihal:council "Is this roadmap realistic?"
+
+  [D] Park and review later
+      → Roadmap is saved; pick up with /rihal:progress anytime
+```
+
+### 4. HALT
+
+This is the terminal step. Do NOT load another step file. The workflow is complete.

package/rihal/skills/actions/2-plan/rihal-create-milestone/workflow.md

@@ -0,0 +1,93 @@
+---
+main_config: '{project-root}/.rihal/config.json'
+outputFile: '{planning_artifacts}/ROADMAP.md'
+inputFile: '{planning_artifacts}/prd.md'
+---
+
+# Create Milestone / Roadmap Workflow
+
+**Goal:** Design a roadmap of milestones (M1..Mn) from an approved PRD. Each milestone carries a window, goal, acceptance, and binary kill criteria.
+
+**Your Role:** Product strategist and program manager collaborating with the user. You sequence outcomes into milestones; the user validates priorities and cut lines.
+
+---
+
+## WORKFLOW ARCHITECTURE
+
+This uses **step-file architecture** for disciplined execution:
+
+### Core Principles
+
+- **Micro-file Design**: Each step is a self-contained instruction file
+- **Just-In-Time Loading**: Only the current step file is in memory
+- **Sequential Enforcement**: Sequence within step files must be completed in order
+- **State Tracking**: Document progress via `stepsCompleted` array in output frontmatter
+- **Append-Only Building**: Build ROADMAP.md by appending each milestone once confirmed
+
+### Critical Rules (NO EXCEPTIONS)
+
+- 🛑 **NEVER** load multiple step files simultaneously
+- 📖 **ALWAYS** read entire step file before execution
+- 🚫 **NEVER** skip steps or optimize the sequence
+- ⏸️ **ALWAYS** halt at menus and wait for user input
+- 💾 **ALWAYS** update frontmatter of output files when writing
+- 🎯 **ALWAYS** follow the exact instructions in the step file
+- 📋 **NEVER** create mental todo lists from future steps
+- 🚷 **NEVER** invent an "autonomous mode" or self-declared bypass. The only sanctioned paths are `.rihal/config.yaml` → `mode: yolo` or `/rihal:do --auto`. See `../../_shared/no-autonomous-bypass.md`.
+- 🔗 **NEVER** cite external sources without `WebFetch`. See `../../_shared/research-citation-rule.md`.
+- 🗂️ **ALWAYS** sync every milestone/phase into `.rihal/state.json` after writing to ROADMAP.md. See `../../_shared/state-sync-rule.md`.
+
+---
+
+## INITIALIZATION SEQUENCE
+
+### 1. Configuration Loading
+
+Load and read full config from `{main_config}` and resolve:
+
+- `project_name`, `output_folder`, `planning_artifacts`, `user_name`
+- `communication_language`, `document_output_language`
+- `date` as system-generated current datetime
+
+✅ SPEAK OUTPUT in `{communication_language}`.
+✅ WRITE all artifact content in `{document_output_language}`.
+
+### 2. Prerequisite Check
+
+Verify `{inputFile}` (PRD) exists and is non-empty. If missing:
+
+- Respond: *"I need an approved PRD first. Run `/rihal:create-prd` or point me at the existing brief."*
+- HALT. Do not create ROADMAP.md.
+
+If PRD frontmatter shows `status: draft`, warn the user and ask whether to proceed.
+
+### 3. Route to First Step
+
+Read fully and follow: `./steps/step-01-init.md`
+
+---
+
+## WORKFLOW OUTLINE
+
+Steps (loaded one at a time):
+
+1. `step-01-init.md` — Load PRD, detect continuation, initialize ROADMAP.md frontmatter.
+2. `step-02-outcomes.md` — Extract major outcomes from PRD. User confirms the list.
+3. `step-03-sequencing.md` — Group outcomes into milestones; agree cut lines.
+4. `step-04-windows.md` — Assign date windows to each milestone; verify realism with user.
+5. `step-05-kill-criteria.md` — Define binary kill criteria per milestone.
+6. `step-06-phase-stubs.md` — List stub phases under each milestone (no plan detail yet).
+7. `step-07-backlog.md` — Capture parking-lot items.
+8. `step-08-write-roadmap.md` — Append all milestones to ROADMAP.md.
+9. `step-09-state-sync.md` — Upsert milestones + phases into `.rihal/state.json`.
+10. `step-10-complete.md` — Summary, next-step hand-off (`/rihal:create-epics-and-stories` for M1).
+
+Each step halts at a menu: [A]ccept / [P]ropose change / [C]ontinue. Only on `C` does the workflow advance.
+
+---
+
+## HAND-OFF
+
+On completion, recommend the user run:
+- `/rihal:create-epics-and-stories` to decompose M1 into epics + stories.
+- `/rihal:sprint-planning` once the first epic is scoped.

package/rihal/skills/actions/2-plan/rihal-create-prd/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: rihal-create-prd
+description: >
+  Create a new Product Requirements Document from scratch through guided
+  facilitation. Activates when the user says "create a PRD", "write product
+  requirements document", "lets make a PRD", "I want to create a new PRD",
+  "draft requirements for", "new product spec", or "start a PRD". Do NOT use
+  for updating an existing PRD (use rihal-edit-prd), or validating an
+  existing PRD (use rihal-validate-prd).
+---
+
+## Workflow
+
+Follow the instructions in ./workflow.md.
+
+## Output Format
+
+- Output: PRD file saved to the configured output folder
+- Structure: Problem → User → Scope → Requirements → Success Metrics → Kill Criteria → Out-of-Scope
+- Each requirement is quantified (numbers, not adjectives)
+- Every section has explicit owner and deadline
+- Do NOT include: vague verbs ("optimize"), unquantified metrics, or requirements without owners
+
+## Examples
+
+### Happy Path
+**Input:** "Create a PRD for a task management feature"
+**Expected behavior:** Interview user for Problem/User/Scope first. Do NOT start the PRD until all 5 discovery questions are answered. Then draft PRD with all sections populated. Save and report location.
+
+### Edge Case: Empty User Input
+**Input:** "Create a PRD"
+**Expected behavior:** Do NOT create a blank template. Ask: "A PRD for what feature/product? And for which audience — engineering, executive, or external?"
+
+### Edge Case: Existing PRD
+**Input:** "Create a PRD for auth" (but one already exists)
+**Expected behavior:** Detect the existing PRD. Respond: "A PRD for auth already exists at [path]. Use rihal-edit-prd to update it, or confirm you want to overwrite."
+
+### Negative Example: Request to Bypass the Interview
+**Input:** "use research skills and create the best PRD ready to execute" / "skip the questions and write it autonomously" / "just generate the full PRD"
+**Expected behavior:** DO NOT invent an "autonomous mode". DO NOT generate a PRD without running discovery. Respond: "The discovery interview is mandatory unless `.rihal/config.yaml` has `mode: yolo` or you re-invoke via `/rihal:do --auto`. Here is the step-01 menu — I will drive each step concisely." Then present the step-01 menu. See `../../_shared/no-autonomous-bypass.md`.