prizmkit 1.0.144 → 1.0.148

package/bundled/skills/app-planner/SKILL.md

@@ -37,6 +37,7 @@ The user chose this skill intentionally. Respect that choice.
 1. `feature-list.json` (project root)
 2. Architecture decisions appended to `CLAUDE.md` / `CODEBUDDY.md` (with user consent, see §Architecture Decision Capture)
 3. Draft backups in `.prizmkit/planning/`
+4. `.prizmkit/project-conventions.json` (project convention answers, see §Project Conventions Check)
 
 **After planning is complete**, you MUST:
 1. Present the summary and recommended next step
@@ -71,13 +72,35 @@ Do NOT use this skill when the user only wants to run the pipeline (`dev-pipelin
    - Architecture decisions emerged → read `references/architecture-decisions.md`
    - Browser interaction fields needed → read `references/browser-interaction.md`
 
-4. **Always validate output via script**:
+4. **Brainstorm deep-dive** — If the user chooses to continue discussing or exploring ideas before finalizing features (e.g., during Intent Confirmation the user selects "just explore ideas", or at any point says "let's discuss more" / "I want to think through this"):
+   → read `references/brainstorm-guide.md` and follow its four-phase structured ideation process (Assess Clarity → Understand → Explore Approaches → Capture Design)
+   → During Phase C (Explore Approaches), also read `references/red-team-checklist.md` for adversarial critique of each approach
+   → When brainstorm Phase D produces a "Capture Design" summary, use it as the Vision Summary (fulfilling CP-AP-2) and proceed to Phase 2 (constraints and tech assumptions)
+
+5. **Frontend / UI design check** — Evaluate during Phase 2 (constraints and tech assumptions), after tech stack is confirmed. If the project has a frontend framework:
+   → Check project root for existing UI/UX design docs (scan for files matching: `design-system*`, `style-guide*`, `ui-guide*`, `ux-guide*`, `theme*`)
+   → Also search the active CLI's project instruction file (`CLAUDE.md` / `CODEBUDDY.md`) for keywords: "UI", "UX", "design system", "style guide", "theme", "typography", "color palette"
+   → If unified design guidance is found → use it as constraint for feature descriptions
+   → If NO unified design guidance found → ask user: "项目中未找到统一的 UI/UX 设计规范。是否需要在特性规划前先建立一套 UI/UX 设计方向？(No unified UI/UX design system found. Would you like to establish one before feature planning?)"
+   → If yes → read `references/frontend-design-guide.md` and conduct a design direction session. Capture the result in the project instruction file (with user consent).
+   → If no → proceed without; individual features may still define their own UI approach.
+
+6. **Project conventions check** — After Intent Confirmation (CP-AP-0), before brainstorm or Phase 1 vision work. This runs regardless of session goal (produce or explore):
+   → Read `.prizmkit/project-conventions.json` if it exists
+   → If the file exists but cannot be parsed as valid JSON → warn user ("conventions file is corrupted, will re-ask all questions"), treat all conventions as unanswered
+   → Cross-reference with `references/project-conventions.md` for the full question list
+   → For any convention with a `null` or missing value → batch all unanswered questions into a single prompt to the user
+   → Save answers to `.prizmkit/project-conventions.json` (create `.prizmkit/` directory if needed — this is an allowed writable output)
+   → If all conventions are already answered → skip silently, do not re-ask
+   → Use convention answers as context when writing feature descriptions and proposing features (see `references/project-conventions.md` §How Conventions Are Used)
+
+7. **Always validate output via script**:
    - run:
      ```bash
      python3 ${SKILL_DIR}/scripts/validate-and-generate.py validate --input <output-path> --mode <new|incremental>
      ```
 
-5. **Use script output as source of truth**:
+8. **Use script output as source of truth**:
    - if validation fails, fix and re-run until pass
 
 ## Prerequisites
@@ -85,6 +108,7 @@ Do NOT use this skill when the user only wants to run the pipeline (`dev-pipelin
 Before questions, check optional context files (never block if absent):
 - `.prizm-docs/root.prizm` (architecture/project context)
 - `.prizmkit/config.json` (existing stack preferences and detected tech stack)
+- `.prizmkit/project-conventions.json` (previously answered project conventions — see §Resource Loading Rules #6)
 - existing `feature-list.json` (required for incremental mode)
 - If `.prizm-docs/root.prizm` is absent and the project has existing source code, scan the directory structure to understand the codebase layout:
   ```bash
@@ -134,7 +158,10 @@ After scenario routing, immediately confirm the user's deliverable intent:
 2. **Route by answer**:
    - **"Produce feature-list.json"** → Continue to Core Workflow. Set session goal = `produce`.
    - **"Just explore ideas"** → Enter **Exploration Mode**:
-     - Run Phases 1-5 normally (vision, constraints, feature proposals, refinement, DAG)
+     - Run project conventions check first (CP-AP-1) — same as produce mode
+     - Load `references/brainstorm-guide.md` and follow its structured ideation process (Phases A-D)
+     - Brainstorm Phase D output serves as the Vision Summary (CP-AP-2)
+     - Continue with Phase 2 (constraints — including frontend design check CP-AP-3 if applicable), then Phases 3-5 normally
      - At Phase 5 completion, re-ask: "Ideas are taking shape. Ready to generate `feature-list.json` now?"
      - If yes → continue to Phase 6
      - If no → summarize discussion, suggest saving notes, end session
@@ -153,10 +180,10 @@ Execute the selected scenario workflow in conversation mode with mandatory check
 3. propose feature set with dependencies
 4. refine descriptions and acceptance criteria
    4.1 **per-feature clarification** — for each feature, if the description, acceptance criteria, or scope is vague or could be interpreted multiple ways, ask the user to clarify before finalizing. Continue until every feature has unambiguous, implementation-ready details.
-   4.2 **browser interaction evaluation** (mandatory for fullstack/frontend projects) — see §Browser Interaction Planning below. For each feature with UI-related acceptance criteria, you MUST ask the user whether to add `browser_interaction`. Do NOT skip or defer this step.
+   4.2 **browser interaction** (mandatory for fullstack/frontend projects) — see §Browser Interaction Planning below. Qualifying features get `browser_interaction` by default. Only confirm with the user as a batch summary; do NOT ask per-feature.
 5. verify DAG/order/priorities
 6. build or append `feature-list.json`
-7. ask whether to enable adversarial critic review for high/critical features
+7. apply default testing strategy (see §Testing Defaults below)
 8. validate and fix until pass
 9. summarize final feature table
 
@@ -164,16 +191,20 @@ Execute the selected scenario workflow in conversation mode with mandatory check
 
 Checkpoints catch cascading errors early — skipping one means the next phase builds on unvalidated assumptions, which compounds into much harder debugging later.
 
+Note: Checkpoint numbers (CP-AP-N) are sequential identifiers for the gate, NOT phase numbers. See the "Phase" column for the corresponding workflow phase.
+
 | Checkpoint | Artifact/State | Criteria | Phase |
 |-----------|----------------|----------|-------|
 | **CP-AP-0** | Intent Confirmed | User confirmed session goal (produce / explore) | 1 |
-| **CP-AP-1** | Vision Summary | Goal/users/differentiators confirmed by user | 1-2 |
-| **CP-AP-2** | Feature Proposals | Feature set with titles+deps identified (pre-validation) | 3-5 |
-| **CP-AP-3** | DAG Validity | No cycles, dependencies resolved (validation dry-run) | 6 |
-| **CP-AP-3.2** | Browser Interaction Evaluated | For each feature with UI acceptance criteria: user was asked about browser verification | 4 |
-| **CP-AP-3.5** | Critic Decision | User decided on critic review for high/critical features | 7 |
-| **CP-AP-4** | `feature-list.json` Generated | Schema validates, all required keys present | 6-7 |
-| **CP-AP-5** | Final Validation Pass | Python script returns `"valid": true` with zero errors | 8 |
+| **CP-AP-1** | Conventions Checked | Project conventions loaded or asked; `.prizmkit/project-conventions.json` up to date | 1 |
+| **CP-AP-2** | Vision Summary | Goal/users/differentiators confirmed by user | 1-2 |
+| **CP-AP-3** | Frontend Design Evaluated | For frontend projects: checked for existing UI/UX design system; user was asked if missing | 2 |
+| **CP-AP-4** | Feature Proposals | Feature set with titles+deps identified (pre-validation) | 3-5 |
+| **CP-AP-5** | DAG Validity | No cycles, dependencies resolved (validation dry-run) | 5 |
+| **CP-AP-5.1** | Browser Interaction Applied | Qualifying features have `browser_interaction` field; user confirmed or opted out | 4 |
+| **CP-AP-5.2** | Testing Defaults Applied | All features have appropriate `critic`, `critic_count`, and testing expectations per §Testing Defaults | 7 |
+| **CP-AP-6** | `feature-list.json` Generated | Schema validates, all required keys present | 6-7 |
+| **CP-AP-7** | Final Validation Pass | Python script returns `"valid": true` with zero errors | 8 |
 
 **Resume Detection**: If existing artifacts are found, read `references/error-recovery.md` §Resume Support for checkpoint-based resumption.
 
@@ -224,11 +255,11 @@ AI: "Ready to proceed to dev-pipeline."
 
 ## Browser Interaction Planning
 
-For fullstack/frontend projects, evaluate each feature for automated browser verification via `browser_interaction`. This is a **mandatory evaluation step** (Phase 4.2), not an optional suggestion.
+For fullstack/frontend projects, qualifying features get `browser_interaction` **by default**. This is not opt-in — it is the standard.
 
 ### Auto-Detection Rule
 
-A feature **qualifies** for browser interaction evaluation when ALL of these are true:
+A feature **qualifies** for browser interaction when ALL of these are true:
 1. `global_context.frontend_framework` exists (project has a frontend)
 2. The feature's `acceptance_criteria` contain UI-related keywords: click, button, modal, page, form, display, navigate, tab, input, opens, shows, renders, visible, redirect, download, upload, preview, select, toggle, dropdown, popup, toast, menu
 
@@ -237,21 +268,19 @@ A feature is **exempt** when ANY of these are true:
 - It is config/setup/infrastructure
 - It has `status: "completed"` (already implemented)
 
-### Mandatory Prompt (Phase 4.2)
-
-For EACH qualifying feature, you MUST ask:
-
-> "Feature {F-XXX} has UI behavior in its acceptance criteria. Add browser verification so the pipeline can auto-check it after implementation? (Y/n)"
+### Default Behavior (Phase 4.2)
 
-- If **yes** → read `references/browser-interaction.md` for the `browser_interaction` object format and field rules. Generate the field for this feature.
-- If **no** → record the decision and move on. No field is added.
-- If **user says no to all** → skip remaining features (batch decline). Record that user declined browser verification globally.
+1. **Auto-generate** `browser_interaction` for ALL qualifying features. Read `references/browser-interaction.md` for the object format and field rules.
+2. **Present a summary** to the user showing which features received `browser_interaction`:
+   > "以下 N 个前端特性已自动添加 browser_interaction 用于 Playwright 自动验证：F-002, F-004, F-007。如需移除某个特性的浏览器验证，请告知。"
+3. **User can opt-OUT** specific features — remove the field for declined features.
+4. If **user opts out entirely** ("remove all browser verification") → remove all fields and record the decision.
 
-**You must NOT skip this prompt for qualifying features.** The checkpoint CP-AP-3.2 verifies this step was completed.
+**You must NOT skip this step for qualifying features.** The checkpoint CP-AP-5.1 verifies this step was completed.
 
-### When NOT to evaluate
+### When NOT to add
 
-**Do NOT prompt for**: backend-only features, config/setup features, or non-UI features. These are automatically exempt — no user prompt needed.
+**Do NOT add for**: backend-only features, config/setup features, or non-UI features. These are automatically exempt.
 
 ## Output Rules
 
@@ -264,11 +293,64 @@ For EACH qualifying feature, you MUST ask:
 - new items default `status: "pending"`
 - English feature titles for stable slug generation
 - `model` field is optional — omitting it means the pipeline uses $MODEL env or CLI default
-- `critic` field is optional (boolean). If user requested adversarial critic review during planning, set `"critic": true` for relevant features. Omitting defaults to `false`.
-- `critic_count` field is optional (integer, 1 or 3). If omitted, defaults to 1 (single critic). Set to 3 for multi-critic voting mode on critical features.
-- `browser_interaction` field is optional (object). If user opted for browser verification during planning, set for features with UI behavior. Requires `playwright-cli` to be installed.
+- `critic` field defaults based on priority: `true` for high/medium priority features, `false` for low. User can override.
+- `critic_count` field defaults based on priority: `3` (multi-critic voting) for high priority, `1` (single critic) for medium. User can override.
+- `browser_interaction` field is auto-generated for qualifying frontend features (see §Browser Interaction Planning). Requires `playwright-cli` to be installed.
 - **descriptions must be implementation-ready** — minimum 15 words (error), recommended 30/50/80 words for low/medium/high complexity (warning). See `planning-guide.md` §4 for what to include.
 
+## Testing Defaults (Phase 7)
+
+All three testing mechanisms are **enabled by default** to maximize quality. The user can opt out of any mechanism, but the default is comprehensive testing.
+
+### 1. Test File Generation (TDD)
+
+Every feature is expected to include tests. When writing feature descriptions, explicitly state testing expectations:
+
+| Complexity | Default Testing Expectation |
+|------------|----------------------------|
+| low | Unit tests for core logic |
+| medium | Unit tests + integration tests for key flows |
+| high | Unit tests + integration tests + edge case coverage |
+
+**In the feature description**, include a line like:
+- "Include unit tests for [key functions/modules]."
+- "Include integration tests verifying [API endpoints / data flows]."
+
+This ensures the downstream `prizmkit-implement` skill (which uses TDD) has clear guidance on what tests to write.
+
+### 2. Browser Verification (Playwright)
+
+See §Browser Interaction Planning above. Default: **ON** for all qualifying frontend features.
+
+### 3. Adversarial Critic Review (Multi-Agent)
+
+Default assignments based on feature priority:
+
+| Priority | `critic` | `critic_count` | Rationale |
+|----------|----------|----------------|-----------|
+| high | `true` | `3` | Multi-critic voting — catches more issues for critical features |
+| medium | `true` | `1` | Single critic review — balanced cost/quality |
+| low | `false` | (omitted) | Skip critic — simple features don't warrant the overhead |
+
+After applying defaults, present a summary to the user:
+> "已为 N 个 high/medium 优先级特性启用代码评审 (critic)：high 优先级使用 3-agent 投票模式，medium 使用单 agent 评审。如需调整请告知。"
+
+The user can override any assignment (enable/disable critic, change critic_count) before finalizing.
+
+### Summary Presentation
+
+At Phase 7, present a consolidated testing summary table:
+
+```
+Feature    | TDD Tests        | Playwright | Critic
+F-001      | unit             | —          | —
+F-002      | unit+integration | ✓          | 3-agent
+F-003      | unit+integration | ✓          | 1-agent
+F-004      | unit             | —          | —
+```
+
+Ask: "以上是各特性的默认测试配置。如需调整请告知，否则将按此配置生成 feature-list.json。"
+
 ## Next-Step Execution Policy (after planning)
 
 Recommend these three options in this strict order:

package/bundled/skills/app-planner/scripts/validate-and-generate.py

@@ -32,7 +32,7 @@ from datetime import datetime, timezone
 
 SCHEMA_VERSION = "dev-pipeline-feature-list-v1"
 
-VALID_STATUSES = {"pending", "in_progress", "completed", "failed", "skipped", "split"}
+VALID_STATUSES = {"pending", "in_progress", "completed", "failed", "skipped", "split", "auto_skipped"}
 VALID_COMPLEXITIES = {"low", "medium", "high"}
 VALID_PRIORITIES = {"high", "medium", "low"}
 VALID_GRANULARITIES = {"feature", "sub_feature", "auto"}

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

@@ -38,6 +38,7 @@ For fast-path changes, you can directly generate a simplified plan.md, then use
 /prizmkit-implement  → executes tasks in order, marks [x] as done
 /prizmkit-code-review → diagnoses issues + produces Fix Instructions
 /prizmkit-retrospective → syncs .prizm-docs/ with code changes
+/prizmkit-deploy     → generates/updates DEPLOY.md with deployment procedures
 /prizmkit-committer  → commits feat(avatar): add upload
 ```
 
@@ -83,6 +84,7 @@ PrizmKit produces two complementary knowledge layers:
 | `/prizmkit-code-review` | Diagnose issues + produce Fix Instructions | "review", "check code", "is it ready to commit" |
 | `/prizmkit-retrospective` | Sync .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-init` | Project bootstrap + .prizm-docs/ setup | "init", "initialize", "take over this project" |
 | `/prizmkit-prizm-docs` | Doc management (init/status/rebuild/validate) | "check docs", "rebuild docs", "validate docs" |
 
@@ -93,7 +95,7 @@ PrizmKit produces two complementary knowledge layers:
 
 - **Tier 1**: AI can perform well independently — these tasks align with AI's core strengths (documentation, code pattern analysis, test generation)
 - **Tier 2**: Useful as guidance/checklist — AI provides static analysis and recommendations, but lacks access to real external tools (scanners, profilers, package registries, runtime environments)
-- **Core skills** (no tier label): The 12 foundational, documentation, spec-driven workflow, and commit skills that form PrizmKit's primary value
+- **Core skills** (no tier label): The foundational, documentation, spec-driven workflow, and commit skills that form PrizmKit's primary value
 
 ## Installation
 

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

@@ -7,7 +7,7 @@ description: "Pure git commit workflow with safety checks. Stages files, analyze
 
 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` before this skill to sync `.prizm-docs/` (architecture index with TRAPS/RULES/DECISIONS). For bug fixes, skip retrospective entirely — bug fixes do not update `.prizm-docs/`.
+**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"

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

@@ -0,0 +1,112 @@
+---
+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)"
+---
+
+# 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
+- When the project has no deployment documentation yet
+- When new infrastructure components have been added (new database, cache, message queue, etc.)
+
+### When NOT to Use
+- Mid-feature development (deployment docs should reflect reviewed, stable code)
+- For actual deployment execution (this skill only produces docs)
+- Fast-path bug fixes (no deployment doc update needed)
+
+### Pipeline Safety
+- **Fully autonomous** — no user interaction required at any step
+
+## Execution Steps
+
+**Phase 1 — Context Gathering:**
+1. Read `.prizmkit/config.json`:
+   - `deploy_strategy` — user's confirmed deployment approach (may be absent)
+   - `tech_stack` — detected or user-provided technology stack
+2. Scan project for deployment-related files:
+   - Container: `Dockerfile`, `docker-compose.yml`, `.dockerignore`
+   - Cloud platforms: `vercel.json`, `netlify.toml`, `fly.toml`, `app.yaml` (GCP), `appspec.yml` (AWS)
+   - CI/CD: `.github/workflows/`, `.gitlab-ci.yml`, `Jenkinsfile`, `bitbucket-pipelines.yml`
+   - Package managers: `package.json` scripts (start, build, preview), `Makefile`, `Procfile`
+   - Infrastructure as Code: `terraform/`, `pulumi/`, `cdk/`, `serverless.yml`
+3. Scan source code for environment variable references:
+   - Grep for `process.env.`, `os.environ`, `os.Getenv`, `env::var`, `System.getenv`
+   - Cross-reference with `.env.example`, `.env.template`, or `.env.sample` if they exist
+   - Catalog all env vars with their usage context
+4. Check for existing `DEPLOY.md` (or `docs/deployment.md`, `docs/DEPLOY.md`)
+5. Read recent git log to identify newly added infrastructure components since last deploy doc update:
+   - If `DEPLOY.md` exists → use `git log -1 --format=%H -- DEPLOY.md` to find the last commit that touched it, then `git diff <that-commit>..HEAD` to identify new infra files
+   - If `DEPLOY.md` does not exist → treat all infrastructure as "new"
+
+**Phase 2 — Document Generation:**
+6. If NO existing deploy doc:
+   - Generate full `DEPLOY.md` from template (`${SKILL_DIR}/assets/deploy-template.md`)
+   - Fill all sections based on scanned project state
+   - If `deploy_strategy` exists in config → use it as the authoritative deployment approach
+   - If `deploy_strategy` is absent → infer from detected files (Dockerfile → Docker-based, vercel.json → Vercel, etc.) and note "Inferred from project files — confirm with `/prizmkit-plan` on next feature"
+7. If existing deploy doc found:
+   - Compare current project state against documented state
+   - Identify gaps: new env vars not documented, new services not covered, outdated commands
+   - Apply incremental updates — preserve user-written sections, only add/update auto-detectable content
+   - Mark updated sections with `<!-- Updated by prizmkit-deploy -->` comment
+
+**Phase 3 — Validation:**
+8. Verify completeness checklist:
+   - [ ] All detected env vars are documented with descriptions
+   - [ ] Local development setup commands are runnable (check referenced scripts/commands exist)
+   - [ ] Build command documented and exists in package.json/Makefile
+   - [ ] Production deployment steps match `deploy_strategy` in config
+   - [ ] Health check or verification step is included
+9. If any checklist item fails, add a `## TODO` section at the bottom listing what needs manual completion
+10. Output: `DEPLOY.md` path, summary of sections generated/updated, list of TODOs if any
+
+**HANDOFF:** `/prizmkit-committer` — commit all changes including the updated `DEPLOY.md`.
+
+## Document Sections
+
+The generated `DEPLOY.md` includes these sections (skip any that don't apply to the project):
+
+| Section | Content | Source |
+|---------|---------|--------|
+| Prerequisites | Required tools, versions, accounts | `tech_stack` from config + detected tooling |
+| Environment Variables | Full list with descriptions and examples | Source code scan + `.env.example` |
+| Local Development | Clone, install, configure, run locally | `package.json` scripts, `Makefile`, `docker-compose` |
+| Testing | Run tests locally, staging test procedures | `tech_stack.testing` + test scripts |
+| Build | Build commands and output artifacts | Build tool config (Vite, Webpack, Go build, etc.) |
+| Production Deployment | Step-by-step deployment procedure | `deploy_strategy` from config |
+| CI/CD | Pipeline overview and trigger conditions | Detected CI/CD config files |
+| Rollback | How to revert a bad deployment | Inferred from deployment method |
+| Health Check | How to verify deployment succeeded | API routes, health endpoints, smoke tests |
+| Troubleshooting | Common deployment issues and fixes | Generated from known patterns per tech stack |
+
+## Incremental Update Rules
+
+When updating an existing `DEPLOY.md`:
+- **NEVER delete** user-written content (sections without `<!-- Updated by prizmkit-deploy -->` markers)
+- **ADD** newly detected env vars to the Environment Variables table
+- **ADD** new services/components to Production Deployment
+- **UPDATE** version numbers and commands if they changed in config files
+- **APPEND** new troubleshooting entries for newly added tech stack components
+- **PRESERVE** custom sections the user may have added (e.g., team-specific procedures)
+
+## Example
+
+**Input state:**
+- `config.json` has `deploy_strategy: { primary: "docker", components: { app: "Docker → AWS ECS", db: "RDS PostgreSQL" } }`
+- Project has `Dockerfile`, `docker-compose.yml`, `package.json` with build script
+- 12 env vars detected in source code, `.env.example` has 8
+
+**Output:** `DEPLOY.md` with all sections filled, plus TODO:
+```
+## TODO
+- [ ] 4 environment variables found in code but missing from `.env.example`: `REDIS_URL`, `SMTP_HOST`, `SMTP_PORT`, `SENTRY_DSN`
+- [ ] No health check endpoint detected — consider adding `GET /health`
+```
+
+IMPORTANT: Use `${SKILL_DIR}` placeholder for all path references. Never hardcode absolute paths.

package/bundled/skills/prizmkit-deploy/assets/deploy-template.md

@@ -0,0 +1,108 @@
+# Deployment Guide: [PROJECT_NAME]
+<!-- Replace [PROJECT_NAME] with: app_name from feature-list.json, or name from package.json, or the project root directory name (in that priority order) -->
+
+> Generated by PrizmKit Deploy
+
+## Prerequisites
+
+| Tool | Version | Install |
+|------|---------|---------|
+| [tool] | [version] | [install command or link] |
+
+## Environment Variables
+
+| Variable | Required | Description | Default | Example |
+|----------|----------|-------------|---------|---------|
+| [VAR_NAME] | yes/no | [Purpose] | [default or n/a] | [example value] |
+
+**Setup:**
+```bash
+cp .env.example .env
+# Edit .env with your values
+```
+
+## Local Development
+
+### First-time Setup
+```bash
+# [Clone + install steps]
+```
+
+### Run Locally
+```bash
+# [Start command]
+```
+
+### Local Services
+<!-- If docker-compose or similar is used for local dependencies -->
+```bash
+# [Local services startup]
+```
+
+## Testing
+
+### Run Tests
+```bash
+# [Test commands]
+```
+
+### Staging / Pre-production
+<!-- How to test against a staging environment -->
+- Staging URL: [URL or "not configured"]
+- Deploy to staging: [command or process]
+
+## Build
+
+```bash
+# [Build command]
+```
+
+**Output:** [where build artifacts go, e.g. `dist/`, `build/`, binary path]
+
+## Production Deployment
+
+### Deployment Method
+<!-- Filled from deploy_strategy in config -->
+[Description of production deployment approach]
+
+### Step-by-step
+1. [Step 1]
+2. [Step 2]
+3. [Step 3]
+
+### Post-deployment Verification
+```bash
+# [Health check or smoke test command]
+```
+
+## CI/CD
+<!-- Skip if no CI/CD config detected -->
+
+| Pipeline | Trigger | Action |
+|----------|---------|--------|
+| [pipeline name] | [trigger event] | [what it does] |
+
+## Rollback
+
+### How to Rollback
+1. [Rollback step 1]
+2. [Rollback step 2]
+
+### When to Rollback
+- [Criteria that warrant a rollback]
+
+## Health Check
+
+| Check | Endpoint / Command | Expected Result |
+|-------|-------------------|-----------------|
+| [check name] | [endpoint or command] | [expected output] |
+
+## Troubleshooting
+
+| Symptom | Cause | Fix |
+|---------|-------|-----|
+| [symptom] | [likely cause] | [resolution steps] |
+
+## TODO
+<!-- Auto-generated: items that need manual attention -->
+- [ ] [items prizmkit-deploy could not auto-fill]

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

@@ -58,19 +58,41 @@ Generate a comprehensive technical implementation plan from a feature specificat
    - Risk assessment
 6. Cross-check plan against spec: every user story should map to plan components — unmapped stories mean the plan has coverage gaps that will surface during implementation
 7. Check alignment with project rules from `.prizm-docs/root.prizm` RULES section — violating project rules causes CRITICAL findings in the analyze phase
+8. **Deployment strategy check:**
+   - Read `.prizmkit/config.json` `deploy_strategy` field (if `config.json` does not exist, treat as "no deploy_strategy")
+   - Compare tech stack used in this plan (from Architecture Approach, Integration Points, Data Model) against the stored strategy
+   - **No `deploy_strategy` in config** → first time: ask user for deployment approach (e.g. Docker, Vercel, static hosting, traditional server, cloud platform, etc.) → write to `config.json` as `deploy_strategy` object with `"_user_confirmed": true`. If `config.json` does not exist, create `.prizmkit/` directory and `config.json` with the `deploy_strategy` field (preserve any existing fields if the file already exists).
+   - **`deploy_strategy` exists, no new tech stack** → skip (no question asked)
+   - **`deploy_strategy` exists, new tech stack detected** (e.g. plan introduces Redis, message queue, new database) → ask user only about the deployment approach for the new component → merge into existing `deploy_strategy`
+   - Store format in `config.json`:
+     ```json
+     {
+       "deploy_strategy": {
+         "primary": "docker",
+         "components": {
+           "app": "Docker container → AWS ECS",
+           "database": "RDS PostgreSQL",
+           "cache": "ElastiCache Redis"
+         },
+         "notes": "user-provided context about their deployment",
+         "_user_confirmed": true
+       }
+     }
+     ```
+   - This step is **skipped entirely in fast-path mode** (bug fixes / simple refactors do not affect deployment)
 
 **Phase 2 — Task Generation:**
-8. Ask user for implementation strategy (or infer from context): MVP-first / Incremental / Parallel
-9. Append `## Tasks` section to `plan.md` using the tasks template at the end of `${SKILL_DIR}/assets/plan-template.md`:
-   - Organized by phases: Setup(T-001~T-009) → Foundational(T-010~T-099) → User Stories(T-100+) → Polish(T-900+)
-   - Each task: `- [ ] [T-NNN] [P?] [US?] Description — file: path/to/file`
-   - `[P]` marker for tasks that can run in parallel within their phase
-   - Checkpoint tasks between phases for validation
-10. Verify coverage and traceability:
+9. Ask user for implementation strategy (or infer from context): MVP-first / Incremental / Parallel
+10. Append `## Tasks` section to `plan.md` using the tasks template at the end of `${SKILL_DIR}/assets/plan-template.md`:
+    - Organized by phases: Setup(T-001~T-009) → Foundational(T-010~T-099) → User Stories(T-100+) → Polish(T-900+)
+    - Each task: `- [ ] [T-NNN] [P?] [US?] Description — file: path/to/file`
+    - `[P]` marker for tasks that can run in parallel within their phase
+    - Checkpoint tasks between phases for validation
+11. Verify coverage and traceability:
     - Every user story maps to at least one task — orphan stories become orphan features
     - Every task references a target file path — pathless tasks leave implementers guessing where to write code
     - Risk assessment includes at least one risk with mitigation — helps the implementer prepare for known challenges
-11. Output: `plan.md` path, summary of design decisions, and task count
+12. Output: `plan.md` path, summary of design decisions, and task count
 
 **Task ID Conventions:**
 - Task IDs use zero-padded numbering: `[T-001]`, `[T-010]`, `[T-100]` — this ensures consistent sorting and visual alignment

package/bundled/skills/prizmkit-plan/assets/plan-template.md

@@ -57,6 +57,25 @@
 |------|--------|------------|
 | [Risk] | [H/M/L] | [Plan] |
 
+## Deployment Considerations
+<!-- Skip this section if the feature does not affect deployment (no new services, infra, or environment changes) -->
+<!-- Only fill when: new external service added, new database/cache introduced, new env vars required, or infra topology changes -->
+
+### New Infrastructure Requirements
+- [Component]: [Deployment target from config deploy_strategy] — [any special config needed]
+
+### New Environment Variables
+| Variable | Required | Description | Example |
+|----------|----------|-------------|---------|
+| [VAR_NAME] | yes/no | [Purpose] | [example value] |
+
+### Deployment Impact
+- [ ] No infrastructure changes needed (skip this section)
+- [ ] New service/container required
+- [ ] New environment variables added
+- [ ] Database migration required in production
+- [ ] CI/CD pipeline update needed
+
 ## Pre-Implementation Gates
 - [ ] Spec coverage: all user stories mapped to components
 - [ ] Data model reviewed — existing schema conventions documented and followed

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

@@ -185,7 +185,9 @@ The pipeline enforces a **docs pass condition**: `.prizm-docs/` must show change
 | From | To | Condition |
 |------|----|-----------|
 | `prizmkit-code-review` | **this skill** | Review passes or work is complete |
-| **this skill** | `prizmkit-committer` | Architecture synced, ready to commit |
+| **this skill** | `prizmkit-deploy` (conditional) | Architecture synced; deploy only if new tech stack detected |
+| **this skill** | `prizmkit-committer` (direct) | Architecture synced, no deployment doc update needed |
+| `prizmkit-deploy` | `prizmkit-committer` | Deploy docs updated, ready to commit |
 | `prizmkit-committer` | — | Committed |
 
 ## Output