5-phase-workflow 1.4.3 → 1.5.0

package/src/commands/5/quick-implement.md

@@ -8,27 +8,6 @@ user-invocable: true
 
 # Quick Implement
 
-## Prerequisites Check
-
-**CRITICAL: Check for configuration before proceeding**
-
-```bash
-if [ ! -f ".claude/.5/config.json" ]; then
-  echo "❌ Configuration not found"
-  echo ""
-  echo "Please run /5:configure first to set up your project."
-  echo ""
-  echo "The configure command will:"
-  echo "  • Detect your project type and build commands"
-  echo "  • Set up ticket tracking conventions"
-  echo "  • Generate documentation (CLAUDE.md)"
-  echo "  • Create project-specific skills"
-  exit 1
-fi
-```
-
-**If config doesn't exist, STOP IMMEDIATELY. Do not proceed with the workflow.**
-
 Fast path for small, well-understood tasks (1-5 files). Skips extensive planning phases but preserves state tracking and skill-based implementation.
 
 ## ⚠️ CRITICAL SCOPE CONSTRAINT
@@ -46,27 +25,10 @@ Your job in this command:
 ✅ Report completion
 
 Your job is NOT:
-❌ Handle complex features (6+ files)
-❌ Work across multiple domains
-❌ Skip clarifying questions if unclear
-❌ Skip state file updates
-❌ Create feature spec files (use full workflow)
-❌ Commit without config - Only commit if git.autoCommit is enabled
-
-**This is a FAST PATH for well-understood, small tasks. For anything complex, use the full workflow.**
-
-## ❌ Boundaries: What This Command Does NOT Do
-
-**CRITICAL:** This command has a LIMITED scope. Do NOT:
-
-- ❌ **Use for complex features** - 6+ files or multiple domains → use full workflow
-- ❌ **Skip clarifying questions** - If implementation is unclear, ask first
-- ❌ **Skip state updates** - State file updates are MANDATORY
-- ❌ **Create feature specs** - This is for quick tasks, not full features
-- ❌ **Commit without config** - Only commit if git.autoCommit is enabled
-- ❌ **Skip plan approval** - Always show plan and get user approval first
-
-**If the task involves more than 5 files or multiple domains, STOP and recommend the full workflow instead.**
+❌ Handle complex features (6+ files or multiple domains → use full workflow)
+❌ Skip clarifying questions, state file updates, or plan approval
+❌ Create feature spec files
+❌ Commit without config (only if git.autoCommit is enabled)
 
 ## Process
 
@@ -87,16 +49,22 @@ git branch --show-current
 
 Extract ticket ID using configurable pattern from config (e.g., `PROJ-\d+` or `\d+`). If not found, ask developer.
 
-Also read `.claude/.5/config.json` and extract:
+**Sanitize the ticket ID:** Only allow alphanumeric characters, dashes (`-`), and underscores (`_`). Strip any other characters (especially `/`, `..`, `~`, spaces). If the sanitized result is empty, ask the user for a valid ticket ID.
+
+Also read `.5/config.json` and extract:
 - `git.autoCommit` (boolean, default `false`)
 - `git.commitMessage.pattern` (string, default `{ticket-id} {short-description}`)
 
 ### Step 3: Generate Identifiers
 
-```bash
-slug=$(echo "$DESCRIPTION" | tr '[:upper:]' '[:lower:]' | sed 's/[^a-z0-9]/-/g' | sed 's/--*/-/g' | sed 's/^-//;s/-$//' | cut -c1-40)
-feature_name="${TICKET_ID}-${slug}"
-```
+Generate a slug from `$DESCRIPTION` using string manipulation (do NOT use bash for this — avoid shell injection):
+1. Convert to lowercase
+2. Replace any non-alphanumeric character with a dash (`-`)
+3. Collapse consecutive dashes into one
+4. Remove leading/trailing dashes
+5. Truncate to 40 characters
+
+Set `feature_name` to `${TICKET_ID}-${slug}`.
 
 ### Step 4: Analyze and Plan
 
