prizmkit 1.1.13 → 1.1.14

package/bundled/VERSION.json

@@ -1,5 +1,5 @@
 {
-  "frameworkVersion": "1.1.13",
-  "bundledAt": "2026-04-09T09:50:44.583Z",
-  "bundledFrom": "fea93ab"
+  "frameworkVersion": "1.1.14",
+  "bundledAt": "2026-04-09T16:24:45.739Z",
+  "bundledFrom": "b887e13"
 }

package/bundled/skills/_metadata.json

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

@@ -70,25 +70,57 @@ Do NOT use this skill when:
    - User wants to explore ideas before committing → read `${SKILL_DIR}/references/brainstorm-guide.md`
    - During brainstorm Phase C → also read `${SKILL_DIR}/references/red-team-checklist.md`
 
-3. **Project conventions check** — after Intent Confirmation, before brainstorm or vision work:
+3. **Project conventions discovery** — after Intent Confirmation, before brainstorm or vision work:
    → Read `CLAUDE.md` / `CODEBUDDY.md` and check for `### Project Conventions` section
-   → If section exists and all conventions are answered → skip silently
-   → If section is missing or incomplete → ask the following conventions as a single batched prompt:
-     - **UI Display Language** (`ui_language`): Primary language for the app's UI (e.g., English, 中文, 日本語). If non-English, confirm whether ALL UI text should use that language.
-     - **Multi-Language Support** (`i18n`): Whether i18n is needed. If yes, which target languages? If enabled, note i18n infrastructure early in dependency graph.
-     - **Date/Time/Currency**: Date format (YYYY-MM-DD, MM/DD/YYYY, etc.), timezone strategy (UTC storage + local display, user-selected, server only), currency format (if applicable).
-     - **Code & Git Language**: Language for code comments and git commit messages (default: English for both).
+   → If section exists and covers the project well → skip silently
+   → If section is missing or incomplete → run the **AI-driven convention discovery** below:
+
+   **Do NOT follow any fixed checklist.** Every project is different. You must analyze the project first, then reason about what system-level conventions this specific project needs.
+
+   **Step 1: Analyze the project**
+   - Read tech stack, dependencies, existing code, config files, README, any existing style guides or linter configs
+   - For brownfield: also read actual source code patterns (naming, file structure, error handling, etc.)
+   - For greenfield: use the user's stated goals and intended tech stack
+
+   **Step 2: Reason about what conventions matter for THIS project**
+   Think about what decisions, if left unstandardized, would cause inconsistency as the project grows. Consider all dimensions relevant to the project — these might include (but are NOT limited to):
+   - Language and localization choices
+   - Code style and naming patterns
+   - Architecture and communication patterns
+   - Data format and storage decisions
+   - Security and auth approaches
+   - UI/UX patterns
+   - Testing strategies
+   - Deployment and environment patterns
+   - ...anything else you observe that needs a project-level decision
+
+   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:
+   >
+   > **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?
+
+   **Rules:**
+   - 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
+
    → Save answers to `CLAUDE.md` / `CODEBUDDY.md` under `### Project Conventions` section (format: one bullet per convention)
-   → Example output:
-     ```markdown
-     ### Project Conventions
-     - UI language: 中文
-     - i18n: disabled
-     - Date format: YYYY-MM-DD, timezone: UTC storage + local display
-     - Currency: CNY ¥
-     - Code comments: English
-     - Git commits: English
-     ```
+   → Output format will naturally vary per project — that is the intended behavior
 
 4. **Project brief accumulation** — throughout all interactive phases:
    → Read `${SKILL_DIR}/references/project-brief-guide.md` for template and rules
@@ -112,25 +144,60 @@ Note:
 - This skill does **not** create `.prizmkit/config.json` directly.
 - Creation/update is handled by bootstrap/init flows (e.g., `prizmkit-init`, `dev-pipeline/scripts/init-dev-team.py`).
 
-## Intent Confirmation (Mandatory First Step)
+## 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:
+- Intent confirmation
+- Project conventions
+- Tech stack selection
+- Architecture decisions
+- Handoff recommendations
+- Session exit gates
+
+**Format**: Present options as a numbered or lettered list. The user picks a number/letter. Include a recommended default where appropriate.
 
-After initial greeting, confirm the user's deliverable intent:
+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
 
-1. **Ask explicitly**:
-   - "Is the goal to produce a project plan for eventual pipeline execution, or just explore ideas first?"
+**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
 
-2. **Route by answer**:
-   - **"Produce a plan"** → Continue to Core Workflow. Set session goal = `produce`.
-   - **"Just explore ideas"** → 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, ask: "Ideas are taking shape. Ready to hand off to `feature-planner` for feature decomposition, or continue refining?"
-     - If ready → proceed to Phase 2 (constraints + frontend design check if applicable) then handoff
-     - If not ready → continue exploring, or save draft to `.prizmkit/planning/` and exit
-     - **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)
+## Intent Confirmation (Mandatory First Step)
 
