prizmkit 1.1.8 → 1.1.9

package/bundled/skills/feature-planner/references/error-recovery.md

@@ -51,59 +51,40 @@ if all_retries_exceeded:
 
 ## Resume Support
 
-feature-planner sessions can be resumed from the last completed checkpoint without losing context.
+feature-planner sessions can be resumed from the last completed checkpoint when artifacts are found.
 
 ### Detection Logic
 
-Check for artifact files in working directory:
+Check for artifact files in `.prizmkit/plans/`:
 
-| Artifacts Found | Last Completed Checkpoint | Next Phase | Resume Action |
-|-----------------|--------------------------|-----------|----------------|
-| None | (new session) | Phase 1: Scope | Start fresh planning |
-| `feature-list.json` exists | CP-FP-4 (file generated) | Phase 9: Final validation | Offer to validate or extend |
-| `feature-list.json` + validation passed | CP-FP-5 (validation pass) | Handoff: dev-pipeline | Offer: execute pipeline now |
-| Partial state (incomplete file) | CP-FP-1 or CP-FP-2 | Next phase after last checkpoint | Resume interactive planning |
-| User restarts mid-session | User says "restart" | Return to Phase 1 Vision, or load previous checkpoint if requested |
-| Max validation retries exceeded | 3 failed validation loops | Offer: (a) manual review, (b) restart from Phase 1 |
+| Artifacts Found | Resume Action |
+|-----------------|---------------|
+| None | Start fresh planning (Phase 1) |
+| `feature-list.json` exists but not validated | Offer to validate or extend (Phase 9) |
+| `feature-list.json` + validation passed | Offer: handoff to `feature-pipeline-launcher` |
+| `feature-list.draft.json` only | Resume interactive planning from last checkpoint |
 
-### Resume Command (Project Structure)
-
-For projects using `.prizmkit/` structure:
-
-```bash
-# Explicit resume (if file is not in current directory):
-feature-planner --resume-from <path-to-existing-feature-list.json>
-```
-
-AI detects existing file → suggests:
-```
-"Existing plan found with N features, M newly added.
-Resume incremental planning? (Y/n)"
-```
+When existing file detected, suggest:
+> "Existing plan found with N features. Resume incremental planning? (Y/n)"
 
 ### Incremental Mode Abort
 
 If in Incremental mode but existing `feature-list.json` not found:
 - Ask: "Start new plan or provide existing file?"
 - If new plan chosen → switch to Route A (New Feature Set)
-- If existing file uploaded → continue Route B
 
 ### Artifact Path Convention
 
-**CRITICAL PATH RULE**: `feature-list.json` MUST be written to `.prizmkit/plans/` directory
-(unified artifact location).
-
-Before writing, verify: `ls .prizmkit 2>/dev/null` — if this directory exists in the current
-directory, you are at the project root. If not, create `.prizmkit/plans/` first (mkdir -p .prizmkit/plans).
+**CRITICAL PATH RULE**: `feature-list.json` MUST be written to `.prizmkit/plans/` directory.
 
-After writing, verify: `ls -la .prizmkit/plans/feature-list.json` from project root.
+Before writing, verify the directory exists: `mkdir -p .prizmkit/plans`
 
 ```
 <project-root>/
   └── .prizmkit/plans/
-      ├── feature-list.json              # Primary output (always here, at .prizmkit/plans/)
-      ├── feature-list.validated.json    # Checkpoint backup after CP-FP-5
+      ├── feature-list.json              # Primary output
+      ├── feature-list.draft.json        # Draft backup (Session Exit Gate)
       └── <ISO-timestamp>.backup.json    # Optional incremental backups
 ```
 
-The pipeline reads `feature-list.json` from `.prizmkit/plans/` by default. If the user specifies a custom path, the launcher accepts it as an argument.
+> **Note**: For cross-session workflow recovery (e.g., interrupted pipeline execution, branch-level state detection), use `recovery-workflow` instead. This error-recovery reference handles only within-session validation retries and checkpoint resumption.

package/bundled/skills/feature-planner/references/incremental-feature-planning.md

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

