prizmkit 1.1.6 → 1.1.8

package/bundled/skills/app-planner/SKILL.md

@@ -10,9 +10,9 @@ Plan a new application from idea to actionable project context through interacti
 - Tech stack selection
 - Constraints and design direction
 - Architecture decision capture
-- Project brief accumulation (`project-brief.md`)
+- Project brief accumulation (`.prizmkit/plans/project-brief.md`)
 
-This skill captures **what to build and why**. For **feature decomposition and `feature-list.json` generation**, hand off to `feature-planner`.
+This skill captures **what to build and why**. For **feature decomposition and `.prizmkit/plans/feature-list.json` generation**, hand off to `feature-planner`.
 
 For adding features to an **existing** project, use `feature-planner` directly.
 
@@ -35,18 +35,21 @@ If you believe the task is better suited for a different workflow, you MUST:
 - Create project scaffolding, directories, or boilerplate
 - Run build/install/test commands (npm init, pip install, etc.)
 - Execute any implementation action beyond writing planning artifacts
-- Generate `feature-list.json` — that is `feature-planner`'s responsibility
+- Generate `.prizmkit/plans/feature-list.json` — that is `feature-planner`'s responsibility
 
 **Your ONLY writable outputs are:**
-1. `project-brief.md` (project root — accumulated project context brief)
+1. `.prizmkit/plans/project-brief.md` (`.prizmkit/plans/` — accumulated project context brief)
 2. `.prizmkit/project-conventions.json` (project convention answers)
-3. Architecture decisions appended to `CLAUDE.md` / `CODEBUDDY.md` (with user consent)
-4. Draft backups in `.prizmkit/planning/`
+3. `.prizm-docs/root.prizm` (if architecture decisions are captured — see Architecture Decision Capture section)
+   - Contains architecture decisions, tech stack rationale, and key constraints
+   - Used as input by feature-planner and other workflows
+4. Architecture decisions appended to `CLAUDE.md` / `CODEBUDDY.md` (with user consent)
+5. Draft backups in `.prizmkit/planning/`
 
 **After planning is complete**, you MUST:
 1. Present the summary of captured vision, constraints, and decisions
 2. **Ask the user explicitly** whether they want to proceed to feature decomposition
-3. If the user agrees → recommend invoking `feature-planner` to decompose into features and generate `feature-list.json`
+3. If the user agrees → recommend invoking `feature-planner` to decompose into features and generate `.prizmkit/plans/feature-list.json`
 4. If the user wants to continue exploring → stay in app-planner
 5. **NEVER auto-execute** the pipeline, feature-planner, or any implementation step
 
@@ -151,16 +154,24 @@ Checkpoints catch cascading errors early — skipping one means the next phase b
 | **CP-AP-1** | Conventions Checked | Project conventions loaded or asked; `.prizmkit/project-conventions.json` up to date | 1 |
 | **CP-AP-2** | Vision Summary | Goal/users/differentiators confirmed by user | 1-2 |
 | **CP-AP-3** | Frontend Design Evaluated | For frontend projects: checked for existing UI/UX design system; user was asked if missing | 2 |
-| **CP-AP-4** | Project Brief Accumulated | `project-brief.md` exists at project root with at least 3 ideas listed | 3 |
+| **CP-AP-4** | Project Brief Accumulated | `.prizmkit/plans/project-brief.md` exists at `.prizmkit/plans/` with at least 3 ideas listed | 3 |
 | **CP-AP-5** | Handoff Ready | All app-level context captured; user confirmed readiness for feature decomposition | 4 |
 
 ## Architecture Decision Capture
 
 After Phase 2, if framework-shaping architecture decisions emerged during planning (tech stack, communication patterns, data model strategies — not individual feature details), read `${SKILL_DIR}/references/architecture-decisions.md` and follow the capture flow. Most sessions will NOT produce architecture decisions — only capture when genuinely impactful.
 
