prizmkit 1.1.7 → 1.1.9

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

@@ -1,7 +1,6 @@
 ---
 name: "refactor-workflow"
-tier: companion
-description: "One-stop entry point for code refactoring. Brainstorms refactoring goals with the user until fully clarified, then orchestrates refactor-planner → refactor-pipeline-launcher → execution. Handles multi-refactor batch development from a single request. Use this skill whenever the user wants to restructure, clean up, or optimize code without changing behavior. Trigger on: 'refactor', 'clean up code', 'restructure', 'optimize code structure', 'extract module', 'code refactoring', 'batch refactor'. (project)"
+description: "One-stop entry point for code refactoring. Brainstorms refactoring goals with the user until fully clarified, then orchestrates refactor-planner → refactor-pipeline-launcher → execution. Handles multi-refactor batch development from a single request. Use this skill whenever the user wants to restructure, clean up, or optimize code without changing behavior. Trigger on: 'refactor', 'clean up code', 'restructure', 'optimize code structure', 'extract module', 'code refactoring', 'batch refactor'."
 ---
 
 # Refactor Workflow
@@ -19,7 +18,7 @@ User says:
 
 **Do NOT use this skill when:**
 - User only wants to plan refactoring (use `refactor-planner` directly)
-- User only wants to launch pipeline for existing refactor-list.json (use `refactor-pipeline-launcher`)
+- User only wants to launch pipeline for existing .prizmkit/plans/refactor-list.json (use `refactor-pipeline-launcher`)
 - User wants to add features (use `feature-workflow`)
 - User wants to fix bugs (use `bug-planner` + `bugfix-pipeline-launcher`)
 
@@ -32,7 +31,7 @@ refactor-workflow <target / goals>
    │
    ├── Phase 1: Brainstorm → interactive Q&A until refactoring goals are clear
    │
-   ├── Phase 2: Plan → refactor-planner → refactor-list.json
+   ├── Phase 2: Plan → refactor-planner → .prizmkit/plans/refactor-list.json
    │
    ├── Phase 3: Launch → refactor-pipeline-launcher → pipeline execution
    │
@@ -44,7 +43,7 @@ refactor-workflow <target / goals>
 | Phase | Action | Result |
 |-------|--------|--------|
 | 1 | **Brainstorm** — interactive Q&A with user | Fully clarified refactoring goals |
-| 2 | Call `refactor-planner` with clarified goals | `refactor-list.json` with N refactor items |
+| 2 | Call `refactor-planner` with clarified goals | `.prizmkit/plans/refactor-list.json` with N refactor items |
 | 3 | Call `refactor-pipeline-launcher` | Pipeline started (execution mode chosen by user via launcher) |
 | 4 | Monitor progress | Status updates, completion report |
 
@@ -52,7 +51,7 @@ refactor-workflow <target / goals>
 
 Without this skill, users must:
 1. Figure out all refactoring goals and scope themselves
-2. Invoke `refactor-planner` → wait for refactor-list.json
+2. Invoke `refactor-planner` → wait for .prizmkit/plans/refactor-list.json
 3. Invoke `refactor-pipeline-launcher` → wait for pipeline start
 4. Manually check progress
 
@@ -81,18 +80,18 @@ Natural language description of the refactoring goals. Can be:
 
 Flow: brainstorm → refactor-planner → refactor-pipeline-launcher → monitor
 
-**Mode B: From existing refactor-list.json**
+**Mode B: From existing .prizmkit/plans/refactor-list.json**
 
-When user says "run pipeline from existing file" or refactor-list.json already exists:
+When user says "run pipeline from existing file" or .prizmkit/plans/refactor-list.json already exists:
 - Skip brainstorm and `refactor-planner` (file already exists)
 - Invoke `refactor-pipeline-launcher` directly
 - Monitor and report progress
 
 **Mode C: Incremental (add to existing refactor plan)**
 
-When user says "add more refactors" or the project already has a refactor-list.json:
+When user says "add more refactors" or the project already has a .prizmkit/plans/refactor-list.json:
 - Brainstorm new refactoring goals with the user
