prizmkit 1.0.45 → 1.0.66

package/bundled/skills/bug-planner/scripts/validate-bug-list.py

@@ -0,0 +1,156 @@
+#!/usr/bin/env python3
+"""
+Validate bug-fix-list.json against the PrizmKit bug-fix-list schema.
+
+Usage:
+    python3 validate-bug-list.py [bug-fix-list.json] [--feature-list feature-list.json]
+
+Exit codes:
+    0 = valid
+    1 = validation errors found
+    2 = file not found or JSON parse error
+"""
+
+import json
+import sys
+import os
+import re
+
+VALID_SEVERITIES = {"critical", "high", "medium", "low"}
+VALID_SOURCE_TYPES = {"stack_trace", "user_report", "failed_test", "log_pattern", "monitoring_alert"}
+VALID_VERIFICATION_TYPES = {"automated", "manual", "hybrid"}
+VALID_STATUSES = {"pending", "in_progress", "fixed", "failed", "skipped", "needs_info"}
+BUG_ID_PATTERN = re.compile(r"^B-\d{3}$")
+
+
+def validate(bug_list_path, feature_list_path=None):
+    errors = []
+    warnings = []
+
+    # Load bug-fix-list.json
+    try:
+        with open(bug_list_path) as f:
+            data = json.load(f)
+    except FileNotFoundError:
+        print(f"ERROR: File not found: {bug_list_path}", file=sys.stderr)
+        return 2
+    except json.JSONDecodeError as e:
+        print(f"ERROR: Invalid JSON in {bug_list_path}: {e}", file=sys.stderr)
+        return 2
+
+    # Load feature-list.json (optional, for cross-reference)
+    feature_ids = set()
+    if feature_list_path:
+        try:
+            with open(feature_list_path) as f:
+                fl_data = json.load(f)
+            feature_ids = {f.get("id") for f in fl_data.get("features", [])}
+        except (FileNotFoundError, json.JSONDecodeError):
+            warnings.append(f"Could not load feature-list.json at {feature_list_path}")
+
+    # Top-level required fields
+    if "$schema" not in data:
+        errors.append("Missing required field: $schema")
+    elif data["$schema"] != "dev-pipeline-bug-fix-list-v1":
+        errors.append(f"Invalid $schema: expected 'dev-pipeline-bug-fix-list-v1', got '{data['$schema']}'")
+
+    if not data.get("project_name"):
+        errors.append("Missing or empty required field: project_name")
+
+    bugs = data.get("bugs", [])
+    if not bugs:
+        errors.append("Missing or empty required field: bugs")
+
+    # Per-bug validation
+    seen_ids = set()
+    seen_priorities = set()
+
+    for i, bug in enumerate(bugs):
+        prefix = f"bugs[{i}]"
+
+        # Required fields
+        bug_id = bug.get("id", "")
+        if not bug_id:
+            errors.append(f"{prefix}: missing required field 'id'")
+        elif not BUG_ID_PATTERN.match(bug_id):
+            errors.append(f"{prefix}: id '{bug_id}' does not match pattern B-NNN")
+
+        if bug_id in seen_ids:
+            errors.append(f"{prefix}: duplicate bug id '{bug_id}'")
+        seen_ids.add(bug_id)
+
+        if not bug.get("title"):
+            errors.append(f"{prefix} ({bug_id}): missing required field 'title'")
+
+        if not bug.get("description"):
+            errors.append(f"{prefix} ({bug_id}): missing required field 'description'")
+
+        severity = bug.get("severity", "")
+        if severity not in VALID_SEVERITIES:
+            errors.append(f"{prefix} ({bug_id}): invalid severity '{severity}' — must be one of {VALID_SEVERITIES}")
+
+        # error_source
+        error_source = bug.get("error_source", {})
+        source_type = error_source.get("type", "") if isinstance(error_source, dict) else ""
+        if source_type not in VALID_SOURCE_TYPES:
+            errors.append(f"{prefix} ({bug_id}): invalid error_source.type '{source_type}' — must be one of {VALID_SOURCE_TYPES}")
+
+        # verification_type
+        vtype = bug.get("verification_type", "")
+        if vtype not in VALID_VERIFICATION_TYPES:
+            errors.append(f"{prefix} ({bug_id}): invalid verification_type '{vtype}' — must be one of {VALID_VERIFICATION_TYPES}")
+
+        # acceptance_criteria
+        ac = bug.get("acceptance_criteria", [])
+        if not ac or not isinstance(ac, list):
+            errors.append(f"{prefix} ({bug_id}): missing or empty acceptance_criteria array")
+
+        # status
+        status = bug.get("status", "")
+        if status not in VALID_STATUSES:
+            errors.append(f"{prefix} ({bug_id}): invalid status '{status}' — must be one of {VALID_STATUSES}")
+
+        # Priority uniqueness
+        priority = bug.get("priority")
+        if priority is not None:
+            if priority in seen_priorities:
+                warnings.append(f"{prefix} ({bug_id}): duplicate priority {priority}")
+            seen_priorities.add(priority)
+
+        # Cross-reference affected_feature
+        affected_feature = bug.get("affected_feature")
+        if affected_feature and feature_ids and affected_feature not in feature_ids:
+            warnings.append(f"{prefix} ({bug_id}): affected_feature '{affected_feature}' not found in feature-list.json")
+
+    # Output results
+    if errors:
+        print(f"VALIDATION FAILED — {len(errors)} error(s), {len(warnings)} warning(s)\n")
+        for e in errors:
+            print(f"  ERROR: {e}")
+        for w in warnings:
+            print(f"  WARN:  {w}")
+        return 1
+    else:
+        bug_count = len(bugs)
+        severity_counts = {}
+        for b in bugs:
+            s = b.get("severity", "unknown")
+            severity_counts[s] = severity_counts.get(s, 0) + 1
+        sev_str = ", ".join(f"{k}={v}" for k, v in sorted(severity_counts.items()))
+        print(f"VALIDATION PASSED — {bug_count} bugs ({sev_str})")
+        if warnings:
+            for w in warnings:
+                print(f"  WARN:  {w}")
+        return 0
+
+
+if __name__ == "__main__":
+    bug_list = sys.argv[1] if len(sys.argv) > 1 else "bug-fix-list.json"
+    feature_list = None
+
+    if "--feature-list" in sys.argv:
+        idx = sys.argv.index("--feature-list")
+        if idx + 1 < len(sys.argv):
+            feature_list = sys.argv[idx + 1]
+
+    sys.exit(validate(bug_list, feature_list))

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

