sdlc-framework 1.0.2 → 2.1.0

package/src/commands/status.md

@@ -1,118 +1,84 @@
 ---
 name: sdlc:status
-description: "Show loop position and forced next action"
-allowed-tools: [Read, Glob, Grep]
+description: "Show loop position, pause/resume sessions, and force next action"
+argument-hint: "[pause [reason] | resume [handoff-path]]"
+allowed-tools: [Read, Write, Bash, Glob, Grep, AskUserQuestion]
 ---
 
 <objective>
-Show exactly where you are in the SDLC loop and what you must do next. Visual progress, current state, and forced next action. Designed for junior developers who need clear guidance.
+Show exactly where you are in the SDLC loop. Optionally pause (save context) or resume (restore context). One command for all session awareness.
 
-**When to use:** You are lost. You do not know what to do next. You want to see progress. Run this anytime.
+**When to use:**
+- No argument: see loop position, progress, and forced next action.
+- `pause`: save session context before a break. Creates HANDOFF.md.
+- `resume`: restore session context after a break. Reads HANDOFF.md.
 
 **What it does:**
-1. Read STATE.md for current position.
-2. Display milestone, phase, plan, and loop position with a visual diagram.
-3. Show progress bar and any blockers.
-4. Force exactly ONE next action with an explanation of what it does and why.
+- **No argument:** Read STATE.md, display visual loop diagram, progress bar, blockers, and force ONE next action.
+- **pause:** Gather session context, create HANDOFF.md, optionally WIP commit. Tell user to run `/sdlc:status resume` when they return.
+- **resume:** Read HANDOFF.md, display restored context, verify git state, archive handoff, force ONE next action.
 
-**What happens next:** The forced next action. No choices.
+**What happens next:** The forced next action. No choices — the state machine decides.
 </objective>
 
 <execution_context>
+@~/.claude/sdlc-framework/workflows/status-session.md
 @.sdlc/STATE.md
 @.sdlc/ROADMAP.md
 </execution_context>
 
 <context>
-No arguments required.
+$ARGUMENTS — empty, "pause [reason]", or "resume [handoff-path]".
 
-Read .sdlc/STATE.md for current loop position, milestone, phase, plan.
-Read .sdlc/ROADMAP.md for milestone completion data.
+Read .sdlc/STATE.md for current loop position.
+Read .sdlc/ROADMAP.md for milestone progress.
 </context>
 
 <process>
+Follow workflow: @~/.claude/sdlc-framework/workflows/status-session.md
+
 Step-by-step:
 