@@ -115,14 +83,15 @@ feature_name="${TICKET_ID}-${slug}"
 
 Write plan to `.5/features/${feature_name}/plan.md` using the template structure.
 
-**Template Reference:** Use the structure from `.claude/templates/workflow/QUICK-PLAN.md`
+**Template Reference:** Use the structure from `.claude/templates/workflow/PLAN.md`
 
 The template contains placeholders for:
+- **YAML frontmatter:** ticket, feature, created
 - **Header:** `# Quick Implementation: {TICKET-ID}`
-- **Task:** The task description
-- **Components table:** Columns for #, Type, Name, Skill, Module
-- **Affected Modules:** List of modules that will be modified
-- **Execution:** Mode (parallel, sequential, or direct)
+- **Task description:** One sentence summary
+- **Components table:** Columns for Step, Component, Action, File, Description, Complexity
+- **Implementation Notes:** Key details and patterns
+- **Verification:** Build and test commands
 
 ### Step 6: Present Plan and Iterate
 
@@ -155,29 +124,15 @@ Use AskUserQuestion:
 
 **CRITICAL**: You MUST create the state file before starting implementation. This enables resumability if work is interrupted.
 
-Create state file at `.5/features/${feature_name}/state.json` using Write tool:
-
-```json
-{
-  "ticketId": "${TICKET_ID}",
-  "featureName": "${feature_name}",
-  "phase": "quick-implementation",
-  "status": "in-progress",
-  "currentWave": 1,
-  "totalWaves": 1,
-  "completedComponents": [],
-  "pendingComponents": [/* from plan */],
-  "failedAttempts": [],
-  "verificationResults": {},
-  "startedAt": "{ISO timestamp}",
-  "lastUpdated": "{ISO timestamp}"
-}
-```
+Create state file at `.5/features/${feature_name}/state.json` with fields: `ticket`, `feature`, `phase: "quick-implementation"`, `status: "in-progress"`, `currentStep: 1`, `totalSteps: 1`, `completed: []`, `pending: [from plan]`, `failed: []`, `verificationResults: {}`, `startedAt`, `lastUpdated`.
+
+Verify the file was written correctly with Read tool. If creation fails, stop and report error.
 
-**After creating the file:**
-1. Use Read tool to verify the file was written correctly
-2. Report to user: "State tracking initialized"
-3. If file creation fails, stop and report error
+Then remove the planning guard marker (implementation is starting):
+
+```bash
+rm -f .5/.planning-active
+```
 
 ### Step 8: Execute Implementation
 
@@ -192,7 +147,7 @@ For each component:
 1. Invoke appropriate skill using Skill tool
 2. **Update state file after each component** (MANDATORY):
    - Read current state file
-   - Move component from `pendingComponents` to `completedComponents`
+   - Move component from `pending` to `completed`
    - Update `lastUpdated` timestamp
    - Write back to state file
    - Verify write succeeded
@@ -200,12 +155,17 @@ For each component:
 
 #### Step-Executor Delegation
 