@@ -1,17 +1,15 @@
 ---
 name: "bugfix-pipeline-launcher"
-description: "Launch and manage the bugfix pipeline from within a cbc session. Start pipeline in background, monitor logs, check status, stop pipeline. Invoke when user wants to start fixing bugs, run the bugfix pipeline, or check bugfix progress. (project)"
+description: "Launch and manage the bugfix pipeline from within an AI CLI session. Start pipeline in background, monitor logs, check status, stop pipeline. Use this skill whenever the user wants to start fixing bugs, run the bugfix pipeline, check bugfix progress, or stop the bugfix pipeline. Trigger on: 'start fixing bugs', 'run bugfix pipeline', 'bugfix status', 'stop bug fix', '启动 bug 修复', '开始修复 bug', '修复进度', '停止修复'. (project)"
 ---
 
 # Bugfix-Pipeline Launcher
 
-Launch the autonomous bug fix pipeline from within a cbc conversation. The pipeline runs as a fully detached background process -- closing the cbc session does NOT stop the pipeline.
+Launch the autonomous bug fix pipeline from within an AI CLI conversation. The pipeline runs as a fully detached background process -- closing the AI CLI session does NOT stop the pipeline.
 
-### Mandatory Execution Mode (MUST)
+### Execution Mode
 
-- Always use daemon mode via `dev-pipeline/launch-bugfix-daemon.sh` for start/stop/status/log actions.
-- NEVER run `dev-pipeline/run-bugfix.sh run ...` directly from this skill.
-- Reason: foreground `run-bugfix.sh` can be terminated by AI CLI command timeout (e.g. cbc 120s), while daemon mode survives session timeout.
+Always use daemon mode via `dev-pipeline/launch-bugfix-daemon.sh` for start/stop/status/log actions. Foreground `run-bugfix.sh` can be terminated by AI CLI command timeout, while daemon mode survives session timeout — this prevents half-finished bug fixes that leave the codebase in an inconsistent state.
 
 ### When to Use
 
@@ -248,7 +246,7 @@ SESSION_TIMEOUT=3600 dev-pipeline/retry-bug.sh B-001 bug-fix-list.json
 ### Integration Notes
 
 - **After bug-planner**: This is the natural next step. When user finishes bug planning and has `bug-fix-list.json`, suggest launching the bugfix pipeline.