+**Handoff to feature-planner**: Captured architecture decisions MUST be written to `.prizm-docs/root.prizm` so that feature-planner can read them as context. This ensures all downstream planners (feature, bug, refactor) share consistent architectural understanding.
+
+**How it works**:
+1. If decisions are captured → create `.prizm-docs/root.prizm` with decision summaries
+2. Also append decisions to `CLAUDE.md` / `CODEBUDDY.md` for human reference
+3. When feature-planner is invoked, it will read `.prizm-docs/root.prizm` as prerequisite context
+4. Feature decomposition will respect captured architecture decisions (no conflicting tech choices)
+
 ## Project Brief Accumulation
 
-During interactive planning, maintain a `project-brief.md` at the project root as a simple checklist of product ideas.
+During interactive planning, maintain a `.prizmkit/plans/project-brief.md` at `.prizmkit/plans/` as a simple checklist of product ideas.
 
 → Read `${SKILL_DIR}/references/project-brief-guide.md` for full format and rules.
 
@@ -192,13 +203,13 @@ Prevent accidental session exit without completing the planning artifacts.
 
 Activate when ALL true:
 - Session goal = `produce`
-- `project-brief.md` has not been written or is incomplete (Vision section missing)
+- `.prizmkit/plans/project-brief.md` has not been written or is incomplete (Vision section missing)
 - No architecture decisions captured yet (if any emerged)
 
 ### Gate Behavior
 
 When the session appears to be ending:
-1. **Remind**: "You set out to produce a project plan but `project-brief.md` isn't complete yet."
+1. **Remind**: "You set out to produce a project plan but `.prizmkit/plans/project-brief.md` isn't complete yet."
 2. **Offer 3 options**:
    - **(a) Continue to completion**
    - **(b) Save draft & exit** — write current progress as draft to `.prizmkit/planning/`
@@ -209,6 +220,6 @@ When the session appears to be ending:
 After all checkpoints pass, present a summary and recommend next steps:
 
 1. **Summary**: List captured vision, tech stack, constraints, architecture decisions, and project brief status
-2. **Primary recommendation**: Invoke `feature-planner` to decompose the application into features and generate `feature-list.json`
+2. **Primary recommendation**: Invoke `feature-planner` to decompose the application into features and generate `.prizmkit/plans/feature-list.json` (schema: `dev-pipeline-feature-list-v1`, uses `project_name` field for the app name)
 3. **Alternative**: If the user wants to continue refining the vision or constraints, stay in app-planner
-4. **Artifacts produced**: List files written (`project-brief.md`, `.prizmkit/project-conventions.json`, architecture decisions if any)
+4. **Artifacts produced**: List files written (`.prizmkit/plans/project-brief.md`, `.prizmkit/project-conventions.json`, architecture decisions if any)

package/bundled/skills/app-planner/references/project-brief-guide.md

