prizmkit 1.1.79 → 1.1.81

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

@@ -26,39 +26,14 @@ User says:
 
 ## Overview
 
-```
-feature-workflow <idea / requirements>
-   │
-   ├── Phase 1: Brainstorm → collect materials → parallel deep read → discuss requirements
-   │
-   ├── Phase 2: Plan → feature-planner → .prizmkit/plans/feature-list.json
-   │
-   ├── Phase 3: Launch → feature-pipeline-launcher → pipeline execution
-   │
-   └── Phase 4: Monitor → track progress → report results
-```
-
-### What This Skill Does
+Given an idea or requirements, the workflow runs four phases:
 
-| Phase | Action | Result |
-|-------|--------|--------|
-| 1 | **Brainstorm** — collect reference materials, parallel deep read code & docs, discuss requirements grounded in real context | Fully clarified requirements document |
-| 2 | Call `feature-planner` with clarified requirements | `.prizmkit/plans/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 |
+1. **Brainstorm** — collect reference materials, parallel deep read code & docs, discuss requirements grounded in real context → fully clarified requirements
+2. **Plan** — call `feature-planner` with clarified requirements → `.prizmkit/plans/feature-list.json` with N features
+3. **Launch** — call `feature-pipeline-launcher` → pipeline started (execution mode chosen by user via launcher)
+4. **Monitor** — track progress → status updates, completion report
 
-### Why This Skill Exists
-
-Without this skill, users must:
-1. Figure out all requirements themselves
-2. Invoke `feature-planner` → wait for .prizmkit/plans/feature-list.json
-3. Invoke `feature-pipeline-launcher` → wait for pipeline start
-4. Manually check progress
-
-With this skill, users can:
-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
+The value: the user starts from a rough idea, the skill brainstorms to fill the gaps, and planning + execution happen automatically — no need to manually invoke each planner/launcher and poll for progress.
 
 ### Branch Management
 
@@ -102,14 +77,14 @@ When user says "add features to existing project" or the project already has fea
 
 **Goal**: Through interactive Q&A and deep context reading, 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.
+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)
+- 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: Collect Reference Materials
 
@@ -131,71 +106,11 @@ Record everything the user provides — these become inputs for Step 1.3.
 
 ### Step 1.3: Parallel Deep Reading
 
-**Goal**: Build comprehensive understanding of the project context before discussing detailed requirements. Spawn multiple agents in parallel to read all relevant materials simultaneously.
-
-**Parallel reading tasks** (launch concurrently):
-
-| Agent | What to read | Purpose |
-|-------|-------------|---------|
-| Agent A | User-provided code paths — read existing source files | Understand current architecture, patterns, conventions |
-| Agent B | User-provided documents — design docs, specs, PRDs | Understand intended requirements and constraints |
-| Agent C | `.prizmkit/prizm-docs/` — root.prizm, L1/L2 docs, TRAPS, RULES | Understand existing architecture knowledge and known pitfalls |
-| Agent D | Database/schema files + `.prizmkit/config.json` | Understand data model and tech stack preferences |
-
-**Also gather** (can be included in any agent's task):
-- Directory structure of the project
-- Existing test patterns and conventions
-- Dependency relationships between existing modules
-
-**After all agents complete**: Synthesize findings into a coherent understanding before proceeding to discussion.
+Read `${SKILL_DIR}/references/brainstorm-guide.md` §Step 1.3 for the parallel agent dispatch procedure — spawn 4 agents (A: code paths, B: documents, C: prizm-docs, D: database/config) to build comprehensive project context before discussion. Synthesize findings before proceeding.
 
 ### Step 1.4: Discuss Requirements
 
-**Now** — with deep knowledge of the actual codebase and documents — discuss the requirements with the user. This discussion is grounded in real context, not abstract questions.
-
-Present what you learned from the parallel reading:
-- Current project structure and patterns (with specific references)
-- Existing data model and schema conventions
-- Known TRAPS and pitfalls from `.prizmkit/prizm-docs/`
-- Integration points with existing modules
-
-Then ask targeted questions based on what you read. **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:**
-- "Based on the existing code, this feature would integrate with [modules]. Does that match your expectations?"
-- 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)
+Read `${SKILL_DIR}/references/brainstorm-guide.md` §Step 1.4 for the full requirements discussion framework — functional requirements, data model, user experience, integration/architecture, edge cases, and non-functional requirements. Ask targeted questions based on what was learned from parallel reading. **Adapt question depth to the feature complexity.**
 
 ### Step 1.5: Confirm and Supplement
 
@@ -206,57 +121,11 @@ After the discussion:
 3. **Identify gaps** — if any areas are still unclear, list them explicitly and ask follow-up questions
 4. **Repeat** until the user confirms: "That covers everything" or "Let's proceed"
 
-**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
+Read `${SKILL_DIR}/references/brainstorm-guide.md` §Completion Signs for the full checklist of when brainstorming is complete vs when more questions are needed.
 
 ### Step 1.6: 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]
-
-### Reference Materials Reviewed
-- [List of code paths, documents, .prizmkit/prizm-docs/ files that were read]
-
-### Confirmed by user: ✓
-```
-
-Present this summary to the user and get explicit confirmation before proceeding.
+Once brainstorming is complete, produce a structured requirements summary. Read `${SKILL_DIR}/references/brainstorm-guide.md` §Requirements Summary Template for the structured output format. Present the summary to the user and get explicit confirmation before proceeding.
 
 **CHECKPOINT CP-FW-0**: Requirements fully clarified and confirmed by user.
 