+Determine the model based on the highest complexity in the plan's components:
+- All components `simple` → `haiku`
+- Any component `moderate` → `sonnet`
+- Any component `complex` → `sonnet`
+
 Spawn an agent with inline instructions:
 
 ```
 Task tool call:
   subagent_type: general-purpose
-  model: haiku
+  model: {haiku or sonnet based on complexity above}
   description: "Execute quick implementation for ${feature_name}"
   prompt: |
     Implement components for a feature by finding patterns in existing code.
@@ -242,8 +202,8 @@ Task tool call:
 
 Process results and **update state file** (MANDATORY):
 - Read current state file
-- Move completed components from `pendingComponents` to `completedComponents`
-- Record any failures in `failedAttempts`
+- Move completed components from `pending` to `completed`
+- Record any failures in `failed`
 - Update `lastUpdated` timestamp
 - Write back to state file
 - Verify write succeeded
@@ -274,76 +234,15 @@ Skill tool call:
 
 ### Step 9b: Auto-Commit (if enabled)
 
-Only fires if `git.autoCommit: true` AND build passed in Step 9.
-
-Creates a **single commit** for all components (not per-component — quick-implement is for small tasks):
-
-1. Stage **only** the specific files from the plan's components (never `git add .`)
-2. Commit using the configured `git.commitMessage.pattern`:
-   - `{ticket-id}` → ticket ID
-   - `{short-description}` → auto-generated summary (imperative mood, max 50 chars for full first line)
-   - Body: one bullet per component
-
-```bash
-# Stage only specific files
-git add {file-1} {file-2} ...
-
-# Commit with configured pattern + body
-git commit -m "{ticket-id} {short-description}
-
-- {concise change 1}
-- {concise change 2}"
-```
-
-3. If commit fails → log warning, record in `state.json`, continue
-4. If build failed in Step 9 → skip commit entirely
+Only fires if `git.autoCommit: true` AND build passed. Creates a single commit: stage only plan files (never `git add .`), commit with configured `git.commitMessage.pattern` (body: one bullet per component). If commit fails, log warning and continue.
 
 ### Step 10: Update State and Report (MANDATORY)
 
 **CRITICAL**: You MUST update the state file to mark completion.
 
-1. **Read current state file**
-2. **Update to completed status**:
-```json
-{
-  "status": "completed",
-  "phase": "completed",
-  "verificationResults": {
-    "buildStatus": "success",
-    "testStatus": "success | skipped",
-    "timestamp": "{ISO timestamp}"
-  },
-  "completedAt": "{ISO timestamp}",
-  "lastUpdated": "{ISO timestamp}"
-}
-```
-3. **Write back using Write tool**
-4. **Verify the update** by reading file again
-
-Report to user:
-
-```
-✅ Quick implementation complete!
-
-${TICKET_ID}: ${DESCRIPTION}
+Update state file to `status: "completed"`, `phase: "completed"`, with `verificationResults` (buildStatus, testStatus, timestamp), `completedAt`, `lastUpdated`. Verify the write.
 