-3. **Session goal tracking**: Track the intent (`produce` or `explore`) throughout the session. If `explore`, always re-prompt before ending.
+After initial greeting, present options:
+
+> 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
+
+Route by answer:
+- **A** → Continue to Core Workflow. Set session goal = `produce`.
+- **B** → 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/
+  - **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
+  - Proactively scan the project (same as brownfield behavior)
+  - Generate project-brief.md from inferred context
+  - Skip extensive brainstorming and constraint phases
+  - Present brief for user confirmation → write → done
+
+Session goal tracking: Track the intent (`produce`, `explore`, or `quick_context`) throughout the session. If `explore`, always re-prompt before ending.
 
 ## Project State Detection (after Intent Confirmation)
 
@@ -153,6 +220,40 @@ Proceed with the standard Core Workflow — ask all questions from scratch.
 
 When an existing project is detected:
 
+**Step 1: Prerequisite Check (Mandatory)**
+
+Before ANY planning work, check if AI-essential project context files exist:
+
+| File | Purpose | Status |
+|------|---------|--------|
+| `.prizm-docs/root.prizm` | Project architecture context for AI | exists / missing |
+| `.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:
+
+> 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
+
+- **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
+
+**Step 2: Proactive Project Scanning**
+
+Do NOT ask the user to describe their project — read it yourself first:
+
 1. **Scan project structure** to understand the codebase layout:
    ```bash
    find . -maxdepth 2 -type d -not -path '*/node_modules/*' -not -path '*/.git/*' -not -path '*/dist/*' -not -path '*/build/*' -not -path '*/__pycache__/*' -not -path '*/vendor/*' | sed -e 's;[^/]*/;|____;g;s;____|; |;g'
@@ -166,19 +267,32 @@ When an existing project is detected:
    - `.prizmkit/config.json` → previously detected tech stack
    - `.prizm-docs/root.prizm` → existing architecture context
 
-3. **Present inferred summary** to the user:
-   > "I see this is a [framework] project using [language] with [key dependencies]. Here's what I inferred about the project: [summary]. Is this correct? Anything to add or change?"
+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**
+
+> Based on my analysis of your codebase:
+>
+> **Project**: [name] — [inferred description]
+> **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
+
+**Step 4: Pre-fill and focus**
 
-4. **Pre-fill where possible** — skip questions already answerable from the codebase:
-   - Phase 2 tech stack selection → largely pre-filled from dependencies
-   - Vision/problem statement → inferred from README or package description (user confirms)
-   - Existing features → note them as `[x]` items in project brief
+- Phase 2 tech stack selection → largely pre-filled from dependencies
+- Vision/problem statement → inferred from README or package description (user confirms)
+- Existing features → note them as `[x]` items in project brief
 
-5. **Focus remaining questions** on what CANNOT be inferred:
-   - Target users and core value proposition
-   - Future direction and planned capabilities
-   - Non-functional requirements (performance, scale, security)
-   - Design direction (for frontend projects)
+**Focus remaining questions** (as options where possible) on what CANNOT be inferred:
+- Target users and core value proposition
+- Future direction and planned capabilities
+- Non-functional requirements (performance, scale, security)
+- Design direction (for frontend projects)
 
 ## Core Workflow
 
@@ -186,11 +300,18 @@ Execute the planning workflow in conversation mode with mandatory checkpoints:
 
 ### Interactive Phases
 1. Clarify business goal and scope
-   1.1 Confirm deliverable intent (→ Intent Confirmation)
-   1.2 **Requirement clarification** — for ANY unclear aspect of the user's vision, goals, target users, or scope, ask questions one at a time until fully understood. No limit on rounds. Do not proceed to Phase 2 with unresolved ambiguities.
+   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
-   2.2 **Frontend design check** (for frontend projects) — scan for existing UI/UX design docs. If none found, ask user if they want to establish design direction via `${SKILL_DIR}/references/frontend-design-guide.md`
+   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
 3. Capture architecture decisions and finalize project brief
 4. Hand off to `feature-planner` for feature decomposition
 
@@ -236,16 +357,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. **Offer 3 options**:
-   - **(a) Continue to completion**
-   - **(b) Save draft & exit** — write current progress as draft to `.prizmkit/planning/`
-   - **(c) Abandon** — exit without saving
+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 recommend next steps:
+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. **Primary recommendation**: Invoke `feature-planner` to decompose the application into features and generate `.prizmkit/plans/feature-list.json` (schema: `dev-pipeline-feature-list-v1`, uses `project_name` field for the app name)
-3. **Alternative**: If the user wants to continue refining the vision or constraints, stay in app-planner
-4. **Artifacts produced**: List files written (`.prizmkit/plans/project-brief.md`, project conventions and architecture decisions in `CLAUDE.md` / `CODEBUDDY.md`)
+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`)

package/package.json

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