prizmkit 1.1.7 → 1.1.9

package/bundled/skills/bug-planner/assets/bug-confirmation-template.md

@@ -0,0 +1,43 @@
+# Bug Confirmation Templates
+
+## Per-Bug Confirmation Template
+
+Present this after extracting and clarifying each bug:
+
+```
+┌─ Bug Confirmation: B-NNN ─────────────────────────────
+│ Title:       <auto-suggested title>
+│ Description: <expected vs actual behavior>
+│ Severity:    <auto-classified> | Verification: <type>
+│
+│ Reproduction: <steps if available, or "not provided">
+│ Affected:     <module/feature or "unknown">
+│
+│ Acceptance Criteria (fix verified when):
+│   1. <criterion — specific enough for automated pipeline to verify>
+│   2. <criterion>
+│
+│ Open Questions:
+│   - <any unclear points, or "None">
+└────────────────────────────────────────────────────────
+```
+
+Then ask three confirmation questions:
+1. "描述是否准确？是否需要修改？" / "Is the description accurate? Any corrections?"
+2. "是否需要补充更多细节？（复现步骤、环境信息、相关代码位置等）" / "Need to add more details? (reproduction steps, environment, related code locations, etc.)"
+3. "验证条件是否具体到 pipeline 可以自主判断修复成功？" / "Are the acceptance criteria specific enough that the pipeline can autonomously verify the fix?"
+
+Only finalize the bug entry after user confirms all three points.
+
+## Completeness Review Template
+
+Display during Phase 4 pre-generation review:
+
+```
+┌─ Completeness Review ─────────────────────────────────────────────────
+│ Bug    │ Description │ Criteria   │ Reproducible │ Notes
+│ B-001  │ ✓ Clear     │ ✓ Specific │ ✓ Yes        │ —
+│ B-002  │ ⚠ Vague     │ ⚠ Subjective│ ✓ Yes       │ "encoding works" → needs specific test case
+│ B-003  │ ✓ Clear     │ ⚠ No metric│ ⚠ No steps  │ needs perf threshold + reproduction steps
+└────────────────────────────────────────────────────────────────────────
+```

package/bundled/skills/bug-planner/references/critic-and-verification.md

@@ -0,0 +1,44 @@
+# Adversarial Critic Review & Browser Verification
+
+## Adversarial Critic Review (Testing Defaults)
+
+All bug fixes support optional critic review for additional quality assurance. The critic mechanism is disabled by default but can be enabled per-bug based on severity and complexity.
+
+### Default Critic Behavior
+
+| Severity | `critic` | `critic_count` | Rationale |
+|----------|----------|----------------|-----------|
+| critical | `true` | `1` | Single critic review for critical bugs |
+| high | `true` | `1` | Single critic review for high-severity bugs |
+| medium | `false` | (omitted) | Skip critic for medium-severity bugs |
+| low | `false` | (omitted) | Skip critic for low-severity bugs |
+
+- `critic: true` — Enable adversarial review after fix implementation
+- `critic_count: 1` — Single critic agent reviews the fix
+- Critic verifies: fix addresses root cause, no regressions introduced, acceptance criteria met
+
+**User Override**: During Phase 2 or Phase 3, users can opt to enable/disable critic on a per-bug basis.
+
+## Browser Verification
+
+**Browser verification is a feature-pipeline capability only.** Bug fixes use the `verification_type` field instead:
+
+- `verification_type: automated` — Use unit/integration tests to verify the fix
+- `verification_type: manual` — Describe manual testing steps in acceptance criteria (including any browser verification steps)
+- `verification_type: hybrid` — Combine automated tests with manual browser verification steps
+
+For UI-related bugs that require visual verification (e.g., "Button doesn't show error message"), describe the verification steps in acceptance criteria.
+
+### Example
+
+```
+Bug Title: Login error message not displaying
+Verification Type: manual
+Acceptance Criteria:
+  1. Navigate to /login with invalid credentials
+  2. Verify error message "Invalid email or password" appears below the email field
+  3. Verify error message is red (#FF0000)
+  4. Verify form fields are still enabled and can be re-submitted
+```
+
+The bugfix pipeline AI will use these criteria during manual verification.