-Components created/modified:
-- {file1}
-- {file2}
-
-Build: Success
-Tests: {Success | Skipped}
-{If git.autoCommit was true: "Commit: {Success | Failed | Skipped (build failed)}"}
-
-State: .5/features/${feature_name}/state.json
-
-Next steps:
-{If auto-commit fired successfully:}
-1. For a new task, run `/clear` before starting
-{If auto-commit not enabled or commit skipped:}
-1. Review and commit changes
-2. For a new task, run `/clear` before starting
-```
+Report: ticket, description, files created/modified, build/test status, commit status (if auto-commit), and next steps (commit if needed, `/clear` before new task).
 
 **🛑 YOUR JOB IS COMPLETE. DO NOT START NEW TASKS.**
 

package/src/commands/5/review-code.md

@@ -18,19 +18,9 @@ After saving the review report, you are DONE.
 
 # Review Code (Phase 5)
 
-## Prerequisites
-
-If the feature argument is `CONFIGURE`, skip this check.
-
-For all other features: Read `.claude/.5/config.json`. If the file does not exist, STOP immediately and tell the user:
-
-"Configuration not found. Please run `/5:configure` first to set up your project."
-
-Do NOT proceed without configuration.
-
 ## Review Tools
 
-Two review tools are supported (configured in `.claude/.5/config.json` field `reviewTool`):
+Two review tools are supported (configured in `.5/config.json` field `reviewTool`):
 
 - **Claude** (default) — Built-in, zero setup. A fresh-context agent reviews code blind.
 - **CodeRabbit** — External CLI. Requires `coderabbit` installed and authenticated.
@@ -41,7 +31,7 @@ Both produce the same structured output format.
 
 ### Step 1: Determine Review Tool
 
-Read `.claude/.5/config.json` and check the `reviewTool` field.
+Read `.5/config.json` and check the `reviewTool` field.
 
 - If not set or missing, default to `"claude"`
 - If `"none"`, inform user that automated review is disabled and STOP
@@ -237,7 +227,7 @@ If "Ask me each": Present each question individually via AskUserQuestion. If the
 
 For "Save to file" mode only.
 
-Determine feature name from `.5/features/*/state.json` (most recent) or ask user.
+Determine feature name from `.5/features/*/state.json` (most recent by `startedAt` field) or ask user.
 
 Write to `.5/features/{feature-name}/review-{YYYYMMDD-HHmmss}-findings.md`.
 
@@ -251,7 +241,7 @@ Skip to REVIEW COMPLETE.
 
 When invoked with `apply`:
 
-1. Determine feature name from `.5/features/*/state.json` or ask user
+1. Determine feature name from `.5/features/*/state.json` (most recent by `startedAt` field) or ask user
 2. Find most recent `review-*-findings.md` in the feature folder
 3. If none found, tell user to run `/5:review-code` first and STOP
 4. Parse each finding and its action marker: `[FIX]`, `[SKIP]`, `[MANUAL]`

package/src/commands/5/unlock.md

@@ -0,0 +1,23 @@
+---
+name: 5:unlock
+description: Remove the planning guard lock to allow edits outside the workflow
+allowed-tools: Bash
+context: inherit
+user-invocable: true
+---
+
+# Unlock Planning Guard
+
+Remove the `.planning-active` marker file that restricts Write/Edit operations during planning phases.
+
+## Process
+
+Run this bash command to check and remove the marker in one step:
+
+```bash
+if [ -f .5/.planning-active ]; then rm .5/.planning-active && echo "REMOVED"; else echo "ABSENT"; fi
+```
+
+Based on the output, confirm to the user:
+- If output contains "REMOVED": "Planning guard removed. You can now edit files freely."
+- If output contains "ABSENT": "No planning guard was active. You're already free to edit files."

package/src/commands/5/update.md

@@ -1,17 +1,54 @@
 ---
 name: 5:update
 description: Update the 5-Phase Workflow to the latest version
-allowed-tools: Bash
+allowed-tools: Bash, Read, AskUserQuestion
 context: inherit
 user-invocable: true
 ---
 
 # Update 5-Phase Workflow
 
-Run the upgrade command to update to the latest version:
+## Step 1: Check Current Version
+
+Read `.5/version.json` and note the current `installedVersion`.
+
+## Step 2: Run Upgrade
 
 ```bash
