prizmkit 1.1.0 → 1.1.3

package/bundled/skills/{app-planner → feature-planner}/assets/planning-guide.md

@@ -1,176 +1,8 @@
-# App Planning Reference Guide
+# Feature Planning Reference Guide
 
-This guide provides structured templates, decision matrices, and patterns for each phase of the app planning process. It is intended as a practical reference for the AI during interactive planning sessions.
+This guide provides structured templates and patterns for writing high-quality feature descriptions, acceptance criteria, complexity estimates, dependency graphs, and session granularity decisions. Use during feature-planner sessions.
 
----
-
-## 1. App Vision Template
-
-Use this template to capture the app vision during the initial planning phase.
-
-```markdown
-# App Vision: [APP_NAME]
-
-## Problem Statement
-[What problem does this app solve?]
-
-## Target Users
-- Primary: [Who are the main users?]
-- Secondary: [Any secondary user types?]
-
-## Core Value Proposition
-[What makes this app valuable? What's the "elevator pitch"?]
-
-## Key Differentiators
-[What sets this apart from existing solutions?]
-```
-
-### Guidance
-
-- **Problem Statement**: Should describe a real pain point in 1-3 sentences. Avoid vague statements like "improve productivity." Be specific about who suffers and why.
-- **Target Users**: Identify at least one primary user persona. Secondary users are optional but useful for prioritization decisions later.
-- **Core Value Proposition**: Should be expressible in one sentence. If it takes a paragraph, the scope is likely too broad.
-- **Key Differentiators**: List 1-3 concrete differentiators. If none exist, reconsider whether the app needs to be built.
-
----
-
-## 2. Tech Stack Decision Matrix
-
-Use these tables to guide tech stack selection based on project requirements.
-
-### Frontend Frameworks
-
-| Framework | Best For | Ecosystem |
-|-----------|----------|-----------|
-| Next.js 14+ | Full-stack React, SSR, API routes | React ecosystem, Vercel |
-| Nuxt 3 | Full-stack Vue, SSR | Vue ecosystem |
-| SvelteKit | Performance-focused, smaller teams | Svelte ecosystem |
-| Remix | Nested routes, data loading | React ecosystem |
-
-### Backend Frameworks
-
-| Framework | Best For | Language |
-|-----------|----------|----------|
-| Express.js | Flexible, minimal | Node.js/TS |
-| FastAPI | High-perf APIs, Python ML | Python |
-| NestJS | Enterprise, structured | Node.js/TS |
-| Django | Batteries-included, admin | Python |
-| Go (Gin/Echo) | High concurrency | Go |
-
-### Databases
-
-| Database | Best For | Type |
-|----------|----------|------|
-| PostgreSQL | Complex queries, ACID | Relational |
-| MySQL | Read-heavy, simple | Relational |
-| MongoDB | Flexible schema, documents | Document |
-| SQLite | Embedded, prototyping | Relational |
-| Redis | Caching, sessions, pub/sub | Key-Value |
-
-### Design Systems
-
-| System | Best For | Framework |
-|--------|----------|-----------|
-| shadcn/ui | Modern, customizable | React/Next.js |
-| Ant Design | Enterprise, data-heavy | React |
-| Material UI | Google-style, full-featured | React |
-| Vuetify | Material Design for Vue | Vue |
-| Tailwind CSS | Utility-first, any framework | Any |
-
-### Common Service Patterns
-
-| Need | Options |
-|------|---------|
-| Auth | NextAuth.js, Auth0, Clerk, Supabase Auth, custom JWT |
-| Real-time | WebSocket, Socket.io, SSE, Supabase Realtime |
-| File Storage | S3, Cloudflare R2, Supabase Storage |
-| Email | SendGrid, Resend, Postmark |
-| Payments | Stripe, LemonSqueezy |
-| Search | Algolia, Meilisearch, Elasticsearch |
-
-### Selection Heuristics
-
-- If the user has no strong preference, default to **Next.js + PostgreSQL + shadcn/ui + Tailwind CSS** as a general-purpose stack.
-- If the project involves ML/AI backends, prefer **FastAPI** on the backend.
-- If the project requires high concurrency with minimal resource usage, consider **Go**.
-- If rapid prototyping is the goal, consider **SQLite** initially with a migration path to PostgreSQL.
-- Always ask about deployment preferences (Vercel, AWS, self-hosted) as this influences framework choice.
-
----
-
-## 3. Feature Decomposition Patterns
-
-Use these patterns as starting points when breaking an app into features. Adapt them to the specific project.
-
-### Pattern A: CRUD-Based App
-
-Examples: CMS, project management tools, inventory systems.
-
-```
-F-001: Infrastructure Setup (no deps)
-F-002: User Authentication (deps: F-001)
-F-003: Core Entity CRUD (deps: F-002)
-F-004: Entity Relationships (deps: F-003)
-F-005: Search & Filtering (deps: F-003)
-F-006: Notifications (deps: F-003)
-F-007: Admin Dashboard (deps: F-004, F-005)
-F-008: Analytics & Reporting (deps: F-007)
-```
-
-### Pattern B: SaaS Platform
-
-Examples: subscription services, multi-tenant tools, B2B products.
-
-```
-F-001: Infrastructure + Multi-tenant Setup (no deps)
-F-002: User Auth + Organization Management (deps: F-001)
-F-003: Core Product Feature (deps: F-002)
-F-004: Subscription & Billing (deps: F-002)
-F-005: Usage Tracking & Limits (deps: F-003, F-004)
-F-006: Admin Portal (deps: F-005)
-F-007: API & Integrations (deps: F-003)
-F-008: Analytics Dashboard (deps: F-006, F-007)
-```
-
-### Pattern C: Social/Community App
-
-Examples: forums, social networks, community platforms.
-
-```
-F-001: Infrastructure Setup (no deps)
-F-002: User Auth + Profiles (deps: F-001)
-F-003: Content Creation (posts/media) (deps: F-002)
-F-004: Social Graph (follow/friend) (deps: F-002)
-F-005: Feed Algorithm (deps: F-003, F-004)
-F-006: Interactions (likes, comments) (deps: F-003)
-F-007: Real-time Messaging (deps: F-004)
-F-008: Notifications (deps: F-005, F-006, F-007)
-F-009: Discovery & Search (deps: F-005)
-```
-
-### Pattern D: E-commerce App
-
-Examples: online stores, marketplaces, booking platforms.
-
-```
-F-001: Infrastructure Setup (no deps)
-F-002: User Auth (deps: F-001)
-F-003: Product Catalog (deps: F-001)
-F-004: Shopping Cart (deps: F-002, F-003)
-F-005: Checkout & Payment (deps: F-004)
-F-006: Order Management (deps: F-005)
-F-007: Inventory Management (deps: F-003)
-F-008: Reviews & Ratings (deps: F-002, F-003)
-F-009: Search & Recommendations (deps: F-003, F-008)
-F-010: Admin Dashboard (deps: F-006, F-007)
-```
-
-### Decomposition Guidelines
-
-- Every app starts with an infrastructure/setup feature (F-001) that has zero dependencies.
-- Authentication almost always comes second unless the app is fully public.
-- Group related functionality into single features rather than splitting too finely. A feature should represent a coherent unit of user-facing value.
-- If a pattern does not match the app being planned, combine elements from multiple patterns or define a custom decomposition from scratch.
+For app-level design references (vision templates, tech stack matrix), see `app-planner/assets/app-design-guide.md`. For feature decomposition patterns (CRUD, SaaS, Social, E-commerce), see `${SKILL_DIR}/references/decomposition-patterns.md`.
 
 ---
 