package/bundled/skills/feature-planner/references/new-project-planning.md

@@ -31,7 +31,7 @@ For each feature define:
 - `id`
 - `title`
 - `description`
-- `priority` — string: `"high"`, `"medium"`, or `"low"` (never numeric)
+- `priority` — string: `"critical"`, `"high"`, `"medium"`, or `"low"` (never numeric)
 - `estimated_complexity`
 - `dependencies`
 - `acceptance_criteria`
@@ -82,4 +82,4 @@ Split into `sub_features` when:
 - [ ] IDs are sequential
 - [ ] `status` initialized to `pending`
 - [ ] Validation passes
-- [ ] Next step recommendation follows priority: launcher → daemon → run-feature.sh
+- [ ] Next step recommendation: `feature-pipeline-launcher`

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

@@ -34,7 +34,7 @@ SCHEMA_VERSION = "dev-pipeline-feature-list-v1"
 
 VALID_STATUSES = {"pending", "in_progress", "completed", "failed", "skipped", "split", "auto_skipped"}
 VALID_COMPLEXITIES = {"low", "medium", "high"}
-VALID_PRIORITIES = {"high", "medium", "low"}
+VALID_PRIORITIES = {"critical", "high", "medium", "low"}
 VALID_GRANULARITIES = {"feature", "sub_feature", "auto"}
 VALID_PLANNING_MODES = {"new", "incremental"}
 
@@ -446,7 +446,6 @@ def generate_template():
         "project_description": "YOUR_PROJECT_DESCRIPTION",
         "created_at": now,
         "created_by": "feature-planner",
