prizmkit 1.1.129 → 1.1.131

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

@@ -1,88 +1,82 @@
 ---
 name: "bug-fix-workflow"
-description: "Triage-based bug-fix workflow for interactive single-bug repair or pipeline handoff. Diagnoses enough to choose Fast Path, Pipeline Path, continue diagnosis, or existing-list launch; keeps a thicker Fast Path for one bug with reproduction, fix, review, user verification, commit, and merge choice. Use for 'fix this bug', 'debug this', stack traces, failed tests, bug IDs, manual bug fixes, or batch bugs that may need bug-planner -> bugfix-pipeline-launcher. Ordinary bug fixes skip retrospective unless structural docs or architecture change."
+description: "Thin bug-fix scenario router. Performs lightweight diagnosis only to choose direct single-requirement guidance, complex or batch bug planning, or existing-list command construction; hands planning to bug-planner and runtime command construction to bugfix-pipeline-launcher. It never starts coding or owns the requirement lifecycle."
 ---
 
 # Bug Fix Workflow
 
-Triage-based entry point for bug fixing. Unlike feature/refactor workflows, this workflow intentionally keeps a thicker Fast Path because high-quality single-bug repair depends on interactive diagnosis, reproduction, verification, and commit decisions.
+Collect enough evidence to classify a reported problem, then route planned work without implementing a fix or duplicating planner/launcher responsibilities.
 
 ## Responsibility Boundary
 
 This workflow owns:
-- Single-bug interactive diagnosis and repair in the current workspace.
-- Lightweight routing between Fast Path, Pipeline Path, existing-list launch, and continued diagnosis.
-- User confirmation before workspace mutation.
-- Reproduction evidence, root-cause fix, code review, user verification, commit, and merge decision for Fast Path.
+- Lightweight diagnosis: symptom, expected/actual behavior, reproduction evidence, impact, and affected area when readily available.
+- Scenario classification: direct single-requirement guidance, Pipeline Path, existing-list command construction, or continued diagnosis.
+- User route selection through `AskUserQuestion`.
+- Prompt brief handoff to `bug-planner` or `bugfix-pipeline-launcher`.
 
 This workflow does not own:
-- Batch bug list generation, headless execution readiness, severity/priority calibration, schema validation, or plan review gates — those belong to `bug-planner`.
-- Pipeline execution mode, runtime configuration, command assembly, status/log/stop/retry details — those belong to `bugfix-pipeline-launcher`.
+- Creating branches, editing source/tests, running a fix, reviewing code, testing a completed change, committing, or merging.
+- Batch bug list generation, severity/priority calibration, schema validation, or planner-local review gates — those belong to `bug-planner`.
+- Runtime option selection, command construction, prerequisite checks, or status/log/stop/retry syntax — those belong to `bugfix-pipeline-launcher`.
+- The independent direct requirement lifecycle.
 
-Ordinary bug fixes do not run `/prizmkit-retrospective`. Run retrospective only when the fix intentionally changes durable architecture, module boundaries, public interfaces, or `.prizmkit/prizm-docs/` structure.
+## Execution Topology
+
+```text
+Direct single requirement:
+User → prizmkit-workflow → atomic lifecycle skills
+
+Planned bug execution:
+User → bug-fix-workflow → bug-planner → bugfix-pipeline-launcher → returned CLI command → runtime → atomic lifecycle skills
+```
+
+The routes are independent. This workflow may identify that one confirmed bug fits the Direct Path, but it ends before the user enters that path and never invokes the direct workflow.
 
 ## When to Use
 
 Use this workflow when:
-- The user wants to fix one specific bug interactively.
-- The user provides a stack trace, error message, failing test, or bug ID and wants diagnosis.
-- The user wants to decide whether a bug is simple enough for current-session repair.
-- The user provides multiple or complex bugs and wants routing to the bug-fix pipeline.
+- A bug report needs lightweight diagnosis before choosing a path.
+- The user provides a stack trace, error message, failing test, or bug ID and wants routing.
+- The user provides complex or multiple bugs that may need planning.
+- The user wants a command for an existing `.prizmkit/plans/bug-fix-list.json`.
 
 Do not use this workflow when:
-- The user only wants to collect or plan bugs -> use `bug-planner`.
-- The user only wants launch/status/logs/retry for an existing bug list -> use `bugfix-pipeline-launcher`.
+- The user already chose the direct single-requirement lifecycle -> enter it independently.
+- The user only wants to collect, append, validate, or summarize bugs -> use `bug-planner`.
+- The user only wants a runtime command for an existing bug list -> use `bugfix-pipeline-launcher`.
 - The user wants feature development -> use `feature-workflow`.
 - The user wants behavior-preserving restructuring -> use `refactor-workflow`.
 
 ## Input Sources
 
