prizmkit 1.1.99 → 1.1.101

package/bundled/skills-windows/app-planner/references/rules/mobile/template.md

@@ -1,175 +0,0 @@
-# Mobile Rules — {{ project_name }}
-
-> This document was generated by the `mobile-rules` skill on {{ generated_at }}
-> Audience: All mobile developers + all AI coding assistants on this project
->
-> **Usage**:
-> 1. All AI coding assistants must read this file before generating or modifying any mobile code
-> 2. This document takes precedence over "general best practices" in AI training data
-> 3. Code conflicting with this document must not be committed
-
----
-
-## 0. TL;DR — Key Decisions at a Glance
-
-| Dimension | Decision |
-|-----------|----------|
-| Platform | {{ platform }} |
-| Min OS Version | {{ min_os_version }} |
-| Architecture Pattern | {{ architecture }} |
-| UI Framework | {{ ui_framework }} |
-| Navigation | {{ navigation }} |
-| State Management | {{ state_management }} |
-| Networking | {{ networking }} |
-| Local Persistence | {{ persistence }} |
-| Push Notifications | {{ push_notifications }} |
-| Background Tasks | {{ background_tasks }} |
-| Permissions Strategy | {{ permissions_strategy }} |
-| Test Coverage | {{ test_coverage }} |
-| Unit Test Framework | {{ unit_test_framework }} |
-| E2E Test Framework | {{ e2e_framework }} |
-| Distribution | {{ distribution }} |
-| Performance Target | {{ performance_target }} |
-| Accessibility Target | {{ a11y_target }} |
-
----
-
-## 1. Project Structure
-
-{{ FIXED_RULES_STRUCTURE }}
-
-{{ tech_stack_rules }}
-
----
-
-## 2. UI Development
-
-{{ FIXED_RULES_UI }}
-
-{{ ui_rules }}
-
----
-
-## 3. Navigation & Deep Linking
-
-{{ FIXED_RULES_NAVIGATION }}
-
-{{ navigation_rules }}
-
----
-
-## 4. State Management
-
-{{ FIXED_RULES_STATE }}
-
-{{ state_rules }}
-
----
-
-## 5. Networking
-
-{{ FIXED_RULES_NETWORKING }}
-
-{{ networking_rules }}
-
----
-
-## 6. Data Persistence
-
-{{ FIXED_RULES_PERSISTENCE }}
-
-{{ persistence_rules }}
-
----
-
-## 7. Platform Features
-
-{{ FIXED_RULES_PLATFORM_FEATURES }}
-
-{{ platform_features_rules }}
-
----
-
-## 8. Performance
-
-{{ FIXED_RULES_PERFORMANCE }}
-
-{{ performance_rules }}
-
----
-
-## 9. Accessibility
-
-{{ FIXED_RULES_A11Y }}
-
-{{ a11y_rules }}
-
----
-
-## 10. Security
-
-{{ FIXED_RULES_SECURITY }}
-
----
-
-## 11. Testing
-
-{{ FIXED_RULES_TEST }}
-
-{{ test_rules }}
-
----
-
-## 12. App Distribution
-
-{{ FIXED_RULES_DISTRIBUTION }}
-
-{{ distribution_rules }}
-
----
-
-## 13. AI Vibecoding Behavior Constraints
-
-### 13.1 Baseline Constraints (project-agnostic, always active)
-
-{{ FIXED_RULES_AI_BASE }}
-
-### 13.2 Project-Specific Hard Constraints
-
-- **Adding dependencies**: {{ ai_dependency_rule }}
-- **Modifying shared code**: {{ ai_breaking_change_rule }}
-- **Platform-specific code**: {{ ai_platform_rule }}
-
-### 13.3 Mandatory Pre-Actions (before every code generation)
-
-AI must complete the following in order before generating or modifying any mobile code:
-
-1. Read this file (`mobile-rules.md`)
-2. Read existing files in the target feature's directory to confirm whether similar functionality already exists
-3. If modifying shared widgets/components/services, search all callers and assess platform impact
-4. If modifying navigation routes or deep link schemes, assess all entry points
-
----
-
-## 14. Architecture
-
-{{ arch_rules }}
-
----
-
-## Appendix A: Deny List (Quick Reference)
-
-> This appendix is auto-generated by AI in Phase 4 by extracting all forbidden entries from each section.
-
-{{ deny_list_summary }}
-
-## Appendix B: Recommended Libraries & Tools
-
-> This appendix is auto-generated by AI in Phase 4 to recommend the supporting ecosystem based on platform and framework choices.
-
-{{ recommended_libs }}
-
----
-
-**Version**: v1.0 — Generated on {{ generated_at }}
-**Next review recommended**: before tech stack changes or platform migration