-        "source_spec": "",
         "features": [
             {
                 "id": "F-001",

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

@@ -1,7 +1,6 @@
 ---
 name: "feature-workflow"
-tier: companion
-description: "One-stop entry point for feature development. Brainstorms requirements with the user until fully clarified, then orchestrates feature-planner → feature-pipeline-launcher → execution. Handles multi-feature batch development from a single request. Use this skill whenever the user wants to build an app, develop multiple features at once, or go from idea to running code in one step. Trigger on: 'build an app', 'develop features', 'implement all features', 'one-stop development', 'batch implement', 'build a new application', 'build a system', 'one-click complete', 'batch implement'. (project)"
+description: "One-stop entry point for feature development. Brainstorms requirements with the user until fully clarified, then orchestrates feature-planner → feature-pipeline-launcher → execution. Handles multi-feature batch development from a single request. Use this skill whenever the user wants to build an app, develop multiple features at once, or go from idea to running code in one step. Trigger on: 'build an app', 'develop features', 'implement all features', 'one-stop development', 'batch implement', 'build a new application', 'build a system', 'one-click complete', 'batch implement'."
 ---
 
 # Feature Workflow
@@ -240,7 +239,7 @@ Present this summary to the user and get explicit confirmation before proceeding
    - Pass the structured requirements summary as input — NOT the raw user conversation
    - For new projects: standard planning mode
    - For existing projects with `--incremental`: incremental planning mode
-   - **Input**: Markdown requirements summary (feature descriptions, user stories, constraints)
+   - **Input**: Markdown requirements summary (feature descriptions, goals, constraints)
    - **Output**: `.prizmkit/plans/feature-list.json` (schema: `dev-pipeline-feature-list-v1`) containing `project_name`, `features[]` with id (F-NNN), title, description, priority, dependencies, acceptance_criteria, status
 
 2. **Interactive planning** (if feature-planner requires clarification):
@@ -398,7 +397,7 @@ While the pipeline runs, the user can continue the conversation:
 | **Input** | Rough idea or requirements | Bug report / stack trace | Module / code target |
 | **Output** | Multiple `feat()` commits | Single `fix()` commit | Single `refactor()` commit |
 | **User verification** | Yes (Phase 1 brainstorm confirmation) | Yes (Phase 5) | Yes (Phase 5) |
-| **Batch alternative** | (this is the batch flow) | `bug-planner` + `bugfix-pipeline-launcher` | N/A |
+| **Batch alternative** | (this is the batch flow) | `bug-planner` + `bugfix-pipeline-launcher` | (this is the batch flow) |
 
 ---
 

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

@@ -1,61 +1,62 @@
 ---
 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', or '/prizmkit'. (project)"
+description: "Full-lifecycle dev toolkit index. Routes to the right PrizmKit skill for spec-driven development, Prizm docs, code quality, deployment, and knowledge management. Use when the user asks 'which command?', 'help', 'how do I start a feature', '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
 
-## When to Use the Full Workflow
+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.
 
-**Full workflow** — forms a continuous loop for feature development:
+**Per-task flow**:
 ```
-read .prizm-docs → plan (specify + design + tasks) → implement → code-review → retrospective → committer
-                      ↑                                                              ↓
-                      └────────────────────── next feature ←─────────────────────────┘
+read docs → plan → implement → code-review → retrospective → committer
 ```
-- New features or user-facing capabilities
-- Multi-file coordinated changes
-- Architectural decisions, data model or API changes
 
-Each cycle produces spec, plan, and task artifacts that create a traceable record of what was built and why — `.prizm-docs/` stays in sync through retrospective, so the next cycle starts with up-to-date context.
+Each task begins by reading context at two levels:
 
-**Fast path** — for small, well-scoped changes:
+**Application level** (read every session):
+- `.prizm-docs/root.prizm` — L0 project architecture index (modules, tech stack, conventions)
+- `.prizmkit/plans/project-brief.md` — user's product vision checklist (generated by app-planner)
+- `.prizmkit/config.json` — tech stack config, deploy strategy
+
+**Task level** (read for the specific task):
+- `spec.md` / `plan.md` — task specification and implementation plan
+- `.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. `.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
 ```
-- Bug fixes with clear root cause
-- Simple refactors (rename, extract)
-- Documentation-only changes, test additions for existing code
 
-Fast path skips specify/analyze/review but still generates a simplified plan.md so implement has a task list to follow.
+### Development Scenarios
 
-### Bug Fix Documentation Policy
+PrizmKit supports any development scenario through the same skill chain. `/prizmkit-plan` produces `spec.md` + `plan.md` regardless of the task type:
 
-**Bug fixes MUST NOT create new documentation entries.** Bug fixes are refinements of incomplete existing features — they complete what was already planned, not introduce new functionality. Specifically:
+| 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. |
 
-- Run `/prizmkit-retrospective` with structural sync only (Job 1) for bug fix commits — skip knowledge injection unless genuinely new TRAP discovered
-- Do NOT create new spec/plan/tasks under `.prizmkit/specs/` for bug fixes
-- Do NOT update `.prizm-docs/` module docs for pure bug fixes (no interface/dependency change)
-- Bug fix commits use `fix(<scope>):` prefix in Conventional Commits, not `feat:`
+All three follow the same per-task flow. Detailed documentation policies (when to update `.prizm-docs/`, when to skip steps) are defined within each skill — not here.
 
-All documentation records are for: features, projects, code logic, and module indexes. Bug fixes do not alter the system's functional scope — they bring existing features to their intended state.
+### Best Practices for AI-Driven Development
 
-## Architecture
+**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.
 
-PrizmKit produces two complementary knowledge layers:
+**Module organization**: Ensure every meaningful module has a `.prizm-docs/` L1 doc. AI reads TRAPS and DECISIONS before modifying files — undocumented modules get no guardrails.
 
-```
-.prizm-docs/           → Architecture Index (structure, interfaces, dependencies, traps, rules, decisions)
-.prizmkit/specs/       → Feature artifacts (spec → plan → implement → review cycle)
-```
+**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-analyze` | Cross-doc consistency check (read-only) | "analyze", "check consistency", "validate spec" |
 | `/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 .prizm-docs/ with code changes | "retrospective", "retro", "sync docs", "wrap up" |
@@ -67,25 +68,14 @@ PrizmKit produces two complementary knowledge layers:
 **Reading guide**:
 - Need code structure/modules/interfaces/traps/decisions? → `.prizm-docs/`
 
-### Tier Definitions
-
-- **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 foundational, documentation, spec-driven workflow, and commit skills that form PrizmKit's primary value
-
-## Installation
-
-**Option 1: npm CLI (recommended — works for both platforms)**
-```bash
-npx prizmkit init
-```
-Interactive installer auto-detects your platform and guides you through configuration.
-
-**Option 2: Claude Code Plugin**
-Install the `prizmkit` plugin via Claude Code's plugin system, then run `/prizmkit-init`.
+## Quick Start (First-Time Setup)
 
-## Hook / Rules Configuration
+1. `npx prizmkit install .` → installs skills, rules (`prizm-documentation.md`, `prizm-commit-workflow.md`), hooks, platform scaffolding
+2. `/prizmkit-init` → scans project code, generates `.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 `.prizm-docs/` with changes
+7. `/prizmkit-committer` → safe Conventional Commit
 
-Hooks and rules are configured automatically by `prizmkit-init`:
-- `assets/project-memory-template.md` for the project memory template
-- The init skill creates `prizm-documentation.md` and `prizm-commit-workflow.md` rules
+> **Note**: Rules and hooks are installed by `npx prizmkit install`, not by `/prizmkit-init`.

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

@@ -1,102 +1,89 @@
 ---
 name: "prizmkit-code-review"
-description: "Code review with fix strategy formulation. Diagnoses issues across 6 dimensions, then produces structured Fix Instructions. Use after /prizmkit-implement as quality gate before committing. Trigger on: 'review', 'check code', 'code review', 'is it ready to commit'. (project)"
+description: "Code review against spec and plan. Diagnoses issues across multiple dimensions, produces findings with fix instructions. Use after /prizmkit-implement as quality gate. Trigger on: 'review', 'check code', 'code review', 'is it ready to commit'. (project)"
 ---
 
 # PrizmKit Code Review
 
-Perform a comprehensive code review against the feature spec, implementation plan, and project best practices. This skill has two phases:
-
-1. **Diagnostic Review** — read-only analysis producing findings with severity ratings
-2. **Fix Strategy Formulation** — for each finding, produce actionable Fix Instructions
-
-The review itself is read-only. Fix Instructions are structured guidance for the developer — the reviewer does not modify code.
+Review code changes against the spec, plan, and project conventions. Produces a diagnostic report with findings and actionable fix instructions. The review itself is read-only — no source code is modified.
 
 ### 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`
 
-**PRECONDITION:**
+### When NOT to Use
+- Trivial changes (typo, single-line config) → commit directly
+- No spec.md or plan.md exists → nothing to review against
 
-| Mode | Required Artifacts | Directory | Check | If Missing |
-|---|---|---|---|---|
-| **Feature** | `spec.md` + `plan.md` (with Tasks) | `.prizmkit/specs/###-feature-name/` | Files exist + tasks completed | Run `/prizmkit-implement` |
-| **Refactor** | `refactor-analysis.md` + `plan.md` (with Tasks) | `.prizmkit/refactor/<refactor-slug>/` | Files exist + tasks completed. Review against behavior preservation, not spec. | Run `/prizmkit-implement` in refactor mode |
-| **Bugfix** | `fix-plan.md` | `.prizmkit/bugfix/<BUG_ID>/` | File exists + tasks completed. Review against bug description + reproduction test. | Run `/prizmkit-implement` in bugfix mode |
+## Input
 
-**Auto-detect**: Check which artifact directory was passed by the calling workflow, or scan `.prizmkit/` for the most recently modified feature/refactor/bugfix directory.
+| 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 1: Diagnostic Review
+## Context Loading
 
-1. **Detect mode and load review baseline + dimension rules**:
-   - If `spec.md` exists → **Feature mode**: read `spec.md` + `plan.md` as baseline. Load `${SKILL_DIR}/rules/dimensions-feature.md` for review dimensions.
-   - If `refactor-analysis.md` exists → **Refactor mode**: read `refactor-analysis.md` + `plan.md` as baseline. Load `${SKILL_DIR}/rules/dimensions-refactor.md` for refactor-specific dimensions, **and also** `${SKILL_DIR}/rules/dimensions-feature.md` §3–§6 for standard dimensions (code quality, security, consistency, test coverage) that still apply.
-   - If `fix-plan.md` exists → **Bugfix mode**: read `fix-plan.md` as baseline. Load `${SKILL_DIR}/rules/dimensions-bugfix.md` for review dimensions.
-   - If none found → prompt user: "No review baseline found. Which workflow are you in? (feature/refactor/bugfix)"
-2. Read **architecture index**: `.prizm-docs/root.prizm` RULES and PATTERNS for project conventions
-3. Read **past decisions**: check DECISIONS sections in relevant `.prizm-docs/` L1/L2 files — helps verify implementation respects established conventions
-4. Read '## Implementation Log' section of context-snapshot.md in the feature directory (if exists) — understand Dev's implementation decisions, trade-offs, and notable discoveries. This context helps distinguish intentional design choices from accidental patterns during review.
-5. Scan all code files referenced in completed tasks
-6. Review across all dimensions defined in the loaded rules file
-7. Generate findings with severity: `CRITICAL` > `HIGH` > `MEDIUM` > `LOW`
+1. **Task context**: Read `spec.md`, `plan.md`, and any companion documents (e.g., `refactor-analysis.md`) from the artifact directory.
+2. **Architecture context**: Read `.prizm-docs/root.prizm` (L0) and relevant L1/L2 docs for affected modules — check RULES, PATTERNS, TRAPS, DECISIONS.
 
-## Phase 2: Fix Strategy Formulation
+## Phase 1: Diagnostic Review
 
-Load `${SKILL_DIR}/rules/fix-strategy.md` for the complete fix formulation process, finding format, grouping rules, and priority ordering.
+1. **Identify changed files**: Extract file paths from completed tasks in plan.md, or use `git diff` against the branch base.
+2. **Read changed files**: Scan all code files identified above.
+3. **Review across dimensions**: Load `${SKILL_DIR}/rules/dimensions.md` and evaluate each applicable dimension. Dimensions are conditionally triggered based on what sections exist in spec.md — see the dimensions file for trigger conditions.
+4. **Generate findings**: For each issue found, describe the problem, its location, which dimension it falls under, and why it matters.
+5. If unsure whether something is a bug or intentional design, flag it with a note asking the developer to confirm.
 
-For each finding from Phase 1 (CRITICAL and HIGH are mandatory; MEDIUM/LOW when actionable), follow the fix strategy rules to produce structured Fix Instructions.
+## Phase 2: Fix Strategy
 
-## Severity & Verdict
+For each finding, load `${SKILL_DIR}/rules/fix-strategy.md` and produce structured Fix Instructions: Root Cause, Impact, Fix Strategy, Code Guidance, Verification Criteria.
 
-Spec compliance failures are always HIGH or CRITICAL — if the code doesn't match what was agreed in the spec, that's a functional gap, not a style issue. Security findings follow the same rule.
+## Reviewer Agent Mode
 
-**Verdict criteria:**
-- `PASS`: No CRITICAL or HIGH findings
-- `PASS WITH WARNINGS`: No CRITICAL findings, some HIGH findings
-- `NEEDS FIXES`: Any CRITICAL findings present
+When interactive session is available, offer the option to spawn an independent reviewer subagent:
 
-Cap findings at 30 to keep the review actionable. If there are more, summarize the overflow with counts by dimension.
+1. Spawn a reviewer subagent with **read-only** permissions (Read, Glob, Grep, Bash for test commands only)
+2. The subagent independently reviews changed files against spec/plan/dimensions and produces findings
+3. The main agent receives findings and applies fixes
+4. Re-spawn the subagent to verify fixes
+5. Repeat until the subagent reports no more findings or the caller's maximum iteration limit is reached
 
-If you're unsure whether something is a bug or intentional design, flag it as MEDIUM with a note asking the developer to confirm. Don't silently skip uncertain findings.
+In non-interactive mode, perform the review directly (no subagent).
 
-## Review Notes Format
+## Output
 
-When writing to context-snapshot.md, use this structured format:
+Write `review-report.md` to the artifact directory:
 
 ```markdown
-## Review Notes
-
-### Verdict: PASS | PASS_WITH_WARNINGS | NEEDS_FIXES
-### Review Iteration: 1/5
-### Summary: X findings (N critical, N high, N medium, N low)
+# Review Report
 
-### Fix Instructions (ordered by priority)
+## Verdict: PASS | NEEDS_FIXES
 
-#### FIX-1: [SEVERITY] Title
-(finding format per ${SKILL_DIR}/rules/fix-strategy.md)
+## Summary: X findings
 
-#### FIX-2: [SEVERITY] Title
-...
+## Findings
 
-### Re-Review Expectations
-After fixes are applied, the reviewer expects:
-1. (specific grep/test commands that should pass)
-2. (behavioral checks)
-3. All existing tests pass
+### Finding 1: Title
+- Location: file:line
+- Dimension: category
+- Problem: what is wrong and why it matters
+- Root Cause: explanation
+- Impact: affected callers/dependents
+- Fix Strategy: step-by-step
+- Code Guidance: before/after snippet
+- Verification: commands/checks to confirm
+- Related: Finding N (if grouped)
 ```
 
-**HANDOFF:** `/prizmkit-retrospective` (if PASS) or Dev fixes following Fix Instructions (if NEEDS FIXES)
+- `PASS`: 0 findings
+- `NEEDS_FIXES`: 1+ findings with fix instructions
 
-## Loop Protection
+Also output findings summary to conversation.
 
-In unattended pipeline mode, the review→fix→review cycle can loop indefinitely if fixes introduce new issues. To prevent this:
+**HANDOFF:** `/prizmkit-retrospective` (if no findings) or apply fixes and re-review (if findings exist)
 
-- Track a `review_iteration` counter starting at 1. Each review-fix-review cycle increments the counter.
-- **max_iterations = 5**: If `review_iteration >= 5`, you MUST proceed to `/prizmkit-retrospective` regardless of remaining findings. Log remaining issues as known technical debt: "Loop protection triggered — proceeding to retrospective with N unresolved findings (iterations: 5/5)."
-- Unresolved findings should be recorded in the review report so they can be tracked as follow-up work.
-- On re-review (iteration > 1): only check the specific Verification Criteria from previous Fix Instructions + scan for regressions. Do NOT re-run the full dimension review unless new code was added beyond the fix scope.
-
-## Output
+## References
 
-Review report with Fix Instructions is output to conversation and written to the '## Review Notes' section of context-snapshot.md. No source code files are created or modified.
+- Review dimensions: `${SKILL_DIR}/rules/dimensions.md`
+- Fix strategy formulation: `${SKILL_DIR}/rules/fix-strategy.md`

package/bundled/skills/prizmkit-code-review/rules/dimensions.md

@@ -0,0 +1,85 @@
+# Review Dimensions
+
+Evaluate code changes across the following dimensions. Each dimension is either **always active** or **conditionally triggered** based on spec.md content.
+
+---
+
+## §1 Goal Compliance (always active)
+
+Does code implement all goals and acceptance criteria from spec.md?
+
+- Check every goal (G-N) in spec.md has a corresponding implementation
+- Verify acceptance criteria are met
+- Verify edge cases mentioned in spec are handled
+- Confirm scope boundaries are respected (no over-implementation, no under-implementation)
+
+## §2 Plan Adherence (always active)
+
+Does implementation follow architectural decisions in plan.md?
+
+- Check component structure matches plan's change approach
+- Verify data model matches plan's schema design (if applicable)
+- Confirm API contracts (endpoints, request/response) match plan (if applicable)
+- Deviations may be improvements — flag for confirmation, not automatic rejection
+
+## §3 Behavior Preservation (conditional: spec.md has `## Behavior Preservation`)
+
+Observable behavior for existing functionality must remain unchanged.
+
+- All existing tests still pass without modification
+- Public API signatures are unchanged (parameter types, return types, error types)
+- Side effects (logging, metrics, events) are preserved unless explicitly scoped for removal
+- Edge case handling is preserved — changes often silently drop edge case branches
+
+## §4 Code Quality (always active)
+
+Naming, structure, complexity, DRY. Focus on maintainability.
+
+- Function/variable names are descriptive and consistent with project conventions
+- No unnecessary complexity (deep nesting, oversized functions)
+- No copy-paste duplication that should be abstracted
+- Error messages are informative for debugging
+
+## §5 Security (always active)
+
+Injection, auth/authz gaps, sensitive data exposure, insecure defaults.
+
+- User input is validated and sanitized before use in queries, HTML, or commands
+- Authentication and authorization checks are present on protected routes
+- Sensitive data (passwords, tokens, PII) is not logged or exposed in responses
+- Cryptographic operations use established libraries, not custom implementations
+
+## §6 Consistency (always active)
+
+Follows project patterns from `.prizm-docs/` PATTERNS and RULES sections.
+
+- Code style matches existing codebase conventions
+- Error handling follows established patterns
+- File organization follows project structure conventions
+- Naming conventions align with `.prizm-docs/` RULES
+
+## §7 Test Coverage (always active)
+
+Are critical paths tested?
+
+- Happy path tests exist for each goal
+- Error/edge case tests for critical paths
+- Tests are deterministic (no flaky timing dependencies)
+- Test names clearly describe what they verify
+
+## §8 Fix Correctness (conditional: spec.md has `## Root Cause`)
+
+The fix addresses the actual root cause, not just symptoms.
+
+- The root cause identified in spec.md is addressed
+- A regression test exists that would catch this issue if reintroduced
+- The fix does not change behavior for non-affected inputs
+- Related code paths are not inadvertently affected
+
+## §9 Change Scope (conditional: spec.md `## Scope` emphasizes minimal change)
+
+Only files directly related to the task are modified.
+
+- No "while I'm here" changes mixed with the primary task
+- If scope creep is detected, flag it — those changes belong in a separate commit
+- Structural improvement (refactoring) is measured against stated goals, not unbounded

package/bundled/skills/prizmkit-code-review/rules/fix-strategy.md

@@ -1,6 +1,6 @@
 # Fix Strategy Formulation
 
-For each finding from the Diagnostic Review (CRITICAL and HIGH mandatory; MEDIUM/LOW when actionable):
+For each finding from the Diagnostic Review, produce actionable Fix Instructions.
 
 ## Per-Finding Analysis
 
@@ -14,7 +14,7 @@ Search the codebase for all callers/dependents of the affected code. List concre
 Concrete step-by-step modification plan:
 - What to change, where, and in what order
 - Which project conventions to follow (reference `.prizm-docs/` RULES)
-- Dependencies between fixes (FIX-1 must be done before FIX-3)
+- Dependencies between fixes (Finding 1 must be done before Finding 3)
 
 ### 4. Code Guidance
 Show before/after code snippets for the key change. Keep minimal — enough to unambiguate the approach, not a full implementation.
@@ -27,21 +27,21 @@ How to confirm the fix works:
 
 ## Finding Grouping
 
-Group related findings that should be fixed together. If FIX-1 and FIX-3 share the same root cause or affect the same code path, mark them as a group with a shared fix strategy. This prevents Dev from fixing symptoms individually only to have the underlying cause persist.
+Group related findings that should be fixed together. If Finding 1 and Finding 3 share the same root cause or affect the same code path, mark them as a group with a shared fix strategy. This prevents fixing symptoms individually only to have the underlying cause persist.
 
-## Fix Priority Ordering
+## Fix Ordering
 
 Order Fix Instructions by:
-1. **Dependencies first** — if FIX-2 depends on FIX-1, FIX-1 comes first
-2. **CRITICAL before HIGH** — severity determines priority within independent fixes
-3. **Grouped fixes together** — related findings are adjacent
+1. **Dependencies first** — if Finding 2 depends on Finding 1, Finding 1 comes first
+2. **Grouped fixes together** — related findings are adjacent
 
 ## Finding Format
 
 ```
-#### FIX-N: [SEVERITY] Title
+### Finding N: Title
 - Location: file:line
 - Dimension: category
+- Problem: what is wrong and why it matters
 - Root Cause: explanation
 - Impact: affected callers/dependents with file:line locations
 - Fix Strategy:
@@ -55,7 +55,7 @@ Order Fix Instructions by:
 - Verification:
   - command to run
   - expected output
-- Related: FIX-X (if grouped)
-- Depends On: FIX-Y (if dependency)
-- Blocks: FIX-Z (if blocking)
+- Related: Finding X (if grouped)
+- Depends On: Finding Y (if dependency)
+- Blocks: Finding Z (if blocking)
 ```

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

@@ -16,8 +16,8 @@ description: "Pure git commit workflow with safety checks. Stages files, generat
 |---|---|---|
 | Uncommitted changes exist | `git status` shows modified/added/untracked files | Inform user "nothing to commit" and stop |
 | `.prizm-docs/` synced (feature/refactor) | `/prizmkit-retrospective` has run | Run `/prizmkit-retrospective` first |
-| Code review passed (pipeline mode) | `context-snapshot.md` has Review Notes with PASS/PASS_WITH_WARNINGS | Run `/prizmkit-code-review` first |
-| `DEPLOY.md` updated (if applicable) | If `/prizmkit-deploy` ran, `DEPLOY.md` is staged | Run `/prizmkit-deploy` or skip if no infrastructure changes |
+| Code review passed (pipeline mode) | `review-report.md` in artifact directory has `## Verdict: PASS` | Run `/prizmkit-code-review` first |
+| `.prizmkit/deploy.md` updated (if applicable) | If `/prizmkit-deploy` ran, `.prizmkit/deploy.md` is staged | Run `/prizmkit-deploy` or skip if no infrastructure changes |
 
 ### Workflow
 
@@ -31,7 +31,7 @@ git status
 - If there are changes: proceed
 
 #### Step 2: Generate Commit Message
-Analyze the staged diff and context (spec title, plan summary, review verdict) to generate a concise Conventional Commits message. The message should capture the *what* and *why* of the change.
+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.
@@ -62,34 +62,6 @@ git status
 ```
 - If "nothing to commit, working tree clean": commit verified successfully, proceed
 
-#### Step 5.5: Generate Session Summary (for cross-session recovery)
-
-After a successful commit, generate a lightweight handoff file for future sessions. Locate the artifact directory (`.prizmkit/specs/<feature-dir>/` for features, `.prizmkit/refactor/<slug>/` for refactors, `.prizmkit/bugfix/<id>/` for bugfixes) by checking which `plan.md` was used in this workflow.
-
-If an artifact directory with `plan.md` is found, write `session-summary.md` in that directory:
-
-```markdown
-# Session Summary
-## Completed Tasks
-<list task IDs and one-line descriptions from plan.md [x] items>
-
-## Files Changed
-<list from `git diff HEAD~1 --name-only` of the commit just made>
-
-## Key Decisions
-<1-3 bullet points of non-obvious design choices made this session, referencing DECISIONS in .prizm-docs/ if applicable>
-
-## Active TRAPS
-<any CRITICAL or HIGH TRAPS relevant to the changed files, copied from .prizm-docs/ L2>
-
-## Remaining Work
-<list unchecked [ ] task IDs from plan.md, or "None — feature complete" if all done>
-```
-
-Keep this file under 1.5KB. If no artifact directory with `plan.md` can be identified (e.g., ad-hoc commit), skip this step.
-
-**Lifecycle**: `session-summary.md` is a local cross-session artifact — do NOT commit it to git. It exists only on disk for the next session to read. Overwrite any existing `session-summary.md` from a previous session — this file reflects only the most recent commit's state. In pipeline mode, this file will remain as an untracked file after commit; the pipeline runner should ignore it (it is not a sign of incomplete work).
-
 #### Step 6: Optional Push
 Ask user: "Push to remote?"
 - Yes: `git push`