-Accept any of these sources:
-
-| Source | Example | Route implication |
-|---|---|---|
-| Bug ID from `.prizmkit/plans/bug-fix-list.json` | `fix B-001` | Can use Fast Path for one bug or launcher for pipeline |
-| Stack trace / error message | `TypeError: ...` | Diagnose before route selection |
-| Natural-language report | `login crashes on submit` | Diagnose before route selection |
-| Failed test | `src/auth/login.test.ts fails` | Use test as reproduction evidence |
-| Multiple bugs/logs | `these 7 tests fail` | Usually Pipeline Path through `bug-planner` |
+| Source | Route implication |
+|---|---|
+| One bug ID or focused report | Diagnose enough to offer Direct Path or planning |
+| Stack trace / error message | Capture evidence before route selection |
+| Failed test | Treat the failure as reproduction evidence |
+| Multiple reports/logs/tests | Usually Pipeline Path through `bug-planner` |
+| Existing validated bug list plus command intent | `bugfix-pipeline-launcher` |
 
-If no input source is clear, ask the user to describe the bug before proceeding.
+If no input source is clear, ask the user to describe the problem.
 
 ## Route Selection
 
-### Step 1: Diagnose enough to choose a path
-
-Do not create a branch or modify files before path selection.
+### Step 1: Diagnose enough to classify
 
-Gather enough information to decide whether this is:
-- One bug suitable for interactive Fast Path.
-- A complex single bug or batch bug set better suited for `bug-planner`.
-- An existing bug list operation better suited for `bugfix-pipeline-launcher`.
-- Still too unclear and needs continued diagnosis.
+Do not create a branch or modify files. Gather only enough evidence to decide whether this is:
+- One confirmed formal bug requirement suited to independent Direct Path execution.
+- A broad/complex bug or batch better suited to `bug-planner`.
+- An existing bug-list command suited to `bugfix-pipeline-launcher`.
+- Too unclear and still needs diagnosis.
 
-For systematic clarification, read `${SKILL_DIR}/references/bug-diagnosis.md` when the report lacks reproduction, expected vs actual behavior, affected scope, data/state trigger, or error details.
+Read `${SKILL_DIR}/references/bug-diagnosis.md` when reproduction, expected/actual behavior, scope, data/state trigger, or error detail is missing. Stop once the route can be chosen; root-cause proof belongs to the eventual execution owner.
 
-### Step 2: Confirm bug understanding
+### Step 2: Confirm understanding
 
-Before asking for an execution path, summarize:
-
-```markdown
-## Bug Understanding
-
-- Symptom:
-- Reproduction:
-- Environment:
-- Expected behavior:
-- Actual behavior:
-- Impact:
-- Suspected affected area:
-- Unknowns:
-```
+Summarize symptom, reproduction, environment, expected/actual behavior, impact, affected area, and unknowns. Ask whether the summary is accurate. If material unknowns remain, keep `Continue diagnosis` available.
 
-Ask whether the summary is accurate. If key fields are still unknown, include `Continue diagnosis` as an approach option.
-
-### Step 3: Ask for approach selection
+### Step 3: Ask for approach
 
 Use `AskUserQuestion`; do not render path options as plain text.
 
@@ -90,35 +84,21 @@ Use `AskUserQuestion`; do not render path options as plain text.
 Question: How would you like to proceed?
 Header: Approach
 Options:
-- Fix now (Fast Path) — create/use a fix branch in this workspace, reproduce, fix, review, verify, commit, and choose merge behavior
-- Use Pipeline Path — bug-planner creates/reviews bug-fix-list.json, then bugfix-pipeline-launcher configures execution
-- Continue diagnosis — inspect or ask more before choosing a path
-```
-
-For an auto-discovered existing bug list:
-
-```text
-Question: Existing bug-fix-list.json found. What should we do with it?
-Header: Bug list
-Options:
-- Launch existing list — hand off to bugfix-pipeline-launcher
-- Inspect summary first — show bug count/status, then ask again
-- Update/re-plan — hand off to bug-planner in append/update mode
-- Fix one bug interactively — choose a single bug for Fast Path
+- Use Direct Path — leave this router and invoke the direct single-requirement workflow independently with the confirmed bug evidence
+- Use Pipeline Path — bug-planner creates/reviews bug-fix-list.json, then bugfix-pipeline-launcher constructs the runtime command
+- Continue diagnosis — collect more route-level evidence before choosing
 ```
 
-If the user explicitly asked to run an existing list, that explicit request counts as path selection; hand off directly to `bugfix-pipeline-launcher`.
+For an auto-discovered bug list, offer construct command, inspect summary, update/re-plan, or select one report for direct-path guidance. An explicit request for a list command counts as route selection.
 
 ## Workflow Handoff Brief
 
-When handing off to `bug-planner`, `bugfix-pipeline-launcher`, or Fast Path L1 skills, include this prompt brief. Do not write the brief to disk.
+When handing off to a planner or launcher, include this prompt brief; do not write it to disk.
 
 ```markdown