-- Invoke `refactor-planner` in incremental mode (reads existing refactor-list.json)
+- Invoke `refactor-planner` in incremental mode (reads existing .prizmkit/plans/refactor-list.json)
 - Append new refactor items to existing list
 - Invoke `refactor-pipeline-launcher`
 - Monitor and report progress
@@ -227,7 +226,7 @@ Present this summary to the user and get explicit confirmation before proceeding
 
 ## Phase 2: Plan
 
-**Goal**: Generate structured refactor-list.json from the clarified refactoring goals.
+**Goal**: Generate structured .prizmkit/plans/refactor-list.json from the clarified refactoring goals.
 
 **STEPS**:
 
@@ -236,17 +235,17 @@ Present this summary to the user and get explicit confirmation before proceeding
    - For new refactoring: standard planning mode
    - For existing projects with `--incremental`: incremental planning mode
    - **Input**: Markdown goals summary (refactor targets, scope, behavior preservation strategy)
-   - **Output**: `refactor-list.json` (schema: `dev-pipeline-refactor-list-v1`) containing `project_name`, `refactors[]` with id (R-NNN), title, description, scope, type, priority, complexity, behavior_preservation, acceptance_criteria, dependencies, status
+   - **Output**: `.prizmkit/plans/refactor-list.json` (schema: `dev-pipeline-refactor-list-v1`) containing `project_name`, `refactors[]` with id (R-NNN), title, description, scope, type, priority, complexity, behavior_preservation, acceptance_criteria, dependencies, status
 
 2. **Interactive planning** (if refactor-planner requires clarification):
    - Because Phase 1 was thorough, refactor-planner should need minimal clarification
    - If questions arise, answer from the Phase 1 context or pass through to user
 
 3. **Validate output**:
-   - Confirm `refactor-list.json` exists
+   - Confirm `.prizmkit/plans/refactor-list.json` exists
    - Show summary: total refactor items, complexity distribution, dependencies
 
-**CHECKPOINT CP-RW-1**: `refactor-list.json` generated and validated.
+**CHECKPOINT CP-RW-1**: `.prizmkit/plans/refactor-list.json` generated and validated.
 
 **If user says `--from <file>`**: Skip Phase 1 and Phase 2 entirely.
 
@@ -269,7 +268,7 @@ Present this summary to the user and get explicit confirmation before proceeding
    ```
 
 2. **Invoke `refactor-pipeline-launcher` skill**:
-   - **Input**: Path to validated `refactor-list.json`
+   - **Input**: Path to validated `.prizmkit/plans/refactor-list.json`
    - The launcher handles all prerequisites checks
    - The launcher presents execution mode choices to the user (foreground/background/manual)
    - Do NOT duplicate execution mode selection here — let the launcher handle it
@@ -303,8 +302,8 @@ Present this summary to the user and get explicit confirmation before proceeding
 3. **Periodic progress reports** (when user asks):
    ```bash
    python3 dev-pipeline/scripts/update-refactor-status.py \