-npx 5-phase-workflow --upgrade
+npx 5-phase-workflow@latest --upgrade
 ```
 
-After the upgrade completes, confirm the new version was installed by checking `.claude/.5/version.json`.
+## Step 3: Confirm Upgrade
+
+Read `.5/version.json` again. Compare the new `installedVersion` to the previous one.
+
+- If the version **did not change**: tell the user they're already on the latest version. Stop here.
+- If the version **changed**: continue to Step 4.
+
+## Step 4: Show What Changed
+
+Run `git status` to show the files modified by the upgrade. Summarize the changes for the user (e.g., "Updated 12 files in `.claude/commands/5/`, `.claude/skills/`, `.claude/hooks/`").
+
+## Step 5: Ask to Commit
+
+Ask the user: "Would you like to commit the upgraded workflow files?"
+
+Options:
+1. **Yes** - commit the changes
+2. **No** - leave changes uncommitted
+
+If the user chooses **No**, stop here.
+
+## Step 6: Commit
+
+Read `.5/config.json` if it exists and extract `git.commitMessage.pattern` (default: `{ticket-id} {short-description}`).
+
+Build the commit message by applying the pattern:
+- Replace `{ticket-id}` with an empty string (no ticket for upgrades) and trim any leading/trailing whitespace
+- Replace `{short-description}` with `update 5-Phase Workflow to {new-version}`
+- If the pattern is the conventional format (`feat({ticket-id}): {short-description}`), use: `chore: update 5-Phase Workflow to {new-version}`
+- If no config or no pattern, use: `update 5-Phase Workflow to {new-version}`
+
+Stage **only** the workflow-managed files shown in `git status` (inside `.claude/commands/5/`, `.claude/skills/`, `.claude/hooks/`, `.claude/templates/`, `.claude/settings.json`, and `.5/version.json`). Never use `git add .` or `git add -A`.
+
+Create the commit. Report success to the user.

package/src/commands/5/verify-implementation.md

@@ -8,31 +8,6 @@ user-invocable: true
 
 # Verify Implementation (Phase 4)
 
-## Prerequisites Check
-
-**CRITICAL: Check for configuration before proceeding (skip for CONFIGURE feature)**
-
-If the feature argument is `CONFIGURE`, skip this check entirely — the CONFIGURE workflow is what creates the config file.
-
-For all other features, run this check:
-
-```bash
-if [ ! -f ".claude/.5/config.json" ]; then
-  echo "❌ Configuration not found"
-  echo ""
-  echo "Please run /5:configure first to set up your project."
-  echo ""
-  echo "The configure command will:"
-  echo "  • Detect your project type and build commands"
-  echo "  • Set up ticket tracking conventions"
-  echo "  • Generate documentation (CLAUDE.md)"
-  echo "  • Create project-specific skills"
-  exit 1
-fi
-```
-
-**If config doesn't exist and the feature is NOT `CONFIGURE`, STOP IMMEDIATELY. Do not proceed with the workflow.**
-
 Verify that an implementation is complete, correct, and meets feature requirements through multi-layer verification.
 
 ## Scope
@@ -74,7 +49,7 @@ Note: feature.md not found — skipping feature completeness checks.
 This is normal for quick-implement workflows. Infrastructure and quality checks will still run.
 ```
 
-Also read `.claude/.5/config.json` and extract:
+Also read `.5/config.json` and extract:
 - `git.autoCommit` (boolean, default `false`)
 - `git.commitMessage.pattern` (string, default `{ticket-id} {short-description}`)
 
@@ -95,7 +70,7 @@ For each component in the plan:
 
 #### 2b. Run Build
 