-- **Session independence**: The bugfix pipeline runs completely detached. User can close cbc, open a new session later, and use this skill to check progress or stop the pipeline.
+- **Session independence**: The bugfix pipeline runs completely detached. User can close the AI CLI, open a new session later, and use this skill to check progress or stop the pipeline.
 - **Single instance**: Only one bugfix pipeline can run at a time. The PID file prevents duplicates.
 - **Feature pipeline coexistence**: Bugfix and feature pipelines use separate state directories (`bugfix-state/` vs `state/`), so they can run simultaneously without conflict.
 - **State preservation**: Stopping and restarting the bugfix pipeline resumes from where it left off -- completed bugs are not re-fixed.

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

@@ -1,17 +1,15 @@
 ---
 name: "dev-pipeline-launcher"
-description: "Launch and manage the dev-pipeline from within an AI CLI session. Start pipeline in background, monitor logs, check status, stop pipeline. Invoke when user wants to start building features, run the pipeline, or check pipeline progress. (project)"
+description: "Launch and manage the dev-pipeline from within an AI CLI session. Start pipeline in background, monitor logs, check status, stop pipeline. Use this skill whenever the user wants to start building features, run the pipeline, check pipeline progress, retry features, or stop the pipeline. Trigger on: 'run pipeline', 'start pipeline', 'start building', 'pipeline status', 'stop pipeline', 'retry feature', '启动流水线', '开始实现', '流水线状态', '停止流水线'. (project)"
 ---
 
 # Dev-Pipeline Launcher
 
 Launch the autonomous development pipeline from within an AI CLI conversation. The pipeline runs as a fully detached background process -- closing the AI CLI session does NOT stop the pipeline.
 
-### Mandatory Execution Mode (MUST)
+### Execution Mode
 
-- Always use daemon mode via `dev-pipeline/launch-daemon.sh` for start/stop/status/log actions.
-- NEVER run `dev-pipeline/run.sh run ...` directly from this skill.
-- Reason: foreground `run.sh` can be terminated by AI CLI command timeout (e.g. cbc 120s, claude may vary), while daemon mode survives session timeout.
+Always use daemon mode via `dev-pipeline/launch-daemon.sh` for start/stop/status/log actions. Foreground `run.sh` can be terminated by AI CLI session timeout, while daemon mode survives session closure — this prevents half-finished features that leave the codebase in an inconsistent state.
 
 ### When to Use
 
@@ -284,4 +282,4 @@ Notes:
 - **Single instance**: Only one pipeline can run at a time. The PID file prevents duplicates.
 - **Pipeline coexistence**: Feature and bugfix pipelines use separate state directories (`state/` vs `bugfix-state/`), so they can run simultaneously without conflict.
 - **State preservation**: Stopping and restarting the pipeline resumes from where it left off -- completed features are not re-run.
-- **HANDOFF**: After pipeline completes all features, suggest running `prizmkit-code-review` for overall review, or `prizmkit-summarize` to archive.
+- **HANDOFF**: After pipeline completes all features, suggest running `prizmkit-retrospective` for project memory update, or ask user what's next.

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

@@ -1,7 +1,7 @@
 ---
 name: "feature-workflow"
 tier: companion
-description: "One-stop entry point for feature development. Orchestrates app-planner → dev-pipeline-launcher → background execution. Handles multi-feature batch development from a single request. (project)"
+description: "One-stop entry point for feature development. Orchestrates app-planner → dev-pipeline-launcher → background 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', '开发一个新应用', '构建系统', '一键完成', '批量实现'. (project)"
 ---
 
 # Feature Workflow