package/bundled/skills-windows/app-planner/references/rules-configuration.md

@@ -1,46 +0,0 @@
-# Rules Configuration — Detailed Q&A Procedures
-
-Procedural details for configuring per-layer development rules during app planning. SKILL.md retains Steps 1-3 and 5 (flow control); this file contains Step 4's full Q&A workflow.
-
-## Step 4: Configure Each Selected Layer — Full Q&A Workflow
-
-For each selected layer, run the 4-phase rule generation pattern:
-
-### Phase A — Load Layer Resources
-
-- Read `${SKILL_DIR}/references/rules/<layer>/fixed-rules.md` — industry-consensus rules injected without asking
-- Read `${SKILL_DIR}/references/rules/<layer>/question-bank.md` — interactive questions organized in groups (G1->G10): authoritative source for question text, options, "Recommended" markers, and Notes
-- Read `${SKILL_DIR}/references/rules/<layer>/question-manifest.json` — machine-readable structure for this layer. **This is your asking checklist.** It lists, per question: `group`, `required`, `maps_to` (which template placeholders the answer fills), and conditional fields (`required_if`, `auto_derived_when`, `options_vary_by`). Its `groups[]` carries each group's `quick_mode` flag, and `template_placeholders` is the expected-set for the Phase D self-check. Use the manifest to track coverage; use question-bank.md for the actual wording you present to the user. If a question id in one file is absent from the other, trust question-bank.md for content and note the drift.
-
-### Phase B — Interactive Q&A
-
-- Ask questions one group at a time (max 3 questions per message), as defined in question-bank.md
-- Each question shows a "Recommended" option to reduce decision cost
-- **Quick mode**: ask only the groups whose `quick_mode` is `true` in `question-manifest.json`. All other groups adopt recommended defaults silently. (The manifest is the single source of truth for quick-mode membership — do not hardcode group lists here.)
-- **Full mode**: ask all groups in manifest order (`groups[]`).
-- **Conditional questions** (driven by the manifest's per-question fields):
-  - `required_if: "<expr>"` — ask this question only when the expression over prior answers holds (e.g. Q14 `required_if: Q13 != D`). If the condition is false, the question is legitimately skipped — not a coverage gap.
-  - `auto_derived_when: "<expr>"` — when this holds, fill the mapped placeholder(s) from the prior answer without asking (e.g. backend Q6 `auto_derived_when: Q5 in [GraphQL, gRPC]`). Count as satisfied, not skipped.
-  - `options_vary_by: "<Qid>"` — the question is still asked; only its option list depends on that prior answer (e.g. framework/ORM options vary by language). Never affects whether the question is required.
-- Shortcut commands work at any point:
-  - `recommended` / `default` -> adopt all recommended for current group
-  - `all recommended` -> adopt all recommended for all remaining groups
-  - `skip` -> mark current group as "Not required at this stage"
-- Record answers in memory after each group. Track which manifest questions are answered, auto-derived, or conditionally skipped so Phase D can verify coverage.
-
-### Phase C — Auto-derivation
-
-- Read `${SKILL_DIR}/references/rules/<layer>/derivation-rules.md`
-- Match user answers against the trigger map using keyword matching
-- Derive platform-specific rules without asking the user (e.g., choosing Flutter -> auto-inject Flutter widget/persistence/navigation rules)
-
-### Phase D — Render and Write
-
-- Read `${SKILL_DIR}/references/rules/<layer>/template.md`
-- Fill all template placeholders with accumulated content from Phases A+B+C
-- **Post-render self-check** (driven by `question-manifest.json` -> `template_placeholders`):
-  1. **Coverage pass** — for every placeholder in `from_questions`, confirm it traces to an answered question OR an `auto_derived_when` path OR a conditionally-skipped question (`required_if` false). If a `from_questions` placeholder has no source, you skipped a required question — go back and ask it before writing.
-  2. **Residual pass** — scan the rendered document for any residual `{{ ` or ` }}`; count must be 0. Placeholders in `from_fixed_rules` / `auto_generated` / `metadata` are filled from fixed-rules.md, Phase D generation, and project metadata respectively — they are NOT expected to come from Q&A, but they MUST still be rendered (no residual braces).
-- Generate Appendix A (Deny List) and Appendix B (Recommended Tools) per template instructions — these fill the `auto_generated` placeholders
-- Create `.prizmkit/rules/` directory if it doesn't exist
-- Write `.prizmkit/rules/<layer>-rules.md`

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

@@ -1,379 +0,0 @@
----
-name: "bug-fix-workflow"
-description: "Interactive single-bug fix in current session. Guides through deep diagnosis Q&A → triage → reproduce → fix → review → commit without the background pipeline. Use this skill when the user wants to fix one specific bug right now, interactively. Trigger on: 'fix this bug', 'debug this', 'fix B-001', 'help me fix', 'let me fix this bug myself', 'interactive fix', 'manually fix bug'."
----
-
-# Bug Fix Workflow
-
-Fix a single bug interactively within the current AI CLI session. This is the in-session counterpart to `bugfix-pipeline-launcher` (which runs multiple bugs in the background).
-
-## When to Use
-
-- User wants to fix **one specific bug** right now, with full visibility
-- User has a stack trace or error and wants interactive debugging
-- User prefers hands-on fixing over background pipeline
-
-**Do NOT use when:**
-- User has multiple bugs to fix in batch → `bug-planner` + `bugfix-pipeline-launcher`
-- User wants to plan/collect bugs without fixing → `bug-planner`
-- User wants background autonomous fixing → `bugfix-pipeline-launcher`
-- User wants to build features → `feature-workflow`
-
-## Input
-
-**PRECONDITION:**
-
-| Input Source | Detection | Example |
-|---|---|---|
-| 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` |
-
-At least one input source must be provided. If none is clear, ask the user to describe the bug.
-
-## Fast Path
-
-For trivial bugs with clear root cause and minimal scope:
-
-### Eligibility Criteria (ALL must be true)
-- Root cause is immediately obvious (typo, missing null check, wrong variable name, off-by-one)
-- Fix is ≤10 lines of code in a single file
-- No cross-module impact
-- Existing tests cover the affected path (or bug is in untested utility)
-- No data model or API changes
-
-### Fast Path Workflow
-1. Branch Setup → `fix/<BUG_ID>-<short-desc>`
-2. Write reproduction test → confirm failing
-3. Apply fix → confirm test passes + full suite green
-4. Run `/prizmkit-code-review` for quality check
-5. Ask user: "Quick fix applied. Verify before commit? (Y/skip)"
-6. Commit with `fix(<scope>):` prefix
-7. Ask merge preference
-
-**Fast Path still requires**: fix branch, reproduction test, full test suite pass, code review, user merge decision.
-
----
-
-## Execution
-
-### Phase 0: Branch Setup
-
-**Goal**: Create an isolated working branch to keep main clean.
-
-1. **Check current branch**:
-   ```powershell
-   git branch --show-current
-   ```
-2. **If on `main` or a shared branch**: Create and switch to fix branch:
-   ```powershell
-   git checkout -b fix/<BUG_ID>-<short-description>
-   ```
-   Example: `git checkout -b fix/B-001-login-null-crash`
-3. **If already on a fix branch**: Confirm with user: "Continue on current branch `<branch-name>`, or create a new one?"
-4. **Record the original branch name** for later merge.
-
-**CHECKPOINT CP-BFW-0**: On a dedicated fix branch, not main/shared branch.
-
----
-
-### Phase 1: Deep Bug Diagnosis — Interactive Q&A
-
-**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 in Step 1.4. If ALL simple bug criteria are met, use `AskUserQuestion` to let the user choose the execution approach. Only proceed with fast path implementation if the user explicitly selects "Fix now". Never guess the user's intent from text — always present the interactive selection.
-
-**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 `.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
-
-#### Step 1.2: Systematic Bug Clarification
-
-Read `${SKILL_DIR}/references/bug-diagnosis.md` for the full question framework — reproduction conditions, expected vs actual behavior, scope/impact, data/state, and error details. Adapt to what the user has already provided; skip answered questions.
-
-#### Step 1.3: Confirmation Before Triage
-
-Summarize the bug understanding:
-
-```
-Bug Summary:
-- Symptom: [what happens]
-- Reproduction: [exact steps]
-- Environment: [where it occurs]
-- Expected: [correct behavior]
-- Impact: [who/what is affected]
-- Data trigger: [what data/state causes it]
-```
-
-Ask the user: "Is this summary accurate? Any details to add?"
-
-**CHECKPOINT CP-BFW-1**: Bug fully understood and confirmed by user.
-
----
-
-#### Step 1.4: Complexity Assessment
-
-After confirming bug understanding, assess whether this bug needs structured planning:
-
-**Simple bug → Fast Path candidate**: meets ALL of the Fast Path §Eligibility Criteria (obvious root cause, ≤10 lines, single file, no cross-module impact, no data/API changes).
-
-**User choice required (mandatory)** — Use `AskUserQuestion` to present interactive selectable options:
-
-```
-AskUserQuestion:
-  question: "This bug appears straightforward. How would you like to proceed?"
-  header: "Approach"
-  options:
-    - label: "Fix now (fast path)"
-      description: "Implement the fix directly in this session — branch → test → fix → review → commit"
-    - label: "Add to bug-fix-list.json (pipeline)"
-      description: "Add this bug to .prizmkit/plans/bug-fix-list.json via bug-planner, then use bugfix-pipeline-launcher to launch autonomous pipeline execution"
-    - label: "Full diagnosis"
-      description: "Continue with in-depth analysis before deciding"
-```
-
-- **Fix now** → Proceed with Fast Path Workflow (Phase 0 branch already set up)
-- **Add to bug-fix-list.json** → Invoke `bug-planner` to add this bug to `.prizmkit/plans/bug-fix-list.json`, then suggest user run `bugfix-pipeline-launcher` to start the pipeline. End this workflow.
-- **Full diagnosis** → Continue with full diagnosis (Phase 2 Triage)
-
-**Complex bug → Planning Path** (ANY is true):
-- Cross-module impact (>2 files affected)
-- Data model or API changes required
-- Root cause is uncertain or multi-layered
-- Fix requires structural changes
-- Multiple interrelated symptoms
-
-**User choice required (mandatory)** — Use `AskUserQuestion` to present interactive selectable options:
-
-```
-AskUserQuestion:
-  question: "This bug appears complex and will need structured planning. How would you like to proceed?"
-  header: "Approach"
-  options:
-    - label: "Plan and fix now"
-      description: "Create a plan and fix it in this session using /prizmkit-plan + /prizmkit-implement"
-    - label: "Add to bug-fix-list.json (pipeline)"
-      description: "Add this bug to .prizmkit/plans/bug-fix-list.json via bug-planner, then use bugfix-pipeline-launcher to launch autonomous pipeline execution"
-```
-
-- **Plan and fix now** → Invoke `/prizmkit-plan` with `artifact_dir=.prizmkit/bugfix/<BUG_ID>/`:
-  1. `/prizmkit-plan` generates `spec.md` (bug description + acceptance criteria) + `plan.md` (fix strategy + test specifications) under `.prizmkit/bugfix/<BUG_ID>/`
-  2. Invoke `/prizmkit-implement` to execute the plan (TDD: write failing reproduction test → implement fix → tests pass)
-  3. Run `/prizmkit-code-review` for quality check
-  4. Commit via `/prizmkit-committer` with `fix(<scope>):` prefix
-  5. **End workflow** — skip Phase 2-7. No `/prizmkit-retrospective` (bug fixes are incomplete features, not new architecture)
-- **Add to bug-fix-list.json** → Invoke `bug-planner` to add this bug to `.prizmkit/plans/bug-fix-list.json`, then suggest user run `bugfix-pipeline-launcher` to start the pipeline. End this workflow.
-
-**NEVER proceed with direct code changes without explicit user confirmation via `AskUserQuestion`. Do NOT render options as plain text — the user must be able to click/select.**
-
----
-
-### Phase 2: Triage
-
-**Goal**: Locate affected code, identify root cause, classify severity.
-
-> **Triage**: Classify error into: Runtime / Network / Auth / Data / Resource / Logic / Config / External. Check `.prizmkit/prizm-docs/` TRAPS for known patterns first. If a TRAPS match is found, use documented solution and reference the specific `.prizmkit/prizm-docs/` entry. If no match, trace the call chain from the stack frame to identify root cause from first principles.
-
-1. **Read project context**: `.prizmkit/prizm-docs/root.prizm` → relevant L1/L2 docs for affected modules
-2. **Locate affected code**: read the files mentioned in the error/stack trace or identified during diagnosis
-3. **Check known issues**: search `.prizmkit/prizm-docs/` TRAPS sections for matching patterns
-4. **If database-related**: read existing schema/model files to understand the data layer
-   ```powershell
-	   Get-ChildItem -Path . -File -Recurse -Depth 4 -Include *.prisma,*.sql,schema.*,*.entity.* -ErrorAction SilentlyContinue |
-	     Where-Object { $_.FullName -match '\\(migrations|models)\\|schema\.|\.prisma$|\.sql$|\.entity\.' } |
-	     Where-Object { $_.FullName -notmatch '\\(node_modules|\.git)(\\|$)' } |
-	     Select-Object -First 20 -ExpandProperty FullName
-   ```
-5. **Classify**: root cause (confirmed/suspected), blast radius, fix complexity
-6. **Present diagnosis to user**:
-   ```
-   Bug: Login page crash on submit
-   Root Cause: AuthService.handleLogin() receives null token when API returns 401
-   Affected Files: src/services/auth.ts (L42), src/pages/login.tsx (L28)
-   Fix Complexity: Low (null check + error handling)
-   ```
-   Ask: "Does this diagnosis look right? Should I proceed with the fix?"
-
-**CHECKPOINT CP-BFW-2**: Root cause identified and diagnosis confirmed by user.
-
-### Phase 3: Reproduce
-
-**Goal**: Create a failing test that proves the bug exists.
-
-> **Reproduce**: For API bugs: generate curl/HTTP request sequence with assertions. For UI bugs: generate step-by-step interaction guide. For logic bugs: generate unit test (arrange/act/assert). For data bugs: generate seed data + query sequence. The reproduction must FAIL with current behavior and be designed to PASS after the fix is applied — making it a regression guard.
-
-1. **Write a reproduction test** that demonstrates the bug:
-   - Name: `<module>.test.ts` → add a test case named `should handle <bug scenario>`
-   - The test captures the exact failure condition
-2. **Run the test** → confirm it **fails** (red)
-3. **Show result to user**: "Reproduction test written and confirmed failing."
-
-If the bug is hard to reproduce automatically (e.g. environment-specific):
-- Ask the user for reproduction steps
-- Write a manual reproduction checklist instead
-- Proceed to Phase 4 with the manual checklist
-
-**CHECKPOINT CP-BFW-3**: Bug reproduction test written and confirmed failing.
-
-### Phase 4: Fix
-
-**Goal**: Implement the minimal fix. Red test → green.
-
-1. **Implement the fix**:
-   - Change the minimum amount of code to fix the root cause
-   - Do NOT refactor or add unrelated improvements — fix the bug only
-   - Follow existing code conventions (read from `.prizmkit/prizm-docs/` RULES/PATTERNS)
-   - If the fix involves database changes: read existing schema first, follow existing naming/constraint conventions
-2. **Run the reproduction test** → must **pass** (green)
-3. **Run the full module test suite** → must pass (no regressions)
-4. **Show the fix to user**:
-   - Summary of changes made
-   - Test results (reproduction + regression)
-   - Ask: "Fix looks good? Any concerns?"
-
-**CHECKPOINT CP-BFW-4**: Fix implemented and all tests passing (reproduction + regression).
-
-If the fix causes test regressions:
-- Show which tests broke and why
-- Revise the fix (max 3 attempts)
-- If still failing after 3 attempts, escalate to user with analysis
-
-### Phase 5: Review
-
-**Goal**: Verify fix quality before committing.
-
-1. **Run `/prizmkit-code-review`** to review the fix:
-   - Reviews git diff against the bug context (root cause, fix approach, affected areas)
-   - Iterative Reviewer Agent + Dev Agent loop (max 3 rounds)
-   - Checks: root cause addressed (not just symptom), edge cases covered, reproduction test thoroughness, project conventions
-2. **If PASS**: Proceed to Phase 6
-3. **If NEEDS_FIXES after max rounds**: Present unresolved findings to user, ask whether to proceed or revise
-
-**CHECKPOINT CP-BFW-5**: Code review completed and quality verified.
-
-### Phase 6: User Verification
-
-**Goal**: Let the user verify the fix works as expected before committing.
-
-1. **Ask user**: "Fix passes all tests. Would you like to verify before committing?"
-   - **(a) Run the app** — Start the dev server so you can manually test the fix scenario
-   - **(b) Run a specific command** — Specify a test or script to run
-   - **(c) Skip verification** — Proceed directly to commit (automated tests already pass)
-2. **If (a)**: Detect and suggest dev server command (e.g. `npm run dev`, `python manage.py runserver`), start it, wait for user confirmation: "Fix verified? (yes/no)"
-3. **If (b)**: Run the specified command, show results, ask confirmation
-4. **If (c)**: Proceed to Phase 7
-
-If user reports the fix is NOT working:
-- Return to Phase 4 (max 2 more attempts)
-- If still failing: escalate with analysis
-
-**CHECKPOINT CP-BFW-6**: Fix manually verified by user and working as expected.
-
----
-
-### Phase 7: Commit & Merge
-
-**Goal**: Commit the fix and offer to merge back to the original branch.
-
-1. **Run `/prizmkit-committer`**:
-   - Commit message: `fix(<scope>): <description>`
-   - Include both fix code and reproduction test
-   - Do NOT push (user decides when to push)
-   - `/prizmkit-committer` is a pure commit tool — it does NOT modify `.prizmkit/prizm-docs/` or any project files
-   - No `/prizmkit-retrospective` — bug fixes are incomplete features, not new architecture worth documenting
-2. **Ask merge preference**:
-   ```
-   Fix committed on branch `fix/<BUG_ID>-<short-desc>`.
-   What would you like to do?
-   (a) Merge to <original-branch> and delete fix branch
-   (b) Keep fix branch (for PR review workflow)
-   (c) Decide later
-   ```
-3. **If (a)**:
-   ```powershell
-   git checkout <original-branch>
-   git merge fix/<BUG_ID>-<short-description>
-   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 .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 .prizmkit/plans/bug-fix-list.json
-   Or retry the pipeline to pick up remaining bugs.
-   ```
-
-**CHECKPOINT CP-BFW-7**: Fix committed and merge decision made.
-
-## Resume — Interruption Recovery
-
-The workflow supports resuming from the last completed phase by detecting existing artifacts.
-
-**Detection logic**: Resume from git branch state plus, for the complex "Plan and fix now" path, the planning docs under `.prizmkit/bugfix/<BUG_ID>/`:
-
-| State Found | Resume From |
-|---------------|------------|
-| Not on a `fix/<BUG_ID>-*` branch | Phase 0: Branch Setup |
-| On `fix/<BUG_ID>-*` branch, no diagnosis done | Phase 1: Deep Bug Diagnosis |
-| `spec.md` + `plan.md` exist, no code changes | Phase 4: Fix (complex path) |
-| Reproduction test written, fix not yet green | Phase 4: Fix |
-| Fix code + passing tests, not yet reviewed | Phase 5: Review |
-| Review passed, not committed | Phase 6: User Verification |
-| Committed on fix branch | Phase 7: Merge decision |
-
-**Resume**: If a `fix/<BUG_ID>-*` branch already exists (and, for the complex path, a matching `.prizmkit/bugfix/<BUG_ID>/` directory), resume from the detected state instead of starting fresh.
-
----
-
-## Artifacts
-
-This workflow favors code + tests over documents — a bug fix is an incomplete feature, not new architecture worth heavy documentation. What gets produced depends on the path taken:
-
-- **Fast path / interactive path** (Phase 2–7): no markdown artifacts. Output is the fix code, a reproduction test, and a git commit on the fix branch. Diagnosis and triage are presented inline to the user, not written to disk.
-- **Complex "Plan and fix now" path**: `/prizmkit-plan` writes `spec.md` (bug description + acceptance criteria) and `plan.md` (fix strategy + test specs) under `.prizmkit/bugfix/<BUG_ID>/`. These are the only persisted documents, and they double as resume anchors.
-
-## Comparison with Pipeline Bug Fix
-
-| Dimension | bug-fix-workflow (this skill) | bugfix-pipeline-launcher |
-|-----------|-------------------------------|-----------------------------|
-| Scope | One bug at a time | All bugs in batch |
-| Execution | Interactive, in-session | Foreground or background daemon |
-| Diagnosis | Deep interactive Q&A with user | Automated from bug description |
-| Branch | Creates `fix/<BUG_ID>-*` branch | Pipeline manages branches |
-| Visibility | Full user interaction at each phase | Async, check status periodically |
-| User verification | Yes (Phase 6) | No (automated) |
-| Best for | Complex bugs needing user input | Batch of well-defined bugs |
-| Artifacts | Code + test (+ spec/plan on complex path) | Pipeline-managed |
-| Commit prefix | `fix(<scope>):` | `fix(<scope>):` |
-
-## Error Handling
-
-| Scenario | Action |
-|----------|--------|
-| 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) |
-| Root cause unclear after investigation | Present findings, ask user for guidance |
-| Affected files are in unfamiliar module | Read `.prizmkit/prizm-docs/` L1/L2 for that module first |
-| Branch conflict during merge | Show conflict, ask user to resolve or keep branch |
-
-## HANDOFF
-
-| From | To | Condition |
-|------|----|-----------|
-| `bug-planner` | **this skill** | User picks one bug to fix interactively |
-| `bugfix-pipeline-launcher` | **this skill** | User wants to fix a stuck/complex bug manually |
-| **this skill** | `bugfix-pipeline-launcher` | After fixing, user wants to continue with remaining bugs |
-| **this skill** | `prizmkit-committer` | Built into Phase 7 (pure commit, no doc sync) |
-
-## Output
-
-- Fixed code with reproduction test
-- On the complex path only: `.prizmkit/bugfix/<BUG_ID>/spec.md` + `plan.md`
-- Git commit with `fix(<scope>):` prefix on dedicated fix branch

