prizmkit 1.0.0 → 1.0.1

package/bundled/skills/prizmkit-analyze/SKILL.md

@@ -0,0 +1,194 @@
+---
+name: "prizmkit-analyze"
+description: "Cross-document consistency analysis for spec.md, plan.md, and tasks.md. Detects duplications, ambiguities, gaps, and rule conflicts. Read-only. (project)"
+---
+
+# PrizmKit Analyze
+
+Perform a non-destructive cross-artifact consistency and quality analysis across spec.md, plan.md, and tasks.md before implementation. Identifies duplications, ambiguities, underspecified items, rule conflicts, and coverage gaps.
+
+### When to Use
+- After `prizmkit.plan` to validate spec-plan alignment before task generation
+- After `prizmkit.tasks` to validate full spec-plan-tasks consistency before implementation
+- User says "analyze", "check consistency", "validate spec", "review plan"
+- Before `prizmkit.implement` as a quality gate
+
+## Commands
+
+### prizmkit.analyze
+
+Cross-document consistency analysis.
+
+**PRECONDITION:** `spec.md` and `plan.md` exist in `.prizmkit/specs/###-feature-name/`. `tasks.md` is recommended but not required.
+
+## Operating Constraints
+
+**STRICTLY READ-ONLY**: Do **not** modify any files. Output a structured analysis report to conversation only. Offer an optional remediation plan (user must explicitly approve before any edits).
+
+**Prizm Rules Authority**: The project rules in `.prizm-docs/root.prizm` RULES section are **non-negotiable** within this analysis scope. Rule conflicts are automatically CRITICAL severity and require adjustment of the spec, plan, or tasks — not dilution or silent ignoring of the rule. If a rule itself needs to change, that must occur via a separate `prizmkit.doc.update`.
+
+## Execution Steps
+
+### Step 1: Initialize Analysis Context
+
+Locate the current feature directory in `.prizmkit/specs/###-feature-name/` by checking the current Git branch name or scanning `.prizmkit/specs/` for the most recent feature directory.
+
+Derive absolute paths:
+- SPEC = `.prizmkit/specs/###-feature-name/spec.md`
+- PLAN = `.prizmkit/specs/###-feature-name/plan.md`
+- TASKS = `.prizmkit/specs/###-feature-name/tasks.md` (optional)
+
+Abort with an error message if spec.md or plan.md is missing — instruct the user to run the missing prerequisite command (`prizmkit.specify` or `prizmkit.plan`).
+
+If tasks.md is missing, proceed with spec+plan analysis only and note reduced coverage in the report.
+
+### Step 2: Load Artifacts (Progressive Disclosure)
+
+Load only the minimal necessary context from each artifact:
+
+**From spec.md:**
+- Overview/Context
+- Functional Requirements
+- Non-Functional Requirements
+- User Stories and Acceptance Criteria
+- Scope Boundaries
+- Edge Cases (if present)
+
+**From plan.md:**
+- Architecture/stack choices
+- Component Design
+- Data Model references
+- API Contracts
+- Testing Strategy
+- Risk Assessment
+
+**From tasks.md (if exists):**
+- Task IDs and Descriptions
+- Phase grouping (Setup, Foundational, User Stories, Polish)
+- Parallel markers `[P]`
+- Referenced file paths
+
+**From .prizm-docs/root.prizm:**
+- RULES section (MUST/NEVER/PREFER directives)
+- PATTERNS section (project-wide code patterns)
+- TECH_STACK section (for consistency checking)
+
+### Step 3: Build Semantic Models
+
+Create internal representations (do not include raw artifacts in output):
+
+- **Requirements inventory**: Each functional + non-functional requirement with a stable key (derive slug from imperative phrase; e.g., "User can upload file" -> `user-can-upload-file`)
+- **User story/action inventory**: Discrete user actions with acceptance criteria
+- **Task coverage mapping**: Map each task to one or more requirements or stories (inference by keyword / explicit reference patterns like IDs or key phrases)
+- **Prizm rule set**: Extract MUST/NEVER/PREFER normative statements from root.prizm RULES
+
+### Step 4: Detection Passes
+
+Focus on high-signal findings. Limit to **50 findings total**; aggregate remainder in overflow summary.
+
+#### A. Duplication Detection
+- Identify near-duplicate requirements across spec.md sections
+- Mark lower-quality phrasing for consolidation
+
+#### B. Ambiguity Detection
+- Flag vague adjectives (fast, scalable, secure, intuitive, robust) lacking measurable criteria
+- Flag unresolved placeholders (TODO, TBD, ???, `<placeholder>`, `[NEEDS CLARIFICATION]`)
+
+#### C. Underspecification
+- Requirements with verbs but missing object or measurable outcome
+- User stories missing acceptance criteria alignment
+- Tasks referencing files or components not defined in spec/plan
+- Plan components with no corresponding spec requirement
+
+#### D. Prizm Rules Alignment
+- Any requirement or plan element conflicting with a MUST/NEVER directive
+- Missing mandated patterns from PATTERNS section
+- Tech stack inconsistencies between plan and root.prizm TECH_STACK
+
+#### E. Coverage Gaps
+- Requirements with zero associated tasks (if tasks.md loaded)
+- Tasks with no mapped requirement/story ("orphan tasks")
+- Non-functional requirements not reflected in tasks (performance, security, etc.)
+- User stories without corresponding plan components
+
+#### F. Inconsistency
+- Terminology drift (same concept named differently across files)
+- Data entities referenced in plan but absent in spec (or vice versa)
+- Task ordering contradictions (e.g., integration tasks before foundational setup without dependency note)
+- Conflicting requirements (e.g., one requires REST while other specifies GraphQL)
+
+### Step 5: Severity Assignment
+
+Use this heuristic to prioritize findings:
+
+- **CRITICAL**: Violates Prizm RULES MUST/NEVER directive, missing core artifact section, or requirement with zero coverage that blocks baseline functionality
+- **HIGH**: Duplicate or conflicting requirement, ambiguous security/performance attribute, untestable acceptance criterion
+- **MEDIUM**: Terminology drift, missing non-functional task coverage, underspecified edge case
+- **LOW**: Style/wording improvements, minor redundancy not affecting execution order
+
+### Step 6: Produce Compact Analysis Report
+
+Output a Markdown report (**no file writes**) with the following structure:
+
+```
+## Consistency Analysis Report
+
+| ID | Category | Severity | Location(s) | Summary | Recommendation |
+|----|----------|----------|-------------|---------|----------------|
+| A1 | Duplication | HIGH | spec.md §2.1, §3.4 | Two similar requirements... | Merge phrasing; keep clearer version |
+| D1 | Rules Alignment | CRITICAL | plan.md §Architecture | Conflicts with MUST rule... | Adjust plan to align with rule |
+
+**Coverage Summary:**
+
+| Requirement Key | Has Task? | Task IDs | Notes |
+|-----------------|-----------|----------|-------|
+
+**Prizm Rules Alignment Issues:** (if any)
+
+**Unmapped Tasks:** (if any)
+
+**Metrics:**
+- Total Requirements: N
+- Total Tasks: N
+- Coverage %: N% (requirements with >=1 task)
+- Ambiguity Count: N
+- Duplication Count: N
+- Critical Issues: N
+```
+
+### Step 7: Provide Next Actions
+
+At end of report, output a concise Next Actions block:
+
+- If CRITICAL issues exist: **Recommend resolving before `prizmkit.implement`**
+- If only LOW/MEDIUM: User may proceed, but provide improvement suggestions
+- Provide explicit command suggestions:
+  - "Run `prizmkit.specify` to refine requirements"
+  - "Run `prizmkit.plan` to adjust architecture"
+  - "Edit tasks.md to add coverage for requirement X"
+  - "Proceed to `prizmkit.implement`" (if clean)
+
+### Step 8: Offer Remediation
+
+Ask the user: "Would you like me to suggest concrete remediation edits for the top N issues?" (Do NOT apply them automatically.)
+
+## Operating Principles
+
+### Context Efficiency
+- **Minimal high-signal tokens**: Focus on actionable findings, not exhaustive documentation
+- **Progressive disclosure**: Load artifacts incrementally; don't dump all content into analysis
+- **Token-efficient output**: Limit findings table to 50 rows; summarize overflow
+- **Deterministic results**: Rerunning without changes should produce consistent IDs and counts
+
+### Analysis Guidelines
+- **NEVER modify files** (this is read-only analysis)
+- **NEVER hallucinate missing sections** (if absent, report them accurately)
+- **Prioritize Prizm Rules violations** (these are always CRITICAL)
+- **Use examples over exhaustive rules** (cite specific instances, not generic patterns)
+- **Report zero issues gracefully** (emit success report with coverage statistics)
+
+**HANDOFF:** `prizmkit.implement` (if clean) or `prizmkit.specify` / `prizmkit.plan` / `prizmkit.tasks` (if issues found)
+
+## Output
+
+Analysis report is output to conversation only. No files are created or modified.