package/bundled/skills/{app-planner → feature-planner}/references/browser-interaction.md

@@ -16,10 +16,9 @@ If yes, generate the `browser_interaction` object:
     "url": "http://localhost:3000/login",
     "setup_command": "npm run dev",
     "verify_steps": [
-      "snapshot",
-      "click <ref> — click login button",
-      "fill <ref> 'test@example.com' — enter email",
-      "screenshot"
+      "Verify login form renders with email and password fields",
+      "Verify valid credentials redirect to dashboard",
+      "Verify invalid password shows error message"
     ],
     "screenshot": true
   }
@@ -30,5 +29,7 @@ If yes, generate the `browser_interaction` object:
 
 - `url` is required — the page URL to verify
 - `setup_command` is optional — command to start dev server (omit if already running)
-- `verify_steps` are descriptive placeholders — the actual `ref` IDs are resolved at runtime by `playwright-cli snapshot`. Use natural language descriptions (e.g., "click login button") that the pipeline agent will map to real refs.
+- `verify_steps` are **verification goals**, not specific playwright-cli commands. Describe WHAT to verify, not HOW to verify it. The pipeline AI will read the actual code, use `playwright-cli snapshot` to discover real element refs, and decide the concrete click/fill/assert operations itself. This works better than prescribing steps at planning time because: (1) element refs don't exist yet, (2) UI structure may change during implementation, (3) the AI has full context of the actual code when it runs verification.
+  - **Good**: `"Verify login form accepts valid credentials and redirects to dashboard"`
+  - **Bad**: `"click <ref> — click login button"` (guesses at refs that don't exist yet)
 - `screenshot` defaults to `true` — capture final state for human review

package/bundled/skills/feature-planner/references/decomposition-patterns.md

@@ -0,0 +1,75 @@
+# Feature Decomposition Patterns
+
+Use these patterns as starting points when breaking an app into features. Adapt them to the specific project.
+
+For app-level design references (vision templates, tech stack decision matrix), see `app-planner/assets/app-design-guide.md`.
+
+## Pattern A: CRUD-Based App
+
+Examples: CMS, project management tools, inventory systems.
+
+```
+F-001: Infrastructure Setup (no deps)
+F-002: User Authentication (deps: F-001)
+F-003: Core Entity CRUD (deps: F-002)
+F-004: Entity Relationships (deps: F-003)
+F-005: Search & Filtering (deps: F-003)
+F-006: Notifications (deps: F-003)
+F-007: Admin Dashboard (deps: F-004, F-005)
+F-008: Analytics & Reporting (deps: F-007)
+```
+
+## Pattern B: SaaS Platform
+
+Examples: subscription services, multi-tenant tools, B2B products.
+
+```
+F-001: Infrastructure + Multi-tenant Setup (no deps)
+F-002: User Auth + Organization Management (deps: F-001)
+F-003: Core Product Feature (deps: F-002)
+F-004: Subscription & Billing (deps: F-002)
+F-005: Usage Tracking & Limits (deps: F-003, F-004)
+F-006: Admin Portal (deps: F-005)
+F-007: API & Integrations (deps: F-003)
+F-008: Analytics Dashboard (deps: F-006, F-007)
+```
+
+## Pattern C: Social/Community App
+
+Examples: forums, social networks, community platforms.
+
+```
+F-001: Infrastructure Setup (no deps)
+F-002: User Auth + Profiles (deps: F-001)
+F-003: Content Creation (posts/media) (deps: F-002)
+F-004: Social Graph (follow/friend) (deps: F-002)
+F-005: Feed Algorithm (deps: F-003, F-004)
+F-006: Interactions (likes, comments) (deps: F-003)
+F-007: Real-time Messaging (deps: F-004)
+F-008: Notifications (deps: F-005, F-006, F-007)
+F-009: Discovery & Search (deps: F-005)
+```
+
+## Pattern D: E-commerce App
+
+Examples: online stores, marketplaces, booking platforms.
+
+```
+F-001: Infrastructure Setup (no deps)
+F-002: User Auth (deps: F-001)
+F-003: Product Catalog (deps: F-001)
+F-004: Shopping Cart (deps: F-002, F-003)
+F-005: Checkout & Payment (deps: F-004)
+F-006: Order Management (deps: F-005)
+F-007: Inventory Management (deps: F-003)
+F-008: Reviews & Ratings (deps: F-002, F-003)
+F-009: Search & Recommendations (deps: F-003, F-008)
+F-010: Admin Dashboard (deps: F-006, F-007)
+```
+
+## Decomposition Guidelines
+
+- Every app starts with an infrastructure/setup feature (F-001) that has zero dependencies.
+- Authentication almost always comes second unless the app is fully public.
+- Group related functionality into single features rather than splitting too finely. A feature should represent a coherent unit of user-facing value.
+- If a pattern does not match the app being planned, combine elements from multiple patterns or define a custom decomposition from scratch.

package/bundled/skills/{app-planner → feature-planner}/references/error-recovery.md

@@ -51,7 +51,7 @@ if all_retries_exceeded:
 
 ## Resume Support
 
-App-planner sessions can be resumed from the last completed checkpoint without losing context.
+feature-planner sessions can be resumed from the last completed checkpoint without losing context.
 
 ### Detection Logic
 
@@ -59,10 +59,10 @@ Check for artifact files in working directory:
 
 | Artifacts Found | Last Completed Checkpoint | Next Phase | Resume Action |
 |-----------------|--------------------------|-----------|----------------|
-| None | (new session) | Phase 1: Vision | Start fresh planning |
-| `feature-list.json` exists | CP-AP-6 (file generated) | Phase 7: Final validation | Offer to validate or extend |
-| `feature-list.json` + validation passed | CP-AP-7 (validation pass) | Handoff: dev-pipeline | Offer: execute pipeline now |
-| Partial state (incomplete file) | CP-AP-2 or CP-AP-4 | Next phase after last checkpoint | Resume interactive planning |
+| None | (new session) | Phase 1: Scope | Start fresh planning |
+| `feature-list.json` exists | CP-FP-4 (file generated) | Phase 9: Final validation | Offer to validate or extend |
+| `feature-list.json` + validation passed | CP-FP-5 (validation pass) | Handoff: dev-pipeline | Offer: execute pipeline now |
+| Partial state (incomplete file) | CP-FP-1 or CP-FP-2 | Next phase after last checkpoint | Resume interactive planning |
 | User restarts mid-session | User says "restart" | Return to Phase 1 Vision, or load previous checkpoint if requested |
 | Max validation retries exceeded | 3 failed validation loops | Offer: (a) manual review, (b) restart from Phase 1 |
 
@@ -72,7 +72,7 @@ For projects using `.prizmkit/` structure:
 
 ```bash
 # Explicit resume (if file is not in current directory):
-app-planner --resume-from <path-to-existing-feature-list.json>
+feature-planner --resume-from <path-to-existing-feature-list.json>
 ```
 
 AI detects existing file → suggests:
@@ -85,7 +85,7 @@ Resume incremental planning? (Y/n)"
 
 If in Incremental mode but existing `feature-list.json` not found:
 - Ask: "Start new plan or provide existing file?"
-- If new plan chosen → switch to Route A (New App Planning)
+- If new plan chosen → switch to Route A (New Feature Set)
 - If existing file uploaded → continue Route B
 
 ### Artifact Path Convention
@@ -102,7 +102,7 @@ After writing, verify: `ls -la feature-list.json` from project root.
 <project-root>/
   ├── feature-list.json              # Primary output (always here, at project root)
   └── .prizmkit/planning/            # Optional organization for backups
-      ├── feature-list.validated.json    # Checkpoint backup after CP-AP-7
+      ├── feature-list.validated.json    # Checkpoint backup after CP-FP-5
       └── <ISO-timestamp>.backup.json    # Optional incremental backups
 ```
 

package/bundled/skills/{app-planner → feature-planner}/references/incremental-feature-planning.md

@@ -109,4 +109,4 @@ Use concise prompts during interaction:
 - [ ] Existing style preserved
 - [ ] Dependency graph still DAG
 - [ ] Validation passes
-- [ ] Next step recommendation follows priority: launcher → daemon → run.sh
+- [ ] Next step recommendation follows priority: launcher → daemon → run-feature.sh

package/bundled/skills/{app-planner/references/new-app-planning.md → feature-planner/references/new-project-planning.md}

@@ -82,4 +82,4 @@ Split into `sub_features` when:
 - [ ] IDs are sequential
 - [ ] `status` initialized to `pending`
 - [ ] Validation passes
-- [ ] Next step recommendation follows priority: launcher → daemon → run.sh
+- [ ] Next step recommendation follows priority: launcher → daemon → run-feature.sh

package/bundled/skills/{app-planner → feature-planner}/scripts/validate-and-generate.py

@@ -13,7 +13,7 @@ Usage:
   python3 validate-and-generate.py validate --input feature-list.json [--output validated.json] [--mode new|incremental]
   python3 validate-and-generate.py template --output feature-list.json
   python3 validate-and-generate.py summary --input feature-list.json [--format markdown|json]
-  python3 validate-and-generate.py grade --workspace /.codebuddy/skill-evals/app-planner-workspace --iteration iteration-1
+  python3 validate-and-generate.py grade --workspace /.codebuddy/skill-evals/feature-planner-workspace --iteration iteration-1
 
 Python 3.6+ required. No external dependencies.
 """
@@ -444,7 +444,7 @@ def generate_template():
         "app_name": "YOUR_APP_NAME",
         "app_description": "YOUR_APP_DESCRIPTION",
         "created_at": now,
-        "created_by": "app-planner",
+        "created_by": "feature-planner",
         "source_spec": "",
         "features": [
             {
@@ -740,7 +740,7 @@ def cmd_grade(args):
     """Handle the 'grade' command for evaluation framework integration.
     
     Collects validation results from eval runs and generates grading data.
-    Used by npm run skill:review for automated evaluation of app-planner.
+    Used by npm run skill:review for automated evaluation of feature-planner.
     """
     workspace = getattr(args, 'workspace', None)
     iteration = getattr(args, 'iteration', None)
@@ -911,7 +911,7 @@ def main():
     p_grade.add_argument(
         "--workspace",
         required=True,
-        help="Path to eval workspace (e.g., /.codebuddy/skill-evals/app-planner-workspace)",
+        help="Path to eval workspace (e.g., /.codebuddy/skill-evals/feature-planner-workspace)",
     )
     p_grade.add_argument(
         "--iteration",

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

@@ -1,7 +1,7 @@
 ---
 name: "feature-workflow"
 tier: companion
-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)"
+description: "One-stop entry point for feature development. Brainstorms requirements with the user until fully clarified, then orchestrates feature-planner → feature-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
@@ -18,8 +18,8 @@ User says:
 - After receiving a batch of related feature requests
 
 **Do NOT use this skill when:**
-- User only wants to plan features (use `app-planner` directly)
-- User only wants to launch pipeline for existing feature-list.json (use `dev-pipeline-launcher`)
+- User only wants to plan features (use `feature-planner` directly)
+- User only wants to launch pipeline for existing feature-list.json (use `feature-pipeline-launcher`)
 - User wants to fix bugs (use `bug-planner` + `bugfix-pipeline-launcher`)
 - User wants to refactor code (use `refactor-workflow`)
 
@@ -32,9 +32,9 @@ feature-workflow <idea / requirements>
    │
    ├── Phase 1: Brainstorm → deep interactive Q&A until requirements are crystal clear
    │
-   ├── Phase 2: Plan → app-planner → feature-list.json
+   ├── Phase 2: Plan → feature-planner → feature-list.json
    │
-   ├── Phase 3: Launch → dev-pipeline-launcher → pipeline execution
+   ├── Phase 3: Launch → feature-pipeline-launcher → pipeline execution
    │
    └── Phase 4: Monitor → track progress → report results
 ```
@@ -44,16 +44,16 @@ feature-workflow <idea / requirements>
 | Phase | Action | Result |
 |-------|--------|--------|
 | 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) |
