prizmkit 1.1.78 → 1.1.79

package/bundled/VERSION.json

@@ -1,5 +1,5 @@
 {
-  "frameworkVersion": "1.1.78",
-  "bundledAt": "2026-06-14T15:40:03.496Z",
-  "bundledFrom": "190a723"
+  "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.78",
+  "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-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"
+```