-## Workflow Handoff Brief
-
 ### Source
 - workflow: bug-fix-workflow
-- selected_path: fast_path | pipeline_path | existing_list_launch | continue_diagnosis
+- selected_path: pipeline_path | existing_list_command | continue_diagnosis
 
 ### Bug Goal
 - original_request: <preserve the user's wording>
@@ -127,151 +107,80 @@ When handing off to `bug-planner`, `bugfix-pipeline-launcher`, or Fast Path L1 s
 ### Evidence
 - reproduction: <known steps or failing test>
 - error_output: <stack trace, logs, console output, or omitted>
-- affected_paths: <files/modules/tests mentioned by user or discovered during diagnosis>
+- affected_paths: <paths/modules/tests mentioned or found during lightweight diagnosis>
 - environment: <runtime/browser/OS/data state if known>
 
 ### Scope
-- included: <bug behavior to fix>
-- excluded: <unrelated cleanup, refactor, feature work>
+- included: <bug behavior to plan>
+- excluded: <unrelated cleanup, refactor, or feature work>
 
 ### Decision
 - route_reason: <why this path was selected>
 - user_confirmed: yes
 
 ### Next Skill Instruction
-- For bug-planner: Use this brief as input; perform your own required clarification, validation, generation, and review gate.
-- For Fast Path: Fix only the root cause for this bug and preserve unrelated behavior.
-```
-
-## Fast Path — Single Bug Interactive Repair
-
-Fast Path starts only after the user selects `Fix now`.
-
-### Phase 1: Branch setup
-
-1. Check current branch.
-2. If on `main` or a shared branch, create a dedicated `fix/<BUG_ID-or-short-desc>` branch.
-3. If already on a fix branch, ask whether to continue on it or create a new one.
-4. Record the original branch for the merge decision.
-
-This phase occurs after path selection so Pipeline Path users do not receive unnecessary workspace mutations.
-
-### Phase 2: Root-cause triage
-
-1. Read `.prizmkit/prizm-docs/root.prizm` and relevant L1/L2 docs for affected modules.
-2. Read files from the error, stack trace, failing test, or bug summary.
-3. Check relevant TRAPS in `.prizmkit/prizm-docs/`.
-4. Identify root cause, blast radius, and fix complexity.
-5. Present diagnosis and ask whether to proceed.
-
-### Phase 3: Reproduce
-
-1. Write or identify a focused reproduction test/check when practical.
-2. Confirm the reproduction fails before the fix when practical.
-3. If automatic reproduction is impractical, record a manual checklist and explain the limitation.
-
-### Phase 4: Fix
-
-1. Make the smallest root-cause fix.
-2. Avoid unrelated refactoring or feature work.
-3. Run the reproduction test/check.
-4. Run the relevant regression tests.
-5. If regressions appear, revise up to three attempts, then ask whether to continue, switch to Pipeline Path, or stop.
-
-If the fix requires a written implementation plan, invoke `/prizmkit-plan` with the handoff brief, then `/prizmkit-implement`. Do not switch to Pipeline Path solely because a current-session plan is useful.
-
-### Phase 5: Review
-
-Run `/prizmkit-code-review` against the bug context and current diff. The review should check root-cause coverage, reproduction strength, edge cases, regressions, and project conventions.
-
-If review needs fixes, apply accepted fixes directly in the current workspace and rerun the review loop according to `/prizmkit-code-review` rules.
-
-### Phase 6: User verification
-
-Use `AskUserQuestion` for the verification decision:
-
-```text
-Question: Fix passes the available checks. Would you like to verify before committing?
-Header: Verify
-Options:
-- Run the app — start the relevant dev command and manually check the scenario
-- Run a command — user provides a test/check command
-- Skip verification — automated checks are enough for now
+- Planner: perform required clarification, severity/priority calibration, validation, generation, and planner-local review; return the validated list without starting a fix.
+- Launcher: own runtime configuration and command construction; do not re-plan, implement the bug, or execute the command.
 ```
 
-If the user reports the fix still fails, return to Phase 4. After two additional failed attempts, ask whether to continue or switch to Pipeline Path.
+The direct path has no planner/launcher handoff. Preserve the confirmed bug evidence in the exit guidance so the user can enter the independent direct workflow.
 
-### Phase 7: Retrospective, commit, and merge decision
+## Selected Path Execution
 
-1. Run `/prizmkit-retrospective` only if the fix changed durable architecture/docs or structural interfaces.
-2. Run `/prizmkit-committer` with a `fix(<scope>):` message.
-3. Use `AskUserQuestion` for merge behavior:
+### Direct Path guidance
 
-```text
-Question: Fix committed on the fix branch. What would you like to do next?
-Header: Merge
-Options:
-- Merge back — merge to the original branch and delete the fix branch
-- Keep branch — retain it for PR/review workflow
-- Decide later — leave the branch as-is
-```
+1. Confirm one formal bug requirement and summarize the available evidence.
+2. Explain the independent direct topology in §Execution Topology.
+3. Provide one concise next-entry instruction containing the original report and evidence.
+4. End `bug-fix-workflow`. Do not create a branch, start coding, invoke lifecycle skills, or later own merge behavior.
 
-Do not push unless the user explicitly asks.
+If the problem expands into multiple requirements or remains too broad, keep control here and offer Pipeline Path.
 
-## Pipeline Path
-
-Use Pipeline Path for multiple bugs, uncertain/broad root cause, structural fix planning, or background autonomous execution.
+### Pipeline Path
 
 1. Invoke `bug-planner` with the handoff brief.
-2. `bug-planner` performs bug collection, severity/priority calibration, headless readiness checks, validation, and plan review.
-3. After `bug-planner` reports a validated `.prizmkit/plans/bug-fix-list.json`, show a concise summary: bug count, severity distribution, and review/validation outcome.
-4. Ask whether to proceed to launch.
+2. The planner owns bug collection, severity/priority calibration, headless readiness, validation, and plan review.
+3. After a validated `.prizmkit/plans/bug-fix-list.json` returns, show bug count, severity distribution, and review/validation outcome.
+4. Ask whether to construct the runtime command.
 5. If yes, invoke `bugfix-pipeline-launcher`.
 
-Do not duplicate launcher execution-mode or configuration questions in this workflow; the launcher owns them.
-
-## Existing List Operations
+Do not duplicate launcher configuration questions.
 
-If the user explicitly requests launch/status/logs/retry/stop for an existing bug list, invoke `bugfix-pipeline-launcher` with the user's intent and list path.
+### Existing list operations
 
-If the user wants to add, edit, deduplicate, or validate bugs, invoke `bug-planner`.
+- Run/status/logs/retry/stop command construction -> `bugfix-pipeline-launcher`.
+- Add/edit/deduplicate/validate -> `bug-planner`.
 
 ## Resume Guidance
 
 | State found | Action |
 |---|---|
-| On fix branch with uncommitted code changes | Resume Fast Path at review or verification depending on test/review status |
-| Fast Path `spec.md` / `plan.md` exists | Ask whether to continue implementation, review, or re-plan |
-| Fix committed on fix branch | Ask merge preference |
-| Valid `.prizmkit/plans/bug-fix-list.json` exists and user wants execution | Invoke `bugfix-pipeline-launcher` |
-| Bug list exists but intent is unclear | Ask launch / inspect / update / fix one bug interactively |
-| Recovery is ambiguous after interruption | Use `recovery-workflow` |
+| Direct workflow state exists | Exit this router and tell the user to resume its recorded requirement workflow |
+| Valid bug list with command intent | Invoke `bugfix-pipeline-launcher` |
+| Valid bug list with planning intent | Invoke `bug-planner` |
+| Interrupted bugfix task branch exists | Route to `recovery-workflow` for the exact continuation command |
+| Only diagnosis evidence exists | Resume lightweight diagnosis and route selection |
 
 ## Error Handling
 
 | Situation | Action |
 |---|---|
-| Bug report is too vague | Ask systematic clarification questions from `references/bug-diagnosis.md` |
-| Bug ID missing from bug list | Ask user for details or route to `bug-planner` to update the list |
-| Many bugs provided to Fast Path | Recommend Pipeline Path and ask via `AskUserQuestion` |
-| Cannot reproduce automatically | Record manual reproduction and proceed only with user awareness |
-| Fix causes regressions | Revise up to three attempts, then ask whether to continue or switch paths |
-| Root cause remains unclear | Continue diagnosis or switch to Pipeline Path based on user choice |
-| Merge conflict occurs | Stop and report the conflict; ask whether user wants manual resolution or to keep the branch |
+| Report is vague | Ask focused route-level questions from `references/bug-diagnosis.md` |
+| Bug ID is missing from list | Route to `bug-planner` to update the list |
+| Many reports are provided | Recommend Pipeline Path and ask via `AskUserQuestion` |
+| Evidence cannot establish a route | Continue diagnosis; do not guess or start implementation |
+| Planner cannot produce a valid list | Keep resolution inside `bug-planner` |
+| Launcher finds configuration issues | Keep remediation inside `bugfix-pipeline-launcher` |
 
 ## Handoff Map
 
 | From | To | Condition |
 |---|---|---|
-| `bug-fix-workflow` | `/prizmkit-plan` / `/prizmkit-implement` | Fast Path needs a written current-session plan |
-| `bug-fix-workflow` | `/prizmkit-code-review` | Fast Path fix is implemented |
-| `bug-fix-workflow` | `/prizmkit-retrospective` | Structural docs/architecture changed |
-| `bug-fix-workflow` | `/prizmkit-committer` | Fast Path fix is reviewed and ready |
-| `bug-fix-workflow` | `bug-planner` | User selects Pipeline Path or wants bug-list planning |
-| `bug-planner` | `bug-fix-workflow` | Planner completed from workflow-origin Pipeline Path |
-| `bug-fix-workflow` | `bugfix-pipeline-launcher` | User confirms launch after planner completion or explicitly requests existing-list execution |
+| `bug-fix-workflow` | `bug-planner` | User selects Pipeline Path or bug-list planning |
+| `bug-planner` | `bug-fix-workflow` | Planning completed from this workflow's Pipeline Path |
+| `bug-fix-workflow` | `bugfix-pipeline-launcher` | User requests command construction or an existing-list operation |
 
 ## Output
 
-- Fast Path: root-cause fix, reproduction evidence, relevant tests/checks, review result, optional structural doc sync, one fix commit, and merge decision.
-- Pipeline Path: handoff brief, validated `.prizmkit/plans/bug-fix-list.json` from `bug-planner`, and pipeline launch/status handled by `bugfix-pipeline-launcher`.
+- Direct guidance: confirmed diagnosis summary, independent direct-entry topology, and preserved bug evidence; no code change or implementation result.
+- Pipeline Path: handoff brief, validated `.prizmkit/plans/bug-fix-list.json`, and a command returned by `bugfix-pipeline-launcher`.

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

@@ -5,7 +5,7 @@ description: "Interactive bug planning that produces, validates, appends, and su
 
 # Bug Planner
 
-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.
+Interactive planning skill that creates, updates, validates, and summarizes the standardized `.prizmkit/plans/bug-fix-list.json` for later autonomous bug-fix execution. It never fixes source code.
 
 ## Invocation Commitment (Hard Rule)
 
@@ -23,7 +23,7 @@ The user chose this skill intentionally. Respect that choice.
 
 ## Scope Boundary (Hard Rule)
 
-This skill is PLANNING ONLY. You must NEVER:
+This skill is PLANNING ONLY. It may create, append, validate, and review bug planning artifacts, but it must never implement a fix or start execution. You must NEVER:
 - Create, modify, or delete source code files (*.js, *.ts, *.py, *.go, *.html, *.css, etc.)
 - Run build/install/test commands
 - Execute any bug fix action
@@ -37,7 +37,8 @@ After planning is complete, you MUST:
 1. Present the summary and recommended next step (invoking `bugfix-pipeline-launcher`)
 2. Ask the user explicitly whether they want to proceed to execution
 3. If the user wants to adjust → continue refining the bug list
-4. NEVER auto-execute the pipeline, launcher, or any fix step
+4. NEVER auto-execute the pipeline, launcher, composite workflow, or any fix step
+5. Return the validated bug list to the caller; only `bugfix-pipeline-launcher` prepares the runtime command
 
 ## User-Provided Content Priority (Hard Rule)
 
@@ -292,22 +293,9 @@ Only proceed to Phase 5 after user confirms.
 
 ## Local Generated-Plan Review Gate
 
-User requirement preserved verbatim: `there is a litter bug for prizm-code-review will to check git diff in working space and staged space , however the .prizmkit will be gitignored in most situation.  so do you think the content should be change to inline a new reference file instead of use prizmkit-code-review`
+Run this gate after `.prizmkit/plans/bug-fix-list.json` passes generation and validation, and before the final handoff. It applies whenever this session added or changed final bug entries. For validate-only, summary-only, or draft-save flows with no final content change, report that the gate is not applicable.
 
-Run this gate **after** `.prizmkit/plans/bug-fix-list.json` passes the validation/generate script and **before** any success output or next-step summary recommends `bugfix-pipeline-launcher`. This gate applies to Interactive Planning, From Log, From Tests, and append-to-existing bug list flows when the current session generated, appended, or rewrote final bug planning content. For Validate, Summary, or draft-save flows with no new final planning content, report: `Local generated-plan review: not applicable — no new final planning content written.`
-
-1. **Load the local reference**: read `${SKILL_DIR}/references/generated-plan-review.md` and follow it as the source of truth for this planner-output review loop.
-2. **Read actual planning artifacts directly**: inspect `.prizmkit/plans/bug-fix-list.json`, `.prizmkit/plans/bug-fix-list.draft.json` when present, and any pre-session or in-memory draft snapshot. Do not rely on `git status`, `git diff`, or `git diff --cached`, because `.prizmkit` planning artifacts are often gitignored or untracked.
-3. **Identify review scope**: compare by stable bug IDs and item fields against the pre-session list when one existed. Ignore root generator metadata such as `$schema`, `created_at`, and `created_by`. Review only newly added or changed bug entries; preserve unchanged historical entries except when needed to verify duplicate/root-cause overlap or dependency references.
-4. **Run the local checklist** from the reference: schema compatibility, dependency/DAG consistency, duplicate handling, root-cause overlap, description completeness, expected vs actual behavior, reproduction path, code-location hints, acceptance criteria measurability, user-provided wording preservation, task-scoped `user_context` isolation, and severity/priority calibration.
-5. **Keep the review planning-only**: do NOT start `bugfix-pipeline-launcher`, do NOT run the bugfix pipeline, do NOT run tests/builds/installs, and do NOT implement source-code fixes.
-6. **Apply accepted review fixes through the draft/source plan**: when a finding is accepted, update `.prizmkit/plans/bug-fix-list.draft.json` or the in-memory draft representation first, then regenerate the final file with:
-   ```bash
-   python3 ${SKILL_DIR}/scripts/validate-bug-list.py generate --input .prizmkit/plans/bug-fix-list.draft.json --output .prizmkit/plans/bug-fix-list.json
-   ```
-   Do not hand-patch the final JSON as the source of truth; map final-output findings back to draft entries before regeneration.
-7. **Revalidate after every accepted fix batch**: the generate script must pass again before the planner can proceed. If validation fails, fix the draft and rerun until pass.
-8. **Report the gate outcome** in the final summary: include local generated-plan review verdict, reviewed bug IDs, accepted fixes (or "none"), and final validation result.
+Read `${SKILL_DIR}/references/generated-plan-review.md` and follow it as the single source of truth. Review the actual draft and final artifacts directly because `.prizmkit` files may be gitignored. Keep the review planning-only, apply accepted findings to the draft/source representation, regenerate the final JSON, and require validation to pass again before reporting the review result.
 
 #### Success Output
 
@@ -382,16 +370,13 @@ Batch-parse failed test output:
 
 Triggers: "validate bug list", "check .prizmkit/plans/bug-fix-list.json".
 
-Validate existing `.prizmkit/plans/bug-fix-list.json`:
+Run the deterministic validator so this operation uses the same contract as generation:
+
+```bash
+python3 ${SKILL_DIR}/scripts/validate-bug-list.py validate .prizmkit/plans/bug-fix-list.json
+```
 
-1. Check JSON syntax
-2. Validate against `.prizmkit/dev-pipeline/templates/bug-fix-list-schema.json`
-3. Check for:
-   - Duplicate IDs
-   - Missing required fields
-   - Invalid status values
-   - Invalid priority values (must be 'high', 'medium', or 'low')
-4. Output: validation result with specific errors/warnings
+Report the validator's errors and warnings without modifying source code. If the file needs correction, update the planning draft or final planning artifact only, then rerun the validator.
 
 ## Operation: Summary