prizmkit 1.1.16 → 1.1.18

package/bundled/VERSION.json

@@ -1,5 +1,5 @@
 {
-  "frameworkVersion": "1.1.16",
-  "bundledAt": "2026-04-09T17:14:25.405Z",
-  "bundledFrom": "e2d888c"
+  "frameworkVersion": "1.1.18",
+  "bundledAt": "2026-04-10T12:27:28.516Z",
+  "bundledFrom": "cc123c5"
 }

package/bundled/skills/_metadata.json

@@ -1,5 +1,5 @@
 {
-  "version": "1.1.16",
+  "version": "1.1.18",
   "skills": {
     "prizm-kit": {
       "description": "Full-lifecycle dev toolkit. Covers spec-driven development, Prizm context docs, code quality, debugging, deployment, and knowledge management.",

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

@@ -164,6 +164,11 @@ This applies to:
 - Use `multiSelect: true` when the user can pick more than one
 - Mark the recommended option first and append "(Recommended)" to its label
 - Use the `description` field to explain trade-offs or implications
+- **Every non-essential question MUST include a "Skip" option** (e.g., "Skip — decide later"). Users should never be forced to answer something they want to defer. Skipped items are simply not written to conventions — they can be added in a future session.
+
+**What can be skipped vs. what cannot:**
+- **Cannot skip**: Intent confirmation (must know the session goal)
+- **Everything else can be skipped**: conventions, tech stack choices, architecture decisions, design direction, etc. If the user skips, move on — do not re-ask or block progress.
 
 **When gathering open-ended information** (e.g., "describe your app idea"), use regular text questions — but follow up with `AskUserQuestion`-based clarifications wherever possible.
 

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

@@ -82,7 +82,7 @@ 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 in Step 1.4. If ALL simple bug 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.
+**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.
 
@@ -149,14 +149,31 @@ Ask the user: "Is this summary accurate? Any details to add?"
 
 After confirming bug understanding, assess whether this bug needs structured planning:
 
-**Simple bug → Fast Path** (ALL must be true):
+**Simple bug → Fast Path candidate** (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
 
-→ Proceed with Fast Path Workflow (Phase 0 branch already set up)
+**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"
+    - label: "Add to bug list"
+      description: "Add to .prizmkit/plans/bug-fix-list.json for pipeline execution later"
+    - 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 list** → Invoke `bug-planner` to add this bug to the list, then 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)
@@ -165,12 +182,26 @@ After confirming bug understanding, assess whether this bug needs structured pla
 - Fix requires structural changes
 - Multiple interrelated symptoms
 
-→ Invoke `/prizmkit-plan` with `artifact_dir=.prizmkit/bugfix/<BUG_ID>/`:
+**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 list"
+      description: "Add to .prizmkit/plans/bug-fix-list.json for pipeline execution later"
+```
+
+- **Plan and fix now** → Invoke `/prizmkit-plan` with `artifact_dir=.prizmkit/bugfix/<BUG_ID>/`:
   1. prizmkit-plan generates `spec.md` + `plan.md` under `.prizmkit/bugfix/<BUG_ID>/`
   2. Invoke `/prizmkit-implement` to execute the plan
   3. After implementation, resume this workflow at Phase 5 (Review)
+- **Add to bug list** → Invoke `bug-planner` to add this bug to the list, then end this workflow
 
-Ask the user: "This bug appears [simple/complex]. Use [fast path/structured planning]? (Y/n)"
+**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.**
 
 ---
 

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

@@ -109,6 +109,17 @@ Gather project metadata from the project's own configuration and documentation
    - If none found, ask the user
 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.
+5. **Collect reference materials** — before proceeding to bug collection, explicitly ask the user whether they have any supplementary materials for you to review:
+   > "Do you have any reference materials I should review to better understand these bugs? This can include:
+   > - **Code paths** — files or directories where the bugs likely originate
+   > - **Documents** — related design docs, API specs, or architecture docs for the affected area
+   > - **Error screenshots** — UI screenshots, console output images, or monitoring dashboards
+   > - **Web links** — related issue tracker links, Stack Overflow threads, or documentation pages
+   > - **Log files** — error log paths or monitoring tool URLs
+   >
+   > If none, we'll proceed with bug collection."
+
+   If the user provides materials, read/fetch them all before proceeding to Phase 2. For web links, use web fetch to retrieve and analyze the content. For images, read and analyze them visually. This context significantly improves bug diagnosis accuracy and description quality.
 
 Output: `project_name`, `project_description`, `global_context` fields populated.
 

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

@@ -166,6 +166,17 @@ Execute the planning workflow in conversation mode with mandatory checkpoints:
 ### Interactive Phases
 1. Clarify scope and goals
    1.1 **Requirement clarification** — for ANY unclear aspect of the user's goals or scope, ask questions one at a time (cite the unclear point, give a recommended answer with rationale) until you fully understand. No limit on rounds. Do not proceed to Phase 2 with unresolved ambiguities.
+   1.2 **Collect reference materials** — before proceeding, explicitly ask the user whether they have any supplementary materials for you to review. Present this as a single prompt covering all material types:
+   > "Do you have any reference materials I should review before planning? This can include:
+   > - **Code paths** — files or directories I should read to understand existing implementation
+   > - **Documents** — design docs, PRDs, API specs, architecture proposals, or internal wiki pages
+   > - **Knowledge docs** — `.prizm-docs/` files, README files, or project-specific documentation
+   > - **Images** — wireframes, mockups, architecture diagrams, or screenshots
+   > - **Web links** — reference implementations, API documentation pages, or relevant articles
+   >
+   > If none, we'll proceed with what's available in the codebase."
+
+   If the user provides materials, read/fetch them all before proceeding to Phase 2. For web links, use web fetch to retrieve and analyze the content. For images, read and analyze them visually. Record what was reviewed for traceability.
 2. Confirm constraints and existing architecture
 3. Propose feature set with dependencies
 4. Refine descriptions and acceptance criteria
@@ -217,7 +228,26 @@ For simple incremental planning, skip detailed Phase 2-3 analysis:
 
 ### Fast Path Workflow
 1. Read existing `.prizmkit/plans/feature-list.json` and confirm scope
-2. **User confirmation (mandatory)** — Tell the user: "This qualifies for fast-path (simple incremental addition). Skip detailed Phase 2-3 analysis and draft directly? Or use full workflow?" Only proceed with fast path if user confirms.
+2. **User confirmation (mandatory)** — Use `AskUserQuestion` to present interactive selectable options:
+
+   ```
+   AskUserQuestion:
+     question: "This qualifies for fast-path (simple incremental addition). How would you like to proceed?"
+     header: "Approach"
+     options:
+       - label: "Fast-path"
+         description: "Skip detailed Phase 2-3 analysis, draft features directly and add to feature-list.json"
+       - label: "Full workflow"
+         description: "Use the complete planning workflow with detailed analysis"
+       - label: "Implement directly"
+         description: "Skip the task list entirely and implement the feature(s) right now using /prizmkit-plan + /prizmkit-implement"
+   ```
+
+   - **Fast-path** → Continue with fast-path workflow below
+   - **Full workflow** → Exit fast path, use full workflow from Phase 2
+   - **Implement directly** → Invoke `/prizmkit-plan` directly to create spec + plan, then `/prizmkit-implement` to execute. Do NOT add to `.prizmkit/plans/feature-list.json`
+   
+   **NEVER proceed without explicit user selection via `AskUserQuestion`. Do NOT render options as plain text — the user must be able to click/select.**
 3. Generate next sequential feature IDs
 4. Draft features (title + description + acceptance_criteria + dependencies)
 5. Run validation script immediately

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

@@ -127,6 +127,17 @@ Execute the planning workflow in conversation mode with mandatory checkpoints:
 2. Read `.prizmkit/config.json` for tech stack info
 3. Identify existing test suite and coverage
 4. Summarize project context to the user: "Here's what I found about your project..."
+5. **Collect reference materials** — before proceeding to goal collection, explicitly ask the user whether they have any supplementary materials for you to review:
+   > "Do you have any reference materials I should review before planning the refactoring? This can include:
+   > - **Code paths** — specific files or directories that are refactoring targets or dependencies
+   > - **Documents** — design docs, architecture proposals, refactoring RFCs, or technical debt analyses
+   > - **Knowledge docs** — `.prizm-docs/` files, README files, or internal wiki pages for the affected area
+   > - **Images** — architecture diagrams, dependency graphs, or whiteboard photos
+   > - **Web links** — reference implementations, design pattern articles, or migration guides
+   >
+   > If none, we'll proceed with what's available in the codebase."
+
+   If the user provides materials, read/fetch them all before proceeding to Phase 2. For web links, use web fetch to retrieve and analyze the content. For images, read and analyze them visually. This context is critical for refactoring — understanding the target architecture and constraints prevents risky structural changes.
 
 **CHECKPOINT CP-RP-0**: Project context loaded, tech stack and test suite status known.
 
@@ -337,7 +348,26 @@ For simple refactoring with minimal scope:
 
 ### Fast Path Workflow
 1. Confirm refactoring scope with user
-2. **User confirmation (mandatory)** — Tell the user: "This qualifies for fast-path (simple refactoring). Skip detailed analysis and draft directly? Or use full workflow?" Only proceed if user confirms.
+2. **User confirmation (mandatory)** — Use `AskUserQuestion` to present interactive selectable options:
+
+   ```
+   AskUserQuestion:
+     question: "This qualifies for fast-path (simple refactoring). How would you like to proceed?"
+     header: "Approach"
+     options:
+       - label: "Fast-path"
+         description: "Skip detailed analysis, draft refactor items directly and add to refactor-list.json"
+       - label: "Full workflow"
+         description: "Use the complete planning workflow with detailed code analysis"
+       - label: "Implement directly"
+         description: "Skip the task list entirely and implement the refactoring right now using /prizmkit-plan + /prizmkit-implement"
+   ```
+
+   - **Fast-path** → Continue with fast-path workflow below
+   - **Full workflow** → Exit fast path, use full workflow from Phase 2
+   - **Implement directly** → Invoke `/prizmkit-plan` directly to create spec + plan, then `/prizmkit-implement` to execute. Do NOT add to `.prizmkit/plans/refactor-list.json`
+   
+   **NEVER proceed without explicit user selection via `AskUserQuestion`. Do NOT render options as plain text — the user must be able to click/select.**
 3. Draft items (title + type + scope + description + acceptance_criteria + behavior_preservation + dependencies)
 4. Run validation script immediately
 5. If valid -> summarize and recommend next step
@@ -355,8 +385,8 @@ For simple refactoring with minimal scope:
 User: "Rename the auth middleware function from checkAuth to requireAuth everywhere."
 AI: [Detects simple rename, single module]
 AI: [Qualifies for fast path: 1 item, low complexity, no cross-module impact]
-AI: "This qualifies for fast-path. Skip detailed analysis and draft directly? Or use full workflow?"
-User: "Fast path."
+AI: [Uses AskUserQuestion with options: "Fast-path", "Full workflow", "Implement directly"]
+User: [Selects "Fast-path"]
 AI: "Drafting R-001..."
 AI: [Validates immediately]
 AI: "Ready to proceed to dev-pipeline."

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "prizmkit",
-  "version": "1.1.16",
+  "version": "1.1.18",
   "description": "Create a new PrizmKit-powered project with clean initialization — no framework dev files, just what you need.",
   "type": "module",
   "bin": {