-1. **Read state**
-   - Read .sdlc/STATE.md. If it does not exist, output: "Framework not initialized. Run /sdlc:init first." Then stop.
-   - Extract: loop_position, current_milestone, current_phase, current_plan, blockers, deferred_issues.
-   - Read .sdlc/ROADMAP.md for milestone progress data.
-
-2. **Display loop position (visual)**
-   - Show the core loop with the current position highlighted:
-
-   ```
-   SDLC Loop Position:
-
-     SPEC ──→ IMPLEMENT ──→ VERIFY ──→ REVIEW ──→ CLOSE
-      │                                              │
-      └──────────────── next cycle ←─────────────────┘
-
-     Current: [IMPLEMENT] ◄── YOU ARE HERE
-   ```
-
-   - Use `[PHASE]` brackets around the current position.
-   - If in DEBUG or HOTFIX, show those as side branches:
-
-   ```
-     SPEC ──→ IMPLEMENT ──→ VERIFY ──→ REVIEW ──→ CLOSE
-                  │
-                  ├──→ [DEBUG] ◄── YOU ARE HERE
-                  └──→ HOTFIX
-   ```
-
-3. **Display project context**
-   - Show:
-   ```
-   Milestone: {name} ({completed_phases}/{total_phases} phases)
-   Phase:     {name}
-   Plan:      {name or "none — run /sdlc:spec"}
-   ```
-
-4. **Show progress bar**
-   - Calculate completion percentage from ROADMAP.md.
-   - Display:
-   ```
-   Progress: [████████░░░░░░░░░░░░] 40% (4/10 plans completed)
-   ```
-
-5. **Show blockers and deferred issues**
-   - If blockers exist in STATE.md:
-   ```
-   BLOCKERS:
-   - {blocker 1}
-   - {blocker 2}
-   ```
-   - If deferred issues exist:
-   ```
-   DEFERRED:
-   - {issue 1}
-   - {issue 2}
-   ```
-   - If none: "No blockers. No deferred issues."
-
-6. **Force ONE next action with explanation**
-   - Determine the next action from loop_position (same logic as /sdlc:resume).
-   - Explain what that action DOES and WHY it is next:
-
-   ```
-   NEXT ACTION REQUIRED: /sdlc:impl
-
-   What it does: Implements the current plan by writing code with subagent workers.
-   Why it is next: The spec phase is complete. The plan has been approved.
-   Your implementation will be verified in the next step.
-   ```
-
-   - Junior-friendly: use plain language. Assume the reader has never used the framework.
+### If no argument: SHOW STATUS
+
+1. Read .sdlc/STATE.md. If missing: "Run /sdlc:init first." Stop.
+2. Display visual loop diagram with current position highlighted using `[PHASE]` brackets.
+3. Display project context: milestone, phase, plan, progress bar.
+4. Display blockers and deferred issues (or "None").
+5. Force ONE next action from loop_position with plain-language explanation.
+
+### If "pause": SAVE SESSION
+
+1. Read .sdlc/STATE.md to get current loop position and active work.
+2. Gather session context: git status, recent commits, in-progress tasks, decisions, blockers.
+3. Ask user: "Anything to remember for next session not already in files?"
+4. Create .sdlc/HANDOFF.md with full session context.
+5. Offer WIP commit if uncommitted changes exist.
+6. Update STATE.md: add paused_at timestamp, history entry. Do NOT change loop_position.
+7. Output: "Session saved. Run /sdlc:status resume when you return."
+
+### If "resume": RESTORE SESSION
+
+1. Locate handoff: from $ARGUMENTS path, STATE.md handoff_file field, or .sdlc/HANDOFF.md.
+2. If no handoff: fall back to STATE.md only. Display: "No handoff found. Resuming from state."
+3. Display restored context: loop position, work in progress, decisions, blockers.
+4. Verify git state matches handoff (warn on mismatch). Pop stash if applicable.
+5. Archive consumed handoff to .sdlc/HANDOFF-{timestamp}.md.archived.
+6. Clean up STATE.md session fields (remove paused_at).
+7. Force ONE next action. Output ends with NEXT ACTION REQUIRED.
 </process>
 
 <success_criteria>
-- [ ] STATE.md read successfully
-- [ ] Visual loop diagram displayed with current position highlighted
-- [ ] Milestone, phase, and plan shown
-- [ ] Progress bar calculated and displayed
-- [ ] Blockers and deferred issues shown (or "none")
-- [ ] Exactly ONE next action forced
-- [ ] Next action includes plain-language explanation of what it does and why
-- [ ] No choices, no menus — one clear path forward
+- [ ] No-arg: visual loop diagram displayed with current position
+- [ ] No-arg: progress bar and blockers shown
+- [ ] No-arg: exactly ONE next action forced with explanation
+- [ ] Pause: session context gathered (git, tasks, decisions, blockers)
+- [ ] Pause: HANDOFF.md created with complete context
+- [ ] Pause: WIP commit offered if uncommitted changes exist
+- [ ] Pause: output states "Run /sdlc:status resume when you return"
+- [ ] Resume: handoff located and context restored
+- [ ] Resume: git state verified against handoff
+- [ ] Resume: handoff archived after consumption
+- [ ] Resume: output ends with NEXT ACTION REQUIRED: /sdlc:{action}
+- [ ] No menus, no options — one clear path forward
 </success_criteria>

package/src/commands/transition.md