-     --refactor-list refactor-list.json \
-     --state-dir dev-pipeline/refactor-state \
+     --refactor-list .prizmkit/plans/refactor-list.json \
+     --state-dir .prizmkit/state/refactor \
      --action status
    ```
 
@@ -333,12 +332,12 @@ The workflow supports resuming by detecting existing state:
 
 | State Found | Resume From |
 |-------------|------------|
-| No `refactor-list.json` | Phase 1: Brainstorm |
-| `refactor-list.json` exists, no pipeline state | Phase 3: Launch |
-| `refactor-list.json` + pipeline state exists | Phase 4: Monitor (check status) |
+| No `.prizmkit/plans/refactor-list.json` | Phase 1: Brainstorm |
+| `.prizmkit/plans/refactor-list.json` exists, no pipeline state | Phase 3: Launch |
+| `.prizmkit/plans/refactor-list.json` + pipeline state exists | Phase 4: Monitor (check status) |
 | All refactors completed | Report completion, suggest next steps |
 
-**Resume**: If `refactor-list.json` exists, ask user: "Existing refactor plan found with N items. Resume pipeline or re-plan?"
+**Resume**: If `.prizmkit/plans/refactor-list.json` exists, ask user: "Existing refactor plan found with N items. Resume pipeline or re-plan?"
 
 ---
 
@@ -363,7 +362,7 @@ While the pipeline runs, the user can continue the conversation:
 | Brainstorming stalls | Offer concrete options: "Would you prefer incremental or comprehensive refactoring?" |
 | No tests exist for target module | WARN user, recommend writing tests first before refactoring |
 | `refactor-planner` cannot parse goals | Refine the goals summary and retry |
-| `refactor-list.json` generation failed | Show error, retry with refined input |
+| `.prizmkit/plans/refactor-list.json` generation failed | Show error, retry with refined input |
 | Pipeline launch failed | Show daemon log, suggest manual start |
 | All refactor items blocked/failed | Show status, suggest retrying specific items |
 | User wants to cancel mid-brainstorming | Save conversation context, offer to resume later |
@@ -375,7 +374,7 @@ While the pipeline runs, the user can continue the conversation:
 
 | Skill | Relationship |
 |-------|-------------|
-| `refactor-planner` | **Called by Phase 2** — generates refactor-list.json from clarified goals |
+| `refactor-planner` | **Called by Phase 2** — generates .prizmkit/plans/refactor-list.json from clarified goals |
 | `refactor-pipeline-launcher` | **Called by Phase 3** — starts pipeline (handles execution mode selection) |
 | `feature-workflow` | **Alternative** — for new feature development |
 | `bug-fix-workflow` | **Alternative** — for bug fix workflows |
@@ -401,7 +400,7 @@ While the pipeline runs, the user can continue the conversation:
 ## Output
 
 - Structured refactoring goals summary (Phase 1 artifact)
-- `refactor-list.json` (Phase 2 artifact)
+- `.prizmkit/plans/refactor-list.json` (Phase 2 artifact)
 - Pipeline execution (Phase 3)
 - Progress updates (Phase 4)
 - Multiple git commits with `refactor(<scope>):` prefix

package/bundled/team/prizm-dev-team.json

@@ -20,7 +20,7 @@
       "name": "reviewer",
       "role": "reviewer",
       "agentDefinition": "prizm-dev-team-reviewer",
-      "prompt": "You are the Reviewer Agent of the prizm-dev-team. In Phase 4: run /prizmkit-analyze for cross-document consistency. In Phase 6: run /prizmkit-code-review for diagnosis + fix strategy formulation, write and execute integration tests. Produce structured Fix Instructions (Root Cause, Impact, Fix Strategy, Code Guidance, Verification) so Dev can follow them precisely. Write Fix Instructions to context-snapshot.md '## Review Notes' section.",
+      "prompt": "You are the Reviewer Agent of the prizm-dev-team. Run /prizmkit-code-review for diagnosis + fix strategy formulation, write and execute integration tests. Produce structured Fix Instructions (Root Cause, Impact, Fix Strategy, Code Guidance, Verification) so Dev can follow them precisely. review-report.md is written to the artifact directory by /prizmkit-code-review.",
       "subscriptions": ["*"]
     },
     {

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

@@ -37,6 +37,6 @@ Not every change needs the full spec -> plan workflow. Use fast path for:
 - Documentation-only changes, test additions for existing code
 - Fast path: `/prizmkit-plan` (simplified) → `/prizmkit-implement` → `/prizmkit-committer`
 
-Use the full workflow (/prizmkit-plan -> /prizmkit-analyze -> /prizmkit-implement) for:
+Use the full workflow (/prizmkit-plan -> /prizmkit-implement) for:
 - New features, multi-file coordinated changes, architectural decisions, data model or API changes
 <!-- PRIZMKIT:END -->

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "prizmkit",
-  "version": "1.1.7",
+  "version": "1.1.9",
   "description": "Create a new PrizmKit-powered project with clean initialization — no framework dev files, just what you need.",
   "type": "module",
   "bin": {

package/src/clean.js

@@ -119,10 +119,9 @@ export async function runClean(directory, options = {}) {
     '.prizm-docs',        // AI-generated project context docs
     'CODEBUDDY.md',
     'CLAUDE.md',
-    'feature-list.json',          // feature-planner output
-    'bug-fix-list.json',          // bug-planner output
-    'project-brief.md',           // feature-planner project brief
-    'project-conventions.json',   // feature-planner coding conventions
+    path.join('.prizmkit', 'plans', 'feature-list.json'),          // feature-planner output
+    path.join('.prizmkit', 'plans', 'bug-fix-list.json'),          // bug-planner output
+    path.join('.prizmkit', 'plans', 'project-brief.md'),           // feature-planner project brief
     path.join('.codebuddy', 'settings.json'),
     path.join('.claude', 'settings.json'),
     path.join('.claude', 'team-info.json'),

package/src/gitignore-template.js

@@ -14,8 +14,8 @@ export function generateGitignore(options = {}) {
     '# PrizmKit Runtime Artifacts',
     '# ===========================',
     '',
-    '# PrizmKit 运行时配置与产物',
-    '.prizmkit/',
+    '# PrizmKit 运行时状态（不提交）',
+    '.prizmkit/state/',
     '',
     '# 多 Agent 协作临时工作区',
     '.dev-team/',
@@ -24,18 +24,16 @@ export function generateGitignore(options = {}) {
     '# .prizm-docs/',
     '',
     '# 规划产物（按需决定是否提交）',
-    '# feature-list.json',
-    '# bug-fix-list.json',
-    '# project-brief.md',
-    '# project-conventions.json',
+    '# .prizmkit/plans/',
     '',
   ];
 
   if (options.pipeline) {
     lines.push(
-      '# Dev-Pipeline 运行时状态',
-      'dev-pipeline/state/',
-      'dev-pipeline/bugfix-state/',
+      '# Dev-Pipeline 运行时状态（已迁移到 .prizmkit/state/）',
+      '.prizmkit/state/features/',
+      '.prizmkit/state/bugfix/',
+      '.prizmkit/state/refactor/',
       'dev-pipeline/logs/',
       'dev-pipeline/*.pid',
       '',

package/src/scaffold.js

@@ -537,11 +537,9 @@ export async function installProjectMemory(platform, projectRoot, dryRun) {
   const targetName = platform === 'claude' ? 'CLAUDE.md' : 'CODEBUDDY.md';
   const targetPath = path.join(projectRoot, targetName);
 
-  // Prefer core/templates, fallback to prizm-kit/assets in hierarchical or flat skills layouts.
+  // Template lives in core/templates/ (bundled as templates/).
   const templateCandidates = [
     path.join(templatesDir, templateName),
-    path.join(skillsDir, 'prizmkit-skill', 'prizm-kit', 'assets', templateName),
-    path.join(skillsDir, 'prizm-kit', 'assets', templateName),
   ];
   const templatePath = templateCandidates.find(candidate => fs.pathExistsSync(candidate));
 
@@ -647,8 +645,10 @@ export async function installPipeline(projectRoot, dryRun, { forceOverwrite = fa
     return [];
   }
 
-  await fs.ensureDir(path.join(pipelineTarget, 'state'));
-  await fs.ensureDir(path.join(pipelineTarget, 'bugfix-state'));
+  await fs.ensureDir(path.join(projectRoot, '.prizmkit', 'plans'));
+  await fs.ensureDir(path.join(projectRoot, '.prizmkit', 'state', 'features'));
+  await fs.ensureDir(path.join(projectRoot, '.prizmkit', 'state', 'bugfix'));
+  await fs.ensureDir(path.join(projectRoot, '.prizmkit', 'state', 'refactor'));
 
   // 动态扫描 bundled dev-pipeline 目录，排除不应安装到用户项目的内容
   const EXCLUDE = new Set(['tests', 'docs', '__pycache__', 'node_modules', '.DS_Store']);
@@ -688,6 +688,15 @@ export async function installPipeline(projectRoot, dryRun, { forceOverwrite = fa
   }
 
   console.log(chalk.green(`      ✓ dev-pipeline/ (${installedCount} 项)`));
+
+  // Copy .env.example to project root if it exists in pipeline source
+  const envExampleSrc = path.join(pipelineSource, '.env.example');
+  const envExampleTgt = path.join(projectRoot, '.env.example');
+  if (await fs.pathExists(envExampleSrc) && !await fs.pathExists(envExampleTgt)) {
+    await fs.copy(envExampleSrc, envExampleTgt);
+    console.log(chalk.green(`      ✓ .env.example (pipeline environment configuration)`));
+  }
+
   return installedFiles;
 }
 

package/bundled/dev-pipeline/templates/agent-prompts/reviewer-analyze.md

@@ -1,5 +0,0 @@
-"Read {{REVIEWER_SUBAGENT_PATH}}. For feature {{FEATURE_ID}} (slug: {{FEATURE_SLUG}}):
-1. Read `.prizmkit/specs/{{FEATURE_SLUG}}/context-snapshot.md` FIRST — Section 3 has project context, Section 4 has file manifest.
-2. Run prizmkit-analyze: cross-check `spec.md` and `plan.md` (including Tasks section) for consistency.
-3. Before flagging CRITICAL or HIGH issues, read the relevant source files listed in the File Manifest to verify.
-Report: CRITICAL, HIGH, MEDIUM issues found (or 'No issues found')."

package/bundled/dev-pipeline/templates/sections/phase-analyze-agent.md

@@ -1,19 +0,0 @@
-### Analyze — Reviewer Subagent
-
-**Spawn Agent**:
-| Parameter | Value |
-|-----------|-------|
-| subagent_type | prizm-dev-team-reviewer |
-| mode | plan |
-| run_in_background | false |
-
-**Prompt**:
-> {{AGENT_PROMPT_REVIEWER_ANALYZE}}
-
-Wait for Reviewer to return.
-- If CRITICAL issues found: fix them yourself — read `.prizmkit/specs/{{FEATURE_SLUG}}/context-snapshot.md` for full project context. Fix ONLY the listed CRITICAL issues in plan.md. Then re-run analyze (max 1 round).
-
-**CP-2**: No CRITICAL issues.
-
-
-**Checkpoint update**: Update `workflow-checkpoint.json` — set step `prizmkit-analyze` to `"completed"`.

package/bundled/dev-pipeline/templates/sections/phase-analyze-full.md

@@ -1,19 +0,0 @@
-### Analyze — Reviewer Agent
-
-**Spawn Agent**:
-| Parameter | Value |
-|-----------|-------|
-| subagent_type | prizm-dev-team-reviewer |
-| mode | plan |
-| run_in_background | false |
-
-**Prompt**:
-> {{AGENT_PROMPT_REVIEWER_ANALYZE}}
-
-Wait for Reviewer to return.
-- If CRITICAL issues found: fix them yourself — read `.prizmkit/specs/{{FEATURE_SLUG}}/context-snapshot.md` for full project context. Fix ONLY the listed CRITICAL issues in spec.md/plan.md. Then re-run analyze (max 1 round).
-
-**CP-2**: No CRITICAL issues.
-
-
-**Checkpoint update**: Update `workflow-checkpoint.json` — set step `prizmkit-analyze` to `"completed"`.

package/bundled/skills/app-planner/references/project-conventions.md

@@ -1,93 +0,0 @@
-# Project Conventions — First-Run Setup Questions
-
-> Capture project-wide norms once, reuse across all planning sessions.
-
-These questions establish foundational conventions that affect every feature. They should be asked **once** during the first `app-planner` session and persisted to `.prizmkit/project-conventions.json` so subsequent sessions skip them.
-
-## Persistence
-
-- **File**: `.prizmkit/project-conventions.json`
-- **Read on startup**: If the file exists and a convention has a non-null value, skip that question.
-- **Write after asking**: Save answers immediately after the user responds.
-- **Shared**: Other skills (`prizmkit-init`, `dev-pipeline`) may also read this file.
-
-## Convention Questions
-
-Ask only unanswered conventions. Group related questions together in a single prompt when possible.
-
-### 1. UI Display Language
-
-**Key**: `ui_language`
-
-> "What is the primary language for the application's user interface? (e.g., English, 中文, 日本語, etc.)"
-
-**Follow-up if applicable**: If the user specifies a non-English language, confirm whether all UI text (buttons, labels, error messages, tooltips) should be in that language.
-
-### 2. Multi-Language Support (i18n)
-
-**Key**: `i18n_enabled`, `i18n_languages`
-
-> "Does the application need multi-language support (i18n)?"
-
-- If **yes** → ask: "Which languages should be supported? List all target languages."
-- If **no** → set `i18n_enabled: false`, skip `i18n_languages`.
-
-**Impact on planning**: If i18n is enabled, add an infrastructure feature for i18n setup (framework, translation file structure, language switcher) early in the dependency graph.
-
-### 3. Date, Time & Currency Formats
-
-**Key**: `date_format`, `timezone_strategy`, `currency`
-
-> "What are your preferences for date/time and currency display?"
-
-Sub-questions (ask as a group):
-- **Date format**: "Preferred date display format?" (e.g., `YYYY-MM-DD`, `MM/DD/YYYY`, `DD/MM/YYYY`, locale-auto)
-- **Timezone strategy**: "How should the app handle timezones?" (e.g., UTC storage + local display, user-selected timezone, server timezone only)
-- **Currency**: "If the app handles money, which currency format?" (e.g., USD `$1,234.56`, CNY `¥1,234.56`, EUR `€1.234,56`, or N/A if no monetary values)
-
-If the user says "not applicable" for currency, set `currency: null`.
-
-### 4. Code & Git Language Conventions
-
-**Key**: `code_comment_language`, `git_commit_language`
-
-> "What language should be used for code comments and git commit messages?"
-
-Options to present:
-- **Code comments**: English / Chinese / Match UI language / Mixed
-- **Git commit messages**: English / Chinese / Match code comments
-
-**Default suggestion**: English for both (widely accessible, compatible with open-source contribution).
-
-## JSON Schema
-
-```json
-{
-  "ui_language": "English",
-  "i18n_enabled": false,
-  "i18n_languages": [],
-  "date_format": "YYYY-MM-DD",
-  "timezone_strategy": "utc_storage_local_display",
-  "currency": null,
-  "code_comment_language": "English",
-  "git_commit_language": "English"
-}
-```
-
-## How Conventions Are Used
-
-Conventions are **AI context** — they inform your behavior during planning but are NOT written into `feature-list.json` `global_context` fields. Specifically:
-
-- `ui_language` → Write feature descriptions and acceptance criteria in a way that acknowledges the target UI language (e.g., mention CJK text handling if Chinese, RTL layout if Arabic)
-- `i18n_enabled` → If true, consider proposing an i18n infrastructure feature early in the dependency graph; ensure feature descriptions mention translation-ready patterns
-- `date_format`, `timezone_strategy` → When features involve date/time display or storage, reference the chosen convention in feature descriptions
-- `currency` → When features involve monetary values, reference the currency convention in descriptions
-- `code_comment_language` → Inform the language used in code-related examples within feature descriptions
-- `git_commit_language` → Inform pipeline and workflow language expectations
-
-## Rules
-
-- **Ask at most once per convention** — if answered, never re-ask unless user invokes a reset.
-- **No blocking** — if the user skips a question ("I'll decide later"), set value to `null` and move on. The question will be re-asked next session.
-- **Respect existing config** — if `.prizmkit/config.json` already has equivalent fields (e.g., `tech_stack.language`), do not duplicate. Only ask questions not covered by existing config.
-- **Minimal interruption** — batch all unanswered questions into a single interaction round, not one-by-one.

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

@@ -1,207 +0,0 @@
----
-name: "prizmkit-analyze"
-description: "Cross-document consistency analysis for spec.md and plan.md. Detects duplications, ambiguities, gaps, and rule conflicts. Read-only quality gate — use after /prizmkit-plan, before /prizmkit-implement. Trigger on: 'analyze', 'check consistency', 'validate spec', 'review plan', 'is the spec ready'. (project)"
----
-
-# PrizmKit Analyze
-
-### When to Use
-- 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
-
-**PRECONDITION:**
-
-| Required Artifact | Directory | Check | If Missing |
-|---|---|---|---|
-| `spec.md` | `.prizmkit/specs/###-feature-name/` | File exists | Run `/prizmkit-plan` |
-| `plan.md` (with Tasks section) | `.prizmkit/specs/###-feature-name/` | File exists + has Tasks section | Run `/prizmkit-plan` |
-
-## Operating Constraints
-
-**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 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
-
-### Step 1: Initialize Analysis Context
-
-Locate the current feature directory in `.prizmkit/specs/###-feature-name/` by checking the current Git branch name or scanning `.prizmkit/specs/` for the most recent feature directory.
-
-Derive absolute paths:
-- SPEC = `.prizmkit/specs/###-feature-name/spec.md`
-- 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 `/prizmkit-plan`.
-
-### Step 2: Load Artifacts (Progressive Disclosure)
-
-Load only the minimal necessary context from each artifact:
-
-**From spec.md:**
-- Overview/Context
-- Functional Requirements
-- Non-Functional Requirements
-- User Stories and Acceptance Criteria
-- Scope Boundaries
-- Edge Cases (if present)
-
-**From plan.md:**
-- Architecture/stack choices
-- Component Design
-- Data Model references
-- API Contracts
-- Testing Strategy
-- Risk Assessment
-- Tasks section (task IDs, phase grouping, parallel markers, file paths)
-
-**From .prizm-docs/root.prizm:**
-- RULES section (MUST/NEVER/PREFER directives)
-- PATTERNS section (project-wide code patterns)
-- TECH_STACK section (for consistency checking)
-
-### Step 3: Build Semantic Models
-
-Create internal representations (do not include raw artifacts in output):
-
-- **Requirements inventory**: Each functional + non-functional requirement with a stable key (derive slug from imperative phrase; e.g., "User can upload file" -> `user-can-upload-file`)
-- **User story/action inventory**: Discrete user actions with acceptance criteria
-- **Task coverage mapping**: Map each task (from plan.md Tasks section) to one or more requirements or stories (inference by keyword / explicit reference patterns like IDs or key phrases)
-- **Prizm rule set**: Extract MUST/NEVER/PREFER normative statements from root.prizm RULES
-
-### Step 4: Detection Passes
-
-Focus on high-signal findings. Limit to **50 findings total**; aggregate remainder in overflow summary.
-
-#### A. Duplication Detection
-- Identify near-duplicate requirements across spec.md sections
-- Mark lower-quality phrasing for consolidation
-
-#### B. Ambiguity Detection
-- Flag vague adjectives (fast, scalable, secure, intuitive, robust) lacking measurable criteria
-- Flag unresolved placeholders (TODO, TBD, ???, `<placeholder>`, `[NEEDS CLARIFICATION]`)
-
-#### C. Underspecification
-- Requirements with verbs but missing object or measurable outcome
-- User stories missing acceptance criteria alignment
-- Tasks referencing files or components not defined in spec/plan
-- Plan components with no corresponding spec requirement
-
-#### D. Prizm Rules Alignment
-- Any requirement or plan element conflicting with a MUST/NEVER directive
-- Missing mandated patterns from PATTERNS section
-- Tech stack inconsistencies between plan and root.prizm TECH_STACK
-
-#### E. Coverage Gaps
-- Requirements with zero associated tasks (from plan.md Tasks section)
-- Tasks with no mapped requirement/story ("orphan tasks")
-- Non-functional requirements not reflected in tasks (performance, security, etc.)
-- User stories without corresponding plan components
-
-#### F. Inconsistency
-- Terminology drift (same concept named differently across files)
-- Data entities referenced in plan but absent in spec (or vice versa)
-- Task ordering contradictions (e.g., integration tasks before foundational setup without dependency note)
-- Conflicting requirements (e.g., one requires REST while other specifies GraphQL)
-
-#### G. Database Design Consistency (when plan.md has Data Model section)
-- New entity/field naming inconsistent with existing schema conventions documented in "Existing Schema Audit"
-- Missing constraints (NOT NULL, UNIQUE, FK, INDEX) on fields where existing similar tables define them
-- Unresolved `[NEEDS CLARIFICATION]` in Data Model section → **CRITICAL** (must be resolved before implementation)
-- Style Conformance Checklist items unchecked → **HIGH** (design not verified against existing conventions)
-- New tables with no foreign key relationship to any existing table (orphan table warning — may indicate missing business logic)
-- Missing migration strategy for schema changes that affect existing data
-
-### Step 5: Severity Assignment
-
-Use this heuristic to prioritize findings:
-
-- **CRITICAL**: Violates Prizm RULES MUST/NEVER directive, missing core artifact section, or requirement with zero coverage that blocks baseline functionality
-- **HIGH**: Duplicate or conflicting requirement, ambiguous security/performance attribute, untestable acceptance criterion
-- **MEDIUM**: Terminology drift, missing non-functional task coverage, underspecified edge case
-- **LOW**: Style/wording improvements, minor redundancy not affecting execution order
-
-### Step 6: Produce Compact Analysis Report
-
-Output a Markdown report (**no file writes**) with the following structure:
-
-```
-## Consistency Analysis Report
-
-| ID | Category | Severity | Location(s) | Summary | Recommendation |
-|----|----------|----------|-------------|---------|----------------|
-| A1 | Duplication | HIGH | spec.md §2.1, §3.4 | Two similar requirements... | Merge phrasing; keep clearer version |
-| D1 | Rules Alignment | CRITICAL | plan.md §Architecture | Conflicts with MUST rule... | Adjust plan to align with rule |
-
-**Coverage Summary:**
-
-| Requirement Key | Has Task? | Task IDs | Notes |
-|-----------------|-----------|----------|-------|
-
-**Prizm Rules Alignment Issues:** (if any)
-
-**Unmapped Tasks:** (if any)
-
-**Metrics:**
-- Total Requirements: N
-- Total Tasks: N
-- Coverage %: N% (requirements with >=1 task)
-- Ambiguity Count: N
-- Duplication Count: N
-- Critical Issues: N
-```
-
-### Step 7: Provide Next Actions
-
-At end of report, output a concise Next Actions block:
-
-- 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-plan` 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
-
-Ask the user: "Would you like me to suggest concrete remediation edits for the top N issues?" (Do NOT apply them automatically.)
-
-## Operating Principles
-
-### Context Efficiency
-- 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
-- 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-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
-
-Analysis report is output to conversation only.

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

@@ -1,25 +0,0 @@
-# Review Dimensions — Bugfix Mode
-
-Review code against `fix-plan.md` and the bug description. Minimal scope — the fix should change as little as possible.
-
-## Bugfix-Specific Dimensions
-
-### Bug Actually Fixed
-- The reproduction steps from fix-plan.md no longer trigger the bug
-- The root cause identified in fix-plan.md is addressed (not just symptoms)
-- A regression test exists that would catch this bug if reintroduced
-
-### No Regressions
-- All existing tests still pass
-- The fix does not change behavior for non-buggy inputs
-- Related code paths are not inadvertently affected
-
-### Minimal Change Scope
-- Only files directly related to the bug are modified
-- No "while I'm here" refactoring mixed with the fix
-- If scope creep is detected, flag it — those changes belong in a separate commit
-
-### Reproduction Test
-- A test exists that reproduces the exact bug scenario
-- The test would fail on the pre-fix code and pass on the post-fix code
-- The test covers the specific input/state that triggered the bug