-Execute the build command from the plan (or auto-detect from `.claude/.5/config.json`):
+Execute the build command from the plan (or auto-detect from `.5/config.json`):
 
 ```bash
 {build-command}
@@ -127,7 +102,7 @@ Task tool call:
   model: sonnet
   description: "Verify feature completeness for {feature-name}"
   prompt: |
-    You are verifying that an implementation satisfies its feature specification.
+    Verify that an implementation satisfies its feature specification.
 
     ## Feature Specification
     {full text of feature.md}
@@ -136,61 +111,33 @@ Task tool call:
     {full text of plan.md}
 
     ## Instructions
-
-    1. **Read each implemented file** listed in the components table below:
-       {components table from plan.md}
-
-    2. **Check acceptance criteria** from the feature spec.
-       For each acceptance criterion, determine:
-       - SATISFIED — code clearly implements this criterion (cite file:line as evidence)
-       - NOT SATISFIED — no code found that implements this criterion
-
-    3. **Check functional requirements** from the feature spec.
-       For each requirement, determine:
-       - IMPLEMENTED — code implements this requirement (cite file:line)
-       - NOT IMPLEMENTED — no code found for this requirement
-
-    4. **Check component completeness** from the plan.
-       For each component in the table, read the file and determine:
-       - COMPLETE — file exists and implements what the description says
-       - PARTIAL — file exists but is missing described functionality
-       - MISSING — file does not exist
+    1. Read each file in the components table
+    2. For each acceptance criterion: SATISFIED (cite file:line) or NOT_SATISFIED
+    3. For each requirement: IMPLEMENTED (cite file:line) or NOT_IMPLEMENTED
+    4. For each component: COMPLETE, PARTIAL (note what's missing), or MISSING
 
     ## Output Format
-    Return EXACTLY this structure:
-
-    ACCEPTANCE_CRITERIA:
-    - criterion: "{text of criterion}"
-      status: SATISFIED | NOT SATISFIED
-      evidence: "{file:line}" or "none"
-      notes: "{brief explanation}"
-
-    REQUIREMENTS:
-    - requirement: "{text of requirement}"
-      status: IMPLEMENTED | NOT IMPLEMENTED
-      evidence: "{file:line}" or "none"
-      notes: "{brief explanation}"
-
-    COMPONENTS:
-    - component: "{component name}"
-      file: "{file path}"
-      status: COMPLETE | PARTIAL | MISSING
-      notes: "{what's missing if partial}"
-
-    SUMMARY:
-    - criteria_satisfied: {N}/{M}
-    - requirements_implemented: {N}/{M}
-    - components_complete: {N}/{M}
-
-    ## Rules
-    - Read every file referenced in the components table
-    - Be precise with evidence — cite actual file paths and line numbers
-    - PARTIAL means the file exists but is missing specific functionality described in the plan
-    - Do NOT interact with the user
-    - Do NOT modify any files
+    End with a results block:
+
+    ---VERIFICATION---
+    ---ACCEPTANCE_CRITERIA---
+    {SATISFIED | NOT_SATISFIED | criterion text | file:line or "none"} (one per line)
+    ---REQUIREMENTS---
+    {IMPLEMENTED | NOT_IMPLEMENTED | requirement text | file:line or "none"} (one per line)
+    ---COMPONENTS---
+    {COMPLETE | PARTIAL | MISSING | component name | file path | notes} (one per line)
+    ---SUMMARY---
+    criteria_satisfied: {N}/{M}
+    requirements_implemented: {N}/{M}
+    components_complete: {N}/{M}
+    ---END_VERIFICATION---
+
+    Rules: Read every file. Cite file:line evidence. Do NOT modify files or interact with user.
 ```
 
-Parse the agent's structured output into:
+Parse the `---VERIFICATION---` ... `---END_VERIFICATION---` block. If malformed, fall back to extracting summary counts from prose.
+
+From the parsed output, collect:
 - Acceptance criteria results (satisfied/not satisfied counts)
 - Requirements results (implemented/not implemented counts)
 - Component completeness results (complete/partial/missing counts)
@@ -254,53 +201,10 @@ Update `.5/features/{feature-name}/state.json`:
 
 ### Step 8: Handle Results
 
-**If PASSED:**
-
-```
-Verification passed!
-
-Layer 1 (Infrastructure): All files exist, build OK, tests OK
-Layer 2 (Feature Completeness): {N}/{N} criteria satisfied, {N}/{N} requirements implemented
-Layer 3 (Quality): {N}/{N} new files have tests
-
-Report: .5/{feature-name}/verification.md
-```
+Report the status with layer-by-layer summary and link to `verification.md`.
 
-**If `git.autoCommit: false` (default):** offer to commit.
-
-```
-Would you like to commit these changes?
-```
-
-Use AskUserQuestion with options:
-1. "Yes - commit now (Recommended)"
-2. "No - I'll commit later"
-
-If yes: stage and commit with message format `{TICKET-ID} {description}`.
-
-**If `git.autoCommit: true`:** skip the commit offer.
-
-```
-Changes were already committed during implementation ({N} atomic commits).
-```
-
-Then go to Step 11 (Next Steps).
-
-**If PARTIAL or FAILED:**
-
-```
-Verification {status}.
-
-Layer 1 (Infrastructure): {summary}
-Layer 2 (Feature Completeness): {summary}
-Layer 3 (Quality): {summary}
-
-{Count} issue(s) found. Generating fix plan...
-
-Report: .5/{feature-name}/verification.md
-```
-
-Continue to Step 9.
+- **PASSED:** If `git.autoCommit: false`, offer to commit via AskUserQuestion. If `git.autoCommit: true`, note commits were already made. Go to Step 11.
+- **PARTIAL or FAILED:** Note issue count, continue to Step 9.
 
 ### Step 9: Generate Fix Plan (PARTIAL or FAILED only)
 
