prizmkit 1.0.121 → 1.0.123

package/bundled/skills/_metadata.json

@@ -1,5 +1,5 @@
 {
-  "version": "1.0.121",
+  "version": "1.0.123",
   "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/assets/evaluation-guide.md

@@ -15,9 +15,9 @@ npm run skill:review -- \
   --workspace /.codebuddy/skill-evals/app-planner-workspace \
   --iteration iteration-N \
   --skill-name app-planner \
-  --skill-path /core/skills/app-planner \
+  --skill-path ${SKILL_DIR} \
   --runs 3 \
-  --grader-cmd "python3 /core/skills/app-planner/scripts/validate-and-generate.py grade --workspace {workspace} --iteration {iteration}"
+  --grader-cmd "python3 ${SKILL_DIR}/scripts/validate-and-generate.py grade --workspace {workspace} --iteration {iteration}"
 ```
 
 Produces:

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

@@ -1,7 +1,7 @@
 ---
 name: "bug-fix-workflow"
 tier: companion
-description: "Interactive single-bug fix in current session. Guides through 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', 'fix this bug', 'interactive fix', 'manually fix bug'. (project)"
+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', 'fix this bug', 'interactive fix', 'manually fix bug'. (project)"
 ---
 
 # Bug Fix Workflow
@@ -79,17 +79,82 @@ For trivial bugs with clear root cause and minimal scope:
 
 ---
 
-### Phase 1: Triage
+### Phase 1: Deep Bug Diagnosis — Interactive Q&A
 
-**Goal**: Understand the bug, locate affected code, classify severity.
+**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.
 
-1. **Gather bug info**:
-   - If bug ID given (e.g. B-001): read entry from `bug-fix-list.json`
-   - If raw error: extract error message, stack trace, affected files
-   - If description: ask clarifying questions to narrow down the issue
-2. **Read project context**: `.prizm-docs/root.prizm` → relevant L1/L2 docs for affected modules
-3. **Locate affected code**: read the files mentioned in the error/stack trace
-4. **Check known issues**: search `.prizm-docs/` TRAPS sections for matching patterns
+**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 `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
+
+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?
+
+#### 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.
+
+---
+
+### Phase 2: Triage
+
+**Goal**: Locate affected code, identify root cause, classify severity.
+
+1. **Read project context**: `.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 `.prizm-docs/` TRAPS sections for matching patterns
+4. **If database-related**: read existing schema/model files to understand the data layer
+   ```bash
+   find . -maxdepth 4 -type f \( -name "*.prisma" -o -name "*.sql" -o -path "*/migrations/*" -o -path "*/models/*" -o -name "schema.*" -o -name "*.entity.*" \) -not -path '*/node_modules/*' -not -path '*/.git/*' | head -20
+   ```
 5. **Classify**: root cause (confirmed/suspected), blast radius, fix complexity
 6. **Present diagnosis to user**:
    ```
@@ -100,7 +165,7 @@ For trivial bugs with clear root cause and minimal scope:
    ```
    Ask: "Does this diagnosis look right? Should I proceed with the fix?"
 
-### Phase 2: Reproduce
+### Phase 3: Reproduce
 
 **Goal**: Create a failing test that proves the bug exists.
 
@@ -113,9 +178,9 @@ For trivial bugs with clear root cause and minimal scope:
 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 3 with the manual checklist
+- Proceed to Phase 4 with the manual checklist
 
-### Phase 3: Fix
+### Phase 4: Fix
 
 **Goal**: Implement the minimal fix. Red test → green.
 
@@ -123,6 +188,7 @@ If the bug is hard to reproduce automatically (e.g. environment-specific):
    - 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 `.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**:
@@ -135,7 +201,7 @@ If the fix causes test regressions:
 - Revise the fix (max 3 attempts)
 - If still failing after 3 attempts, escalate to user with analysis
 
-### Phase 4: Review
+### Phase 5: Review
 
 **Goal**: Verify fix quality before committing.
 
@@ -156,7 +222,7 @@ If the fix causes test regressions:
    Ready to commit.
    ```
 
-### Phase 5: User Verification
+### Phase 6: User Verification
 
 **Goal**: Let the user verify the fix works as expected before committing.
 
@@ -166,15 +232,15 @@ If the fix causes test regressions:
    - **(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 6
+4. **If (c)**: Proceed to Phase 7
 
 If user reports the fix is NOT working:
-- Return to Phase 3 (max 2 more attempts)
+- Return to Phase 4 (max 2 more attempts)
 - If still failing: escalate with analysis
 
 ---
 
-### Phase 6: Commit & Merge
+### Phase 7: Commit & Merge
 
 **Goal**: Commit the fix and offer to merge back to the original branch.
 
@@ -215,11 +281,11 @@ The workflow supports resuming from the last completed phase by detecting existi
 | Artifact Found | Resume From |
 |---------------|------------|
 | (nothing) | Phase 0: Branch Setup |
-| On `fix/<BUG_ID>-*` branch, no artifacts | Phase 1: Triage |
-| `fix-plan.md` only | Phase 3: Fix |
-| `fix-plan.md` + code changes exist | Phase 4: Review |
-| All docs + review passed | Phase 5: User Verification |
-| All docs + committed | Phase 6: Merge decision |
+| On `fix/<BUG_ID>-*` branch, no artifacts | Phase 1: Deep Bug Diagnosis |
+| `fix-plan.md` only | Phase 4: Fix |
+| `fix-plan.md` + code changes exist | Phase 5: Review |
+| All docs + review passed | Phase 6: User Verification |
+| All docs + committed | Phase 7: Merge decision |
 
 **Resume**: If `<BUG_ID>` matches an existing `.prizmkit/bugfix/<BUG_ID>/` directory, resume instead of starting fresh.
 
@@ -236,12 +302,13 @@ Only 2 artifact files per bug, consistent with the pipeline convention.
 ## 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 5) | No (automated) |
+| User verification | Yes (Phase 6) | No (automated) |
 | Best for | Complex bugs needing user input | Batch of well-defined bugs |
 | Artifacts | Same (fix-plan.md + fix-report.md) | Same |
 | Commit prefix | `fix(<scope>):` | `fix(<scope>):` |
@@ -251,6 +318,7 @@ Only 2 artifact files per bug, consistent with the pipeline convention.
 | Scenario | Action |
 |----------|--------|
 | Bug ID not found in 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 |
@@ -264,7 +332,7 @@ Only 2 artifact files per bug, consistent with the pipeline convention.
 | `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 6 (pure commit, no doc sync) |
+| **this skill** | `prizmkit-committer` | Built into Phase 7 (pure commit, no doc sync) |
 
 ## Output
 

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

@@ -1,12 +1,12 @@
 ---
 name: "feature-workflow"
 tier: companion
-description: "One-stop entry point for feature development. Orchestrates app-planner → dev-pipeline-launcher → background execution. Handles multi-feature batch development from a single request. Use this skill whenever the user wants to build an app, develop multiple features at once, or go from idea to running code in one step. Trigger on: 'build an app', 'develop features', 'implement all features', 'one-stop development', 'batch implement', 'build a new application', 'build a system', 'one-click complete', 'batch implement'. (project)"
+description: "One-stop entry point for feature development. Brainstorms requirements with the user until fully clarified, then orchestrates app-planner → dev-pipeline-launcher → execution. Handles multi-feature batch development from a single request. Use this skill whenever the user wants to build an app, develop multiple features at once, or go from idea to running code in one step. Trigger on: 'build an app', 'develop features', 'implement all features', 'one-stop development', 'batch implement', 'build a new application', 'build a system', 'one-click complete', 'batch implement'. (project)"
 ---
 
 # Feature Workflow
 
-One-stop entry point for feature development. Orchestrates the complete flow from requirements to committed code in a single invocation.
+One-stop entry point for feature development. Covers the complete journey from a vague idea to running code: deep requirement brainstorming → structured planning → autonomous pipeline execution.
 
 ## When to Use
 
@@ -28,33 +28,38 @@ User says:
 ## Overview
 
 ```
-feature-workflow <requirements description>
+feature-workflow <idea / requirements>
    │
-   ├── Phase 1: Plan → app-planner → feature-list.json
+   ├── Phase 1: Brainstorm → deep interactive Q&A until requirements are crystal clear
    │
-   ├── Phase 2: Launch → dev-pipeline-launcher → pipeline execution
+   ├── Phase 2: Plan → app-planner → feature-list.json
    │
-   └── Phase 3: Monitor → track progress → report results
+   ├── Phase 3: Launch → dev-pipeline-launcher → pipeline execution
+   │
+   └── Phase 4: Monitor → track progress → report results
 ```
 
 ### What This Skill Does
 
 | Phase | Action | Result |
 |-------|--------|--------|
-| 1 | Call `app-planner` | `feature-list.json` with N features |
-| 2 | Call `dev-pipeline-launcher` | Pipeline started (execution mode chosen by user via launcher) |
-| 3 | Monitor progress | Status updates, completion report |
+| 1 | **Brainstorm** — interactive Q&A with user | Fully clarified requirements document |
+| 2 | Call `app-planner` with clarified requirements | `feature-list.json` with N features |
+| 3 | Call `dev-pipeline-launcher` | Pipeline started (execution mode chosen by user via launcher) |
+| 4 | Monitor progress | Status updates, completion report |
 
 ### Why This Skill Exists
 
 Without this skill, users must:
-1. Invoke `app-planner` → wait for feature-list.json
-2. Invoke `dev-pipeline-launcher` → wait for pipeline start
-3. Manually check progress
+1. Figure out all requirements themselves
+2. Invoke `app-planner` → wait for feature-list.json
+3. Invoke `dev-pipeline-launcher` → wait for pipeline start
+4. Manually check progress
 
 With this skill, users can:
-1. Say "Build a task management App" and walk away
-2. All planning + execution happens automatically
+1. Say "Build a task management App" with a rough idea
+2. The skill brainstorms to fill in all gaps
+3. All planning + execution happens automatically
 
 ### Branch Management
 
@@ -74,18 +79,19 @@ Natural language description of the project or features. Can be:
 - A batch of features: "Implement user registration, login, and password recovery features"
 - An incremental request: "Add user avatar upload and nickname modification to the existing system"
 
-Flow: app-planner → dev-pipeline-launcher → monitor
+Flow: brainstorm → app-planner → dev-pipeline-launcher → monitor
 
 **Mode B: From existing feature-list.json**
 
 When user says "run pipeline from existing file" or feature-list.json already exists:
-- Skip `app-planner` (file already exists)
+- Skip brainstorm and `app-planner` (file already exists)
 - Invoke `dev-pipeline-launcher` directly
 - Monitor and report progress
 
 **Mode C: Incremental (add to existing project)**
 
 When user says "add features to existing project" or the project already has features:
+- Brainstorm new feature requirements with the user
 - Invoke `app-planner` in incremental mode (reads existing feature-list.json)
 - Append new features to existing list
 - Invoke `dev-pipeline-launcher`
@@ -93,19 +99,151 @@ When user says "add features to existing project" or the project already has fea
 
 ---
 
-## Phase 1: Plan
+## Phase 1: Brainstorm — Deep Requirement Clarification
+
+**Goal**: Through interactive Q&A, transform the user's rough idea into fully clarified, implementation-ready requirements. This phase is the foundation for high-quality code generation — vague requirements produce vague code.
+
+**CRITICAL RULE**: The number of questions is **unlimited**. Do NOT rush through this phase. Ask as many rounds as needed until every aspect is clear. The framework strives for perfect code generation, which requires perfect understanding of requirements.
+
+### Step 1.1: Understand the User's Vision
+
+Ask the user to describe what they want to build. Listen for:
+- **What** the system/feature does (core functionality)
+- **Who** uses it (user roles, personas)
+- **Why** it's needed (business value, problem being solved)
+
+### Step 1.2: Context Gathering
+
+Before asking detailed questions, gather existing project context:
+- If `.prizm-docs/root.prizm` exists → read it to understand existing architecture, tech stack, patterns
+- If `.prizmkit/config.json` exists → read tech stack preferences
+- If existing source code exists → scan directory structure:
+  ```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'
+  ```
+- If database/schema files exist → scan them to understand existing data model:
+  ```bash
+  find . -maxdepth 4 -type f \( -name "*.prisma" -o -name "*.sql" -o -path "*/migrations/*" -o -path "*/models/*" -o -name "schema.*" -o -name "*.entity.*" \) -not -path '*/node_modules/*' -not -path '*/.git/*' -not -path '*/dist/*' -not -path '*/__pycache__/*' | head -20
+  ```
+
+This context informs better questions — e.g., if the project uses PostgreSQL + Prisma, ask about schema design in those terms.
+
+### Step 1.3: Adaptive Deep-Dive Questioning
+
+Based on the user's description, ask questions across these dimensions. **Adapt question depth to the feature complexity** — a simple CRUD feature needs fewer questions than a real-time collaboration system.
+
+**Functional Requirements:**
+- What are the core user actions/workflows?
+- What inputs does the system accept? What outputs does it produce?
+- What are the key business rules and validation logic?
+- Are there different user roles with different permissions?
+
+**Data Model & Database** (if applicable):
+- What entities/data need to be stored?
+- What are the relationships between entities?
+- Are there existing database tables this feature must integrate with?
+- What fields are required vs optional? What data types?
+- Any unique constraints, indexes, or special query patterns needed?
+- **RULE**: If the project has existing database tables, ALL new table designs must reference and conform to the existing schema style (naming conventions, ID strategy, timestamp patterns, constraint patterns). Ask the user to confirm the data model before proceeding.
+
+**User Experience:**
+- What does the user see and interact with?
+- What is the expected flow/sequence of actions?
+- How should errors be displayed to the user?
+- Are there any specific UI/UX requirements?
+
+**Integration & Architecture:**
+- Does this feature depend on or affect other features/modules?
+- Any external APIs or services involved?
+- What authentication/authorization model applies?
+- Any real-time requirements (WebSocket, SSE, polling)?
+
+**Edge Cases & Error Handling:**
+- What happens when things go wrong? (network failure, invalid input, concurrent access)
+- What are the boundary conditions? (empty states, max limits, permissions denied)
+- Any rate limiting, quotas, or resource constraints?
+
+**Non-Functional Requirements:**
+- Performance expectations? (response time, throughput)
+- Scalability considerations?
+- Security requirements? (encryption, audit logs, compliance)
+
+### Step 1.4: Iterative Clarification Loop
+
+After the initial deep-dive:
+
+1. **Summarize** what you've understood so far — present it back to the user
+2. **Identify gaps** — explicitly list any areas that are still unclear or ambiguous
+3. **Ask follow-up questions** for each gap
+4. **Repeat** until the user confirms: "Yes, that covers everything" or "That's clear enough"
+
+**Signs that brainstorming is complete:**
+- All functional requirements have concrete acceptance criteria
+- Data model entities and relationships are defined
+- Edge cases and error handling are addressed
+- Integration points are identified
+- The user has confirmed the summary is accurate
+
+**Signs that more questions are needed:**
+- User's answers contain vague terms ("handle it appropriately", "make it user-friendly", "standard behavior")
+- Core business rules are undefined ("depends on the situation")
+- Data relationships are unclear ("somehow connected")
+- User says "I'm not sure" — help them think through it with concrete options
+
+### Step 1.5: Requirements Summary
+
+Once brainstorming is complete, produce a structured requirements summary:
+
+```markdown
+## Requirements Summary
+
+### Project/Feature: [Name]
+
+### Core Functionality
+- [Bullet list of what the system does]
+
+### User Roles
+- [Role]: [What they can do]
+
+### Data Model Overview
+- [Entity]: [Key fields, relationships]
+
+### Key Business Rules
+- [Rule 1]
+- [Rule 2]
+
+### Integration Points
+- [External system/API/module]
+
+### Edge Cases & Error Handling
+- [Case]: [Expected behavior]
+
+### Non-Functional Requirements
+- [Requirement]
+
+### Confirmed by user: ✓
+```
+
+Present this summary to the user and get explicit confirmation before proceeding to Phase 2.
+
+**CHECKPOINT CP-FW-0**: Requirements fully clarified and confirmed by user.
+
+---
+
+## Phase 2: Plan
 
-**Goal**: Generate structured feature-list.json from natural language requirements.
+**Goal**: Generate structured feature-list.json from the clarified requirements.
 
 **STEPS**:
 
-1. **Invoke `app-planner` skill** with the user's requirement description:
+1. **Invoke `app-planner` skill** with the full requirements summary from Phase 1:
+   - Pass the structured requirements summary as input — NOT the raw user conversation
    - For new projects: standard planning mode
    - For existing projects with `--incremental`: incremental planning mode
 
 2. **Interactive planning** (if app-planner requires clarification):
-   - Pass through any questions to the user
-   - Collect responses and continue planning
+   - Because Phase 1 was thorough, app-planner should need minimal clarification
+   - If questions arise, answer from the Phase 1 context or pass through to user
 
 3. **Validate output**:
    - Confirm `feature-list.json` exists
@@ -113,11 +251,11 @@ When user says "add features to existing project" or the project already has fea
 
 **CHECKPOINT CP-FW-1**: `feature-list.json` generated and validated.
 
-**If user says `--from <file>`**: Skip this phase entirely.
+**If user says `--from <file>`**: Skip Phase 1 and Phase 2 entirely.
 
 ---
 
-## Phase 2: Launch
+## Phase 3: Launch
 
 **Goal**: Start the development pipeline.
 
@@ -141,13 +279,13 @@ When user says "add features to existing project" or the project already has fea
 
 3. **Verify launch success**:
    - Confirm pipeline is running
-   - Record PID and log path for Phase 3
+   - Record PID and log path for Phase 4
 
 **CHECKPOINT CP-FW-2**: Pipeline launched successfully.
 
 ---
 
-## Phase 3: Monitor
+## Phase 4: Monitor
 
 **Goal**: Track pipeline progress and report to user.
 
@@ -196,9 +334,9 @@ The workflow supports resuming by detecting existing state:
 
 | State Found | Resume From |
 |-------------|------------|
-| No `feature-list.json` | Phase 1: Plan |
-| `feature-list.json` exists, no pipeline state | Phase 2: Launch |
-| `feature-list.json` + pipeline state exists | Phase 3: Monitor (check status) |
+| No `feature-list.json` | Phase 1: Brainstorm |
+| `feature-list.json` exists, no pipeline state | Phase 3: Launch |
+| `feature-list.json` + pipeline state exists | Phase 4: Monitor (check status) |
 | All features completed | Report completion, suggest next steps |
 
 **Resume**: If `feature-list.json` exists, ask user: "Existing feature plan found with N features. Resume pipeline or re-plan?"
@@ -222,11 +360,13 @@ While the pipeline runs, the user can continue the conversation:
 
 | Error | Action |
 |-------|--------|
-| `app-planner` cannot parse requirements | Ask user for clarification |
+| User's idea is too vague to brainstorm | Ask for more context: "Can you describe the main problem this solves?" |
+| Brainstorming stalls | Offer concrete options: "Would you prefer A or B?" |
+| `app-planner` cannot parse requirements | Refine the requirements summary and retry |
 | `feature-list.json` generation failed | Show error, retry with refined input |
 | Pipeline launch failed | Show daemon log, suggest manual start |
 | All features blocked/failed | Show status, suggest retrying specific features |
-| User wants to cancel mid-planning | Stop and save partial feature-list.json |
+| User wants to cancel mid-brainstorming | Save conversation context, offer to resume later |
 
 ---
 
@@ -234,8 +374,8 @@ While the pipeline runs, the user can continue the conversation:
 
 | Skill | Relationship |
 |-------|-------------|
-| `app-planner` | **Called by Phase 1** — generates feature-list.json |
-| `dev-pipeline-launcher` | **Called by Phase 2** — starts pipeline (handles execution mode selection) |
+| `app-planner` | **Called by Phase 2** — generates feature-list.json from clarified requirements |
+| `dev-pipeline-launcher` | **Called by Phase 3** — starts pipeline (handles execution mode selection) |
 | `bug-planner` | **Alternative** — for bug fix workflows |
 | `bugfix-pipeline-launcher` | **Alternative** — for bug fix pipelines |
 | `refactor-workflow` | **Alternative** — for code restructuring |
@@ -247,12 +387,13 @@ While the pipeline runs, the user can continue the conversation:
 | Dimension | feature-workflow | bug-fix-workflow | refactor-workflow |
 |-----------|-----------------|------------------|-------------------|
 | **Purpose** | New features (batch) | Single bug fix (interactive) | Code restructuring |
+| **Brainstorming** | Yes — deep interactive Q&A | No (bug report is input) | No (analysis built-in) |
 | **Planning Skill** | `app-planner` | None (triage built-in) | None (analysis built-in) |
 | **Branch** | Pipeline manages per-feature | `fix/<BUG_ID>-*` | `refactor/<slug>` |
 | **Execution** | Foreground or background daemon | In-session, interactive | In-session |
-| **Input** | Requirements description | Bug report / stack trace | Module / code target |
+| **Input** | Rough idea or requirements | Bug report / stack trace | Module / code target |
 | **Output** | Multiple `feat()` commits | Single `fix()` commit | Single `refactor()` commit |
-| **User verification** | No (pipeline automated) | Yes (Phase 5) | Yes (Phase 5) |
+| **User verification** | Yes (Phase 1 brainstorm confirmation) | Yes (Phase 5) | Yes (Phase 5) |
 | **Batch alternative** | (this is the batch flow) | `bug-planner` + `bugfix-pipeline-launcher` | N/A |
 
 ---
@@ -263,8 +404,9 @@ All internal asset paths use `${SKILL_DIR}` placeholder for cross-IDE compatibil
 
 ## Output
 
-- `feature-list.json` (Phase 1 artifact)
-- Pipeline execution (Phase 2)
-- Progress updates (Phase 3)
+- Structured requirements summary (Phase 1 artifact)
+- `feature-list.json` (Phase 2 artifact)
+- Pipeline execution (Phase 3)
+- Progress updates (Phase 4)
 - Multiple git commits with `feat(<scope>):` prefix
 - Updated `.prizm-docs/` (via prizmkit-retrospective per feature)

package/bundled/skills/prizm-kit/SKILL.md

@@ -115,6 +115,6 @@ python3 ${SKILL_DIR}/scripts/install-prizmkit.py --target <project-skills-dir>
 
 Both CodeBuddy and Claude Code use unified commands for automatic doc updates and commit enforcement.
 Hooks and rules are configured automatically by `prizmkit-init`. See:
-- `core/templates/hooks/commit-intent.json` for the commit hook template
+- The commit hook template is configured automatically during `prizmkit-init`
 - `assets/project-memory-template.md` for the project memory template
 - The init skill creates `prizm-documentation.md` and `prizm-commit-workflow.md` rules

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

@@ -46,7 +46,54 @@ Execute implementation by following the task breakdown in plan.md. Respects task
    f. Error handling: sequential tasks stop on failure (later tasks may depend on this one). Parallel `[P]` tasks continue — report all failures at the end.
 5. At each checkpoint: verify build passes and tests pass. Checkpoints catch integration errors early — skipping them means cascading failures in later phases that are much harder to debug.
 6. After all tasks: run full test suite
-7. Output implementation summary with pass/fail status
+7. **Deploy guide update** (only when new frameworks/tools were added):
+   - Check if any dependency manifests were modified in this session:
+     ```bash
+     git diff --name-only HEAD -- package.json requirements*.txt Pipfile pyproject.toml go.mod Cargo.toml pom.xml build.gradle Gemfile composer.json docker-compose*.yml Dockerfile .tool-versions 2>/dev/null
+     ```
+   - If no manifest files changed → skip this step entirely
+   - If manifest files changed, scan for **newly added** dependencies (not version bumps):
+     ```bash
+     git diff -U0 HEAD -- package.json requirements*.txt Pipfile pyproject.toml go.mod Cargo.toml pom.xml build.gradle Gemfile composer.json docker-compose*.yml Dockerfile .tool-versions 2>/dev/null | grep '^\+' | grep -v '^\+\+\+' | head -30
+     ```
+   - For each genuinely new framework/tool, record in `deploy_guide.md` at project root:
+
+     | Field | Description | Source |
+     |-------|-------------|--------|
+     | **Name** | Framework/tool name | Package name from manifest |
+     | **Version** | Installed version or constraint | Version spec from manifest |
+     | **Purpose** | Why it was introduced | You just added it — you know why |
+     | **Install Command** | How to install locally | Standard install command for the ecosystem |
+     | **Key Config** | Config files or env vars needed | Config files you just created/modified |
+     | **Notes** | Setup gotchas, required services | Docker services, manual steps, env vars |
+
+   - Template for `deploy_guide.md`:
+     ```markdown
+     # Deploy Guide
+
+     > Auto-maintained by PrizmKit. Manual edits are preserved.
+     > Last updated: YYYY-MM-DD
+
+     ## Frameworks & Tools
+
+     ### <Framework Name>
+
+     - **Version**: <version constraint>
+     - **Purpose**: <why this framework is used>
+     - **Install**:
+       ```bash
+       <install command>
+       ```
+     - **Key Config**:
+       - `<config file or env var>`: <description>
+     - **Notes**:
+       - <any setup gotchas, required external services, manual steps>
+     ```
+
+   - **Update rules**: create file if absent; append new sections if file exists; update version if framework already documented; preserve manually added content; keep entries sorted alphabetically
+   - **Filter out**: patch version bumps of existing deps, dev-only tools needing no setup (linters, formatters), transitive/lock-file-only changes
+   - Stage the file: `git add deploy_guide.md`
+8. Output implementation summary with pass/fail status
 
 ## Task Format in plan.md
 
@@ -85,4 +132,5 @@ If a session is interrupted mid-implementation:
 
 - Code files created/modified as specified in plan.md Tasks section
 - `plan.md` Tasks section updated with completion markers `[x]`
+- `deploy_guide.md` created/updated (only when new frameworks/tools were added)
 - Implementation summary output to conversation