@@ -28,7 +28,7 @@ User says:
 ## Overview
 
 ```
-prizmkit.feature <需求描述>
+feature-workflow <需求描述>
    │
    ├── Phase 1: Plan → app-planner → feature-list.json
    │
@@ -58,48 +58,31 @@ With this skill, users can:
 
 ---
 
-## Commands
+## Input Modes
 
-### prizmkit.feature \<需求描述\>
+**Mode A: From natural language requirements** (default)
 
-One-stop feature development from natural language requirements.
-
-**INPUT**: Natural language description of the project or features. Can be:
+Natural language description of the project or features. Can be:
 - A project vision: "开发一个任务管理 App，支持用户登录、任务增删改查、任务分类"
 - A batch of features: "实现用户注册、登录、找回密码这三个功能"
 - An incremental request: "给现有系统追加用户头像上传和昵称修改功能"
 
-**FLOW**:
-1. Invoke `app-planner` with the description
-2. After feature-list.json is generated, invoke `dev-pipeline-launcher`
-3. Monitor and report progress
-
-### prizmkit.feature --from \<feature-list.json\>
-
-Skip planning, directly launch pipeline from existing feature-list.json.
-
-**USE WHEN**:
-- feature-list.json already exists
-- User wants to restart/resume pipeline execution
-
-**FLOW**:
-1. Skip `app-planner` (file already exists)
-2. Invoke `dev-pipeline-launcher` directly
-3. Monitor and report progress
+Flow: app-planner → dev-pipeline-launcher → monitor
 
-### prizmkit.feature \<需求描述\> --incremental
+**Mode B: From existing feature-list.json**
 
-Add new features to an existing project (incremental mode).
+When user says "run pipeline from existing file" or feature-list.json already exists:
+- Skip `app-planner` (file already exists)
+- Invoke `dev-pipeline-launcher` directly
+- Monitor and report progress
 
-**USE WHEN**:
-- Project already has features implemented
-- User wants to add new features to existing codebase
+**Mode C: Incremental (add to existing project)**
 
-**FLOW**:
-1. Invoke `app-planner` in incremental mode (reads existing feature-list.json)
-2. Append new features to existing list
-3. Invoke `dev-pipeline-launcher`
-4. Monitor and report progress
+When user says "add features to existing project" or the project already has features:
+- Invoke `app-planner` in incremental mode (reads existing feature-list.json)
+- Append new features to existing list
+- Invoke `dev-pipeline-launcher`
+- Monitor and report progress
 
 ---
 
@@ -248,18 +231,18 @@ While the pipeline runs in background, the user can continue the conversation:
 
 | Dimension | feature-workflow | bug-fix-workflow | refactor-workflow |
 |-----------|-----------------|------------------|-------------------|
-| **Purpose** | New features (batch) | Bug fixes (batch) | Code restructuring |
-| **Planning Skill** | `app-planner` | `bug-planner` | None (direct invocation) |
-| **Launcher Skill** | `dev-pipeline-launcher` | `bugfix-pipeline-launcher` | None (in-session) |
-| **Input** | Requirements description | Bug reports / logs | Module / code target |
-| **Output** | Multiple `feat()` commits | Multiple `fix()` commits | Single `refactor()` commit |
-| **Execution Mode** | Background daemon | Background daemon | In-session |
+| **Purpose** | New features (batch) | Single bug fix (interactive) | Code restructuring |
+| **Planning Skill** | `app-planner` | None (triage built-in) | None (analysis built-in) |
+| **Execution** | Background daemon | In-session, interactive | In-session |
+| **Input** | Requirements description | Bug report / stack trace | Module / code target |
+| **Output** | Multiple `feat()` commits | Single `fix()` commit | Single `refactor()` commit |
+| **Batch alternative** | (this is the batch flow) | `bug-planner` + `bugfix-pipeline-launcher` | N/A |
 
 ---
 
 ## Path References
 
-All internal asset paths MUST use `${SKILL_DIR}` placeholder for cross-IDE compatibility.
+All internal asset paths use `${SKILL_DIR}` placeholder for cross-IDE compatibility.
 
 ## Output
 
@@ -267,4 +250,4 @@ All internal asset paths MUST use `${SKILL_DIR}` placeholder for cross-IDE compa
 - Background pipeline running (Phase 2)
 - Progress updates (Phase 3)
 - Multiple git commits with `feat(<scope>):` prefix
-- Updated `REGISTRY.md` (via prizmkit.summarize per feature)
+- Updated `.prizm-docs/` (via prizmkit-retrospective per feature)

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

@@ -1,6 +1,6 @@
 ---
 name: "prizm-kit"
-description: "Full-lifecycle dev toolkit. Covers spec-driven development, Prizm context docs, code quality, debugging, deployment, and knowledge management. Use 'prizmkit.*' for help. (project)"
+description: "Full-lifecycle dev toolkit. Covers spec-driven development, Prizm context docs, code quality, debugging, deployment, and knowledge management. Use this skill whenever the user asks about PrizmKit workflow, wants to know which command to use, or needs help choosing between full workflow and fast path. Trigger on: '/prizmkit', 'prizmkit help', 'which prizmkit command', 'how do I start a feature'. (project)"
 ---
 
 # PrizmKit — Full-Lifecycle Development Toolkit
@@ -25,22 +25,47 @@ PrizmKit is a comprehensive, independent AI development toolkit that covers the
 - Architectural decisions
 - Data model or API changes
 
-**Use fast path (implement -> commit directly):**
+The full workflow generates spec, plan, and task artifacts that create a traceable record of what was built and why — this matters for future maintainability and AI context loading.
+
+**Use fast path (plan → implement → commit):**
 - Bug fixes with clear root cause
 - Single-file config or typo fixes
 - Simple refactors (rename, extract)
 - Documentation-only changes
 - Test additions for existing code
 
-For fast-path changes, you can directly use the implement command with inline task description, then the commit command.
-- CodeBuddy: `prizmkit.implement` → `prizmkit.commit`
-- Claude Code: `/prizmkit-implement` → `/prizmkit-committer`
+The fast path skips specify and analyze but still generates a simplified plan.md (with Tasks section) so that implement has a task list to follow.
+
+For fast-path changes, you can directly generate a simplified plan.md, then use implement and commit commands.
+
+## Workflow Example
+
+**Full workflow** for adding a user avatar upload feature:
+```
+/prizmkit-specify    → writes .prizmkit/specs/001-avatar-upload/spec.md
+/prizmkit-plan       → writes plan.md with tasks (architecture, data model, API, UI)
+/prizmkit-analyze    → checks spec↔plan consistency, finds gaps
+/prizmkit-implement  → executes tasks in order, marks [x] as done
+/prizmkit-code-review → reviews against spec, outputs PASS/NEEDS FIXES
+/prizmkit-retrospective → syncs .prizm-docs/ with code changes
+/prizmkit-committer  → commits feat(avatar): add upload
+```
+
+**Fast path** for fixing a null pointer bug:
+```
+/prizmkit-plan       → "fix null check in UserService.getAvatar()" (simplified plan.md)
+/prizmkit-implement  → executes tasks from plan.md
+/prizmkit-committer  → commits fix(user): handle null avatar gracefully
+```
+
+### Fast Path Commands
+ `/prizmkit-plan` → `/prizmkit-implement` → `/prizmkit-committer`
 
 ### Bug Fix Documentation Policy
 
 **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:
 
-- Do NOT run `prizmkit.summarize` for bug fix commits (no new REGISTRY.md entries)
+- 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:`
@@ -53,7 +78,7 @@ PrizmKit produces two complementary knowledge layers:
 
 ```
 .prizm-docs/           → Project "what is" (static: structure, interfaces, rules, traps, decisions)
-.prizmkit/specs/       → Feature "what to do" (workflow: spec → plan → tasks → code)
+.prizmkit/specs/       → Feature "what to do" (workflow: spec → plan → code(implement))
 ```
 
 ## Skill Inventory