@@ -266,7 +135,7 @@ Present this summary to the user and get explicit confirmation before proceeding
 
 After confirming requirements, assess whether this feature needs the full pipeline or can be done directly in the current session.
 
-**Simple feature → Fast Path candidate** (ALL must be true):
+**Simple feature** (Fast Path candidate — ALL must be true):
 - Single module, no cross-module architectural impact
 - ≤2 new files to create
 - No new external dependencies or infrastructure changes
@@ -274,11 +143,18 @@ After confirming requirements, assess whether this feature needs the full pipeli
 - Clear acceptance criteria with existing patterns to follow
 - No dependency on other unbuilt features
 
-**User choice required (mandatory)** — Use `AskUserQuestion` to present interactive selectable options:
+**Complex feature** (Planning Path — ANY is true):
+- Cross-module impact (>2 modules affected)
+- New infrastructure, dependencies, or architectural patterns required
+- Multiple interrelated features with dependency ordering
+- Data model or API design decisions needed
+- Requires integration with external services
+
+User choice is required (mandatory) — use `AskUserQuestion` to present interactive selectable options. Adjust the question framing to the assessment: for a simple feature, "This feature appears straightforward."; for a complex feature, "This feature is complex and will benefit from structured planning."
 
 ```
 AskUserQuestion:
-  question: "This feature appears straightforward. How would you like to proceed?"
+  question: "How would you like to proceed?"   # prefix with the framing note above
   header: "Approach"
   options:
     - label: "Implement now (fast path)"
@@ -293,33 +169,10 @@ AskUserQuestion:
   3. After implementation, run `/prizmkit-code-review` for quality check
   4. Commit via `/prizmkit-committer` with `feat(<scope>):` prefix
   5. Run `/prizmkit-retrospective` to sync `.prizmkit/prizm-docs/`
-  6. **End workflow** — skip Phase 2/3/4
-- **Add to feature list** → Continue to Phase 2 (Plan via pipeline)
-
-**Complex feature → Planning Path** (ANY is true):
-- Cross-module impact (>2 modules affected)
-- New infrastructure, dependencies, or architectural patterns required
-- Multiple interrelated features with dependency ordering
-- Data model or API design decisions needed
-- Requires integration with external services
-
-**User choice required (mandatory)** — Use `AskUserQuestion` to present interactive selectable options:
-
-```
-AskUserQuestion:
-  question: "This feature is complex and will benefit from structured planning. How would you like to proceed?"
-  header: "Approach"
-  options:
-    - label: "Plan and implement now"
-      description: "Create a plan and implement in this session using /prizmkit-plan + /prizmkit-implement"
-    - label: "Add to feature list (pipeline)"
-      description: "Generate .prizmkit/plans/feature-list.json via feature-planner, then launch pipeline for autonomous execution"
-```
-
-- **Plan and implement now** → Invoke `/prizmkit-plan` with requirements → `/prizmkit-implement` → `/prizmkit-code-review` → `/prizmkit-committer` → `/prizmkit-retrospective`. **End workflow** — skip Phase 2/3/4.
+  6. End workflow — skip Phase 2/3/4
 - **Add to feature list** → Continue to Phase 2 (Plan via pipeline)
 
-**NEVER proceed without explicit user confirmation via `AskUserQuestion`. Do NOT render options as plain text — the user must be able to click/select.**
+Never proceed without explicit user confirmation via `AskUserQuestion`. Do NOT render options as plain text — the user must be able to click/select.
 
 **CHECKPOINT CP-FW-0.5**: Approach selected by user (fast path or pipeline).
 
@@ -483,17 +336,7 @@ While the pipeline runs, the user can continue the conversation:
 
 ## Comparison with Alternative Workflows
 
-| Dimension | feature-workflow | bug-fix-workflow | refactor-workflow |
-|-----------|-----------------|------------------|-------------------|
-| **Purpose** | New features (batch) | Single bug fix (interactive) | Code restructuring (batch) |
-| **Brainstorming** | Yes — collect materials, parallel read, discuss | No (bug report is input) | Yes — clarify type, collect materials, parallel read, discuss |
-| **Planning Skill** | `feature-planner` | None (triage built-in) | `refactor-planner` |
-| **Branch** | Pipeline manages per-feature | `fix/<BUG_ID>-*` | Pipeline manages per-refactor |
-| **Execution** | Foreground or background daemon | In-session, interactive | Foreground or background daemon |
-| **Input** | Rough idea or requirements | Bug report / stack trace | Rough refactoring idea or target |
-| **Output** | Multiple `feat()` commits | Single `fix()` commit | Multiple `refactor()` commits |
-| **Behavior Change** | Expected (new functionality) | Fix behavior | Forbidden (structure only) |
-| **Batch alternative** | (this is the batch flow) | `bug-planner` + `bugfix-pipeline-launcher` | (this is the batch flow) |
+Read `${SKILL_DIR}/references/brainstorm-guide.md` §Comparison for the full comparison table (feature-workflow vs bug-fix-workflow vs refactor-workflow across 9 dimensions).
 
 ---
 

package/bundled/skills/feature-workflow/references/brainstorm-guide.md

@@ -0,0 +1,137 @@
+# Brainstorm Guide — Detailed Procedures
+
+Procedural details for Phase 1 brainstorming in feature-workflow.
+
+## Step 1.3: Parallel Deep Reading
+
+**Goal**: Build comprehensive understanding of the project context before discussing detailed requirements. Spawn multiple agents in parallel to read all relevant materials simultaneously.
+
+**Parallel reading tasks** (launch concurrently):
+
+| Agent | What to read | Purpose |
+|-------|-------------|---------|
+| Agent A | User-provided code paths — read existing source files | Understand current architecture, patterns, conventions |
+| Agent B | User-provided documents — design docs, specs, PRDs | Understand intended requirements and constraints |
+| Agent C | `.prizmkit/prizm-docs/` — root.prizm, L1/L2 docs, TRAPS, RULES | Understand existing architecture knowledge and known pitfalls |
+| Agent D | Database/schema files + `.prizmkit/config.json` | Understand data model and tech stack preferences |
+
+**Also gather** (can be included in any agent's task):
+- Directory structure of the project
+- Existing test patterns and conventions
+- Dependency relationships between existing modules
+
+**After all agents complete**: Synthesize findings into a coherent understanding before proceeding to discussion.
+
+## Step 1.4: Discuss Requirements
+
+**Now** — with deep knowledge of the actual codebase and documents — discuss the requirements with the user. This discussion is grounded in real context, not abstract questions.
+
+Present what you learned from the parallel reading:
+- Current project structure and patterns (with specific references)
+- Existing data model and schema conventions
+- Known TRAPS and pitfalls from `.prizmkit/prizm-docs/`
+- Integration points with existing modules
+
+Then ask targeted questions based on what you read. **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
+- "Based on the existing code, this feature would integrate with [modules]. Does that match your expectations?"
+- 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)
+
+## Comparison with Alternative Workflows
+
+| Dimension | feature-workflow | bug-fix-workflow | refactor-workflow |
+|-----------|-----------------|------------------|--------------------|
+| **Purpose** | New features (batch) | Single bug fix (interactive) | Code restructuring (batch) |
+| **Brainstorming** | Yes — collect materials, parallel read, discuss | No (bug report is input) | Yes — clarify type, collect materials, parallel read, discuss |
+| **Planning Skill** | `feature-planner` | None (triage built-in) | `refactor-planner` |
+| **Branch** | Pipeline manages per-feature | `fix/<BUG_ID>-*` | Pipeline manages per-refactor |
+| **Execution** | Foreground or background daemon | In-session, interactive | Foreground or background daemon |
+| **Input** | Rough idea or requirements | Bug report / stack trace | Rough refactoring idea or target |
+| **Output** | Multiple `feat()` commits | Single `fix()` commit | Multiple `refactor()` commits |
+| **Behavior Change** | Expected (new functionality) | Fix behavior | Forbidden (structure only) |
+| **Batch alternative** | (this is the batch flow) | `bug-planner` + `bugfix-pipeline-launcher` | (this is the batch flow) |
+
+## Completion Signs
+
+**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
+
+## Requirements Summary Template
+
+Once brainstorming is complete, produce a structured requirements summary using the following format. Present the summary to the user and get explicit confirmation before proceeding.
+
+```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]
+
+### Reference Materials Reviewed
+- [List of code paths, documents, .prizmkit/prizm-docs/ files that were read]
+
+### Confirmed by user: ✓
+```

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

@@ -1,10 +1,21 @@
 ---
 name: "prizm-kit"
-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', 'get started', 'what tools', 'dev workflow', 'lifecycle', or '/prizmkit'. Use this as the entry point for the full PrizmKit development lifecycle."
+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', 'get started', 'what tools', 'dev workflow', 'lifecycle', or '/prizmkit'. Use this as the entry point for the full PrizmKit development lifecycle. (project)"
 ---
 
 # PrizmKit — Full-Lifecycle Development Toolkit
 
+### When to Use
+- User asks "which command?", "help", "how do I start a feature", "get started", "what tools"
+- User wants to understand the PrizmKit development lifecycle
+- User invokes "/prizmkit" or asks about dev workflow
+- User is new to the project and needs orientation
+
+### When NOT to Use
+- User already knows which specific skill to use — invoke it directly
+- Mid-implementation — use the specific skill needed (/prizmkit-implement, /prizmkit-code-review, etc.)
+- User wants to execute immediately without orientation — go directly to /prizmkit-plan or /prizmkit-implement
+
 ## Task Execution Model
 
 PrizmKit uses **headless mode** — each task runs as an independent AI CLI session with NO context carryover between tasks. Every session starts by reading docs and ends by maintaining docs.
@@ -61,7 +72,8 @@ All three follow the same per-task flow. Detailed documentation policies (when t
 | `/prizmkit-code-review` | Diagnose issues + produce Fix Instructions | "review", "check code", "is it ready to commit" |
 | `/prizmkit-retrospective` | Sync .prizmkit/prizm-docs/ with code changes | "retrospective", "retro", "sync docs", "wrap up" |
 | `/prizmkit-committer` | Safe git commit with Conventional Commits | "commit", "submit", "finish", "ship it" |
-| `/prizmkit-deploy` | Generate/update deployment documentation | "deploy docs", "deployment guide", "how to deploy" |
+| `/prizmkit-test` | Generate + run tests, analyze coverage gaps, unified quality report | "test", "run tests", "check quality", "verify code", "补测试" |
+| `/prizmkit-deploy` | Universal deployment gateway: SSH automation, cloud/Docker guided setup, status/logs/rollback | "deploy", "ship it", "go live", "rollback", "deploy status" |
 | `/prizmkit-init` | Project bootstrap + .prizmkit/prizm-docs/ setup | "init", "initialize", "take over this project" |
 | `/prizmkit-prizm-docs` | Doc management (init/status/rebuild/validate) | "check docs", "rebuild docs", "validate docs" |