@@ -0,0 +1,99 @@
+---
+name: sdlc:transition
+description: Transition to the next phase after all plans in a phase complete
+argument-hint: "[phase-name]"
+allowed-tools: [Read, Write, Bash, Glob, Grep, Edit, AskUserQuestion]
+---
+
+<objective>
+Transition from the current phase to the next phase within a milestone. Verify phase completeness, update project state, commit the phase, and advance to the next phase.
+
+**When to use:** After /sdlc:close detects the last plan in a phase is done. Can also be run manually to force a phase transition.
+
+**What it does:**
+1. Verify all plans in the current phase are complete (every SPEC has a SUMMARY, all ACs passed).
+2. Cross-check STATE.md, PROJECT.md, and ROADMAP.md for consistency.
+3. Update PROJECT.md with implemented, superseded, and newly discovered requirements.
+4. Advance state to the next phase (or trigger milestone completion if this was the last phase).
+5. Update ROADMAP.md with phase completion details.
+6. Create a git commit marking the phase boundary.
+
+**What happens next:**
+- Next phase exists: Framework directs you to /sdlc:spec for the first plan of the new phase.
+- Last phase in milestone: Framework directs you to /sdlc:close for milestone finalization.
+
+**Critical rule:** No phase transitions without completeness verification. Every plan must have a summary. Every AC must pass. State inconsistencies are surfaced and resolved before advancing.
+</objective>
+
+<execution_context>
+@~/.claude/sdlc-framework/workflows/transition-phase.md
+@.sdlc/STATE.md
+@.sdlc/ROADMAP.md
+@.sdlc/PROJECT.md
+</execution_context>
+
+<context>
+$ARGUMENTS — optional phase name to transition from. If not provided, read from .sdlc/STATE.md current_phase field.
+
+Read these files:
+- .sdlc/STATE.md — current phase, milestone, loop position.
+- .sdlc/ROADMAP.md — phase list, plan counts, next phase identification.
+- .sdlc/PROJECT.md — requirements to update based on completed work.
+- All SUMMARY.md files in the completing phase's directory.
+</context>
+
+<process>
+Follow workflow: @~/.claude/sdlc-framework/workflows/transition-phase.md
+
+Step-by-step:
+
+1. **Verify phase completeness**
+   - Read .sdlc/STATE.md. Confirm loop_position is CLOSE ✓. If not, warn: "Loop not closed. Run /sdlc:close first."
+   - List all SPEC and SUMMARY files in .sdlc/phases/{current_phase}/.
+   - Every SPEC must have a corresponding SUMMARY. If not, block: "Phase transition blocked. Plan {N} has a spec but no summary."
+   - Every SUMMARY must show all ACs passed. If not, block: "Phase transition blocked. Plan {N} has failing ACs."
+
+2. **Verify state consistency**
+   - Cross-check STATE.md, PROJECT.md, and ROADMAP.md:
+     - STATE.md current_milestone matches ROADMAP.md in-progress milestone.
+     - STATE.md current_phase matches the phase being completed.
+     - Prior phases in this milestone are all COMPLETE.
+   - If inconsistency found: display details, offer to auto-fix, ask for confirmation.
+
+3. **Update PROJECT.md**
+   - Read all SUMMARY.md files from the completing phase.
+   - Mark addressed requirements as IMPLEMENTED.
+   - Mark contradicted requirements as SUPERSEDED.
+   - Add newly discovered requirements as NOT STARTED.
+   - Display proposed changes and ask user to confirm before writing.
+
+4. **Advance state to next phase**
+   - Read ROADMAP.md to identify the next phase.
+   - If next phase exists:
+     - Update STATE.md: current_phase, clear current_plan, set loop_position: TRANSITION ✓, set next_required_action: /sdlc:spec.
+     - Update ROADMAP.md: mark completed phase as COMPLETE, set next phase to IN PROGRESS.
+   - If no next phase (last phase in milestone):
+     - Update STATE.md: set next_required_action: /sdlc:close (milestone completion).
+
+5. **Update ROADMAP.md with phase summary**
+   - Add completion date, plan count, hotfix count, key deliverables, and duration.
+
+6. **Create git commit** (if in a git repository)
+   - Stage .sdlc/ files and source files from the phase.
+   - Commit with message: "feat({phase-name}): complete phase {number}"
+
+7. **Output next action**
+   - If next phase exists: end with NEXT ACTION REQUIRED: /sdlc:spec
+   - If milestone complete: end with NEXT ACTION REQUIRED: /sdlc:close
+</process>
+
+<success_criteria>
+- [ ] Phase completeness verified: every SPEC has a SUMMARY, all ACs passed
+- [ ] State consistency checked across STATE.md, PROJECT.md, ROADMAP.md
+- [ ] PROJECT.md updated with implemented, superseded, and new requirements
+- [ ] STATE.md advanced to next phase (or milestone completion)
+- [ ] ROADMAP.md updated with phase completion details and summary
+- [ ] Git commit created at phase boundary (if in a git repo)
+- [ ] If next phase exists: output ends with NEXT ACTION REQUIRED: /sdlc:spec
+- [ ] If milestone complete: output ends with NEXT ACTION REQUIRED: /sdlc:close
+</success_criteria>

package/src/commands/verify.md