@@ -337,86 +241,15 @@ Use AskUserQuestion:
 
 **If user selects "Apply fixes automatically":**
 
-For each fix in the fix plan, spawn an agent following the same pattern as `implement-feature`:
-
-- **simple** fixes → `haiku` model
-- **moderate** fixes → `haiku` or `sonnet` depending on context
-- **complex** fixes → `sonnet` model
-
-Group independent fixes for parallel execution. Fixes modifying the same file must be sequential.
-
-```
-Task tool call:
-  subagent_type: general-purpose
-  model: {based on complexity}
-  description: "Fix: {short description}"
-  prompt: |
-    You are fixing a verification issue in a codebase.
-
-    ## Issue
-    Category: {infrastructure | feature-gap | quality}
-    File: {file-path}
-    Issue: {description of what's wrong}
-    Fix: {description of what to do}
-
-    ## Context
-    {relevant section from plan.md or feature.md}
-
-    ## Instructions
-    1. If creating a new file: find a similar existing file using Glob, read it to understand the pattern, create the new file following that pattern
-    2. If modifying a file: read the file, make the described change
-    3. Verify the file exists after changes
-    4. Report what you did
-
-    Use Glob to find similar files. Use Read to understand patterns. Use Write/Edit to create/modify files.
-```
-
-After all fixes are applied, re-run build and tests:
-
-```bash
-{build-command}
-{test-command}
-```
-
-**If `git.autoCommit: true` and fixes succeeded (build + tests pass):**
+Spawn agents following `implement-feature` patterns (simple→haiku, moderate→haiku/sonnet, complex→sonnet). Group independent fixes for parallel execution; same-file fixes must be sequential.
 
-Auto-commit the fix files:
-```bash
-# Stage only the specific fix files
-git add {fix-file-1} {fix-file-2} ...
+Each agent prompt includes: category, file path, issue description, fix description, and relevant context from plan/feature spec. Agent finds similar files via Glob, reads patterns, applies fix with Write/Edit.
 
-# Commit with ticket ID
-git commit -m "{ticket-id} fix verification issues
+After fixes: re-run build and tests. If `git.autoCommit: true` and fixes succeeded, commit fix files with `{ticket-id} fix verification issues`. Update `fix-plan.md` with APPLIED/FAILED status per fix.
 
-- {concise fix 1}
-- {concise fix 2}"
-```
-
-If commit fails → log warning, continue.
+**If user selects manual fix:** save `fix-plan.md` and exit with re-run guidance.
 
-Update `fix-plan.md` with results:
-- Mark each fix as APPLIED / FAILED
-- Record build and test results after fixes
-
-Report to user:
-```
-Applied {N} fixes.
-
-Build: {status}
-Tests: {status}
-{If git.autoCommit was true: "Commit: {Success | Failed | Skipped}"}
-
-{If any fixes failed, list them}
-
-Updated: .5/{feature-name}/fix-plan.md
-```
-
-**If user selects manual fix:** exit with guidance.
-```
-Fix plan saved: .5/{feature-name}/fix-plan.md
-
-When ready, re-run: /5:verify-implementation {feature-name}
-```
+**Iteration limit:** On 3rd+ verify+fix cycle, warn user to consider manual fixes or revisiting the plan.
 
 ### Step 11: Next Steps