@@ -8,7 +8,7 @@ During `app-planner` conversation, the user describes what they want to build. `
 
 ## Persistence
 
-- **File**: `project-brief.md` at project root (same level as `feature-list.json`)
+- **File**: `project-brief.md` at `.prizmkit/plans/` (shared location with `feature-list.json`)
 - **Format**: Checklist — one idea per line, `[ ]` for pending, `[x]` for completed
 - **Size limit**: 500 words max (injected into every session's context window)
 - **Consumed by**: `dev-pipeline/scripts/generate-bootstrap-prompt.py` → `{{PROJECT_BRIEF}}` placeholder

package/bundled/skills/bug-fix-workflow/SKILL.md

@@ -27,7 +27,7 @@ Fix a single bug interactively within the current AI CLI session. This is the in
 
 | Input Source | Detection | Example |
 |---|---|---|
-| Bug-fix-list.json entry | User says "fix B-001" → read entry from `bug-fix-list.json` | `fix B-001` |
+| Bug-fix-list.json entry | User says "fix B-001" → read entry from `.prizmkit/plans/bug-fix-list.json` | `fix B-001` |
 | Stack trace / error message | User pastes error directly | `TypeError: Cannot read property...` |
 | Natural language description | User describes the problem | "login page crashes on submit" |
 | Failed test | User references a failing test file | `src/auth/__tests__/login.test.ts` |
@@ -83,11 +83,13 @@ For trivial bugs with clear root cause and minimal scope:
 
 **Goal**: Fully understand the bug before touching any code. Vague bug reports lead to incorrect fixes that mask the real issue or introduce new bugs.
 
+**Fast Path Decision Point**: After initial information gathering (Step 1.1), evaluate the Fast Path Eligibility Criteria above. If ALL criteria are met, ask the user: "This looks like a straightforward fix. Use fast path? (Y/n)". If yes, skip directly to the Fast Path Workflow (branch setup already done in Phase 0). If no or uncertain, continue with full diagnosis.
+
 **CRITICAL RULE**: Ask as many questions as needed until the bug is fully understood. Do NOT rush into code. A misdiagnosed bug leads to a wrong fix, which is worse than no fix.
 
 #### Step 1.1: Initial Bug Information Gathering
 
-- If bug ID given (e.g. B-001): read entry from `bug-fix-list.json` — but DO NOT assume the description is complete
+- If bug ID given (e.g. B-001): read entry from `.prizmkit/plans/bug-fix-list.json` — but DO NOT assume the description is complete
 - If raw error/stack trace: extract error message, affected files, line numbers
 - If natural language description: start the deep-dive Q&A below
 
@@ -269,10 +271,10 @@ If user reports the fix is NOT working:
    git branch -d fix/<BUG_ID>-<short-description>
    ```
 4. **If (b)**: Inform user: "Branch `fix/<BUG_ID>-<short-desc>` retained. Create a PR when ready."
-5. **If bug came from bug-fix-list.json**: inform user to update bug status
+5. **If bug came from .prizmkit/plans/bug-fix-list.json**: inform user to update bug status
    ```
    Bug B-001 fixed and committed.
-   To update the bug list: manually set B-001 status to "fixed" in bug-fix-list.json
+   To update the bug list: manually set B-001 status to "fixed" in .prizmkit/plans/bug-fix-list.json
    Or retry the pipeline to pick up remaining bugs.
    ```
 
@@ -321,7 +323,7 @@ Only 2 artifact files per bug, consistent with the pipeline convention.
 
 | Scenario | Action |
 |----------|--------|
-| Bug ID not found in bug-fix-list.json | Ask user to provide bug details directly |
+| Bug ID not found in .prizmkit/plans/bug-fix-list.json | Ask user to provide bug details directly |
 | User's bug description is too vague | Ask systematic clarification questions (Phase 1) |
 | Cannot reproduce the bug | Ask for more context, try alternative reproduction |
 | Fix causes regressions | Revert, analyze, retry (max 3 rounds) |

package/bundled/skills/bug-planner/SKILL.md

@@ -1,12 +1,12 @@
 ---
 name: "bug-planner"
 tier: companion
-description: "Interactive bug planning that produces bug-fix-list.json for the Bug Fix Pipeline. Supports multiple input formats: error logs, stack traces, user reports, failed tests, monitoring alerts. Use this skill whenever the user has bugs to report, errors to parse, or test failures to organize. Trigger on: 'plan bug fixes', 'report bugs', 'I have some bugs', 'these tests are failing', 'here is an error log', 'parse these errors', 'generate bug list'. (project)"
+description: "Interactive bug planning that produces .prizmkit/plans/bug-fix-list.json for the Bug Fix Pipeline. Supports multiple input formats: error logs, stack traces, user reports, failed tests, monitoring alerts. Use this skill whenever the user has bugs to report, errors to parse, or test failures to organize. Trigger on: 'plan bug fixes', 'report bugs', 'I have some bugs', 'these tests are failing', 'here is an error log', 'parse these errors', 'generate bug list'. (project)"
 ---
 
 # Bug Planner
 
