prizmkit 1.1.14 → 1.1.16

package/bundled/VERSION.json

@@ -1,5 +1,5 @@
 {
-  "frameworkVersion": "1.1.14",
-  "bundledAt": "2026-04-09T16:24:45.739Z",
-  "bundledFrom": "b887e13"
+  "frameworkVersion": "1.1.16",
+  "bundledAt": "2026-04-09T17:14:25.405Z",
+  "bundledFrom": "e2d888c"
 }

package/bundled/skills/_metadata.json

@@ -1,5 +1,5 @@
 {
-  "version": "1.1.14",
+  "version": "1.1.16",
   "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

@@ -12,7 +12,7 @@ Plan an application from idea to actionable project context through interactive
 - Architecture decision capture
 - Project brief accumulation (`.prizmkit/plans/project-brief.md`)
 
-This skill captures **what to build and why**. For **feature decomposition and `.prizmkit/plans/feature-list.json` generation**, hand off to `feature-planner`.
+This skill captures **project-level context only**: vision, tech stack, conventions, architecture decisions, and project brief. It does NOT do feature decomposition or generate `feature-list.json` — that is `feature-planner`'s job.
 
 For adding features to an **existing** project that already has a project brief, use `feature-planner` directly.
 
@@ -38,10 +38,10 @@ If you believe the task is better suited for a different workflow, you MUST:
 2. Project conventions and architecture decisions appended to `CLAUDE.md` / `CODEBUDDY.md` (with user consent)
 
 **After planning is complete**, you MUST:
-1. Present the summary of captured vision, constraints, and decisions
-2. **Ask the user explicitly** whether they want to proceed to feature decomposition
-3. If the user wants to continue exploring → stay in app-planner
-4. **NEVER auto-execute** the pipeline, feature-planner, or any implementation step
+1. Present the summary of captured project-level context (vision, conventions, architecture decisions, project brief)
+2. List the artifacts produced and suggest possible next steps (e.g., `feature-planner`, `prizmkit-plan`, etc.) — but do NOT auto-invoke any of them
+3. **NEVER auto-execute** the pipeline, feature-planner, or any implementation step
+4. **NEVER generate `feature-list.json`** — that is exclusively `feature-planner`'s responsibility
 
 ## When to Use
 
@@ -96,28 +96,29 @@ Do NOT use this skill when:
 
    The point is: YOU decide what's relevant based on what you see. A Next.js SaaS app needs completely different conventions than a Python data pipeline or a Go microservice.
 
-   **Step 3: Present findings as two groups**
-   > Based on analyzing your project, here are the system-level conventions I recommend establishing:
-   >
+   **Step 3: Present findings via `AskUserQuestion`**
+
+   First, show "Already decided" conventions as text:
    > **Already decided** (detected from your codebase):
    > - [convention]: [value] (source: [where you found it])
    > - [convention]: [value] (source: [where you found it])
-   >
-   > **Need your input** (would impact consistency if left unaddressed):
-   > **1. [Convention name]** — [why this matters for your project]
-   > [A] option  [B] option  [C] option
-   >
-   > **2. [Convention name]** — [why this matters for your project]
-   > [A] option  [B] option
-   >
-   > Anything I missed that you'd like to standardize?
+
+   Then use `AskUserQuestion` for conventions that need user input (up to 4 questions per call, use multiple calls as needed — no limit on total rounds). Each question:
+   - Question text includes the convention name AND why it matters for this project
+   - Options are the reasonable choices (2-4 per question)
+   - Mark the recommended option first with "(Recommended)" in its label
+   - Use `description` field to explain trade-offs
+
+   After each batch of `AskUserQuestion` calls, reassess: are there more project-level conventions to cover? If yes, continue with more `AskUserQuestion` calls. Keep going until ALL project-level conventions are fully addressed.
+
+   Then ask in text: "Anything I missed that you'd like to standardize?" — if the user adds more, continue the discovery loop.
 
    **Rules:**
+   - **No interaction limit** — keep asking until every project-level convention is covered. Do NOT stop early or batch-skip to save rounds.
    - Every proposed convention must be justified by something you observed in the project — explain WHY it matters
    - Auto-confirm anything already evident from the codebase (show as "detected", let user override)
-   - No fixed upper/lower limit on count — propose as many as the project genuinely needs, but don't pad with irrelevant ones
-   - Always end with "Anything I missed?" to let the user add things you didn't think of
-   - Present options (not open-ended questions) for each convention that needs input
+   - Propose as many conventions as the project genuinely needs, but don't pad with irrelevant ones
+   - The "Anything I missed?" question is NOT the end — if the user adds items, ask follow-up `AskUserQuestion` calls to clarify those too
 
    → Save answers to `CLAUDE.md` / `CODEBUDDY.md` under `### Project Conventions` section (format: one bullet per convention)
    → Output format will naturally vary per project — that is the intended behavior
@@ -146,52 +147,48 @@ Note:
 
 ## Interaction Style (Hard Rule)
 
-**ALL decision points MUST use numbered/lettered options.** Never ask open-ended questions when the answer can be structured as a choice. This applies to:
+**ALL decision points MUST use the `AskUserQuestion` tool** to present interactive, selectable options. Do NOT render options as plain text (e.g., `[A] option [B] option`) — the user must be able to click/select, not type a letter.
+
+This applies to:
 - Intent confirmation
 - Project conventions
 - Tech stack selection
 - Architecture decisions
-- Handoff recommendations
 - Session exit gates
+- Brownfield prerequisite check
+- Any other decision point
 
-**Format**: Present options as a numbered or lettered list. The user picks a number/letter. Include a recommended default where appropriate.
+**How to use `AskUserQuestion`:**
+- Each decision point → one `AskUserQuestion` call with 1-4 questions. Use multiple calls as needed — there is NO limit on total rounds for project-level convention discovery. Keep going until everything is covered.
+- Each question has 2-4 selectable options (the tool auto-adds "Other" for custom input)
+- 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
 
-Example:
-> What would you like to do next?
->
-> **[A] Produce a project plan** — capture vision, stack, constraints → project-brief.md (recommended)
-> **[B] Explore ideas first** — brainstorm freely before committing to a plan
-> **[C] Skip to feature planning** — if you already know what to build
-
-**When gathering information** (e.g., target users, problem statement), use a hybrid approach:
-- If common answers exist → offer options + "Other" choice
-- If truly open-ended (e.g., "describe your app idea") → ask directly, but follow up with option-based clarifications
+**When gathering open-ended information** (e.g., "describe your app idea"), use regular text questions — but follow up with `AskUserQuestion`-based clarifications wherever possible.
 
 ## Intent Confirmation (Mandatory First Step)
 
-After initial greeting, present options:
+After initial greeting, use `AskUserQuestion` to confirm intent:
 
-> Welcome to App Planner! What would you like to do?
->
-> **[A] Produce a project plan** — define vision, tech stack, and constraints → generates project-brief.md for pipeline use (recommended)
-> **[B] Explore ideas first** — brainstorm and refine ideas before committing to a plan
-> **[C] Generate project context only** — for an existing project that needs a project brief without full planning
+**Question**: "What would you like to do?"
+- **Produce a project plan (Recommended)** — define vision, tech stack, and constraints → generates project-brief.md for pipeline use
+- **Explore ideas first** — brainstorm and refine ideas before committing to a plan
+- **Generate project context only** — for an existing project that needs a project brief without full planning
 
 Route by answer:
-- **A** → Continue to Core Workflow. Set session goal = `produce`.
-- **B** → Enter **Exploration Mode**:
+- **Produce a project plan** → Continue to Core Workflow. Set session goal = `produce`.
+- **Explore ideas first** → Enter **Exploration Mode**:
   - Run project conventions check first
   - Load `${SKILL_DIR}/references/brainstorm-guide.md` and follow its structured ideation process (Phases A-D)
   - Brainstorm Phase D output serves as the Vision Summary (CP-AP-2)
-  - After brainstorm completes, present options:
-    > Ideas are taking shape. What's next?
-    >
-    > **[A] Proceed to feature decomposition** — hand off to feature-planner
-    > **[B] Continue refining** — keep brainstorming
-    > **[C] Save draft & exit** — save progress to .prizmkit/planning/
+  - After brainstorm completes, use `AskUserQuestion`: "Ideas are taking shape. What's next?"
+    - **Continue to project planning (Recommended)** — capture tech stack, conventions, and architecture decisions
+    - **Continue refining** — keep brainstorming
+    - **Save draft & exit** — save progress to .prizmkit/planning/
   - **Checkpoints in explore mode**: CP-AP-0 (required), CP-AP-1 (required), CP-AP-2 (from brainstorm output), CP-AP-3 (only if user proceeds to Phase 2), CP-AP-4 and CP-AP-5 (only if user transitions to produce mode)
-- **C** → Enter **Quick Context Mode** (brownfield only):
-  - Run Project State Detection → if greenfield, redirect to option A
+- **Generate project context only** → Enter **Quick Context Mode** (brownfield only):
+  - Run Project State Detection → if greenfield, redirect to produce mode
   - Proactively scan the project (same as brownfield behavior)
   - Generate project-brief.md from inferred context
   - Skip extensive brainstorming and constraint phases
@@ -230,25 +227,16 @@ Before ANY planning work, check if AI-essential project context files exist:
 | `.prizmkit/config.json` | Tech stack + runtime config | exists / missing |
 | `.prizmkit/plans/project-brief.md` | Product vision checklist | exists / missing |
 
-**If ANY are missing**, present this recommendation:
+**If ANY are missing**, show the status table, then use `AskUserQuestion`:
 
-> I detected this is an existing project, but some AI context files are missing:
->
-> | File | Status |
-> |------|--------|
-> | `.prizm-docs/` | ❌ missing |
-> | `.prizmkit/config.json` | ❌ missing |
-> | `.prizmkit/plans/project-brief.md` | ❌ missing |
->
-> These files help AI understand your project structure, tech stack, and goals — making planning much more effective.
->
-> **[A] Run project init first** — invoke `prizmkit-init` to scan your codebase and generate these files, then return to planning (recommended)
-> **[B] Continue without init** — I'll scan the project manually during this session (less thorough)
-> **[C] I'll set these up later** — proceed with planning using only what's available
+**Question**: "Some AI context files are missing. These help AI understand your project — making planning much more effective. How would you like to proceed?"
+- **Run project init first (Recommended)** — invoke `prizmkit-init` to scan your codebase and generate these files, then return to planning
+- **Continue without init** — I'll scan the project manually during this session (less thorough)
+- **Skip, I'll set these up later** — proceed with planning using only what's available
 
-- **A** → Invoke `prizmkit-init`, then resume app-planner from where it left off
-- **B** → Continue with Step 2 below (manual scan)
-- **C** → Continue with Step 3, skip scanning
+- **Run project init first** → Invoke `prizmkit-init`, then resume app-planner from where it left off
+- **Continue without init** → Continue with Step 2 below (manual scan)
+- **Skip** → Continue with Step 3, skip scanning
 
 **Step 2: Proactive Project Scanning**
 
@@ -269,7 +257,9 @@ Do NOT ask the user to describe their project — read it yourself first:
 
 3. **Read key source files** (entry points, main routes, core models) to understand what the project actually does — don't rely solely on metadata.
 
-**Step 3: Present inferred summary with confirmation options**
+**Step 3: Present inferred summary with confirmation**
+
+Show the summary as text, then use `AskUserQuestion`:
 
 > Based on my analysis of your codebase:
 >
@@ -277,10 +267,11 @@ Do NOT ask the user to describe their project — read it yourself first:
 > **Tech Stack**: [framework] + [language] + [key dependencies]
 > **Key Features Found**: [list 3-5 detected capabilities]
 > **Architecture**: [e.g., monolithic, microservices, serverless]
->
-> **[A] This looks correct** — proceed with planning
-> **[B] Mostly correct, with changes** — I'll note corrections
-> **[C] This is off** — let me describe the project
+
+**Question**: "Does this look correct?"
+- **Yes, looks correct (Recommended)** — proceed with planning
+- **Mostly correct, with changes** — I'll note corrections
+- **This is off** — let me describe the project
 
 **Step 4: Pre-fill and focus**
 
@@ -303,17 +294,12 @@ Execute the planning workflow in conversation mode with mandatory checkpoints:
    1.1 Confirm deliverable intent (→ Intent Confirmation — option-based)
    1.2 **Requirement clarification** — for ANY unclear aspect of the user's vision, goals, target users, or scope, use option-based questions where possible. When common patterns exist, present them as choices. Only use open-ended questions for truly unique input (e.g., "describe your app idea"). Follow up with option-based clarifications.
 2. Confirm constraints and tech assumptions
-   2.1 Tech stack selection — use `${SKILL_DIR}/assets/app-design-guide.md` §2 decision matrix. Present as options:
-       > **Frontend framework?**
-       > [A] Next.js (recommended)  [B] Nuxt 3  [C] SvelteKit  [D] Other
-   2.2 **Frontend design check** (for frontend projects) — scan for existing UI/UX design docs. If none found, present options:
-       > No UI/UX design docs found. Would you like to:
-       >
-       > **[A] Establish design direction now** — guided questions about style, layout, color
-       > **[B] Skip for now** — decide during implementation
-       > **[C] I have external designs** — link or describe them
+   2.1 Tech stack selection — use `${SKILL_DIR}/assets/app-design-guide.md` §2 decision matrix. Use `AskUserQuestion` for each major tech decision (framework, database, styling, etc.)
+   2.2 **Frontend design check** (for frontend projects) — scan for existing UI/UX design docs. If none found, use `AskUserQuestion`:
+       - Question: "No UI/UX design docs found. Would you like to establish design direction?"
+       - Options: "Establish design direction now (Recommended)", "Skip for now", "I have external designs"
 3. Capture architecture decisions and finalize project brief
-4. Hand off to `feature-planner` for feature decomposition
+4. Present completion summary with artifacts produced and possible next steps
 
 ### Checkpoints (Mandatory Gates)
 
@@ -326,7 +312,7 @@ Checkpoints catch cascading errors early — skipping one means the next phase b
 | **CP-AP-2** | Vision Summary | Goal/users/differentiators confirmed by user. For brownfield: existing purpose confirmed or refined. | 1-2 |
 | **CP-AP-3** | Frontend Design Evaluated | For frontend projects: checked for existing UI/UX design system; user was asked if missing. **Auto-pass** for backend-only or non-UI projects. | 2 |
 | **CP-AP-4** | Project Brief Accumulated | `.prizmkit/plans/project-brief.md` exists at `.prizmkit/plans/` with at least 3 ideas listed. For brownfield: already-implemented items marked `[x]` count toward this total. | 3 |
-| **CP-AP-5** | Handoff Ready | All app-level context captured; user confirmed readiness for feature decomposition | 4 |
+| **CP-AP-5** | Planning Complete | All project-level context captured: conventions, tech stack, architecture decisions, project brief finalized | 4 |
 
 ## Architecture Decision Capture
 
@@ -334,7 +320,7 @@ After Phase 2, if framework-shaping architecture decisions emerged during planni
 
 **How it works**:
 1. If decisions are captured → append to `CLAUDE.md` / `CODEBUDDY.md` under `### Architecture Decisions` section
-2. Feature-planner and other downstream skills read `CLAUDE.md` / `CODEBUDDY.md` as standard context, so they automatically receive these decisions
+2. Downstream skills (feature-planner, prizmkit-plan, etc.) read `CLAUDE.md` / `CODEBUDDY.md` as standard context, so they automatically receive these decisions
 3. Do NOT write directly to `.prizm-docs/root.prizm` — that file is maintained by `prizmkit-prizm-docs` and `prizmkit-retrospective`. If the project needs `.prizm-docs/`, recommend the user run `prizmkit-prizm-docs` init after planning.
 
 ## Project Brief Accumulation
@@ -357,25 +343,25 @@ Activate when ALL true:
 
 When the session appears to be ending:
 1. **Remind**: "You set out to produce a project plan but `.prizmkit/plans/project-brief.md` isn't complete yet."
-2. **Present options**:
-   > **[A] Continue to completion** — finish the project brief
-   > **[B] Save draft & exit** — write current progress as draft to `.prizmkit/planning/`
-   > **[C] Abandon** — exit without saving
-
-## Handoff to feature-planner
-
-After all checkpoints pass, present a summary and offer next steps as options:
-
-1. **Summary**: List captured vision, tech stack, constraints, architecture decisions, and project brief status
-2. **Present options**:
-   > Planning complete! Here's what was captured:
-   > - Tech stack: [summary]
-   > - Project brief: `.prizmkit/plans/project-brief.md` ([N] items)
-   > - Conventions: saved to `CLAUDE.md` / `CODEBUDDY.md`
-   >
-   > **What's next?**
-   >
-   > **[A] Proceed to feature decomposition** — invoke `feature-planner` to break down features into `.prizmkit/plans/feature-list.json` (recommended)
-   > **[B] Continue refining** — stay in app-planner to adjust vision or constraints
-   > **[C] Done for now** — exit with artifacts saved
-3. **Artifacts produced**: List files written (`.prizmkit/plans/project-brief.md`, project conventions and architecture decisions in `CLAUDE.md` / `CODEBUDDY.md`)
+2. Use `AskUserQuestion`: "How would you like to proceed?"
+   - **Continue to completion (Recommended)** — finish the project brief
+   - **Save draft & exit** — write current progress as draft to `.prizmkit/planning/`
+   - **Abandon** — exit without saving
+
+## Completion Summary
+
+After all checkpoints pass, present a summary and end the session:
+
+1. **Summary** (as text): List all project-level artifacts produced:
+   - Project conventions → `CLAUDE.md` / `CODEBUDDY.md` `### Project Conventions`
+   - Tech stack → `.prizmkit/config.json`
+   - Architecture decisions (if any) → `CLAUDE.md` / `CODEBUDDY.md` `### Architecture Decisions`
+   - Project brief → `.prizmkit/plans/project-brief.md`
+
+2. **Suggest possible next steps** (as text, NOT auto-invoked):
+   > Project-level planning is complete. When you're ready, here are some possible next steps:
+   > - `feature-planner` — decompose the project into features and generate `feature-list.json`
+   > - `prizmkit-plan` — start working on a specific feature directly
+   > - `prizmkit-prizm-docs` — initialize or update project documentation
+
+   **Do NOT invoke any of these.** The user decides what to do next, in their own time.

package/package.json

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