package/bundled/skills/bug-planner/references/error-recovery.md

@@ -0,0 +1,73 @@
+# Error Recovery & Resume Support
+
+Reference document for bug-planner error handling and session recovery. Load this when validation fails, a session is interrupted, or existing artifacts are detected.
+
+## Validation Failure Handling
+
+### Warnings Only
+
+If `validate-bug-list.py` returns warnings but no errors:
+1. Present warnings to user
+2. Ask: "Proceed with these warnings, or fix them first?"
+3. If user approves → write file and continue
+4. If user wants fixes → address each warning, re-validate
+
+### Errors Found
+
+If validation returns errors:
+1. Group errors by type (missing fields, invalid values, duplicate IDs, broken references)
+2. Auto-fix where possible:
+   - Missing `status` → set to `pending`
+   - Duplicate IDs → re-number with next sequential B-NNN
+   - Invalid `priority` → re-derive from severity using the mapping table
+3. Present fixes to user for confirmation
+4. Re-validate after fixes
+5. Maximum 3 total validation attempts — if still failing after 3 rounds, present the raw errors and ask user for guidance
+
+### JSON Parse Failure
+
+If the generated JSON is malformed:
+1. Do not write the file
+2. Regenerate from the collected bug data (Phase 2-3 state)
+3. Re-validate before writing
+
+## Resume Support
+
+### Checkpoint-Based Resumption
+
+When bug-planner detects existing artifacts, determine the last completed checkpoint and offer to resume:
+
+| Existing Artifact | Last Checkpoint | Resume From |
+|---|---|---|
+| `.prizmkit/plans/bug-fix-list.json` (valid) | CP-BP-5 | Offer: "Valid bug list exists. Append new bugs (Route B) or regenerate?" |
+| `.prizmkit/plans/bug-fix-list.json` (invalid) | CP-BP-4 | Re-run Phase 5 validation and fix |
+| `.prizmkit/plans/bug-fix-list.draft.json` | CP-BP-2 or CP-BP-3 | Load draft, determine phase from content completeness, resume |
+| `.prizmkit/config.json` with tech_stack | CP-BP-1 (partial) | Skip project context questions, start at Phase 2 |
+| No artifacts | — | Start from Phase 1 |
+
+### Resume Detection Flow
+
+1. Check for `.prizmkit/plans/bug-fix-list.json`
+   - If exists and valid → offer Route B (append) or full regeneration
+   - If exists but invalid → offer to fix and re-validate (resume from CP-BP-4)
+2. Check for `.prizmkit/plans/bug-fix-list.draft.json`
+   - If exists → load draft, count bugs with/without confirmation, resume from appropriate phase
+3. Check for `.prizmkit/config.json`
+   - If exists with tech_stack → skip Phase 1 context gathering
+4. If no artifacts → start fresh (Route A)
+
+### Session Interruption Recovery
+
+If a bug-planner session is interrupted mid-planning:
+
+1. On next invocation, run the Resume Detection Flow above
+2. If a draft exists, present: "Found a draft with N bugs from a previous session. Resume from where you left off, or start fresh?"
+3. If user resumes → load draft state, skip completed phases
+4. If user starts fresh → archive draft as `bug-fix-list.draft.TIMESTAMP.json`, begin Phase 1
+
+## Draft Management
+
+- Save drafts to `.prizmkit/plans/bug-fix-list.draft.json` after each completed phase (CP-BP-1 through CP-BP-4)
+- Drafts use the same schema as the final file but may have incomplete fields
+- Delete draft after successful generation of the final `bug-fix-list.json`
+- Keep at most 1 draft — overwrite on each phase completion

package/bundled/skills/bug-planner/references/input-formats.md