-Interactive skill that collects bug information from various input formats and generates a standardized `bug-fix-list.json` for the Bug Fix Pipeline. This is the bug-fix counterpart to `feature-planner` (which generates `feature-list.json`).
+Interactive skill that collects bug information from various input formats and generates a standardized `.prizmkit/plans/bug-fix-list.json` for the Bug Fix Pipeline. This is the bug-fix counterpart to `feature-planner` (which generates `.prizmkit/plans/feature-list.json`).
 
 ## When to Use
 
@@ -30,7 +30,7 @@ This skill handles multiple operations. Determine the user's intent and execute
 | Plan bugs interactively | **Interactive Planning** | "plan bug fixes", "report bugs" |
 | Parse error logs into bugs | **From Log** | "parse this error log", "here's a stack trace", "parse these errors" |
 | Parse test failures into bugs | **From Tests** | "these tests are failing", "parse test output" |
-| Validate existing bug list | **Validate** | "validate bug list", "check bug-fix-list.json" |
+| Validate existing bug list | **Validate** | "validate bug list", "check .prizmkit/plans/bug-fix-list.json" |
 | Summarize bug list | **Summary** | "bug summary", "show bug list", "list bugs" |
 
 ---
@@ -41,8 +41,8 @@ Launch the interactive bug planning process through 5 phases.
 
 ### Phase 1: Project Context
 
-1. **Identify project**: Read project name and description from existing `feature-list.json` or ask user
-2. **Identify tech stack**: Read from `.prizmkit/config.json` `tech_stack` (preferred), then `feature-list.json` global_context, then `.prizm-docs/root.prizm`. Only ask user if none of these sources provide tech stack info.
+1. **Identify project**: Read project name and description from existing `.prizmkit/plans/feature-list.json` or ask user
+2. **Identify tech stack**: Read from `.prizmkit/config.json` `tech_stack` (preferred), then `.prizmkit/plans/feature-list.json` global_context, then `.prizm-docs/root.prizm`. Only ask user if none of these sources provide tech stack info.
 3. **Identify testing framework**: Read from `.prizmkit/config.json` `tech_stack.testing`, or auto-detect from package.json/requirements.txt/etc., or ask user
 4. **Clarify context** — if the project context, affected systems, or bug scope is unclear, ask questions one at a time (cite the unclear point, give a recommended answer with rationale) until you fully understand the environment. No limit on rounds or number of questions.
 
@@ -116,6 +116,7 @@ ALERT: Error rate spike: 500 errors/min on /api/login endpoint
 - Environment (ask or auto-detect from logs)
 - Verification type (suggest `automated` by default, ask user)
 - Acceptance criteria (auto-suggest based on description, user can edit)
+- Model override (optional; if specified, overrides $MODEL env var for this bug fix)
 
 **Per-bug clarification** — if the bug's root cause, reproduction steps, expected behavior, or scope is unclear from the provided information, ask focused questions one at a time (cite the unclear point, give a recommended answer with rationale) until the bug is fully understood. Do not finalize a bug entry with ambiguous details. No limit on the number of questions per bug.
 
@@ -152,20 +153,28 @@ Only finalize the bug entry after user confirms all three points.
 
 ### Phase 3: Prioritization & Review
 
-1. **Auto-assign priorities**: Based on severity (critical=1, high=2, medium=3, low=4), adjustable by user
+1. **Auto-assign priorities**: Based on severity (critical → high, high → high, medium → medium, low → low), adjustable by user
+   
+   **Severity → Priority Mapping**:
+   - `critical` severity → `high` priority (treated with highest urgency)
+   - `high` severity → `high` priority
+   - `medium` severity → `medium` priority
+   - `low` severity → `low` priority
+   
+   Note: Severity has 4 levels (critical, high, medium, low) but Priority has 3 levels (high, medium, low). Both critical and high severity bugs map to high priority.
 2. **Display summary table**:
    ```
    ID    | Title                        | Severity | Priority | Verification
-   B-001 | Login null reference crash    | critical | 1        | automated
-   B-002 | CSV export Chinese encoding   | medium   | 3        | hybrid
-   B-003 | Slow dashboard loading        | low      | 4        | manual
+   B-001 | Login null reference crash    | critical | high     | automated
+   B-002 | CSV export Chinese encoding   | medium   | medium   | hybrid
+   B-003 | Slow dashboard loading        | low      | low      | manual
    ```
 3. **Ask for adjustments**: "Want to reorder priorities, change severity, or remove any bugs?"
 4. **Detect potential duplicates**: If two bugs have similar error messages or affected modules, warn user
 
 ### Phase 4: Pre-Generation Completeness Review
 
