@leeovery/claude-technical-workflows 2.0.47 → 2.0.49

package/skills/technical-planning/references/planning-principles.md

@@ -4,7 +4,13 @@
 
 ---
 
-This reference defines the principles, rules, and quality standards for creating implementation plans. It is loaded at the start of the planning process and stays in context throughout.
+These are the principles, rules, and quality standards that govern the planning process.
+
+## Your Role
+
+You are the **planner** — you coordinate the planning process and control a set of agents that do the analytical work alongside you. You invoke agents (for phase design, task design, and task authoring), present their output to the user, handle approval gates, and manage the Plan Index File.
+
+Analysis principles (`phase-design.md`, `task-design.md`) are loaded by the agents, not by you. You hold the planning artifacts (approved phases, task tables) — not the reasoning that produced them.
 
 ## Planning is a Gated Process
 
@@ -12,9 +18,35 @@ Planning translates the specification into actionable structure. This translatio
 
 ### Process Expectations
 
-**This is a step-by-step process with mandatory stop points.** You must work through each step sequentially. Steps end with **STOP** — you must present your work, wait for explicit user confirmation, and only then proceed to the next step.
+**This is a step-by-step process with mandatory stop points.** You must work through each step sequentially. Steps end with **STOP** — you must present your work, wait for explicit user approval, and only then proceed to the next step.
+
+**Never one-shot the plan.** Do not write the entire Plan Index File in a single operation. The plan is built incrementally — one phase at a time, with the user confirming the structure at each stage. A one-shot plan that misses requirements, hallucinates content, or structures tasks poorly wastes more time than a careful, step-by-step process. Go slow to go fast.
+
+### Explicit Approval Required
+
+At every stop point — phases, task lists, individual tasks, dependencies — the user must explicitly approve before you proceed or log content.
+
+**What counts as approval:** `y`/`yes` or equivalent explicit confirmation: "Approved", "That's good", "Looks right".
+
+**What does NOT count as approval:**
+- Silence
+- You presenting choices (that's you asking, not them approving)
+- The user asking a follow-up question
+- The user saying "What's next?" or "Continue"
+- The user making a comment or observation without explicit approval
+- ANY response that isn't explicit confirmation
+
+**If you are uncertain whether the user approved, ASK:** "Ready to proceed, or do you want to change something?"
+
+#### Self-Check Before Logging
+
+Before logging any task to the plan, ask yourself:
+
+1. **Did I present this specific content to the user?** If no → STOP. Present it first.
+2. **Did the user explicitly approve it?** If no → STOP. Wait for approval.
+3. **Am I writing exactly what was approved?** If adding or changing anything → STOP. Present the changes first.
 
-**Never one-shot the plan.** Do not write the entire plan document in a single operation. The plan is built incrementally — one phase at a time, with the user confirming the structure at each stage. A one-shot plan that misses requirements, hallucinates content, or structures tasks poorly wastes more time than a careful, step-by-step process. Go slow to go fast.
+### Collaboration and Judgment
 
 **Stop and ask when judgment is needed.** Planning is collaborative — not in the sense that every line needs approval, but in the sense that the user guides structural decisions and resolves ambiguity. You must stop and ask when:
 

package/skills/technical-planning/references/read-specification.md

@@ -0,0 +1,47 @@
+# Read Specification
+
+*Reference for **[technical-planning](../SKILL.md)***
+
+---
+
+This reference defines how planning agents must read the specification. It is passed to every agent alongside the specification path.
+
+**This is a full-ingestion protocol, not a summarisation guide.**
+
+---
+
+## Read the Entire Specification
+
+Read the specification file from top to bottom. Every section, every decision, every edge case, every constraint. If the file is large, read it in sequential chunks until you have consumed the entire document. Do not stop early. Do not skim.
+
+The specification is a verbatim, user-approved artifact. Every detail was explicitly agreed — treat nothing as filler or boilerplate.
+
+---
+
+## What to Absorb
+
+As you read, internalise:
+
+- **Decisions and rationale** — what was decided and why
+- **Architectural choices** — patterns, technologies, structures chosen
+- **Edge cases** — boundary conditions, unusual inputs, failure modes
+- **Acceptance boundaries** — what constitutes "done" for each requirement
+- **Constraints** — performance, compatibility, regulatory, or scope limits
+- **Dependencies** — what this feature needs from other systems or topics
+
+---
+
+## Cross-Cutting Specifications
+
+If cross-cutting specification paths are provided, read each one in full using the same protocol. Cross-cutting specs contain architectural decisions (caching, rate limiting, error handling) that influence how features are built — they inform implementation approach without adding scope.
+
+Note where cross-cutting decisions apply to the work you are designing.
+
+---
+
+## What NOT to Do
+
+- **Do not summarise** — your job is to use the spec directly, not to create a derivative
+- **Do not skip sections** — even sections that seem irrelevant may contain constraints or edge cases that affect your work
+- **Do not reinterpret decisions** — the spec contains validated decisions; translate them into plan structure, don't second-guess them
+- **Do not reference other source material** — the specification is the sole input; it already incorporates prior research and discussion

package/skills/technical-planning/references/spec-change-detection.md

@@ -0,0 +1,35 @@
+# Spec Change Detection
+
+*Reference for **[technical-planning](../SKILL.md)***
+
+---
+
+When resuming planning, check whether the specification or cross-cutting specifications have changed since planning started.
+
+The Plan Index File stores `spec_commit` — the git commit hash captured when planning began. This allows diffing any input file against that point in time.
+
+## Detection
+
+Run a git diff against the stored commit for all input files:
+
+```bash
+git diff {spec_commit} -- {specification-path} {cross-cutting-spec-paths...}
+```
+
+Also check for new cross-cutting specification files that didn't exist at that commit.
+
+## Reporting
+
+**If no changes detected:**
+
+> "Specification unchanged since planning started."
+
+**If changes detected:**
+
+Summarise the extent of changes:
+
+- **What files changed** (specification, cross-cutting specs, or both)
+- **Whether any cross-cutting specs are new** (didn't exist at the stored commit)
+- **Nature of changes** — formatting/cosmetic, minor additions/removals, or substantial restructuring
+
+Return the summary for use in the resume prompt.

package/skills/technical-planning/references/steps/author-tasks.md

@@ -4,60 +4,63 @@
 
 ---
 
-Load **[task-design.md](../task-design.md)** — the task design principles, template structure, and quality standards for writing task detail.
+This step uses the `planning-task-author` agent (`.claude/agents/planning-task-author.md`) to write full detail for a single task. You invoke the agent, present its output, and handle the approval gate.
 
 ---
 
-Orient the user:
+## Author the Task
 
-> "Task list for Phase {N} is agreed. I'll work through each task one at a time — presenting the full detail, discussing if needed, and logging it to the plan once approved."
+### Invoke the Agent
 
-Work through the agreed task list **one task at a time**.
+Invoke `planning-task-author` with these file paths:
 
-#### Present
+1. **read-specification.md**: `.claude/skills/technical-planning/references/read-specification.md`
+2. **Specification**: path from the Plan Index File's `specification:` field
+3. **Cross-cutting specs**: paths from the Plan Index File's `cross_cutting_specs:` field (if any)
+4. **task-design.md**: `.claude/skills/technical-planning/references/task-design.md`
+5. **All approved phases**: the complete phase structure from the Plan Index File body
+6. **Task list for current phase**: the approved task table
+7. **Target task**: the task name, edge cases, and ID from the table
+8. **Output format adapter**: path to the loaded output format adapter
 
-Write the complete task using the task template — Problem, Solution, Outcome, Do, Acceptance Criteria, Tests, Context.
+### Present the Output
 
-Present it to the user **in the format it will be written to the plan**. The output format adapter determines the exact format. What the user sees is what gets logged — no changes between approval and writing.
+The agent returns complete task detail in the output format's structure. Present it to the user **exactly as it will be written** — what the user sees is what gets logged.
 
 After presenting, ask:
 
 > **Task {M} of {total}: {Task Name}**
 >
-> **To proceed, choose one:**
-> - **"Approve"** — Task is confirmed. I'll log it to the plan verbatim.
-> - **"Adjust"** — Tell me what to change.
+> **To proceed:**
+> - **`y`/`yes`** — Approved. I'll log it to the plan.
+> - **Or tell me what to change.**
+> - **Or navigate** — a different phase or task, or the leading edge.
 
 **STOP.** Wait for the user's response.
 
-#### If adjust
+#### If the user provides feedback
 
-The user may:
-- Request changes to the task content
-- Ask questions about scope, granularity, or approach
-- Flag that something doesn't match the specification
-- Identify missing edge cases or acceptance criteria
+Re-invoke `planning-task-author` with all original inputs PLUS:
+- **Previous output**: the current task detail
+- **User feedback**: what the user wants changed
 
-Incorporate feedback and re-present the updated task **in full**. Then ask the same choice again. Repeat until approved.
+Present the revised task in full. Ask the same choice again. Repeat until approved.
 
-#### If approved
+#### If the user navigates
 
-Log the task to the plan — verbatim, as presented. Do not modify content between approval and writing. The output format adapter determines how tasks are written (appending markdown, creating issues, etc.).
+→ Return to **Plan Construction**.
 
-After logging, confirm:
+#### If approved (`y`/`yes`)
 
-> "Task {M} of {total}: {Task Name} — logged."
+> **CHECKPOINT**: Before logging, verify: (1) You presented this exact content, (2) The user explicitly approved with `y`/`yes` or equivalent — not a question, comment, or "okay" in passing, (3) You are writing exactly what was approved with no modifications.
 
-#### Next task or phase complete
+1. Write the task to the output format (format-specific — see output adapter)
+2. Update the task table in the Plan Index File: set `status: authored`
+3. Advance the `planning:` block in frontmatter to the next pending task (or next phase if this was the last task)
+4. Commit: `planning({topic}): author task {task-id} ({task name})`
 
-**If tasks remain in this phase:** → Return to the top of **Step 6** with the next task. Present it, ask, wait.
+Confirm:
 
-**If all tasks in this phase are logged:**
+> "Task {M} of {total}: {Task Name} — authored."
 
-```
-Phase {N}: {Phase Name} — complete ({M} tasks logged).
-```
-
-→ Return to **Step 5** for the next phase.
-
-**If all phases are complete:** → Proceed to **Step 7**.
+→ Return to **Plan Construction**.

package/skills/technical-planning/references/steps/define-phases.md

@@ -4,37 +4,79 @@
 
 ---
 
-Load **[phase-design.md](../phase-design.md)** — the principles for structuring phases as independently valuable, testable increments built on a walking skeleton.
+This step uses the `planning-phase-designer` agent (`.claude/agents/planning-phase-designer.md`) to define or review the phase structure. Whether phases are being designed for the first time or reviewed from a previous session, the process converges on the same approval gate.
 
 ---
 
+## Determine Phase State
+
+Read the Plan Index File. Check if phases already exist in the body.
+
+#### If phases exist
+
 Orient the user:
 
-> "I've read the full specification. I'm going to propose a phase structure — how we break this into independently testable stages. Once we agree on the phases, we'll take each one and break it into tasks."
+> "Phase structure already exists. I'll present it for your review."
 
-With the full specification understood, break it into logical phases. Understanding what tasks belong in each phase is necessary to determine the right ordering.
+Continue to **Review and Approve** below.
 
-Present the proposed phase structure using this format:
+#### If no phases exist
 
+Orient the user:
+
+> "I'll delegate phase design to a specialist agent. It will read the full specification and propose a phase structure — how we break this into independently testable stages."
+
+### Invoke the Agent
+
+Invoke `planning-phase-designer` with these file paths:
+
+1. **read-specification.md**: `.claude/skills/technical-planning/references/read-specification.md`
+2. **Specification**: path from the Plan Index File's `specification:` field
+3. **Cross-cutting specs**: paths from the Plan Index File's `cross_cutting_specs:` field (if any)
+4. **phase-design.md**: `.claude/skills/technical-planning/references/phase-design.md`
+5. **task-design.md**: `.claude/skills/technical-planning/references/task-design.md`
+
+The agent returns a complete phase structure. Write it directly to the Plan Index File body.
+
+Update the frontmatter `planning:` block:
+```yaml
+planning:
+  phase: 1
+  task: ~
 ```
-Phase {N}: {Phase Name}
-  Goal: {What this phase accomplishes}
-  Why this order: {Why this phase comes at this position in the sequence}
-  Acceptance criteria:
-    - [ ] {First verifiable criterion}
-    - [ ] {Second verifiable criterion}
-```
 
-**STOP.** Present your proposed phase structure and ask:
+Commit: `planning({topic}): draft phase structure`
+
+Continue to **Review and Approve** below.
+
+---
+
+## Review and Approve
+
+Present the phase structure to the user.
+
+**STOP.** Ask:
+
+> **Phase Structure**
+>
+> **To proceed:**
+> - **`y`/`yes`** — Approved. I'll proceed to task breakdown.
+> - **Or tell me what to change** — reorder, split, merge, add, edit, or remove phases.
+> - **Or navigate** — a different phase or task, or the leading edge.
+
+#### If the user provides feedback
+
+Re-invoke `planning-phase-designer` with all original inputs PLUS:
+- **Previous output**: the current phase structure
+- **User feedback**: what the user wants changed
 
-> **To proceed, choose one:**
-> - **"Approve"** — Phase structure is confirmed. I'll proceed to task breakdown.
-> - **"Adjust"** — Tell me what to change: reorder, split, merge, add, or remove phases.
+Update the Plan Index File with the revised output, re-present, and ask again. Repeat until approved.
 
-#### If Adjust
+#### If approved
 
-Incorporate feedback, re-present the updated phase structure, and ask again. Repeat until approved.
+**If the phase structure is new or was amended:**
 
-#### If Approved
+1. Update each phase in the Plan Index File: set `status: approved` and `approved_at: YYYY-MM-DD` (use today's actual date)
+2. Commit: `planning({topic}): approve phase structure`
 
-→ Proceed to **Step 5**.
+**If the phase structure was already approved and unchanged:** No updates needed.

package/skills/technical-planning/references/steps/define-tasks.md

@@ -4,40 +4,64 @@
 
 ---
 
-Load **[task-design.md](../task-design.md)** — the principles for breaking phases into well-scoped, vertically-sliced tasks.
+This step uses the `planning-task-designer` agent (`.claude/agents/planning-task-designer.md`) to design a task list for a single phase. You invoke the agent, present its output, and handle the approval gate.
 
 ---
 
+## Design the Task List
+
 Orient the user:
 
-> "Taking Phase {N}: {Phase Name} and breaking it into tasks. Here's the overview — once we agree on the list, I'll write each task out in full detail."
+> "Taking Phase {N}: {Phase Name} and breaking it into tasks. I'll delegate this to a specialist agent that will read the full specification and propose a task list."
 
-Take the first (or next) phase and break it into tasks. Present a high-level overview so the user can see the shape of the phase before committing to the detail of each task.
+### Invoke the Agent
 
-Present the task overview using this format:
+Invoke `planning-task-designer` with these file paths:
 
-```
-Phase {N}: {Phase Name}
+1. **read-specification.md**: `.claude/skills/technical-planning/references/read-specification.md`
+2. **Specification**: path from the Plan Index File's `specification:` field
+3. **Cross-cutting specs**: paths from the Plan Index File's `cross_cutting_specs:` field (if any)
+4. **task-design.md**: `.claude/skills/technical-planning/references/task-design.md`
+5. **All approved phases**: the complete phase structure from the Plan Index File body
+6. **Target phase number**: the phase being broken into tasks
 
-  1. {Task Name} — {One-line summary}
-     Edge cases: {comma-separated list, or "none"}
+### Present the Output
 
-  2. {Task Name} — {One-line summary}
-     Edge cases: {comma-separated list, or "none"}
+The agent returns a task overview and task table. Write the task table directly to the Plan Index File under the phase.
+
+Update the frontmatter `planning:` block:
+```yaml
+planning:
+  phase: {N}
+  task: ~
 ```
 
-This overview establishes the scope and ordering. The user should be able to see whether the phase is well-structured, whether tasks are in the right order, and whether anything is missing or unnecessary — before investing time in writing out full task detail.
+Commit: `planning({topic}): draft Phase {N} task list`
+
+Present the task overview to the user.
+
+**STOP.** Ask:
+
+> **To proceed:**
+> - **`y`/`yes`** — Approved.
+> - **Or tell me what to change** — reorder, split, merge, add, edit, or remove tasks.
+> - **Or navigate** — a different phase or task, or the leading edge.
+
+#### If the user provides feedback
+
+Re-invoke `planning-task-designer` with all original inputs PLUS:
+- **Previous output**: the current task list
+- **User feedback**: what the user wants changed
 
-**STOP.** Present the phase task overview and ask:
+Update the Plan Index File with the revised task table, re-present, and ask again. Repeat until approved.
 
-> **To proceed, choose one:**
-> - **"Approve"** — Task list is confirmed. I'll begin writing full task detail.
-> - **"Adjust"** — Tell me what to change: reorder, split, merge, add, or remove tasks.
+#### If approved
 
-#### If Adjust
+**If the task list is new or was amended:**
 
-Incorporate feedback, re-present the updated task overview, and ask again. Repeat until approved.
+1. Advance the `planning:` block to the first task in this phase
+2. Commit: `planning({topic}): approve Phase {N} task list`
 
-#### If Approved
+**If the task list was already approved and unchanged:** No updates needed.
 
-→ Proceed to **Step 6**.
+→ Return to **Plan Construction**.

package/skills/technical-planning/references/steps/plan-construction.md

@@ -0,0 +1,131 @@
+# Plan Construction
+
+*Reference for **[technical-planning](../../SKILL.md)***
+
+---
+
+This step constructs the complete plan — defining phases, designing task lists, and authoring every task. It operates as a nested structure:
+
+    ┌─────────────────────────────────────────────────────┐
+    │                                                     │
+    │  Phase Structure — define or review all phases      │
+    │                                                     │
+    │  ┌─────────────────────────────────────────────┐    │
+    │  │  For each phase:                            │    │
+    │  │                                             │    │
+    │  │    Step A → Define tasks for the phase      │    │
+    │  │                                             │    │
+    │  │      ┌─────────────────────────────────┐    │    │
+    │  │      │  For each task in the phase:    │    │    │
+    │  │      │                                 │    │    │
+    │  │      │    Step B → Author the task     │    │    │
+    │  │      └─────────────────────────────────┘    │    │
+    │  │                                             │    │
+    │  └─────────────────────────────────────────────┘    │
+    │                                                     │
+    └─────────────────────────────────────────────────────┘
+
+---
+
+## Navigation
+
+At any approval gate during plan construction, the user can navigate. They may describe where they want to go in their own words — a specific phase, a specific task, "the beginning", "the leading edge", or any point in the plan.
+
+The **leading edge** is where new work begins — the first phase, task list, or task that hasn't been completed yet. It is tracked by the `planning:` block in the Plan Index File frontmatter (`phase` and `task`). To find the leading edge, read those values. If all phases and tasks are complete, the leading edge is the end of plan construction.
+
+The `planning:` block always tracks the leading edge. It is only advanced when work is completed — never when the user navigates. Navigation moves the user's position, not the leading edge.
+
+Navigation stays within plan construction. It cannot skip past the end of this step.
+
+---
+
+## Phase Structure
+
+Load **[define-phases.md](define-phases.md)** and follow its instructions as written.
+
+After the phase structure is approved, continue to **Process Phases** below.
+
+---
+
+## Process Phases
+
+Work through each phase in order.
+
+Orient the user:
+
+> "I'll now work through each phase — presenting existing work for review and designing or authoring anything still pending. You'll approve at every stage."
+
+### For each phase, check its state:
+
+#### If the phase has no task table
+
+This phase needs task design.
+
+→ Go to **Step A** with this phase.
+
+After Step A returns with an approved task table, continue to **Author Tasks for the Phase** below.
+
+#### If the phase has a task table
+
+Present the task list to the user for review.
+
+> **Phase {N}: {Phase Name}** — {M} tasks.
+>
+> **To proceed:**
+> - **`y`/`yes`** — Confirmed.
+> - **Or tell me what to change.**
+> - **Or navigate** — a different phase or task, or the leading edge.
+
+**STOP.** Wait for the user's response.
+
+**If the user wants changes:** → Go to **Step A** with this phase for revision.
+
+**If confirmed:** Continue to **Author Tasks for the Phase** below.
+
+---
+
+## Author Tasks for the Phase
+
+Work through each task in the phase's task table, in order.
+
+#### If the task status is `authored`
+
+Already written. Present a brief summary:
+
+> "Task {M} of {total}: {Task Name} — already authored."
+
+Continue to the next task.
+
+#### If the task status is `pending`
+
+→ Go to **Step B** with this task.
+
+After Step B returns, the task is authored. Continue to the next task.
+
+#### When all tasks in the phase are authored
+
+Advance the `planning:` block in frontmatter to the next phase. Commit: `planning({topic}): complete Phase {N} tasks`
+
+> Phase {N}: {Phase Name} — complete ({M} tasks authored).
+
+Continue to the next phase.
+
+---
+
+## Loop Complete
+
+When all phases have all tasks authored:
+
+> "All phases are complete. The plan has **{N} phases** with **{M} tasks** total."
+
+---
+
+## Step A: Define Tasks
+
+Load **[define-tasks.md](define-tasks.md)** and follow its instructions as written. This step designs and approves a task list for **one phase**.
+
+---
+
+## Step B: Author Tasks
+
+Load **[author-tasks.md](author-tasks.md)** and follow its instructions as written. This step authors **one task** and returns.

package/skills/technical-planning/references/steps/plan-review.md

@@ -12,7 +12,7 @@ After completing the plan, perform a comprehensive two-part review before handin
 
 To ensure analysis isn't lost during context refresh, create tracking files that capture findings. These files persist analysis so work can continue across sessions.
 
-**Location**: Store tracking files alongside the plan file:
+**Location**: Store tracking files alongside the Plan Index File:
 - `{topic}-review-traceability-tracking.md` — Traceability findings
 - `{topic}-review-integrity-tracking.md` — Integrity findings
 
@@ -20,7 +20,7 @@ To ensure analysis isn't lost during context refresh, create tracking files that
 ```markdown
 ---
 status: in-progress | complete
-created: YYYY-MM-DD
+created: YYYY-MM-DD  # Use today's actual date
 phase: Traceability Review | Plan Integrity Review
 topic: [Topic Name]
 ---
@@ -92,5 +92,3 @@ After both reviews:
 > Review is complete."
 
 > **CHECKPOINT**: Do not confirm completion if tracking files still exist. They indicate incomplete review work.
-
-→ Proceed to **Step 9**.

package/skills/technical-planning/references/steps/resolve-dependencies.md

@@ -43,14 +43,12 @@ Skip the resolution and reverse check — there is nothing to resolve against. D
 
 **STOP.** Present a summary of the dependency state: what was documented, what was resolved, what remains unresolved, and any reverse resolutions made.
 
-> **To proceed, choose one:**
-> - **"Approve"** — Dependency state is confirmed. Proceed to plan review.
-> - **"Adjust"** — Tell me what to change.
+> **To proceed:**
+> - **`y`/`yes`** — Approved. I'll proceed to plan review.
+> - **Or tell me what to change.**
 
-#### If Adjust
+#### If the user provides feedback
 
 Incorporate feedback, re-present the updated dependency state, and ask again. Repeat until approved.
 
-#### If Approved
-
-→ Proceed to **Step 8**.
+#### If approved

package/skills/technical-planning/references/steps/review-integrity.md

@@ -172,14 +172,14 @@ After presenting the finding and proposed fix, ask:
 
 > **Finding {N} of {total}: {Brief Title}**
 >
-> **To proceed, choose one:**
-> - **"Approve"** — Fix is confirmed. I'll apply it to the plan verbatim.
-> - **"Adjust"** — Tell me what to change about the proposed fix.
-> - **"Skip"** — Leave this as-is and move to the next finding.
+> **To proceed:**
+> - **`y`/`yes`** — Approved. I'll apply it to the plan verbatim.
+> - **`skip`** — Leave this as-is and move to the next finding.
+> - **Or tell me what to change.**
 
 **STOP.** Wait for the user's response.
 
-### If Adjust
+### If the user provides feedback
 
 The user may:
 - Request changes to the proposed fix

package/skills/technical-planning/references/steps/review-traceability.md

@@ -149,14 +149,14 @@ After presenting the finding and proposed fix, ask:
 
 > **Finding {N} of {total}: {Brief Title}**
 >
-> **To proceed, choose one:**
-> - **"Approve"** — Fix is confirmed. I'll apply it to the plan verbatim.
-> - **"Adjust"** — Tell me what to change about the proposed fix.
-> - **"Skip"** — Leave this as-is and move to the next finding.
+> **To proceed:**
+> - **`y`/`yes`** — Approved. I'll apply it to the plan verbatim.
+> - **`skip`** — Leave this as-is and move to the next finding.
+> - **Or tell me what to change.**
 
 **STOP.** Wait for the user's response.
 
-### If Adjust
+### If the user provides feedback
 
 The user may:
 - Request changes to the proposed fix