+| 2 | Call `feature-planner` with clarified requirements | `feature-list.json` with N features |
+| 3 | Call `feature-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. Figure out all requirements themselves
-2. Invoke `app-planner` → wait for feature-list.json
-3. Invoke `dev-pipeline-launcher` → wait for pipeline start
+2. Invoke `feature-planner` → wait for feature-list.json
+3. Invoke `feature-pipeline-launcher` → wait for pipeline start
 4. Manually check progress
 
 With this skill, users can:
@@ -79,22 +79,22 @@ 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: brainstorm → app-planner → dev-pipeline-launcher → monitor
+Flow: brainstorm → feature-planner → feature-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 brainstorm and `app-planner` (file already exists)
-- Invoke `dev-pipeline-launcher` directly
+- Skip brainstorm and `feature-planner` (file already exists)
+- Invoke `feature-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)
+- Invoke `feature-planner` in incremental mode (reads existing feature-list.json)
 - Append new features to existing list
-- Invoke `dev-pipeline-launcher`
+- Invoke `feature-pipeline-launcher`
 - Monitor and report progress
 
 ---
@@ -236,13 +236,13 @@ Present this summary to the user and get explicit confirmation before proceeding
 
 **STEPS**:
 
-1. **Invoke `app-planner` skill** with the full requirements summary from Phase 1:
+1. **Invoke `feature-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):
-   - Because Phase 1 was thorough, app-planner should need minimal clarification
+2. **Interactive planning** (if feature-planner requires clarification):
+   - Because Phase 1 was thorough, feature-planner should need minimal clarification
    - If questions arise, answer from the Phase 1 context or pass through to user
 
 3. **Validate output**:
@@ -271,7 +271,7 @@ Present this summary to the user and get explicit confirmation before proceeding
    Proceed? (Y/n)
    ```
 