package/bundled/skills/prizmkit-api-doc-generator/SKILL.md

@@ -0,0 +1,56 @@
+---
+name: "prizmkit-api-doc-generator"
+tier: 2
+description: "[Tier 2] Extract API documentation from source code into OpenAPI/Markdown. May miss undocumented or dynamically generated endpoints. (project)"
+---
+
+# PrizmKit API Doc Generator
+
+Generate API documentation from source code by scanning routes, controllers, and handlers. Produces OpenAPI 3.0 specs or Markdown reference docs.
+
+## Commands
+
+### prizmkit.api-docs [api-directory]
+
+Generate API documentation from source code.
+
+**STEPS:**
+
+1. Read `.prizm-docs/` for project tech stack (framework, language, API style: REST / GraphQL / gRPC)
+2. Scan API source files (routes, controllers, handlers):
+   - Detect routing patterns based on framework:
+     - Express/Fastify: `app.get()`, `router.post()`, etc.
+     - Django/Flask: `@app.route()`, `urlpatterns`
+     - Spring: `@GetMapping`, `@PostMapping`, etc.
+     - Go: `http.HandleFunc`, gorilla/mux, chi routes
+   - If `api-directory` is specified, limit scan to that directory
+3. Extract for each endpoint:
+   - **HTTP method and path**: GET /api/users/:id
+   - **Request parameters**:
+     - Path parameters (with types)
+     - Query parameters (with types and defaults)
+     - Request body schema (from types, validation decorators, or inline definitions)
+   - **Response body schemas**: Success and error response structures
+   - **Authentication requirements**: Which auth mechanism is required (JWT, API key, session, none)
+   - **Error responses**: Common error codes and their meanings (400, 401, 403, 404, 500)
+   - **Description**: From JSDoc comments, docstrings, or function/handler names
+4. Generate documentation in requested format:
+   - **OpenAPI 3.0 YAML** (default): Full spec with schemas, security definitions, and server info
+   - **Markdown API reference**: Human-readable endpoint documentation
+   - **Both**: Generate both formats
+5. Include examples for each endpoint:
+   - Sample request (curl command)
+   - Sample success response (JSON)
+   - Sample error response (JSON)
+6. Write to `docs/api/` directory:
+   - `docs/api/openapi.yaml` for OpenAPI spec
+   - `docs/api/API_REFERENCE.md` for Markdown docs
+
+## Path References
+
+All internal asset paths MUST use `${SKILL_DIR}` placeholder for cross-IDE compatibility.
+
+## Output
+
+- `docs/api/openapi.yaml`: OpenAPI 3.0 specification
+- `docs/api/API_REFERENCE.md`: Markdown API reference

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