@@ -61,18 +86,17 @@ PrizmKit produces two complementary knowledge layers:
 ### Foundation (3)
 - **prizm-kit** — Full-lifecycle dev toolkit entry point
 - **prizmkit-init** — Project takeover: scan → assess → generate docs → initialize
-- **prizmkit-prizm-docs** — Prizm documentation framework: `prizmkit.doc.init`, `prizmkit.doc.update`, `prizmkit.doc.status`, `prizmkit.doc.rebuild`, `prizmkit.doc.validate`, `prizmkit.doc.migrate`
+- **prizmkit-prizm-docs** — Prizm documentation framework with 6 operations: init, update, status, rebuild, validate, migrate
 
-### Spec-Driven Workflow (9)
+### Spec-Driven Workflow (8)
 - **prizmkit-specify** — Create structured feature specifications from natural language
 - **prizmkit-clarify** — Interactive requirement clarification
 - **prizmkit-plan** — Generate technical plan with data model, API contracts, and executable task breakdown (all in one plan.md)
 - **prizmkit-analyze** — Cross-document consistency analysis (spec ↔ plan ↔ tasks)
 - **prizmkit-implement** — Execute tasks following TDD approach
 - **prizmkit-code-review** — Review code against spec and plan
-- **prizmkit-summarize** — Archive completed features to REGISTRY.md
-- **prizmkit-committer** — Commit workflow with automatic Prizm doc update
-- **prizmkit-retrospective** — Post-feature learning: extract lessons → update Prizm docs
+- **prizmkit-retrospective** — Sole .prizm-docs/ maintainer: structural sync + knowledge injection (TRAPS/RULES/DECISIONS)
+- **prizmkit-committer** — Pure git commit: diff analysis, safety checks, Conventional Commits
 
 ### Quality Assurance (5)
 - **prizmkit-tool-tech-debt-tracker** — [Tier 1] Technical debt identification and tracking via code pattern analysis