-2. **Invoke `dev-pipeline-launcher` skill**:
+2. **Invoke `feature-pipeline-launcher` skill**:
    - The launcher handles all prerequisites checks
    - The launcher presents execution mode choices to the user (foreground/background/manual)
    - The launcher asks whether to enable Critic Agent (adversarial review) — passes `--critic` flag if chosen
@@ -294,7 +294,7 @@ Present this summary to the user and get explicit confirmation before proceeding
 
 1. **Initial status check**:
    ```bash
-   dev-pipeline/launch-daemon.sh status
+   dev-pipeline/launch-feature-daemon.sh status
    ```
 
 2. **Offer monitoring options**:
@@ -363,7 +363,7 @@ While the pipeline runs, the user can continue the conversation:
 |-------|--------|
 | 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-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 |
@@ -375,8 +375,8 @@ While the pipeline runs, the user can continue the conversation:
 
 | Skill | Relationship |
 |-------|-------------|
-| `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) |
+| `feature-planner` | **Called by Phase 2** — generates feature-list.json from clarified requirements |
+| `feature-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 |
@@ -389,7 +389,7 @@ While the pipeline runs, the user can continue the conversation:
 |-----------|-----------------|------------------|-------------------|
 | **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) |
+| **Planning Skill** | `feature-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** | Rough idea or requirements | Bug report / stack trace | Module / code target |

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

@@ -1,12 +1,10 @@
 ---
 name: "prizm-kit"
-description: "Full-lifecycle dev toolkit. Covers spec-driven development, Prizm context docs, code quality, debugging, deployment, and knowledge management. Use this skill whenever the user asks about PrizmKit workflow, wants to know which command to use, or needs help choosing between full workflow and fast path. Trigger on: '/prizmkit', 'prizmkit help', 'which prizmkit command', 'how do I start a feature'. (project)"
+description: "Full-lifecycle dev toolkit index. Routes to the right PrizmKit skill for spec-driven development, Prizm docs, code quality, deployment, and knowledge management. Use when the user asks 'which command?', 'help', 'how do I start a feature', or '/prizmkit'. (project)"
 ---
 
 # PrizmKit — Full-Lifecycle Development Toolkit
 
-PrizmKit is a comprehensive, independent AI development toolkit that covers the complete development lifecycle from project inception to delivery and maintenance. It can take over any project and keep documentation in sync with code.
-
 
 ## When to Use the Full Workflow
 

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

@@ -1,12 +1,10 @@
 ---
 name: "prizmkit-analyze"
-description: "Cross-document consistency analysis for spec.md and plan.md (including Tasks section). Detects duplications, ambiguities, gaps, and rule conflicts. Read-only. Use this skill to check if spec and plan are aligned, validate documents before coding, or as a quality gate after planning. Trigger on: 'analyze', 'check consistency', 'validate spec', 'review plan', 'is the spec ready', 'check if spec and plan are aligned', 'validate documents before coding'. (project)"
+description: "Cross-document consistency analysis for spec.md and plan.md. Detects duplications, ambiguities, gaps, and rule conflicts. Read-only quality gate — use after /prizmkit-plan, before /prizmkit-implement. Trigger on: 'analyze', 'check consistency', 'validate spec', 'review plan', 'is the spec ready'. (project)"
 ---
 
 # PrizmKit Analyze
 
-Perform a non-destructive cross-artifact consistency and quality analysis across spec.md and plan.md (including Tasks section) before implementation. Identifies duplications, ambiguities, underspecified items, rule conflicts, and coverage gaps.
-
 ### When to Use
 - After `/prizmkit-plan` to validate spec-plan-tasks alignment before implementation
 - User says "analyze", "check consistency", "validate spec", "review plan"
@@ -179,7 +177,6 @@ Ask the user: "Would you like me to suggest concrete remediation edits for the t
 - Rerunning without changes should produce consistent IDs and counts (deterministic)
 
 ### Analysis Approach
-- Do not modify files — read-only analysis ensures artifacts remain stable for the implement phase
 - If a section is absent, report it accurately rather than guessing what it might contain
 - Prizm Rules violations are always CRITICAL — they represent project-wide constraints that outrank individual feature decisions
 - Cite specific instances rather than generic patterns — "spec §2.1 says REST but plan §Architecture says GraphQL" is more useful than "terminology inconsistency found"
@@ -207,4 +204,4 @@ In unattended pipeline mode, the analyze→fix→analyze cycle can loop indefini
 
 ## Output
 
-Analysis report is output to conversation only. No files are created or modified.
+Analysis report is output to conversation only.

package/bundled/skills/prizmkit-code-review/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: "prizmkit-code-review"
-description: "Code review with fix strategy formulation. Diagnoses issues across 6 dimensions, then produces structured Fix Instructions with root cause, impact analysis, and verification criteria. Use after implementation as quality gate before committing. Trigger on: 'review', 'check code', 'review my implementation', 'code review', 'is it ready to commit'. (project)"
+description: "Code review with fix strategy formulation. Diagnoses issues across 6 dimensions, then produces structured Fix Instructions. Use after /prizmkit-implement as quality gate before committing. Trigger on: 'review', 'check code', 'code review', 'is it ready to commit'. (project)"
 ---
 
 # PrizmKit Code Review
@@ -31,7 +31,7 @@ The review itself is read-only. Fix Instructions are structured guidance for the
 
 1. **Detect mode and load review baseline + dimension rules**:
    - If `spec.md` exists → **Feature mode**: read `spec.md` + `plan.md` as baseline. Load `${SKILL_DIR}/rules/dimensions-feature.md` for review dimensions.
-   - If `refactor-analysis.md` exists → **Refactor mode**: read `refactor-analysis.md` + `plan.md` as baseline. Load `${SKILL_DIR}/rules/dimensions-refactor.md` for review dimensions.
+   - If `refactor-analysis.md` exists → **Refactor mode**: read `refactor-analysis.md` + `plan.md` as baseline. Load `${SKILL_DIR}/rules/dimensions-refactor.md` for refactor-specific dimensions, **and also** `${SKILL_DIR}/rules/dimensions-feature.md` §3–§6 for standard dimensions (code quality, security, consistency, test coverage) that still apply.
    - If `fix-plan.md` exists → **Bugfix mode**: read `fix-plan.md` as baseline. Load `${SKILL_DIR}/rules/dimensions-bugfix.md` for review dimensions.
    - If none found → prompt user: "No review baseline found. Which workflow are you in? (feature/refactor/bugfix)"
 2. Read **architecture index**: `.prizm-docs/root.prizm` RULES and PATTERNS for project conventions

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

@@ -1,14 +1,10 @@
 ---
 name: "prizmkit-committer"
-description: "Pure git commit workflow with safety checks. Stages files, analyzes diff, generates Conventional Commits message, and commits. Does NOT modify .prizm-docs/ — architecture sync is handled by /prizmkit-retrospective before this skill is invoked. Trigger on: 'commit', 'submit', 'finish', 'done', 'ship it', 'save my work'. (project)"
+description: "Pure git commit workflow with safety checks. Stages files, generates Conventional Commits message, and commits. Does NOT modify .prizm-docs/ — run /prizmkit-retrospective first. Trigger on: 'commit', 'submit', 'finish', 'done', 'ship it'. (project)"
 ---
 
 # PrizmKit Committer
 
-Pure git commit workflow. Analyzes changes, generates a Conventional Commits message, performs safety checks, and commits.
-
-**This skill is a pure git commit tool. It does NOT modify any project files — no `.prizm-docs/`, no source code.** It only reads diffs, generates a commit message, and commits. For feature/refactor workflows, run `/prizmkit-retrospective` (and optionally `/prizmkit-deploy` if new infrastructure was introduced) before this skill. For bug fixes, skip retrospective and deploy entirely.
-
 ### When to Use
 - User says "commit", "submit", "finish", "done with this task", "ship it"
 - After `/prizmkit-retrospective` has finished architecture sync
@@ -24,7 +20,7 @@ Pure git commit workflow. Analyzes changes, generates a Conventional Commits mes
 
 ### Workflow
 
-Follow these steps STRICTLY in order:
+Follow these steps in order — skipping or reordering can stage sensitive files or commit without proper verification:
 
 #### Step 1: Status Check
 ```bash