@@ -0,0 +1,53 @@
+# Bug Input Format Detection & Extraction
+
+Auto-detect the user's input format and extract structured bug information accordingly.
+
+## Format A: Stack Trace / Error Log
+
+```
+TypeError: Cannot read property 'token' of null
+    at AuthService.handleLogin (src/services/auth.ts:42)
+    at LoginPage.onSubmit (src/pages/login.tsx:28)
+```
+
+Extract: `error_source.type="stack_trace"`, `error_message`, `stack_trace`, `affected_modules`
+
+## Format B: Natural Language User Report
+
+```
+When I click the login button with correct credentials, the page turns white.
+Expected: redirect to home page.
+Actual: white screen with no error message visible.
+```
+
+Extract: `error_source.type="user_report"`, `reproduction_steps`, `description` (expected vs actual)
+
+## Format C: Failed Test Output
+
+```
+FAIL src/services/__tests__/auth.test.ts
+  ● AuthService > handleLogin > should return token on success
+    Expected: "abc123"
+    Received: null
+```
+
+Extract: `error_source.type="failed_test"`, `failed_test_path`, `error_message`
+
+## Format D: Log Pattern
+
+```
+[2026-03-07 10:23:45] ERROR [auth-service] Connection timeout after 30000ms
+[2026-03-07 10:23:45] ERROR [auth-service] Failed to authenticate user: ETIMEDOUT
+[2026-03-07 10:23:46] ERROR [auth-service] Connection timeout after 30000ms
+```
+
+Extract: `error_source.type="log_pattern"`, `log_snippet`, `affected_modules`
+
+## Format E: Monitoring Alert
+
+```
+ALERT: CPU usage > 95% for auth-service pod (5min avg)
+ALERT: Error rate spike: 500 errors/min on /api/login endpoint
+```
+
+Extract: `error_source.type="monitoring_alert"`, `error_message`, `affected_modules`

package/bundled/skills/bug-planner/references/schema-validation.md

@@ -0,0 +1,25 @@
+# Schema Validation Checklist
+
+Use this checklist for manual validation when `validate-bug-list.py` is not available. The script is the source of truth — this checklist mirrors its logic.
+
+## Required Top-Level Fields
+
+- [ ] `$schema`: must be `"dev-pipeline-bug-fix-list-v1"`
+- [ ] `project_name`: non-empty string
+- [ ] `bugs`: non-empty array
+
+## Per-Bug Required Fields
+
+- [ ] `id`: matches pattern `B-NNN` (e.g., `B-001`)
+- [ ] `title`: non-empty string
+- [ ] `description`: non-empty string
+- [ ] `severity`: one of `critical`, `high`, `medium`, `low`
+- [ ] `error_source.type`: one of `stack_trace`, `user_report`, `failed_test`, `log_pattern`, `monitoring_alert`
+- [ ] `verification_type`: one of `automated`, `manual`, `hybrid`
+- [ ] `acceptance_criteria`: non-empty array of strings
+- [ ] `status`: must be `pending` for new bugs
+
+## Consistency Checks
+
+- [ ] No duplicate bug IDs
+- [ ] If `priority` is set, must be one of `high`, `medium`, `low`

package/bundled/skills/bug-planner/references/severity-rules.md

@@ -0,0 +1,16 @@
+# Severity Auto-Classification Rules
+
+When extracting bugs, apply these rules to auto-suggest severity:
+
+| Severity | Indicators | Examples |
+|----------|------------|----------|
+| **critical** | System crash, data loss, security breach, OOM, unrecoverable error | `Segmentation fault`, `OutOfMemoryError`, `SQL injection vulnerability`, `Database corrupted` |
+| **high** | Core feature broken, authentication failure, data integrity issue, timeout | `Auth token invalid`, `Payment failed`, `Connection timeout`, `500 Internal Server Error` |
+| **medium** | Feature partially broken, workaround exists, incorrect output | `CSV encoding issue`, `Pagination not working`, `Wrong date format`, `Missing validation` |
+| **low** | Cosmetic issue, minor inconvenience, edge case | `UI misalignment`, `Typo in error message`, `Slow loading (non-critical page)`, `Non-breaking warning` |
+
+## Special Cases
+
+- Failed test → medium (unless test covers critical path, then high)
+- User report with "cannot use app" → high
+- User report with "annoying but works" → low

package/bundled/skills/bug-planner/scripts/validate-bug-list.py