@@ -25,7 +25,7 @@ Verify the implementation against every acceptance criterion in the SPEC.md. Use
 </objective>
 
 <execution_context>
-@~/.claude/sdlc-framework/workflows/run-verify.md
+@~/.claude/sdlc-framework/workflows/verify-phase.md
 @.sdlc/STATE.md
 The SPEC.md path is read from STATE.md or provided via $ARGUMENTS.
 </execution_context>
@@ -40,7 +40,7 @@ Read these files:
 </context>
 
 <process>
-Follow workflow: @~/.claude/sdlc-framework/workflows/run-verify.md
+Follow workflow: @~/.claude/sdlc-framework/workflows/verify-phase.md
 
 Step-by-step:
 

package/src/references/prompt-detection.md

@@ -10,7 +10,7 @@ When a developer types `/sdlc:fast "add a login page"`, the framework must deter
 
 1. **What type of work is this?** (feature, bug, critical, research, test, refactor, docs)
 2. **How complex is it?** (simple, medium, complex)
-3. **Where should it route?** (inline execution, /sdlc:spec, /sdlc:debug, /sdlc:hotfix, /sdlc:research)
+3. **Where should it route?** (inline execution, /sdlc:spec, /sdlc:debug, /sdlc:research, /sdlc:discuss, or inline hotfix)
 
 `/sdlc:fast` is the **default entry point** for all work — not just small tasks. It is a universal router that classifies intent and complexity, then either handles work inline (simple) or routes to the appropriate specialized command (complex, bugs, research, emergencies).
 

package/src/templates/PRD.md

@@ -0,0 +1,89 @@
+# PRD: {title}
+
+## Meta
+
+| Field | Value |
+|-------|-------|
+| Created | {date} |
+| Status | DRAFT / APPROVED |
+| Author | {user} + AI |
+| Source | /sdlc:discuss |
+
+## Problem Statement
+
+{2-3 sentences describing the problem being solved. Focus on the pain, not the solution.}
+
+### Who Has This Problem
+
+- **Primary user:** {role/persona} — {how they encounter the problem}
+- **Secondary user:** {role/persona} — {how they are affected}
+
+### Current Workarounds
+
+- {How users solve this today, and why it is insufficient}
+
+### Impact
+
+- {What happens if this problem is not solved}
+- {Quantifiable impact if available: time wasted, errors caused, revenue lost}
+
+## Proposed Solution
+
+{2-3 sentences describing the solution at a high level. What changes for the user.}
+
+### Approach
+
+{Technical approach chosen during discussion, with rationale for why this approach over alternatives.}
+
+### Alternatives Considered
+
+| Approach | Pros | Cons | Why Not |
+|----------|------|------|---------|
+| {alternative 1} | {pros} | {cons} | {reason rejected} |
+| {alternative 2} | {pros} | {cons} | {reason rejected} |
+
+## Requirements
+
+### Functional Requirements
+
+- **FR-1:** {requirement} — Priority: {must/should/could}
+- **FR-2:** {requirement} — Priority: {must/should/could}
+
+### Non-Functional Requirements
+
+- **NFR-1:** {performance, security, scalability, accessibility requirement}
+
+### User Flows
+
+#### Flow 1: {flow name}
+
+1. User {action}
+2. System {response}
+3. User {action}
+4. System {response}
+
+## Constraints
+
+- **Technical:** {tech stack limitations, existing architecture constraints}
+- **Timeline:** {deadline or time budget}
+- **Scope:** {explicit boundaries — what is NOT included}
+
+## Edge Cases
+
+- {edge case 1} — Expected behavior: {behavior}
+- {edge case 2} — Expected behavior: {behavior}
+
+## Success Metrics
+
+- {How to measure whether this solution works}
+- {Concrete, measurable criteria}
+
+## Open Questions
+
+- {Unresolved questions deferred to spec phase}
+
+## Decisions Log
+
+| # | Question | Decision | Rationale |
+|---|----------|----------|-----------|
+| 1 | {question asked during discussion} | {answer} | {why} |

package/src/workflows/close-phase.md

@@ -188,7 +188,7 @@
     Phase {phase} COMPLETE.
     MILESTONE {milestone} COMPLETE.
 