-Before generating `bug-fix-list.json`, perform a holistic scan across all collected bugs. The bugfix pipeline runs autonomously — any ambiguity left here becomes a wrong assumption later.
+Before generating `.prizmkit/plans/bug-fix-list.json`, perform a holistic scan across all collected bugs. The bugfix pipeline runs autonomously — any ambiguity left here becomes a wrong assumption later.
 
 **Step 1 — Description adequacy scan**: For each bug, check:
 - Description clearly states **expected** vs **actual** behavior (not just "X doesn't work")
@@ -199,13 +208,13 @@ Only proceed to Phase 5 after user confirms.
 
 ### Phase 5: Generate & Validate
 
-1. **Generate `bug-fix-list.json`**: Conform to `dev-pipeline/templates/bug-fix-list-schema.json`
+1. **Generate `.prizmkit/plans/bug-fix-list.json`**: Conform to `dev-pipeline/templates/bug-fix-list-schema.json`
 2. **Validate against schema**: Run the validation script:
    ```bash
-   python3 ${SKILL_DIR}/scripts/validate-bug-list.py bug-fix-list.json --feature-list feature-list.json
+   python3 ${SKILL_DIR}/scripts/validate-bug-list.py .prizmkit/plans/bug-fix-list.json --feature-list .prizmkit/plans/feature-list.json
    ```
    If the script is not available, perform the validation checks manually (see checklist below).
-3. **Write file** to project root (or user-specified path)
+3. **Write file** to `.prizmkit/plans/` (or user-specified path)
 4. **Output**: File path, summary, and next steps
 
 #### Schema Validation Checklist
@@ -230,19 +239,19 @@ Before writing the file, verify all items pass:
 **Consistency checks:**
 - [ ] No duplicate bug IDs
 - [ ] If `priority` is set, must be one of `high`, `medium`, `low`
-- [ ] If `affected_feature` is set, verify it exists in `feature-list.json` (if available)
+- [ ] If `affected_feature` is set, verify it exists in `.prizmkit/plans/feature-list.json` (if available)
 
 If any check fails, fix before writing the file.
 
 #### Success Output
 
 ```
-✅ bug-fix-list.json generated with 3 bugs (1 critical, 1 medium, 1 low)
+✅ .prizmkit/plans/bug-fix-list.json generated with 3 bugs (1 critical, 1 medium, 1 low)
 
 Next steps:
-- Review: cat bug-fix-list.json
+- Review: cat .prizmkit/plans/bug-fix-list.json
 - Start fixing: say "start fixing" or "start fixing bugs" to launch the bugfix pipeline
-- Or run directly: ./dev-pipeline/launch-bugfix-daemon.sh start bug-fix-list.json
+- Or run directly: ./dev-pipeline/launch-bugfix-daemon.sh start .prizmkit/plans/bug-fix-list.json
 ```
 
 ---
@@ -260,7 +269,7 @@ Batch-parse error logs to generate bug entries without interactive prompts:
    - error_source: populated from log content
    - verification_type: default to `automated`
    - acceptance_criteria: auto-generate "Error no longer occurs in [scenario]"
-4. Output draft `bug-fix-list.json` for user review
+4. Output draft `.prizmkit/plans/bug-fix-list.json` for user review
 5. Ask: "Review and confirm? You can edit individual entries."
 
 ## Operation: From Tests
