prizmkit 1.1.77 → 1.1.79

package/bundled/VERSION.json

@@ -1,5 +1,5 @@
 {
-  "frameworkVersion": "1.1.77",
-  "bundledAt": "2026-06-14T15:13:42.592Z",
-  "bundledFrom": "2327b8b"
+  "frameworkVersion": "1.1.79",
+  "bundledAt": "2026-06-28T02:05:10.521Z",
+  "bundledFrom": "bba9d87"
 }

package/bundled/skills/_metadata.json

@@ -1,5 +1,5 @@
 {
-  "version": "1.1.77",
+  "version": "1.1.79",
   "skills": {
     "prizm-kit": {
       "description": "Full-lifecycle dev toolkit. Covers spec-driven development, Prizm context docs, code quality, debugging, deployment, and knowledge management.",

package/bundled/skills/bugfix-pipeline-launcher/SKILL.md

@@ -152,7 +152,7 @@ Detect user intent from their message, then follow the corresponding workflow:
 
    **Question 4 — Advanced config?** (multiSelect: false):
    - No (default) — Use defaults for session timeout and failure behavior
-   - Yes — Configure session timeout and stop-on-failure options
+   - Yes — Configure session timeout, stop-on-failure, and reasoning effort options
 
    Note: Bug filter defaults to all bugs (by severity order). Default Critic to Off unless bugs have `severity: "critical"` or `severity: "high"` (in which case default to On). If the user selects "Other" on any option, handle their custom input.
 
@@ -172,6 +172,14 @@ Detect user intent from their message, then follow the corresponding workflow:
    - No (default) — Skip deployment after pipeline completes
    - Yes — Run /prizmkit-deploy automatically after all bugs fixed successfully (`ENABLE_DEPLOY=1`). Deployment is blocked if any bug was not fixed (status not 'completed', 'skipped', or 'needs_info').
 
+   **Question 4 — Reasoning effort** (multiSelect: false):
+   - Default (none) — Use CLI default
+   - low — Minimize reasoning, fastest output (`PRIZMKIT_EFFORT=low`)
+   - medium — Moderate reasoning (`PRIZMKIT_EFFORT=medium`)
+   - high — Thorough reasoning for complex tasks (`PRIZMKIT_EFFORT=high`)
+   - xhigh — Extensive reasoning (`PRIZMKIT_EFFORT=xhigh`)
+   - max — Maximum reasoning, Claude Code only (`PRIZMKIT_EFFORT=max`)
+
    **Environment variable mapping** (for translating user responses → env vars):
 
    | Config choice | Environment variable |
@@ -183,13 +191,13 @@ Detect user intent from their message, then follow the corresponding workflow:
    | Timeout: value | `SESSION_TIMEOUT=<seconds>` |
    | Stop on failure: On | `STOP_ON_FAILURE=1` |
    | Deploy: Yes | `ENABLE_DEPLOY=1` |
+   | Effort: value | `PRIZMKIT_EFFORT=<value>` |
 
    **Advanced environment variables** (not exposed in interactive menu, pass via `--env`):
 
    | Variable | Default | Purpose |
    |----------|---------|---------|
    | `MODEL` | (none) | AI model override (e.g. `claude-opus-4.6`) |
-   | `PRIZMKIT_EFFORT` | (none) | AI reasoning effort: `low`\|`medium`\|`high`\|`xhigh`\|`max` (max = Claude Code only) |
    | `AUTO_PUSH` | `0` | Auto-push to remote after successful bug fix (`1` to enable) |
    | `DEV_BRANCH` | auto-generated | Custom dev branch name (default: `bugfix/pipeline-{run_id}`) |
    | `HEARTBEAT_INTERVAL` | `30` | Heartbeat log interval in seconds |
@@ -208,7 +216,7 @@ Detect user intent from their message, then follow the corresponding workflow:
    ```
    With all options:
    ```bash
-   VERBOSE=1 MAX_RETRIES=5 SESSION_TIMEOUT=3600 ENABLE_DEPLOY=1 \
+   VERBOSE=1 MAX_RETRIES=5 SESSION_TIMEOUT=3600 ENABLE_DEPLOY=1 PRIZMKIT_EFFORT=high \
      .prizmkit/dev-pipeline/run-bugfix.sh run .prizmkit/plans/bug-fix-list.json
    ```
 

package/bundled/skills/feature-pipeline-launcher/SKILL.md

@@ -169,7 +169,7 @@ Detect user intent from their message, then follow the corresponding workflow:
 
    **Question 4 — Advanced config?** (multiSelect: false):
    - No (default) — Use defaults for session timeout and failure behavior
-   - Yes — Configure session timeout, stop-on-failure, and deploy-after-completion options
+   - Yes — Configure session timeout, stop-on-failure, deploy-after-completion, and reasoning effort options
 
    Default Critic to Off unless features have `estimated_complexity: "high"` or above (in which case default to On).
 
@@ -189,6 +189,14 @@ Detect user intent from their message, then follow the corresponding workflow:
    - No (default) — Skip deployment after pipeline completes
    - Yes — Run /prizmkit-deploy automatically after all features complete successfully (`ENABLE_DEPLOY=1`). Deployment is blocked if any feature did not complete successfully (status not 'completed' or manually 'skipped').
 
+   **Question 4 — Reasoning effort** (multiSelect: false):
+   - Default (none) — Use CLI default
+   - low — Minimize reasoning, fastest output (`PRIZMKIT_EFFORT=low`)
+   - medium — Moderate reasoning (`PRIZMKIT_EFFORT=medium`)
+   - high — Thorough reasoning for complex tasks (`PRIZMKIT_EFFORT=high`)
+   - xhigh — Extensive reasoning (`PRIZMKIT_EFFORT=xhigh`)
+   - max — Maximum reasoning, Claude Code only (`PRIZMKIT_EFFORT=max`)
+
    **Environment variable mapping** (for translating user responses → env vars):
 
    | Config choice | Environment variable |
@@ -200,13 +208,13 @@ Detect user intent from their message, then follow the corresponding workflow:
    | Timeout: value | `SESSION_TIMEOUT=<seconds>` |
    | Stop on failure: On | `STOP_ON_FAILURE=1` |
    | Deploy: Yes | `ENABLE_DEPLOY=1` |
+   | Effort: value | `PRIZMKIT_EFFORT=<value>` |
 
    **Advanced environment variables** (not exposed in interactive menu, pass via `--env`):
 
    | Variable | Default | Purpose |
    |----------|---------|---------|
    | `MODEL` | (none) | AI model override (e.g. `claude-opus-4.6`) |
-   | `PRIZMKIT_EFFORT` | (none) | AI reasoning effort: `low`\|`medium`\|`high`\|`xhigh`\|`max` (max = Claude Code only) |
    | `AUTO_PUSH` | `0` | Auto-push to remote after successful feature (`1` to enable) |
    | `DEV_BRANCH` | auto-generated | Custom dev branch name (default: `dev/{feature_id}-YYYYMMDDHHmm`) |
    | `HEARTBEAT_INTERVAL` | `30` | Heartbeat log interval in seconds |
@@ -226,7 +234,7 @@ Detect user intent from their message, then follow the corresponding workflow:
    ```
    With all options:
    ```bash
-   VERBOSE=1 ENABLE_CRITIC=true MAX_RETRIES=5 SESSION_TIMEOUT=3600 ENABLE_DEPLOY=1 \
+   VERBOSE=1 ENABLE_CRITIC=true MAX_RETRIES=5 SESSION_TIMEOUT=3600 ENABLE_DEPLOY=1 PRIZMKIT_EFFORT=high \
      .prizmkit/dev-pipeline/run-feature.sh run .prizmkit/plans/feature-list.json --features F-001:F-005
    ```
 
@@ -237,7 +245,7 @@ Detect user intent from their message, then follow the corresponding workflow:
    With all options:
    ```bash
    .prizmkit/dev-pipeline/launch-feature-daemon.sh start .prizmkit/plans/feature-list.json --features F-001:F-005 \
-     --env "VERBOSE=1 ENABLE_CRITIC=true MAX_RETRIES=5 ENABLE_DEPLOY=1"
+     --env "VERBOSE=1 ENABLE_CRITIC=true MAX_RETRIES=5 ENABLE_DEPLOY=1 PRIZMKIT_EFFORT=high"
    ```
 
    **Manual mode**: Print the assembled command(s) and **stop here**. Do not execute anything. Do not proceed to step 8.

package/bundled/skills/refactor-pipeline-launcher/SKILL.md

@@ -170,7 +170,7 @@ Detect user intent from their message, then follow the corresponding workflow:
 
    **Question 4 — Advanced config?** (multiSelect: false):
    - No (default) — Use defaults for critic review, session timeout, and failure behavior
-   - Yes — Configure critic review, session timeout, and stop-on-failure options
+   - Yes — Configure critic review, session timeout, stop-on-failure, and reasoning effort options
 
    Note: Refactor filter defaults to all refactor items (by priority order). If the user selects "Other" on any option, handle their custom input.
 
@@ -196,6 +196,16 @@ Detect user intent from their message, then follow the corresponding workflow:
 
    Default Critic to Off unless refactor items have `priority: "critical"` (in which case default to On).
 
+   **If advanced config was selected, also ask about reasoning effort** in a follow-up `AskUserQuestion` call:
+
+   **Question — Reasoning effort** (multiSelect: false):
+   - Default (none) — Use CLI default
+   - low — Minimize reasoning, fastest output (`PRIZMKIT_EFFORT=low`)
+   - medium — Moderate reasoning (`PRIZMKIT_EFFORT=medium`)
+   - high — Thorough reasoning for complex tasks (`PRIZMKIT_EFFORT=high`)
+   - xhigh — Extensive reasoning (`PRIZMKIT_EFFORT=xhigh`)
+   - max — Maximum reasoning, Claude Code only (`PRIZMKIT_EFFORT=max`)
+
    **Environment variable mapping** (for translating user responses → env vars):
 
    | Config choice | Environment variable |
@@ -209,13 +219,13 @@ Detect user intent from their message, then follow the corresponding workflow:
    | Timeout: value | `SESSION_TIMEOUT=<seconds>` |
    | Stop on failure: On | `STOP_ON_FAILURE=1` |
    | Deploy: Yes | `ENABLE_DEPLOY=1` |
+   | Effort: value | `PRIZMKIT_EFFORT=<value>` |
 
    **Advanced environment variables** (not exposed in interactive menu, pass via `--env`):
 
    | Variable | Default | Purpose |
    |----------|---------|---------|
    | `MODEL` | (none) | AI model override (e.g. `claude-opus-4.6`) |
-   | `PRIZMKIT_EFFORT` | (none) | AI reasoning effort: `low`\|`medium`\|`high`\|`xhigh`\|`max` (max = Claude Code only) |
    | `AUTO_PUSH` | `0` | Auto-push to remote after successful refactor (`1` to enable) |
    | `DEV_BRANCH` | auto-generated | Custom dev branch name (default: `refactor/pipeline-{run_id}`) |
    | `HEARTBEAT_INTERVAL` | `30` | Heartbeat log interval in seconds |
@@ -234,7 +244,7 @@ Detect user intent from their message, then follow the corresponding workflow:
    ```
    With all options:
    ```bash
-   VERBOSE=1 STRICT_BEHAVIOR_CHECK=1 MAX_RETRIES=5 SESSION_TIMEOUT=3600 ENABLE_DEPLOY=1 \
+   VERBOSE=1 STRICT_BEHAVIOR_CHECK=1 MAX_RETRIES=5 SESSION_TIMEOUT=3600 ENABLE_DEPLOY=1 PRIZMKIT_EFFORT=high \
      .prizmkit/dev-pipeline/run-refactor.sh run .prizmkit/plans/refactor-list.json
    ```
 

package/bundled/skills-windows/bugfix-pipeline-launcher/SKILL.md

@@ -177,7 +177,7 @@ Detect user intent from their message, then follow the corresponding workflow:
 
    **Question 4 — Advanced config?** (multiSelect: false):
    - No (default) — Use defaults for session timeout and failure behavior
-   - Yes — Configure session timeout and stop-on-failure options
+   - Yes — Configure session timeout, stop-on-failure, and reasoning effort options
 
    Note: Bug filter defaults to all bugs (by severity order). Default Critic to Off unless bugs have `severity: "critical"` or `severity: "high"` (in which case default to On). If the user selects "Other" on any option, handle their custom input.
 
@@ -193,6 +193,14 @@ Detect user intent from their message, then follow the corresponding workflow:
    - Off (default) — Pipeline continues to next task after failure
    - On — Pipeline halts immediately when a task exhausts all retries (`STOP_ON_FAILURE=1`)
 
+   **Question 3 — Reasoning effort** (multiSelect: false):
+   - Default (none) — Use CLI default
+   - low — Minimize reasoning, fastest output (`PRIZMKIT_EFFORT=low`)
+   - medium — Moderate reasoning (`PRIZMKIT_EFFORT=medium`)
+   - high — Thorough reasoning for complex tasks (`PRIZMKIT_EFFORT=high`)
+   - xhigh — Extensive reasoning (`PRIZMKIT_EFFORT=xhigh`)
+   - max — Maximum reasoning, Claude Code only (`PRIZMKIT_EFFORT=max`)
+
    **Environment variable mapping** (for translating user responses → env vars):
 
    | Config choice | Environment variable |
@@ -203,6 +211,7 @@ Detect user intent from their message, then follow the corresponding workflow:
    | Critic: On | `ENABLE_CRITIC=true` |
    | Timeout: value | `SESSION_TIMEOUT=<seconds>` |
    | Stop on failure: On | `STOP_ON_FAILURE=1` |
+   | Effort: value | `PRIZMKIT_EFFORT=<value>` |
 
    **Advanced environment variables** (not exposed in interactive menu, pass via `--env`):
 
@@ -220,7 +229,7 @@ Detect user intent from their message, then follow the corresponding workflow:
    ```
    With all options:
    ```powershell
-   $env:VERBOSE = "1"; $env:MAX_RETRIES = "5"; $env:SESSION_TIMEOUT = "3600"
+   $env:VERBOSE = "1"; $env:MAX_RETRIES = "5"; $env:SESSION_TIMEOUT = "3600"; $env:PRIZMKIT_EFFORT = "high"
    .\.prizmkit\dev-pipeline\run-bugfix.ps1 run .prizmkit/plans/bug-fix-list.json
    ```
 
@@ -231,7 +240,7 @@ Detect user intent from their message, then follow the corresponding workflow:
    With all options:
    ```powershell
    .\.prizmkit\dev-pipeline\launch-bugfix-daemon.ps1 start .prizmkit/plans/bug-fix-list.json `
-     --env "VERBOSE=1 MAX_RETRIES=5"
+     --env "VERBOSE=1 MAX_RETRIES=5 PRIZMKIT_EFFORT=high"
    ```
 
    **Manual mode**: Print the assembled command(s) and **stop here**. Do not execute anything. Do not proceed to step 7.

package/bundled/skills-windows/feature-pipeline-launcher/SKILL.md

@@ -195,7 +195,7 @@ Detect user intent from their message, then follow the corresponding workflow:
 
    **Question 4 — Advanced config?** (multiSelect: false):
    - No (default) — Use defaults for session timeout and failure behavior
-   - Yes — Configure session timeout and stop-on-failure options
+   - Yes — Configure session timeout, stop-on-failure, and reasoning effort options
 
    Default Critic to Off unless features have `estimated_complexity: "high"` or above (in which case default to On).
 
@@ -211,6 +211,14 @@ Detect user intent from their message, then follow the corresponding workflow:
    - Off (default) — Pipeline continues to next task after failure
    - On — Pipeline halts immediately when a task exhausts all retries (`STOP_ON_FAILURE=1`)
 
+   **Question 3 — Reasoning effort** (multiSelect: false):
+   - Default (none) — Use CLI default
+   - low — Minimize reasoning, fastest output (`PRIZMKIT_EFFORT=low`)
+   - medium — Moderate reasoning (`PRIZMKIT_EFFORT=medium`)
+   - high — Thorough reasoning for complex tasks (`PRIZMKIT_EFFORT=high`)
+   - xhigh — Extensive reasoning (`PRIZMKIT_EFFORT=xhigh`)
+   - max — Maximum reasoning, Claude Code only (`PRIZMKIT_EFFORT=max`)
+
    **Environment variable mapping** (for translating user responses → env vars):
 
    | Config choice | Environment variable |
@@ -221,6 +229,7 @@ Detect user intent from their message, then follow the corresponding workflow:
    | Max retries: N | `MAX_RETRIES=N` |
    | Timeout: value | `SESSION_TIMEOUT=<seconds>` |
    | Stop on failure: On | `STOP_ON_FAILURE=1` |
+   | Effort: value | `PRIZMKIT_EFFORT=<value>` |
 
    **Advanced environment variables** (not exposed in interactive menu, pass via `--env`):
 
@@ -239,7 +248,7 @@ Detect user intent from their message, then follow the corresponding workflow:
    ```
    With all options:
    ```powershell
-   $env:VERBOSE = "1"; $env:ENABLE_CRITIC = "true"; $env:MAX_RETRIES = "5"; $env:SESSION_TIMEOUT = "3600"
+   $env:VERBOSE = "1"; $env:ENABLE_CRITIC = "true"; $env:MAX_RETRIES = "5"; $env:SESSION_TIMEOUT = "3600"; $env:PRIZMKIT_EFFORT = "high"
    .\.prizmkit\dev-pipeline\run-feature.ps1 run .prizmkit/plans/feature-list.json --features F-001:F-005
    ```
 
@@ -250,7 +259,7 @@ Detect user intent from their message, then follow the corresponding workflow:
    With all options:
    ```powershell
    .\.prizmkit\dev-pipeline\launch-feature-daemon.ps1 start .prizmkit/plans/feature-list.json --features F-001:F-005 `
-     --env "VERBOSE=1 ENABLE_CRITIC=true MAX_RETRIES=5"
+     --env "VERBOSE=1 ENABLE_CRITIC=true MAX_RETRIES=5 PRIZMKIT_EFFORT=high"
    ```
 
    **Manual mode**: Print the assembled command(s) and **stop here**. Do not execute anything. Do not proceed to step 8.

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

@@ -0,0 +1,81 @@
+---
+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."
+---
+
+# PrizmKit — Full-Lifecycle Development Toolkit
+
+## 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.
+
+**Per-task flow**:
+```
+read docs → plan → implement → code-review → retrospective → committer
+```
+
+Each task begins by reading context at two levels:
+
+**Application level** (read every session):
+- `.prizmkit/prizm-docs/root.prizm` — L0 project architecture index (modules, tech stack, conventions)
+- `.prizmkit/plans/project-brief.md` — user's product vision checklist (generated during project initialization)
+- `.prizmkit/config.json` — tech stack config, deploy strategy
+
+**Task level** (read for the specific task):
+- `spec.md` / `plan.md` — task specification and implementation plan
+- `.prizmkit/prizm-docs/<module>.prizm` (L1/L2) — architecture docs for affected modules (TRAPS, DECISIONS, INTERFACES)
+
+Each cycle produces spec, plan, and task artifacts that create a traceable record of what was built and why. `.prizmkit/prizm-docs/` stays in sync through retrospective, so the next session starts with up-to-date context.
+
+**Fast path** — for small, well-scoped changes, always ask user whether to use fast path:
+```
+/prizmkit-plan → /prizmkit-implement → /prizmkit-committer
+```
+
+### Development Scenarios
+
+PrizmKit supports any development scenario through the same skill chain. `/prizmkit-plan` produces `spec.md` + `plan.md` regardless of the task type:
+
+| Scenario | Artifacts | When to Use |
+|----------|-----------|-------------|
+| **Feature** | `spec.md` → `plan.md` → code | New functionality, UI, API, data model changes |
+| **Bug Fix** | `spec.md` → `plan.md` → code | Complex defects, regressions, crash fixes. Simple bugs can use fast path directly. |
+| **Refactor** | `spec.md` → `plan.md` → code | Restructure, extract, rename, performance. No behavior change. |
+
+All three follow the same per-task flow. Detailed documentation policies (when to update `.prizmkit/prizm-docs/`, when to skip steps) are defined within each skill — not here.
+
+### Best Practices for AI-Driven Development
+
+**Monorepo structure recommended**: Keep frontend, backend, and shared libraries in one repository. AI needs visibility into the full call chain — cross-repo references are invisible to it. If you have a multi-repo setup, add all related repos to the AI workspace so module boundaries and API contracts are discoverable.
+
+**Module organization**: Ensure every meaningful module has a `.prizmkit/prizm-docs/` L1 doc. AI reads TRAPS and DECISIONS before modifying files — undocumented modules get no guardrails.
+
+**Small, focused tasks**: Break large features into tasks that can each be completed in one AI session. The pipeline handles this automatically via `/prizmkit-plan` task decomposition.
+
+## Core Skill Reference
+
+| Skill | Purpose | Trigger Phrases |
+|-------|---------|-----------------|
+| `/prizmkit-plan` | Specify + plan: natural language → spec.md → plan.md + tasks | "specify", "plan", "new feature", "I want to add...", "architect", "break it down" |
+| `/prizmkit-implement` | Execute plan.md tasks, write code (TDD) | "implement", "build", "code it", "start coding" |
+| `/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-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" |
+
+**Reading guide**:
+- Need code structure/modules/interfaces/traps/decisions? → `.prizmkit/prizm-docs/`
+
+## Quick Start (First-Time Setup)
+
+1. `npx prizmkit install .` → installs skills, rules (`prizm-documentation.md`, `prizm-commit-workflow.md`), hooks, platform scaffolding
+2. `/prizmkit-init` → scans project code, generates `.prizmkit/prizm-docs/`, detects tech stack, populates `.prizmkit/config.json`
+3. `/prizmkit-plan` → specify your first feature → produces spec.md + plan.md
+4. `/prizmkit-implement` → TDD implementation following the plan
+5. `/prizmkit-code-review` → review before commit
+6. `/prizmkit-retrospective` → sync `.prizmkit/prizm-docs/` with changes
+7. `/prizmkit-committer` → safe Conventional Commit
+
+> **Note**: Rules and hooks are installed by `npx prizmkit install`, not by `/prizmkit-init`.

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

@@ -0,0 +1,225 @@
+---
+name: "prizmkit-code-review"
+description: "Iterative review-fix loop against spec and plan. Spawns a read-only Reviewer agent, filters findings, then a Dev agent applies fixes. Loops until PASS (max 3 rounds). Use after /prizmkit-implement as quality gate. Trigger on: 'review', 'check code', 'code review', 'is it ready to commit'. (project)"
+---
+
+# PrizmKit Code Review
+
+An iterative review-fix loop that reviews code changes against the spec and plan, then automatically fixes issues. Uses three separated roles:
+
+- **Reviewer Agent** (read-only): analyzes git diff against spec goals and plan decisions, produces structured findings
+- **Main Agent** (orchestrator): filters Reviewer findings for reasonableness, coordinates the loop
+- **Dev Agent** (read-write): applies fixes for accepted findings
+
+The loop repeats until the Reviewer finds no issues or the max round limit is reached.
+
+### When to Use
+- After `/prizmkit-implement` to verify code quality before commit
+- User says "review", "check code", "review my implementation"
+- As a quality gate before `/prizmkit-committer`
+
+### When NOT to Use
+- Trivial changes (typo, single-line config) → commit directly
+- No spec.md or plan.md exists → nothing to review against
+
+## Input
+
+| Parameter | Required | Description |
+|-----------|----------|-------------|
+| `artifact_dir` | No | Directory containing spec.md + plan.md. If omitted, scan `.prizmkit/` subdirectories for the most recently modified directory with a `plan.md` whose tasks are all completed. |
+
+## Phase 0: Context Loading
+
+1. **Read spec.md** from the artifact directory — extract goals and acceptance criteria.
+2. **Read plan.md** from the artifact directory — extract architecture decisions and completed tasks.
+3. **Read dev rules** (if configured): Read `.prizmkit/prizm-docs/root.prizm` and check for a `RULES:` line. If present, read all referenced `.prizmkit/rules/<layer>-rules.md` files. If a referenced file does not exist, skip it silently and continue. These define per-layer conventions that the code should follow.
+4. **Capture workspace diff**: run `git diff` (unstaged) + `git diff --cached` (staged) + `git status` to understand the full scope of changes. For new files in git status, note their paths for the Reviewer to read.
+   - If no changes are detected, output PASS and stop.
+
+## Phase 1: Review-Fix Loop
+
+```
+┌─── Loop (max 3 rounds) ──────────────────────────────┐
+│                                                        │
+│  Step 1: Spawn Reviewer Agent (read-only)              │
+│    → Input: git diff + spec goals + plan decisions + dev rules│
+│    → Output: structured findings or PASS               │
+│                                                        │
+│  Step 2: Check result                                  │
+│    → If PASS (no findings): exit loop                  │
+│                                                        │
+│  Step 3: Main Agent filters findings                   │
+│    → For each finding: accept (reasonable) or reject   │
+│    → If all rejected: exit loop                        │
+│                                                        │
+│  Step 4: Spawn Dev Agent (read-write)                  │
+│    → Input: accepted findings + spec/plan context      │
+│    → Output: fix report                                │
+│                                                        │
+│  Step 5: Back to Step 1                                │
+│                                                        │
+│  Hard limit: exit after 3 rounds regardless            │
+│  → On max-round exhaustion: output a summary of all    │
+│    unresolved findings to the conversation, then write  │
+│    review-report.md with NEEDS_FIXES verdict.           │
+└────────────────────────────────────────────────────────┘
+```
+
+### Step 1: Spawn Reviewer Agent
+
+Include the dev rules read in Phase 0 step 3 in the `## Dev Rules` section of the prompt below. Spawn a **read-only** agent (subagent_type: `Explore`) with the following prompt:
+
+```
+You are a code reviewer. Review workspace changes against the spec goals, plan decisions, and per-layer dev rules.
+
+## Spec Goals
+{goals and acceptance criteria from spec.md}
+
+## Plan Decisions
+{architecture decisions and task list from plan.md}
+
+## Dev Rules (per-layer conventions)
+{rules from .prizmkit/rules/<layer>-rules.md, or "No custom dev rules configured — use general best practices."}
+
+## Review Round
+Round {N}. {round_context}
+
+## What to Review
+Run these commands to see the current workspace changes:
+- `git diff` (unstaged changes)
+- `git diff --cached` (staged changes)
+- `git status` (new/deleted files)
+
+For new files shown in git status, read their full content.
+For modified files, read enough surrounding context to understand the change.
+
+## Review Dimensions
+Evaluate the changes across these dimensions (focus on what's relevant):
+
+1. **Goal alignment**: Do the changes accomplish all goals from spec.md? Anything missing or off-target?
+2. **Defects**: Logic bugs, missing error handling, boundary condition issues, incorrect behavior.
+3. **Completeness**: Files that should have been changed but weren't? Missing tests, types, imports, exports?
+4. **Consistency**: Do changes follow the project's existing patterns, naming conventions, and code style?
+5. **Security**: Hardcoded secrets, injection vulnerabilities, unsafe operations.
+6. **Rules compliance**: (Skip this dimension if no dev rules were provided.) Do changes follow the per-layer dev rules? Flag violations of framework conventions, naming patterns, state management, or other rules defined for that layer.
+
+## Output Format
+Respond with EXACTLY this format:
+
+### Result: PASS | NEEDS_FIXES
+
+### Findings
+(If PASS, write "No issues found.")
+
+#### Finding N
+- **Severity**: high | medium | low
+- **Dimension**: goal-alignment | defect | completeness | consistency | security | rules-compliance
+- **Location**: filepath:line (or "project-level")
+- **Problem**: What is wrong and why it matters
+- **Suggestion**: Recommended fix approach
+- **Verification**: How to confirm the fix is correct
+
+### Summary
+One to two sentences about the overall state of the changes.
+```
+
+**Round context** varies by round:
+- Round 1: "This is the first review. Examine all changes comprehensively."
+- Round 2+: "Previous round found issues that were fixed. Focus on: (1) whether previous fixes are correct, (2) whether fixes introduced new problems, (3) any remaining issues. Do not re-report issues that have already been fixed."
+
+### Step 2: Check Result
+
+Parse the Reviewer Agent's output:
+- If `Result: PASS` → exit loop, proceed to Phase 2.
+- If `Result: NEEDS_FIXES` → extract findings and continue to Step 3.
+
+### Step 3: Main Agent Filters Findings
+
+Review each finding and decide whether it's reasonable. This prevents unnecessary or harmful changes.
+
+**For each finding, evaluate:**
+- Is this relevant to the current changes? (Reject findings about unmodified, unrelated code.)
+- Is this a real problem or a subjective style preference? (Reject pure style preferences unless they violate clear project conventions.)
+- Would fixing this improve the code without introducing risk? (Reject fixes that require large refactors outside scope.)
+
+**Output per finding:**
+- **Accepted**: The finding is reasonable — include it in the Dev Agent's task.
+- **Rejected** (with reason): Brief explanation (e.g., "Out of scope", "Style preference, not a defect").
+
+If all findings are rejected → exit loop, proceed to Phase 2.
+
+### Step 4: Spawn Dev Agent
+
+Spawn a **general-purpose** agent (read-write) with the following prompt:
+
+```
+You are a developer fixing code review findings. Apply each fix carefully without breaking existing functionality.
+
+## Spec Context
+{goals from spec.md for reference}
+
+## Findings to Fix
+{accepted findings list — each with Severity, Location, Problem, Suggestion, Verification}
+
+## Instructions
+1. Read each finding carefully.
+2. For each finding:
+   a. Read the relevant code and understand the context.
+   b. Implement the fix based on the suggestion.
+   c. If a suggestion is not feasible (would break other functionality, technically impossible), explain why.
+3. After all fixes, report what you did.
+
+## Output Format
+For each finding, report:
+- **Finding N**: [fixed | unable-to-fix]
+- **What was done**: Brief description
+- **Files modified**: List of changed files
+(If unable-to-fix, explain why)
+```
+
+After the Dev Agent returns, record results and return to Step 1 for the next round.
+
+## Phase 2: Output
+
+Write `review-report.md` to the artifact directory:
+
+```markdown
+# Review Report
+
+## Verdict: PASS
+## Rounds: 2
+## Total findings: 3 → Fixed: 2, Rejected: 1
+
+## Round 1
+Findings: 3 | Accepted: 2, Rejected: 1
+
+### Finding 1: Missing null check in parseConfig
+- Severity: high
+- Dimension: defect
+- Location: src/config.ts:42
+- Problem: parseConfig crashes when input is undefined
+- Status: fixed (round 1)
+
+### Finding 2: Export missing from index.ts
+- Severity: medium
+- Dimension: completeness
+- Location: src/index.ts
+- Problem: New parseConfig function not exported
+- Status: fixed (round 1)
+
+### Finding 3: Consider renaming variable
+- Severity: low
+- Dimension: consistency
+- Location: src/config.ts:15
+- Problem: Variable `d` should be more descriptive
+- Status: rejected — Style preference; existing code uses short names in this module
+
+## Round 2: PASS — no new findings
+```
+
+- `PASS`: Reviewer returned no findings (or all remaining findings were rejected as unreasonable)
+- `NEEDS_FIXES`: 3 rounds completed but unresolved findings remain
+
+Also output a completion summary to conversation.
+
+**HANDOFF:** `/prizmkit-retrospective` (if PASS) or inform the caller of remaining issues (if NEEDS_FIXES after max rounds)

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

@@ -0,0 +1,81 @@
+---
+name: "prizmkit-committer"
+description: "Pure git commit workflow with safety checks. Stages files, generates Conventional Commits message, and commits. Does NOT modify .prizmkit/prizm-docs/ — run /prizmkit-retrospective first. Trigger on: 'commit', 'submit', 'finish', 'done', 'ship it'. (project)"
+---
+
+# PrizmKit Committer
+
+### When to Use
+- User says "commit", "submit", "finish", "done with this task", "ship it"
+- After `/prizmkit-retrospective` has finished architecture sync
+- The UserPromptSubmit hook will remind to use this skill when commit intent is detected
+
+**PRECONDITION:**
+
+| Required State | Check | If Missing |
+|---|---|---|
+| Uncommitted changes exist | `git status` shows modified/added/untracked files | Inform user "nothing to commit" and stop |
+| `.prizmkit/prizm-docs/` synced (feature/refactor) | `/prizmkit-retrospective` has run | Run `/prizmkit-retrospective` first |
+| Code review passed (pipeline mode) | `review-report.md` in artifact directory has `## Verdict: PASS` | Run `/prizmkit-code-review` first |
+
+### Workflow
+
+Follow these steps in order — skipping or reordering can stage sensitive files or commit without proper verification:
+
+#### Step 1: Status Check
+```powershell
+git status
+```
+- If "nothing to commit, working tree clean": inform user and stop
+- If there are changes: proceed
+
+#### Step 2: Generate Commit Message
+Analyze the staged diff and context (spec title, plan summary) 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.
+
+#### Step 4: Git Commit
+
+Stage changes using a safe strategy — **never use `git add .` or `git add -A`** as they may stage sensitive files (.env, credentials, secrets) or unintended changes:
+
+1. Review untracked files with `git status`. Warn the user if any files match sensitive patterns (`.env*`, `*credential*`, `*secret*`, `*.pem`, `*.key`).
+2. Stage tracked modified files: `git add -u`
+3. For new files: stage explicitly by name after confirming they should be included.
+4. Verify staged content with `git diff --cached --stat` before committing.
+
+```powershell
+git commit -m "<type>(<scope>): <description>"
+```
+Follow Conventional Commits format.
+
+#### Step 5: Verification
+```powershell
+git log -1 --stat
+```
+Confirm the commit was recorded.
+
+Then verify working tree is clean:
+```powershell
+git status
+```
+- If "nothing to commit, working tree clean": commit verified successfully, proceed
+
+#### Step 6: Optional Push
+Ask user: "Push to remote?"
+- Yes: `git push`
+- No: Stop
+
+**Headless mode**: If the skill was invoked with `--headless` in the args (e.g., `/prizmkit-committer --headless feat(F-001): ...`), **SKIP this step entirely**. Do NOT ask the question. Do NOT push. Stop after Step 5 verification. Headless mode is used by autonomous pipeline sessions where there is no human to answer interactive prompts.
+
+## Example
+
+**Feature commit:**
+```
+git commit -m "feat(avatar): add user avatar upload with S3 storage"
+```
+
+**Bug fix commit:**
+```
+git commit -m "fix(auth): handle null token in refresh flow"
+```