-    Run /sdlc:milestone to finalize and start next milestone.
+    Milestone completion is handled automatically by /sdlc:close.
     ```
 
   WHY: The display tells the user exactly where they are in the bigger picture. Completing a phase or milestone is a significant moment — acknowledge it.

package/src/workflows/discuss-phase.md

@@ -0,0 +1,195 @@
+<purpose>Drive AI-led brainstorming to transform a raw idea into a structured PRD. The discuss phase sits upstream of spec — it explores the problem space, validates approaches, and builds requirements through targeted questioning. Without this phase, specs are built on assumptions instead of explored decisions.</purpose>
+<when_to_use>Run when the user has an idea but has not yet defined what to build. This is pre-loop discovery — it feeds into /sdlc:spec. Can run at any point: before init, between loops, or when pivoting direction.</when_to_use>
+<required_reading>.sdlc/PROJECT.md (if exists), .sdlc/ROADMAP.md (if exists), codebase structure for technical context</required_reading>
+<loop_context>
+  expected_phase: DISCUSS (pre-loop activity)
+  prior_phase: any (entry point or between loops)
+  next_phase: SPEC (discuss always leads to spec)
+</loop_context>
+<process>
+
+<step name="seed_idea" priority="first">
+  The discussion needs a starting point — without one, questions are unfocused.
+
+  IF $ARGUMENTS provided:
+    Restate the idea in one sentence to confirm understanding.
+    Ask: "Is this what you want to explore, or should I adjust the framing?"
+
+  IF $ARGUMENTS empty:
+    Ask: "What idea, feature, or problem do you want to explore?"
+    Wait for response before proceeding.
+
+  IF .sdlc/PROJECT.md exists:
+    Read it. Note the tech stack, architecture, and constraints.
+    These inform all downstream questions — do not ask about things the project context already answers.
+
+  Record the seed idea for the decisions log.
+</step>
+
+<step name="explore_problem" priority="second">
+  Understanding the problem prevents building solutions to the wrong thing. Most failed features solve real problems badly because the problem was never properly defined.
+
+  Ask 2-4 questions from this category. Include a recommendation with each. Use AskUserQuestion.
+
+  PROBLEM QUESTIONS (pick the most relevant):
+  - "What specific problem does this solve? Who encounters it and how often?"
+    Recommendation: Frame the problem from the user's perspective, not the system's.
+  - "How do users solve this today? What makes current workarounds insufficient?"
+    Recommendation: Based on codebase scan, suggest what exists and what gaps you see.
+  - "What happens if this is not built? What is the cost of inaction?"
+    Recommendation: Assess severity based on what you know about the project.
+  - "Is this a new capability, an improvement to something existing, or a fix?"
+    Recommendation: Based on codebase, state whether related functionality already exists.
+
+  DO NOT ask questions whose answers are already in PROJECT.md or the codebase.
+  DO NOT ask questions that do not affect the technical solution.
+
+  Record all answers in the decisions log.
+</step>
+
+<step name="define_scope" priority="third">
+  Scope prevents building too much or too little. Without explicit scope, features creep and deadlines slip.
+
+  Ask 2-4 questions from this category. Include a recommendation with each.
+
+  SCOPE QUESTIONS (pick the most relevant):
+  - "What is the smallest version of this that delivers value? What is the full vision?"
+    Recommendation: Propose an MVP scope based on the problem definition.
+  - "What is explicitly NOT included? What should be deferred to later?"
+    Recommendation: Suggest boundaries based on complexity and dependencies.
+  - "Are there timeline or resource constraints that affect scope?"
+    Recommendation: If constraints exist, suggest what to cut first.
+  - "Does this interact with existing features? Which ones?"
+    Recommendation: Based on codebase scan, identify integration points.
+
+  After this round, you should be able to state the scope in one sentence.
+  Display: "Scope summary: {one sentence}. Does this match your intent?"
+
+  Record all answers in the decisions log.
+</step>
+
+<step name="validate_approach" priority="fourth">
+  Choosing the wrong approach is the most expensive mistake — it compounds through every downstream phase. Presenting options with trade-offs prevents blind commitment to the first idea.
+
+  Based on the problem and scope, identify 2-3 viable technical approaches.
+
+  Present each approach:
+  ```
+  Approach A (recommended): {description}
+  - Effort: {low/medium/high}
+  - Risk: {what could go wrong}
+  - Maintenance: {ongoing burden}
+  - Fits existing patterns: {yes/no — reference specific codebase patterns}
+
+  Approach B: {description}
+  - Effort: {low/medium/high}
+  - Risk: {what could go wrong}
+  - Maintenance: {ongoing burden}
+  - Fits existing patterns: {yes/no}
+
+  Approach C (do nothing / defer): {description}
+  - Risk of deferring: {what happens}
+  ```
+
+  Ask: "Which approach do you prefer? I recommend Approach A because {concrete reason}."
+
+  IF the user picks a non-recommended approach:
+    Acknowledge the choice. Do not argue. Record the rationale.
+
+  IF the user is unsure:
+    Ask one targeted follow-up to resolve the uncertainty.
+
+  Record the chosen approach and rationale in the decisions log.
+</step>
+
+<step name="detail_requirements" priority="fifth">
+  Requirements bridge the gap between "what to build" and "how to spec it." Missing requirements surface as bugs during implementation.
+
+  Ask 2-4 questions from this category. Include a recommendation with each.
+
+  REQUIREMENTS QUESTIONS (pick the most relevant):
+  - "Walk me through the primary user flow. What does the user do step by step?"
+    Recommendation: Propose a flow based on the chosen approach.
+  - "What are the edge cases? What happens when {unlikely but possible scenario}?"
+    Recommendation: List 2-3 edge cases you identified and propose handling.
+  - "Are there security, performance, or accessibility requirements?"
+    Recommendation: Based on project context, suggest relevant NFRs.
+  - "How will you know this works? What does success look like?"
+    Recommendation: Propose measurable success criteria.
+  - "What data does this feature need? New models, fields, or API endpoints?"
+    Recommendation: Based on codebase, suggest data model approach.
+
+  STOP ASKING SIGNAL:
+  - You can write functional requirements for the core flow.
+  - You can list at least 3 edge cases with expected behavior.
+  - You know the primary user flow end to end.
+  - Remaining unknowns are implementation details, not requirements.
+
+  IF clarity is sufficient after round 2 or 3, skip this round and proceed to compile.
+
+  Record all answers in the decisions log.
+</step>
+
+<step name="compile_prd" priority="sixth">
+  The PRD is the deliverable — it captures every decision made during discussion. Without it, the discussion is just a conversation that evaporates.
+
+  Create .sdlc/discuss/ directory if it does not exist.
+
+  Generate a topic slug from the seed idea: lowercase, hyphens, no special characters, max 40 chars.
+
+  Write .sdlc/discuss/{topic-slug}-PRD.md using the PRD template structure:
+  - Problem Statement: from explore_problem answers
+  - Proposed Solution: from validate_approach chosen approach
+  - Alternatives Considered: from validate_approach rejected approaches
+  - Requirements: from detail_requirements answers
+  - Constraints: from define_scope answers
+  - Edge Cases: from detail_requirements answers
+  - Success Metrics: from detail_requirements answers
+  - Decisions Log: every question asked and answer received, numbered
+
+  Display a compact summary of the PRD (30-50 lines):
+  - Problem (2 lines)
+  - Solution (2 lines)
+  - Requirements (numbered list)
+  - Constraints (list)
+  - Edge cases (list)
+  - Open questions (list)
+</step>
+
+<step name="approve_and_route" priority="seventh">
+  The user must approve the PRD before it feeds into spec. An unapproved PRD is just notes.
+
+  Ask: "PRD complete. Review the summary above."
+  Present options:
+  - APPROVE: Lock the PRD and proceed to /sdlc:spec
+  - REVISE: Tell me what to change (re-compile after changes)
+  - REJECT: Discard the PRD and stop
+
+  IF APPROVE:
+    Set PRD status to APPROVED.
+    Update .sdlc/STATE.md:
+    - Add history entry: "{timestamp} | discuss | Topic: {topic}. PRD saved."
+    - Set next_required_action: /sdlc:spec
+    - Add prd_path: .sdlc/discuss/{topic-slug}-PRD.md
+
+    Display:
+    ```
+    PRD approved.
+
+    Saved: .sdlc/discuss/{topic-slug}-PRD.md
+
+    The spec phase will use this PRD to create a detailed specification with
+    acceptance criteria and task dependencies.
+
+    NEXT ACTION REQUIRED: /sdlc:spec
+    Run /sdlc:spec to formalize this PRD into an implementation-ready specification.
+    ```
+
+  IF REVISE:
+    Apply changes. Re-display summary. Re-ask for approval.
+
+  IF REJECT:
+    Delete the PRD file. Display: "PRD discarded." Stop.
+</step>
+
+</process>