@@ -271,11 +280,11 @@ Batch-parse failed test output:
 2. Parse each failed test case as a separate bug entry
 3. Auto-populate `failed_test_path`, `error_message`
 4. Set verification_type to `automated` (test already exists)
-5. Output draft `bug-fix-list.json`
+5. Output draft `.prizmkit/plans/bug-fix-list.json`
 
 ## Operation: Validate
 
-Validate existing `bug-fix-list.json`:
+Validate existing `.prizmkit/plans/bug-fix-list.json`:
 
 1. Check JSON syntax
 2. Validate against `dev-pipeline/templates/bug-fix-list-schema.json`
@@ -284,7 +293,7 @@ Validate existing `bug-fix-list.json`:
    - Missing required fields
    - Invalid status values
    - Invalid priority values (must be 'high', 'medium', or 'low')
-   - Invalid `affected_feature` references (if feature-list.json exists)
+   - Invalid `affected_feature` references (if .prizmkit/plans/feature-list.json exists)
 4. Output: validation result with specific errors/warnings
 
 ## Operation: Summary
@@ -309,13 +318,59 @@ Affected Features: F-003 (1 bug), F-012 (1 bug), none (1 bug)
 
 ---
 
+## 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 your 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.
+
+---
+
 ## Integration with Bug Fix Pipeline
 
-After `bug-fix-list.json` is generated, the user can:
+After `.prizmkit/plans/bug-fix-list.json` is generated, the user can:
 
 1. **Say "start fixing" or "start fixing bugs"** — triggers `bugfix-pipeline-launcher` skill to auto-launch pipeline in background (recommended)
-2. **Background daemon**: `./dev-pipeline/launch-bugfix-daemon.sh start bug-fix-list.json`
-3. **Foreground run**: `./dev-pipeline/run-bugfix.sh run bug-fix-list.json`
+2. **Background daemon**: `./dev-pipeline/launch-bugfix-daemon.sh start .prizmkit/plans/bug-fix-list.json`
+3. **Foreground run**: `./dev-pipeline/run-bugfix.sh run .prizmkit/plans/bug-fix-list.json`
 4. **Fix single bug interactively**: invoke `bug-fix-workflow` in current session
 5. **Retry a failed bug**: `./dev-pipeline/retry-bugfix.sh B-001`
 
@@ -332,6 +387,6 @@ After `bug-fix-list.json` is generated, the user can:
 
 ## Output
 
-- `bug-fix-list.json` conforming to `dev-pipeline/templates/bug-fix-list-schema.json`
+- `.prizmkit/plans/bug-fix-list.json` conforming to `dev-pipeline/templates/bug-fix-list-schema.json`
 - Validation report (if validation run)
 - Summary report (if summary run)

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
@@ -145,7 +145,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,16 +117,20 @@ 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 — Verbose logging** (multiSelect: false):
+   **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):
    - On (default) — Detailed AI session logs including tool calls and subagent activity
    - Off — Minimal logging
 
-   **Question 2 — Max retries** (multiSelect: false):
+   **Question 3 — Max retries** (multiSelect: false):
    - 3 (default)
    - 1
    - 5
 
-   **Question 3 — Session timeout** (multiSelect: false):
+   **Question 4 — Session timeout** (multiSelect: false):
    - None (default) — No timeout
    - 30 min — `SESSION_TIMEOUT=1800`
    - 1 hour — `SESSION_TIMEOUT=3600`
@@ -138,6 +142,7 @@ 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` |
@@ -163,34 +168,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):
@@ -204,7 +209,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 some failed: show failed bug IDs and suggest `retry-bugfix.sh <B-XXX>` or `reset-bug.sh <B-XXX> --clean --run`
+   - 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**:
    1. Verify launch:
@@ -213,7 +218,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
@@ -233,14 +238,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.
@@ -272,20 +277,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
    ```
 
 ---
@@ -295,35 +300,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.
 
 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.