@@ -1,9 +1,9 @@
 #!/usr/bin/env python3
 """
-Validate bug-fix-list.json against the PrizmKit bug-fix-list schema.
+Validate .prizmkit/plans/bug-fix-list.json against the PrizmKit bug-fix-list schema.
 
 Usage:
-    python3 validate-bug-list.py [bug-fix-list.json] [--feature-list feature-list.json]
+    python3 validate-bug-list.py [.prizmkit/plans/bug-fix-list.json] [--feature-list .prizmkit/plans/feature-list.json]
 
 Exit codes:
     0 = valid
@@ -19,7 +19,7 @@ import re
 VALID_SEVERITIES = {"critical", "high", "medium", "low"}
 VALID_SOURCE_TYPES = {"stack_trace", "user_report", "failed_test", "log_pattern", "monitoring_alert"}
 VALID_VERIFICATION_TYPES = {"automated", "manual", "hybrid"}
-VALID_STATUSES = {"pending", "in_progress", "fixed", "failed", "skipped", "needs_info"}
+VALID_STATUSES = {"pending", "triaging", "reproducing", "fixing", "verifying", "completed", "failed", "needs_info", "skipped"}
 BUG_ID_PATTERN = re.compile(r"^B-\d{3}$")
 SCHEMA_VERSION = "dev-pipeline-bug-fix-list-v1"
 
@@ -117,10 +117,6 @@ def validate(bug_list_path, feature_list_path=None):
             if priority not in ("high", "medium", "low"):
                 errors.append(f"{prefix} ({bug_id}): invalid priority '{priority}' — must be one of 'high', 'medium', 'low'")
 
-        # Cross-reference affected_feature
-        affected_feature = bug.get("affected_feature")
-        if affected_feature and feature_ids and affected_feature not in feature_ids:
-            warnings.append(f"{prefix} ({bug_id}): affected_feature '{affected_feature}' not found in feature-list.json")
 
     # Output results
     if errors:
@@ -145,7 +141,7 @@ def validate(bug_list_path, feature_list_path=None):
 
 
 if __name__ == "__main__":
-    bug_list = sys.argv[1] if len(sys.argv) > 1 else "bug-fix-list.json"
+    bug_list = sys.argv[1] if len(sys.argv) > 1 else ".prizmkit/plans/bug-fix-list.json"
     feature_list = None
 
     if "--feature-list" in sys.argv:

package/bundled/skills/bugfix-pipeline-launcher/SKILL.md

@@ -17,7 +17,7 @@ Three execution modes are available. The user chooses one before configuring oth
 
 **Background mode documentation**: When the user chooses background/daemon mode, record the choice and PID in `.prizmkit/bugfix-pipeline-run.log` (append-only) with timestamp, so the decision is traceable:
 ```
-[2026-03-26T10:30:00] MODE=daemon PID=12345 BUG_LIST=bug-fix-list.json BUGS=3
+[2026-03-26T10:30:00] MODE=daemon PID=12345 BUG_LIST=.prizmkit/plans/bug-fix-list.json BUGS=3
 ```
 
 ### When to Use
@@ -48,7 +48,7 @@ Three execution modes are available. The user chooses one before configuring oth
 Before any action, validate:
 
 1. **bugfix pipeline exists**: Confirm `dev-pipeline/launch-bugfix-daemon.sh` and `dev-pipeline/run-bugfix.sh` are present and executable
-2. **For start**: `bug-fix-list.json` must exist in project root (or user-specified path)
+2. **For start**: `.prizmkit/plans/bug-fix-list.json` must exist in `.prizmkit/plans/` (or user-specified path)
 3. **Dependencies**: `jq`, `python3`, AI CLI (`cbc` or `claude`) must be in PATH
 
 Quick check:
@@ -56,8 +56,8 @@ Quick check:
 command -v jq && command -v python3 && (command -v cbc || command -v claude) && echo "All dependencies OK"
 ```
 
-If `bug-fix-list.json` is missing, inform user:
-> "No bug-fix-list.json found. Run the `bug-planner` skill first to generate one, or provide a path to your bug fix list."
+If `.prizmkit/plans/bug-fix-list.json` is missing, inform user:
+> "No .prizmkit/plans/bug-fix-list.json found. Run the `bug-planner` skill first to generate one, or provide a path to your bug fix list."
 
 ### Workflow
 
@@ -69,7 +69,7 @@ Detect user intent from their message, then follow the corresponding workflow:
 
 1. **Check prerequisites**:
    ```bash
-   ls bug-fix-list.json 2>/dev/null && echo "Found" || echo "Missing"
+   ls .prizmkit/plans/bug-fix-list.json 2>/dev/null && echo "Found" || echo "Missing"
    ```
 
 2. **Check not already running**:
@@ -82,7 +82,7 @@ Detect user intent from their message, then follow the corresponding workflow:
    ```bash
    python3 -c "
    import json
-   with open('bug-fix-list.json') as f:
+   with open('.prizmkit/plans/bug-fix-list.json') as f:
        data = json.load(f)
    bugs = data.get('bugs', [])
    severity_order = {'critical': 0, 'high': 1, 'medium': 2, 'low': 3}
@@ -101,8 +101,8 @@ Detect user intent from their message, then follow the corresponding workflow:
    If pipeline state already exists, use the status command instead:
    ```bash
    python3 dev-pipeline/scripts/update-bug-status.py \
-     --bug-list bug-fix-list.json \
-     --state-dir dev-pipeline/bugfix-state \
+     --bug-list .prizmkit/plans/bug-fix-list.json \
+     --state-dir .prizmkit/state/bugfix \
      --action status 2>/dev/null
    ```
 
@@ -117,20 +117,16 @@ Detect user intent from their message, then follow the corresponding workflow:
 
    Use `AskUserQuestion` to present the following configuration choices. Each question is a separate selectable option:
 
-   **Question 1 — Critic review** (multiSelect: false):
-   - Off (default) — Skip adversarial review
-   - On — Enable critic review after bug fix (+2-5 min/bug for critical/high severity)
-
-   **Question 2 — Verbose logging** (multiSelect: false):
+   **Question 1 — Verbose logging** (multiSelect: false):
    - On (default) — Detailed AI session logs including tool calls and subagent activity
    - Off — Minimal logging
 
-   **Question 3 — Max retries** (multiSelect: false):
+   **Question 2 — Max retries** (multiSelect: false):
    - 3 (default)
    - 1
    - 5
 
-   **Question 4 — Session timeout** (multiSelect: false):
+   **Question 3 — Session timeout** (multiSelect: false):
    - None (default) — No timeout
    - 30 min — `SESSION_TIMEOUT=1800`
    - 1 hour — `SESSION_TIMEOUT=3600`
@@ -142,7 +138,6 @@ Detect user intent from their message, then follow the corresponding workflow:
 
    | Config choice | Environment variable |
    |-----------|---------------------|
-   | Critic: On | `ENABLE_CRITIC=true` |
    | Verbose: Off | `VERBOSE=0` |
    | Verbose: On | `VERBOSE=1` |
    | Max retries: N | `MAX_RETRIES=N` |
@@ -168,34 +163,34 @@ Detect user intent from their message, then follow the corresponding workflow:
 
    **Foreground command:**
    ```bash
-   VERBOSE=1 dev-pipeline/run-bugfix.sh run bug-fix-list.json
+   VERBOSE=1 dev-pipeline/run-bugfix.sh run .prizmkit/plans/bug-fix-list.json
    ```
    With all options:
    ```bash
    VERBOSE=1 MAX_RETRIES=5 SESSION_TIMEOUT=3600 \
-     dev-pipeline/run-bugfix.sh run bug-fix-list.json
+     dev-pipeline/run-bugfix.sh run .prizmkit/plans/bug-fix-list.json
    ```
 
    **Background daemon command:**
    ```bash
-   dev-pipeline/launch-bugfix-daemon.sh start bug-fix-list.json --env "VERBOSE=1"
+   dev-pipeline/launch-bugfix-daemon.sh start .prizmkit/plans/bug-fix-list.json --env "VERBOSE=1"
    ```
    With all options:
    ```bash
-   dev-pipeline/launch-bugfix-daemon.sh start bug-fix-list.json \
+   dev-pipeline/launch-bugfix-daemon.sh start .prizmkit/plans/bug-fix-list.json \
      --env "VERBOSE=1 MAX_RETRIES=5"
    ```
 
    **Manual mode**: Print the assembled command(s) and **stop here**. Do not execute anything. Do not proceed to step 7.
    ```
    # To run in foreground:
-   VERBOSE=1 dev-pipeline/run-bugfix.sh run bug-fix-list.json
+   VERBOSE=1 dev-pipeline/run-bugfix.sh run .prizmkit/plans/bug-fix-list.json
 
    # To run in background (detached):
-   dev-pipeline/launch-bugfix-daemon.sh start bug-fix-list.json --env "VERBOSE=1"
+   dev-pipeline/launch-bugfix-daemon.sh start .prizmkit/plans/bug-fix-list.json --env "VERBOSE=1"
 
    # To check status:
-   dev-pipeline/run-bugfix.sh status bug-fix-list.json
+   dev-pipeline/run-bugfix.sh status .prizmkit/plans/bug-fix-list.json
    ```
 
 7. **Confirm and launch** (Foreground and Background only — Manual mode ends at step 6):
@@ -208,7 +203,7 @@ Detect user intent from their message, then follow the corresponding workflow:
 
    **If foreground**: Pipeline runs to completion in the terminal. After it finishes:
    - Summarize results: total bugs, fixed, failed, skipped
-   - If all fixed: each bug session has already run `prizmkit-retrospective` (structural sync) internally. Ask user what's next.
+   - If all fixed: each bug session has already run `prizmkit-retrospective` internally (structural sync by default; full retrospective when the fix changed interfaces, dependencies, or observable behavior). Ask user what's next.
    - If some failed: show failed bug IDs and suggest `retry-bugfix.sh <B-XXX>` or `dev-pipeline/reset-bug.sh <B-XXX> --clean --run`
 
    **If background daemon**:
@@ -218,7 +213,7 @@ Detect user intent from their message, then follow the corresponding workflow:
       ```
    2. Start log monitoring — Use the Bash tool with `run_in_background: true`:
       ```bash
-      tail -f dev-pipeline/bugfix-state/pipeline-daemon.log
+      tail -f .prizmkit/state/bugfix/pipeline-daemon.log
       ```
    3. Report to user:
       - Pipeline PID
@@ -238,14 +233,14 @@ Detect user intent from their message, then follow the corresponding workflow:
 2. **Show bug-level progress**:
    ```bash
    python3 dev-pipeline/scripts/update-bug-status.py \
-     --bug-list bug-fix-list.json \
-     --state-dir dev-pipeline/bugfix-state \
+     --bug-list .prizmkit/plans/bug-fix-list.json \
+     --state-dir .prizmkit/state/bugfix \
      --action status
    ```
 
 3. **Show recent log activity** (last 20 lines):
    ```bash
-   tail -20 dev-pipeline/bugfix-state/pipeline-daemon.log
+   tail -20 .prizmkit/state/bugfix/pipeline-daemon.log
    ```
 
 4. **Summarize** to user: total bugs, completed, in-progress, failed, pending, needs-info.
@@ -277,20 +272,20 @@ Detect user intent from their message, then follow the corresponding workflow:
 
 2. **If running** -- Start live tail with Bash tool `run_in_background: true`:
    ```bash
-   tail -f dev-pipeline/bugfix-state/pipeline-daemon.log
+   tail -f .prizmkit/state/bugfix/pipeline-daemon.log
    ```
 
 3. **If not running** -- Show last 50 lines:
    ```bash
-   tail -50 dev-pipeline/bugfix-state/pipeline-daemon.log
+   tail -50 .prizmkit/state/bugfix/pipeline-daemon.log
    ```
 
 4. **For per-bug session logs** (when user asks about a specific bug):
    ```bash
    # Check bug status for last session ID
-   cat dev-pipeline/bugfix-state/bugs/<BUG_ID>/status.json 2>/dev/null
+   cat .prizmkit/state/bugfix/bugs/<BUG_ID>/status.json 2>/dev/null
    # Then tail that bug's session log
-   tail -100 dev-pipeline/bugfix-state/bugs/<BUG_ID>/sessions/<SESSION_ID>/logs/session.log
+   tail -100 .prizmkit/state/bugfix/bugs/<BUG_ID>/sessions/<SESSION_ID>/logs/session.log
    ```
 
 ---
@@ -300,35 +295,35 @@ Detect user intent from their message, then follow the corresponding workflow:
 When user says "retry B-001":
 
 ```bash
-dev-pipeline/retry-bugfix.sh B-001 bug-fix-list.json
+dev-pipeline/retry-bugfix.sh B-001 .prizmkit/plans/bug-fix-list.json
 ```
 
-**Note:** `retry-bugfix.sh` automatically cleans bug artifacts and resets status before retrying. This is equivalent to `reset-feature.sh --clean --run` in the feature pipeline. No separate reset command is needed.
+**Note:** `retry-bugfix.sh` runs exactly one bug session and exits. It **preserves prior session artifacts and checkpoint state** — reads `retry_count` and `resume_from_phase` from `status.json` so the AI session can resume from where it left off. For a full clean retry, use `dev-pipeline/reset-bug.sh <B-XXX> --clean --run`.
 
 Environment variables (optional):
 ```bash
-SESSION_TIMEOUT=3600 dev-pipeline/retry-bugfix.sh B-001 bug-fix-list.json
+SESSION_TIMEOUT=3600 dev-pipeline/retry-bugfix.sh B-001 .prizmkit/plans/bug-fix-list.json
 ```
 
 ### Error Handling
 
 | Error | Action |
 |-------|--------|
-| `bug-fix-list.json` not found | Tell user to run `bug-planner` skill first |
+| `.prizmkit/plans/bug-fix-list.json` not found | Tell user to run `bug-planner` skill first |
 | `jq` not installed | Suggest: `brew install jq` |
 | `cbc`/`claude` not in PATH | Check AI CLI installation |
 | Bugfix pipeline already running | Show status, ask if user wants to stop and restart |
 | PID file stale (process dead) | `launch-bugfix-daemon.sh` auto-cleans, retry start |
-| Launch failed (process died immediately) | Show last 20 lines of log: `tail -20 dev-pipeline/bugfix-state/pipeline-daemon.log` |
+| Launch failed (process died immediately) | Show last 20 lines of log: `tail -20 .prizmkit/state/bugfix/pipeline-daemon.log` |
 | All bugs blocked/failed/needs-info | Show status, suggest retrying or providing more info |
 | Permission denied on script | Run `chmod +x dev-pipeline/launch-bugfix-daemon.sh dev-pipeline/run-bugfix.sh` |
 
 ### Integration Notes
 
-- **After bug-planner**: This is the natural next step. When user finishes bug planning and has `bug-fix-list.json`, suggest launching the bugfix pipeline.
+- **After bug-planner**: This is the natural next step. When user finishes bug planning and has `.prizmkit/plans/bug-fix-list.json`, suggest launching the bugfix pipeline.
 - **Session independence**: In daemon mode, the bugfix pipeline runs completely detached. User can close the AI CLI, open a new session later, and use this skill to check progress or stop the pipeline.
 - **Single instance**: Only one bugfix pipeline can run at a time. The PID file prevents duplicates.
-- **Feature pipeline coexistence**: Bugfix and feature pipelines use separate state directories (`bugfix-state/` vs `state/`), so they can run simultaneously without conflict.
+- **Feature pipeline coexistence**: Bugfix and feature pipelines use separate state directories (`.prizmkit/state/bugfix/` vs `.prizmkit/state/features/`), so they can run simultaneously without conflict.
 - **State preservation**: Stopping and restarting the bugfix pipeline resumes from where it left off -- completed bugs are not re-fixed.
 - **Bug ordering**: Bugs are processed by severity (critical → high → medium → low), then by priority number within the same severity.
 - **Background mode traceability**: When daemon mode is chosen, the decision is logged to `.prizmkit/bugfix-pipeline-run.log` with timestamp, PID, and bug count for auditability.