package/bundled/skills-windows/bug-fix-workflow/references/bug-diagnosis.md

@@ -1,41 +0,0 @@
-# Bug Diagnosis — Question Framework
-
-Procedural details for systematic bug clarification in bug-fix-workflow Phase 1.
-
-## Step 1.2: Systematic Bug Clarification
-
-Ask questions across these dimensions until every aspect is clear. **Adapt to what the user has already provided** — skip questions that are already answered.
-
-### Reproduction Conditions
-- What exact steps trigger the bug? (step-by-step)
-- Which environment/browser/OS/version?
-- Is it reproducible every time, or intermittent?
-- When did it first appear? (after a specific change/deploy?)
-- Does it happen for all users or only specific accounts/roles/data?
-
-### Expected vs Actual Behavior
-- What should happen? (the correct behavior)
-- What actually happens? (the buggy behavior)
-- Is there partial functionality (e.g., works for some inputs but not others)?
-
-### Scope and Impact
-- Which features/pages/modules are affected?
-- Are there workarounds users are currently using?
-- Is this blocking other work?
-- Are there related symptoms elsewhere?
-
-### Data and State
-- What data/state triggers the issue? (specific input values, DB state, user session state)
-- Does the bug involve data corruption or just incorrect display/behavior?
-- If database-related: which tables/records are affected?
-
-### Error Details (if not already provided)
-- Full error message and stack trace?
-- Browser console errors?
-- Server-side logs?
-- Network request/response details?
-
-> Complexity assessment (simple vs complex routing) and the comparison with the
-> background pipeline live in the skill body (§Step 1.4 and §Comparison with
-> Pipeline Bug Fix) — they are flow-control decisions, kept here only by pointer
-> to avoid drift.