@@ -33,8 +29,8 @@ git status
 - If "nothing to commit, working tree clean": inform user and stop
 - If there are changes: proceed
 
-#### Step 2: Condense Commit
-By consulting the primary agent or based on the existing context, condense this commit message.
+#### Step 2: Generate Commit Message
+Analyze the staged diff and context (spec title, plan summary, review verdict) to generate a concise Conventional Commits message. The message should capture the *what* and *why* of the change.
 
 #### Step 3: Update CHANGELOG.md
 If CHANGELOG.md exists in the project root, append an entry following Keep a Changelog format under the `[Unreleased]` section. Match the existing style in the file.

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

@@ -1,14 +1,10 @@
 ---
 name: "prizmkit-deploy"
-description: "Generate or update deployment documentation based on project state and deploy strategy. Produces DEPLOY.md with local dev setup, testing, production deployment, and rollback procedures. Fully autonomous — no user interaction required. Use after /prizmkit-retrospective and before /prizmkit-committer. Trigger on: 'deploy docs', 'deployment guide', 'how to deploy', 'generate deploy', 'update deploy'. (project)"
+description: "Generate or update DEPLOY.md with local dev setup, testing, production deployment, and rollback procedures. Fully autonomous. Use after /prizmkit-retrospective, before /prizmkit-committer. Trigger on: 'deploy docs', 'deployment guide', 'how to deploy', 'DEPLOY.md'. (project)"
 ---
 
 # PrizmKit Deploy
 
-Generate or update deployment documentation by scanning the project's actual state and reading the deployment strategy from `.prizmkit/config.json`. Produces a `DEPLOY.md` at the project root covering local development, testing, production deployment, and rollback.
-
-**This skill generates documentation — it does NOT execute any deployment operations.**
-
 ### When to Use
 - After `/prizmkit-retrospective` and before `/prizmkit-committer` to complete documentation before commit
 - After a batch of features has been implemented and reviewed