@@ -96,13 +120,29 @@ PrizmKit produces two complementary knowledge layers:
 - **prizmkit-tool-onboarding-generator** — [Tier 2] Generate developer onboarding guides
 - **prizmkit-tool-api-doc-generator** — [Tier 2] Extract API documentation from source code
 
-### Pipeline & Companion (6)
-- **feature-workflow** — [Tier 1] End-to-end feature workflow: specify → plan → analyze → implement → review → commit
-- **refactor-workflow** — [Tier 1] End-to-end refactor workflow: analyze → plan → implement → review → commit
+### Pipeline & Companion (7)
+- **feature-workflow** — One-stop feature development: plan → launch pipeline → monitor
+- **refactor-workflow** — End-to-end refactor: analyze → plan → implement → review → commit
 - **app-planner** — Interactive app planning that produces feature-list.json for dev-pipeline
 - **bug-planner** — Interactive bug planning that produces bug-fix-list.json for bugfix-pipeline
-- **dev-pipeline-launcher** — Launch and manage the dev-pipeline from within a CLI session
-- **bugfix-pipeline-launcher** — Launch and manage the bugfix pipeline from within a CLI session
+- **bug-fix-workflow** — Interactive single-bug fix in current session (triage → reproduce → fix → review → commit)
+- **dev-pipeline-launcher** — Launch and manage the feature dev-pipeline (background daemon)
+- **bugfix-pipeline-launcher** — Launch and manage the bugfix pipeline (background daemon)
+
+### Scenario Decision Tree
+
+Not sure which skill to use? Follow this:
+
+| I want to... | Use this |
+|---|---|
+| Build a new app or batch of features from scratch | `feature-workflow` (one-stop) |
+| Plan features first, then decide when to build | `app-planner` → `dev-pipeline-launcher` |
+| Launch pipeline for an existing feature-list.json | `dev-pipeline-launcher` |
+| Fix multiple bugs in batch | `bug-planner` → `bugfix-pipeline-launcher` |
+| Fix one specific bug right now, interactively | `bug-fix-workflow` |
+| Refactor/restructure code without changing behavior | `refactor-workflow` |
+| Add a single small feature (spec → plan → implement) | `/prizmkit-specify` → `/prizmkit-plan` → `/prizmkit-implement` |
+| Quick bug fix or config change | Fast path: `/prizmkit-plan` → `/prizmkit-implement` → `/prizmkit-committer` |
 
 ### Tier Definitions
 
@@ -128,10 +168,8 @@ python3 ${SKILL_DIR}/scripts/install-prizmkit.py --target <project-skills-dir>
 
 ## Hook / Rules Configuration
 
-**CodeBuddy:** Uses native `type: prompt` hooks for automatic doc updates before commits.
-The hook is configured automatically by `prizmkit-init`. See `assets/hooks/prizm-commit-hook.json`.
-
-**Claude Code:** Uses `.claude/rules/` glob-scoped markdown files for automatic enforcement.
-Rules are created automatically by `prizmkit-init` (or `/prizmkit-init`). See:
-- `assets/claude-md-template.md` for the project memory template
+Both CodeBuddy and Claude Code use unified commands for automatic doc updates and commit enforcement.
+Hooks and rules are configured automatically by `prizmkit-init`. See:
+- `core/templates/hooks/commit-intent.json` for the commit hook template
+- `assets/project-memory-template.md` for the project memory template
 - The init skill creates `prizm-documentation.md` and `prizm-commit-workflow.md` rules

package/bundled/skills/prizm-kit/assets/{claude-md-template.md → project-memory-template.md}

@@ -10,8 +10,8 @@ This project uses PrizmKit with the Prizm documentation system for AI-optimized
 
 ### Auto-Update Protocol
 - BEFORE EVERY COMMIT: Update affected `.prizm-docs/` files
-- The `.claude/rules/` files will enforce this automatically
-- Use `/prizmkit-committer` command for the complete commit workflow
+- Platform hooks (rules or UserPromptSubmit) will remind you automatically
+- Use `/prizmkit-committer` for the complete commit workflow
 
 ### Doc Format Rules
 - All `.prizm` files use KEY: value format, not prose
@@ -32,7 +32,7 @@ Run `/prizm-kit` to see all available PrizmKit commands.
 Not every change needs the full spec -> plan workflow. Use fast path for:
 - Bug fixes with clear root cause, config tweaks, typo fixes, simple refactors
 - Documentation-only changes, test additions for existing code