@@ -0,0 +1,351 @@
+---
+name: "prizmkit-bug-fix-workflow"
+tier: 1
+description: "[Tier 1] End-to-end bug fix workflow: triage → reproduce → fix → verify → commit. Orchestrates existing skills into a closed-loop 5-phase pipeline with standardized input/output artifacts. (project)"
+---
+
+# PrizmKit Bug Fix Workflow
+
+End-to-end orchestration skill for bug fixes. Chains existing PrizmKit skills (error-triage, bug-reproducer, implement, code-review, committer) into a closed-loop 5-phase pipeline with standardized artifacts.
+
+## Overview
+
+```
+bug-planner → bug-fix-list.json → Bug Fix Pipeline → fix-plan.md + fix-report.md
+  (plan)         (input)             (5 phases)         (2 artifacts per bug)
+```
+
+### Pipeline Phases
+
+| Phase | Name | Skill Used | Artifact |
+|-------|------|-----------|----------|
+| 1 | Triage 分诊 | `prizmkit.error-triage` | → `fix-plan.md` |
+| 2 | Reproduce 复现 | `prizmkit.bug-reproduce` | (reproduction test) |
+| 3 | Fix 修复 | `prizmkit.implement` | (code changes) |
+| 4 | Verify 验证 | `prizmkit.code-review` | (review report) |
+| 5 | Commit & Learn | `prizmkit.committer` | → `fix-report.md` |
+
+### Artifacts — Fixed at 2, NEVER more
+
+Each bug produces exactly **2 artifact documents**:
+
+1. **`fix-plan.md`** — Generated after Phase 1 Triage. Contains root cause analysis, impact assessment, test strategy, and fix approach.
+2. **`fix-report.md`** — Generated after Phase 5 Commit. Contains fix details, verification results, knowledge captured, and acceptance criteria verification.
+
+Artifacts are stored at: `.prizmkit/bugfix/<BUG_ID>/`
+
+## Commands
+
+### prizmkit.bug-fix \<bug-description-or-error\>
+
+Execute the full bug fix pipeline for a single bug.
+
+**INPUT FORMATS** (any of the following):
+- Natural language bug description
+- Stack trace / error log
+- Failed test case output
+- User reproduction steps
+- Reference to a `bug-fix-list.json` entry
+
+### prizmkit.bug-fix-batch \<bug-fix-list.json\>
+
+Execute the bug fix pipeline for all pending bugs in a standardized `bug-fix-list.json` file.
+
+- Processes bugs in priority order (lower priority number = processed first)
+- Skips bugs with status ≠ `pending`
+- Updates status in `bug-fix-list.json` as each bug progresses through phases
+
+---
+
+## Phase 1: Triage — 分诊分类
+
+**Goal**: Classify the bug, identify scope and severity, check known issues, produce `fix-plan.md`.
+
+**STEPS:**
+
+1. **Parse bug input**: Extract:
+   - Error message / stack trace (if provided)
+   - Expected vs actual behavior
+   - Steps to reproduce (if provided)
+   - Environment details (OS, runtime, browser)
+   - Affected feature / module (if identifiable)
+
+2. **Invoke `prizmkit.error-triage`**:
+   - Receive: error category, subcategory, root cause analysis, affected files
+   - Receive: severity rating (CRITICAL / HIGH / MEDIUM / LOW)
+
+3. **Check TRAPS for known issues**:
+   - Read `.prizm-docs/` TRAPS sections for identified modules
+   - If matching trap found:
+     - Set `KNOWN_ISSUE=true`, `SKIP_REPRODUCE=true`
+     - Include documented solution in fix-plan.md
+     - Jump to Phase 3
+
+4. **Generate `fix-plan.md`** at `.prizmkit/bugfix/<BUG_ID>/fix-plan.md`:
+
+   Required sections:
+   - **Bug Summary**: ID, title, severity, source type, affected feature
+   - **Root Cause Analysis**: error classification, root cause, call chain, TRAP match status
+   - **Impact Assessment**: directly affected files (with impact level), potentially affected modules (with risk level), cross-module impact notes
+   - **Test Strategy**: verification type, reproduction test design, regression test plan, manual verification steps (if verification_type=manual/hybrid)
+   - **Fix Approach**: proposed fix, fix scope (estimated lines changed), constraints
+
+**CHECKPOINT CP-BF-1**: `fix-plan.md` exists.
+
+**DECISION GATE — Fast Path**:
+- If severity ∈ {low, medium} AND root cause confidence is HIGH AND estimated change < 10 lines:
+  → Skip Phase 2, go directly to Phase 3
+- Otherwise → proceed to Phase 2
+
+---
+
+## Phase 2: Reproduce — 复现确认
+
+**Goal**: Create an automated reproduction that proves the bug exists.
+
+**STEPS:**
+
+1. **Invoke `prizmkit.bug-reproduce`** with triage results and bug description
+
+2. **Receive and execute reproduction**:
+   - Run the generated reproduction test
+   - Verify it FAILS (proving the bug exists)
+
+3. **Handle reproduction result**:
+   - **Success** (test fails as expected): record as regression baseline, proceed to Phase 3
+   - **Failure** (cannot reproduce): refine and retry, **max 2 rounds**
+   - **After 2 failed rounds**: set status to `needs_info`, output questions for reporter, STOP
+
+**CHECKPOINT CP-BF-2**: Reproduction test exists and FAILS.
+
+**KEY RULES:**
+- Reproduction test MUST be automated
+- MUST fail with current code and pass after fix
+- Use project's existing test framework and conventions
+- Naming convention: `test_bugfix_<short-description>.<ext>`
+
+---
+
+## Phase 3: Fix — 修复实现
+
+**Goal**: Implement the fix using TDD — reproduction test goes red → green.
+
+**STEPS:**
+
+1. **Read context**: fix-plan.md, reproduction test, `.prizm-docs/` (TRAPS, RULES, PATTERNS)
+
+2. **Plan fix** (lightweight, inline — NO spec/plan/tasks files):
+   - Identify exact code location(s) to modify
+   - Determine minimal fix approach
+   - Assess regression risk
+
+3. **Implement fix** via `prizmkit.implement` in TDD mode:
+   - Reproduction test is the "red test"
+   - Implement minimal code change to make it pass
+   - Ensure all existing tests still pass
+
+4. **Local verification**:
+   - Reproduction test → MUST PASS (green)
+   - Module test suite → MUST PASS (no regression)
+
+**CHECKPOINT CP-BF-3**: Reproduction test passes, module tests pass.
+
+**FIX LOOP**: Max 3 rounds. If still failing → escalate to user.
+
+**KEY RULES:**
+- Do NOT create `.prizmkit/specs/` directories
+- Do NOT create spec.md, plan.md, or tasks.md
+- Fix MUST be minimal and targeted — no scope creep
+- If fix requires architectural changes → STOP, recommend creating a Feature instead
+
+---
+
+## Phase 4: Verify — 代码审查与回归验证
+
+**Goal**: Ensure fix correctness and zero regressions.
+
+**STEPS:**
+
+1. **Invoke `prizmkit.code-review`** (scoped to changed files only):
+   - Review dimensions for bug fix:
+     - **Fix correctness**: Does it address the root cause?
+     - **Regression safety**: Does it break existing behavior?
+     - **Code quality**: Is the fix clean and maintainable?
+     - **Test coverage**: Is the reproduction test adequate?
+   - Verdict: PASS / PASS_WITH_WARNINGS / NEEDS_FIXES
+
+2. **Run full test suite**: All tests MUST pass
+
+3. **Handle review results**:
+   - PASS / PASS_WITH_WARNINGS → proceed to Phase 5
+   - NEEDS_FIXES → return to Phase 3 (max 2 review rounds)
+
+**CHECKPOINT CP-BF-4**: Code review passes, all tests green.
+
+**MANUAL VERIFICATION GATE** (when verification_type=manual or hybrid):
+- Pipeline PAUSES after automated review passes
+- Output UAT checklist from fix-plan.md
+- Set status to `verifying`, wait for user confirmation
+- Resume to Phase 5 after user sign-off
+
+---
+
+## Phase 5: Commit & Learn — 提交与知识积累
+
+**Goal**: Commit with proper conventions, capture lessons, generate `fix-report.md`.
+
+**STEPS:**
+
+1. **Invoke `prizmkit.committer`**:
+   - Commit message: `fix(<scope>): <description>`
+   - Include fix code + reproduction test
+   - Do NOT run `prizmkit.summarize` (no REGISTRY.md entry)
+   - Do NOT push
+
+2. **Update TRAPS** (if new pitfall discovered):
+   - Append to affected module's TRAPS section in `.prizm-docs/`
+   - Format: `- TRAP: <description> | FIX: <solution> | DATE: YYYY-MM-DD`
+   - If no new pitfall: skip
+
+3. **Generate `fix-report.md`** at `.prizmkit/bugfix/<BUG_ID>/fix-report.md`:
+
+   Required sections:
+   - **Bug Resolution Summary**: ID, title, status (✅ FIXED), phases completed, duration
+   - **What Was Fixed**: changes made (file, change type, description), diff summary, commit message
+   - **Verification Results**: reproduction test before/after, regression test results, review verdict
+   - **Knowledge Captured**: TRAPS updated (yes/no with details), prevention recommendation
+   - **Acceptance Criteria Verification**: checklist with pass/fail for each criterion
+
+   Additional sections (when verification_type=manual or hybrid):
+   - **Manual Verification Results**: UAT checklist results, sign-off status, reviewer, date
+
+**CHECKPOINT CP-BF-5**: Commit recorded, fix-report.md written.
+
+---
+
+## Fast Path — 快速修复路径
+
+For LOW/MEDIUM severity bugs with obvious root cause and high confidence:
+
+```
+Phase 1 (Triage) → Phase 3 (Fix) → Phase 5 (Commit)
+```
+
+Skip Phase 2 (Reproduce) and Phase 4 (full Review).
+- Still write a basic test for the fix
+- Still use `fix(<scope>):` commit convention
+- Still update TRAPS if applicable
+- Still generate both fix-plan.md and fix-report.md
+
+**CRITERIA**:
+- Triage confidence is HIGH
+- Root cause is a single, obvious code error
+- Fix is less than 10 lines of code changes
+- No cross-module impact
+
+---
+
+## Status Mapping
+
+`bug-fix-list.json` status values map to pipeline phases:
+
+| Phase | Entry Status | In-Progress | Success Exit | Failure Exit |
+|-------|-------------|-------------|-------------|-------------|
+| Phase 1: Triage | `pending` | `triaging` | → `reproducing` | → `failed` |
+| Phase 2: Reproduce | `reproducing` | `reproducing` | → `fixing` | → `needs_info` |
+| Phase 3: Fix | `fixing` | `fixing` | → `verifying` | → `failed` (3 rounds) |
+| Phase 4: Verify | `verifying` | `verifying` | → Phase 5 | → `fixing` (return) |
+| Phase 5: Commit | — | — | → `completed` | → `failed` |
+
+---
+
+## Knowledge Accumulation Mechanism
+
+### Automatic TRAPS Update
+
+After each successful bug fix (Phase 5):
+- If new pitfall discovered (not previously in TRAPS):
+  → Append to `.prizm-docs/<affected-module>.prizm` TRAPS section
+- If `affected_feature` is set:
+  → Cross-reference original Feature ID in TRAPS entry
+
+### Bug Pattern Analysis (optional, manual trigger)
+
+When `.prizmkit/bugfix/` accumulates 5+ completed bugs:
+- Analyze `error_source.type` distribution
+- Analyze `severity` distribution trends
+- Analyze `affected_modules` frequency (identify fragile modules)
+- Output recommendations for preventive refactoring
+
+### Feature Quality Tracking
+
+When `affected_feature` is non-empty:
+- If same Feature accumulates 3+ bugs → flag as "needs-revisit"
+
+---
+
+## Error Handling
+
+| Scenario | Action |
+|----------|--------|
+| Cannot parse bug description | Ask user for clarification |
+| Triage returns LOW confidence | Proceed with warning |
+| Cannot reproduce after 2 rounds | STOP, set `needs_info`, request more info |
+| Fix fails after 3 rounds | Escalate to user with analysis |
+| Review fails after 2 rounds | Escalate with review findings |
+| Full test suite has pre-existing failures | Warn user, isolate bug fix tests |
+| Fix requires architectural change | STOP, recommend Feature instead |
+| verification_type=manual and no user response | Keep status `verifying`, wait |
+
+---
+
+## Relationship to Other Skills
+
+| Skill | Role in Bug Fix Workflow |
+|-------|------------------------|
+| `prizmkit-error-triage` | Phase 1: error classification and root cause analysis |
+| `prizmkit-bug-reproducer` | Phase 2: generate minimal reproduction |
+| `prizmkit-implement` | Phase 3: TDD-style fix implementation |
+| `prizmkit-code-review` | Phase 4: review fix correctness |
+| `prizmkit-committer` | Phase 5: commit with `fix()` convention |
+| `prizmkit-log-analyzer` | Optional: analyze logs if bug includes log files |
+| `bug-planner` | Pre-pipeline: generate standardized `bug-fix-list.json` |
+| `prizmkit-retrospective` | NOT used (bug fixes don't get retrospectives) |
+| `prizmkit-summarize` | NOT used (no REGISTRY entries for bugs) |
+| `prizmkit-specify` | NOT used (no spec.md for bugs) |
+| `prizmkit-plan` | NOT used (no plan.md for bugs) |
+| `prizmkit-tasks` | NOT used (no tasks.md for bugs) |
+
+---
+
+## Comparison with Feature Pipeline
+
+| Dimension | Feature Pipeline | Bug Fix Pipeline |
+|-----------|-----------------|-----------------|
+| Input Skill | `app-planner` (7-phase interactive) | `bug-planner` (multi-format parser) |
+| Input File | `feature-list.json` (F-NNN) | `bug-fix-list.json` (B-NNN) |
+| Schema Version | `dev-pipeline-feature-list-v1` | `dev-pipeline-bug-fix-list-v1` |
+| Pipeline Phases | 10 Phase (0-7 + init + cleanup) | 5 Phase (Fast Path: 3) |
+| Artifact Docs | 3: spec.md + plan.md + tasks.md | 2: fix-plan.md + fix-report.md |
+| Artifact Path | `.prizmkit/specs/<feature-slug>/` | `.prizmkit/bugfix/<bug-id>/` |
+| Prompt Template | `bootstrap-prompt.md` | `bugfix-bootstrap-prompt.md` |
+| Skills Chain | specify → plan → tasks → implement → review → summarize → commit | error-triage → bug-reproduce → implement → code-review → commit |
+| Commit Prefix | `feat(<scope>):` | `fix(<scope>):` |
+| REGISTRY Update | ✅ via summarize | ❌ not applicable |
+| TRAPS Update | Only in retrospective | ✅ automatic after every fix |
+| Manual Verification | None | Supported (verification_type=manual/hybrid) |
+| Agent Roles | PM → Dev → Reviewer → Doc | Dev → Reviewer (streamlined) |
+
+## Path References
+
+All internal asset paths MUST use `${SKILL_DIR}` placeholder for cross-IDE compatibility.
+
+## Output
+
+- `fix-plan.md` (Phase 1 artifact)
+- Reproduction test file (Phase 2)
+- Fix implementation (Phase 3)
+- Code review report (Phase 4, conversation only)
+- `fix-report.md` (Phase 5 artifact)
+- Git commit with `fix(<scope>):` prefix (Phase 5)
+- Updated `.prizm-docs/` TRAPS (if applicable)

package/bundled/skills/prizmkit-bug-reproducer/SKILL.md

@@ -0,0 +1,62 @@
+---
+name: "prizmkit-bug-reproducer"
+tier: 1
+description: "[Tier 1] Generate minimal reproduction scripts and test cases from bug descriptions. AI strength in test/script generation. (project)"
+---
+
+# PrizmKit Bug Reproducer
+
+Generate minimal reproduction scripts and test cases from bug descriptions to isolate, confirm, and verify fixes.
+
+## Commands
+
+### prizmkit.bug-reproduce \<bug-description\>
+
+Generate a minimal reproduction for a reported bug.
+
+**STEPS:**
+
+1. Parse bug description: extract expected vs actual behavior, steps to reproduce (if given), environment details
+2. Read `.prizm-docs/` for relevant module context, paying special attention to TRAPS sections that may document known pitfalls
+3. Identify affected code path from description:
+   - Map user-facing behavior to source code modules
+   - Identify entry points and data flow
+4. Generate minimal reproduction based on bug type:
+   a. **For API bugs**: Generate curl/HTTP request sequence
+      - Include headers, authentication, request body
+      - Show expected vs actual response
+      - Add assertions on status code and response body
+   b. **For UI bugs**: Generate step-by-step user interaction guide
+      - Numbered steps with specific UI elements to interact with
+      - Screenshot annotation points (where to look)
+      - Browser/device requirements if relevant
+   c. **For logic bugs**: Generate unit test that demonstrates the failure
+      - Minimal test case with clear arrange/act/assert
+      - Test name describes the expected behavior
+      - Comments explaining why this should pass
+   d. **For data bugs**: Generate seed data + query sequence
+      - Minimal dataset that triggers the issue
+      - Query or operation sequence to reproduce
+      - Expected vs actual result comparison
+5. Write reproduction script/test to a temporary file:
+   - Use project's existing test framework and conventions
+   - Include setup and teardown
+   - Make it self-contained and runnable
+6. Include assertions that:
+   - FAIL with current (buggy) behavior
+   - PASS with expected (correct) behavior
+   - Serve as regression test after fix is applied
+7. Output:
+   - Reproduction file path
+   - Minimal steps document describing how to run
+   - Suggested fix investigation starting points
+
+## Path References
+
+All internal asset paths MUST use `${SKILL_DIR}` placeholder for cross-IDE compatibility.
+
+## Output
+
+- Reproduction script or test file written to project's test directory
+- Minimal steps document printed to console
+- Investigation pointers for the fix