-- Directly use `/prizmkit-implement` with inline task description, then `/prizmkit-committer`
+- Fast path: `/prizmkit-plan` (simplified) → `/prizmkit-implement` → `/prizmkit-committer`
 
 Use the full workflow (/prizmkit-specify -> /prizmkit-plan -> /prizmkit-analyze -> /prizmkit-implement) for:
 - New features, multi-file coordinated changes, architectural decisions, data model or API changes

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

@@ -1,30 +1,24 @@
 ---
 name: "prizmkit-analyze"
-description: "Cross-document consistency analysis for spec.md, plan.md, and tasks.md. Detects duplications, ambiguities, gaps, and rule conflicts. Read-only. (project)"
+description: "Cross-document consistency analysis for spec.md and plan.md (including Tasks section). Detects duplications, ambiguities, gaps, and rule conflicts. Read-only. Use this skill to check if spec and plan are aligned, validate documents before coding, or as a quality gate after planning. Trigger on: 'analyze', 'check consistency', 'validate spec', 'review plan', 'is the spec ready', 'check if spec and plan are aligned', 'validate documents before coding'. (project)"
 ---
 
 # PrizmKit Analyze
 
-Perform a non-destructive cross-artifact consistency and quality analysis across spec.md, plan.md, and tasks.md before implementation. Identifies duplications, ambiguities, underspecified items, rule conflicts, and coverage gaps.
+Perform a non-destructive cross-artifact consistency and quality analysis across spec.md and plan.md (including Tasks section) before implementation. Identifies duplications, ambiguities, underspecified items, rule conflicts, and coverage gaps.
 
 ### When to Use
-- After `prizmkit.plan` to validate spec-plan-tasks alignment before implementation
+- After `/prizmkit-plan` to validate spec-plan-tasks alignment before implementation
 - User says "analyze", "check consistency", "validate spec", "review plan"
-- Before `prizmkit.implement` as a quality gate
-
-## Commands
-
-### prizmkit.analyze
-
-Cross-document consistency analysis.
+- Before `/prizmkit-implement` as a quality gate
 
 **PRECONDITION:** `spec.md` and `plan.md` exist in `.prizmkit/specs/###-feature-name/`. `plan.md` must include a Tasks section.
 
 ## Operating Constraints
 
-**STRICTLY READ-ONLY**: Do **not** modify any files. Output a structured analysis report to conversation only. Offer an optional remediation plan (user must explicitly approve before any edits).
+**Read-only analysis**: Do not modify any files. The analysis output goes to conversation only, with an optional remediation plan the user must explicitly approve. This separation matters because the user needs to understand what's wrong before deciding what to change — auto-fixing consistency issues often introduces new ones.
 
-**Prizm Rules Authority**: The project rules in `.prizm-docs/root.prizm` RULES section are **non-negotiable** within this analysis scope. Rule conflicts are automatically CRITICAL severity and require adjustment of the spec, plan, or tasks — not dilution or silent ignoring of the rule. If a rule itself needs to change, that must occur via a separate `prizmkit.doc.update`.
+**Prizm Rules take precedence**: The project rules in `.prizm-docs/root.prizm` RULES section are the source of truth. If a spec or plan element conflicts with a MUST/NEVER directive, the spec/plan needs to change, not the rule. This prevents well-intentioned features from silently violating project-wide constraints. If a rule itself is wrong, that's a separate conversation via prizmkit-prizm-docs (Update operation).
 
 ## Execution Steps
 
@@ -34,10 +28,9 @@ Locate the current feature directory in `.prizmkit/specs/###-feature-name/` by c
 
 Derive absolute paths:
 - SPEC = `.prizmkit/specs/###-feature-name/spec.md`
-- PLAN = `.prizmkit/specs/###-feature-name/plan.md`
-- TASKS = `.prizmkit/specs/###-feature-name/tasks.md` (optional)
+- PLAN = `.prizmkit/specs/###-feature-name/plan.md` (must include a Tasks section)
 
-Abort with an error message if spec.md or plan.md is missing — instruct the user to run the missing prerequisite command (`prizmkit.specify` or `prizmkit.plan`).
+Abort with an error message if spec.md or plan.md is missing — instruct the user to run the missing prerequisite command (`/prizmkit-specify` or `/prizmkit-plan`).
 
 ### Step 2: Load Artifacts (Progressive Disclosure)
 
@@ -152,13 +145,13 @@ Output a Markdown report (**no file writes**) with the following structure:
 
 At end of report, output a concise Next Actions block:
 
-- If CRITICAL issues exist: **Recommend resolving before `prizmkit.implement`**
+- If CRITICAL issues exist: **Recommend resolving before `/prizmkit-implement`**
 - If only LOW/MEDIUM: User may proceed, but provide improvement suggestions
 - Provide explicit command suggestions:
-  - "Run `prizmkit.specify` to refine requirements"
-  - "Run `prizmkit.plan` to adjust architecture or tasks"
-  - "Edit tasks.md to add coverage for requirement X"
-  - "Proceed to `prizmkit.implement`" (if clean)
+  - "Run `/prizmkit-specify` to refine requirements"
+  - "Run `/prizmkit-plan` to adjust architecture or tasks"
+  - "Edit plan.md Tasks section to add coverage for requirement X"
+  - "Proceed to `/prizmkit-implement`" (if clean)
 
 ### Step 8: Offer Remediation
 
@@ -167,19 +160,37 @@ Ask the user: "Would you like me to suggest concrete remediation edits for the t
 ## Operating Principles
 
 ### Context Efficiency
-- **Minimal high-signal tokens**: Focus on actionable findings, not exhaustive documentation
-- **Progressive disclosure**: Load artifacts incrementally; don't dump all content into analysis
-- **Token-efficient output**: Limit findings table to 50 rows; summarize overflow
-- **Deterministic results**: Rerunning without changes should produce consistent IDs and counts
-
-### Analysis Guidelines
-- **NEVER modify files** (this is read-only analysis)
-- **NEVER hallucinate missing sections** (if absent, report them accurately)
-- **Prioritize Prizm Rules violations** (these are always CRITICAL)
-- **Use examples over exhaustive rules** (cite specific instances, not generic patterns)
-- **Report zero issues gracefully** (emit success report with coverage statistics)
-
-**HANDOFF:** `prizmkit.implement` (if clean) or `prizmkit.specify` / `prizmkit.plan` (if issues found)
+- Focus on actionable findings, not exhaustive documentation — the goal is to surface problems, not prove you read everything
+- Load artifacts incrementally; reading all content upfront wastes tokens on sections irrelevant to the feature
+- Cap findings at 50 rows to keep the report scannable; summarize overflow with counts
+- Rerunning without changes should produce consistent IDs and counts (deterministic)
+
+### Analysis Approach
+- Do not modify files — read-only analysis ensures artifacts remain stable for the implement phase
+- If a section is absent, report it accurately rather than guessing what it might contain
+- Prizm Rules violations are always CRITICAL — they represent project-wide constraints that outrank individual feature decisions
+- Cite specific instances rather than generic patterns — "spec §2.1 says REST but plan §Architecture says GraphQL" is more useful than "terminology inconsistency found"
+- If zero issues found, report success with coverage statistics — a clean report is valuable confirmation
+
+## Example Finding
+
+```
+| ID | Category | Severity | Location(s) | Summary | Recommendation |
+|----|----------|----------|-------------|---------|----------------|
+| D1 | Rules Alignment | CRITICAL | plan.md §Architecture | Plan specifies SQLite but root.prizm RULES has "MUST: use PostgreSQL for all persistent storage" | Change plan to use PostgreSQL or request rule amendment via prizmkit-prizm-docs |
+| E1 | Coverage Gap | HIGH | spec.md §FR-3 | "User can export reports as PDF" has no corresponding task in plan.md Tasks section | Add export task to Phase 3 of plan.md |
+```
+
+**HANDOFF:** `/prizmkit-implement` (if clean) or `/prizmkit-specify` / `/prizmkit-plan` (if issues found)
+
+## Loop Protection
+
+In unattended pipeline mode, the analyze→fix→analyze cycle can loop indefinitely if issues keep reappearing. To prevent this:
+
+- Track an `analyze_iteration` counter starting at 1. Each re-run of this skill after remediation increments the counter.
+- **max_iterations = 5**: If `analyze_iteration >= 5`, you MUST proceed to `/prizmkit-implement` regardless of remaining findings. Log a warning: "Loop protection triggered — proceeding to implement with N unresolved findings (iterations: 5/5)."
+- Unresolved findings from the final iteration should be noted in the handoff so that `/prizmkit-code-review` can catch them downstream.
+- This guard exists because some findings oscillate (fixing one re-introduces another) and blocking forever is worse than proceeding with known issues.
 
 ## Output