prizmkit 1.1.113 → 1.1.115

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

@@ -106,7 +106,7 @@ Trigger conditions are covered by the frontmatter `description`. Do NOT use this
    8. **Browser interaction**: If present, may include `tool` and `verify_steps`; planner should add concrete `verify_steps` when known, but the schema permits an empty object for AI runtime exploration.
    9. **Complexity enum**: If present, is one of: low, medium, high, critical
    10. **Model field**: If present, is a non-empty string
-   11. **Critic field**: If present, is boolean; if true, critic_count should be 1 or 3
+   11. **Retired fields**: `critic` and `critic_count` must not appear; validation fails if either field is present
    12. **Root schema**: Has $schema='dev-pipeline-feature-list-v1', project_name, and non-empty features array
 
 5. **Use script output as source of truth** — if validation fails, fix and re-run until pass
@@ -184,7 +184,7 @@ Assign `estimated_complexity` from concrete scope indicators, not from perceived
 - acceptance-criteria count and edge-case breadth
 - test coverage and verification difficulty
 
-Use `low` for focused changes in 1 module with <=5 acceptance criteria and no public API/schema changes. Use `medium` for normal multi-file or 2-3 module work with bounded interfaces. Use `high` only when multiple concrete high indicators are present, such as 3+ modules plus public API changes, deep dependencies, weak tests, or substantial architectural risk. Use `critical` only for system-wide architectural/infrastructure changes or safety-critical work requiring full-team/multi-critic execution.
+Use `low` for focused changes in 1 module with <=5 acceptance criteria and no public API/schema changes. Use `medium` for normal multi-file or 2-3 module work with bounded interfaces. Use `high` only when multiple concrete high indicators are present, such as 3+ modules plus public API changes, deep dependencies, weak tests, or substantial architectural risk. Use `critical` only for system-wide architectural/infrastructure changes or safety-critical work requiring the strongest orchestrator/reviewer/test guardrails.
 
 ### Required Planning Review Summary
 
@@ -253,8 +253,8 @@ Execute the planning workflow in conversation mode with mandatory checkpoints:
 7. Build or append `.prizmkit/plans/feature-list.json`
 8. Apply default testing strategy (see §Testing Defaults below)
 9. Validate and fix until pass
-10. Run the mandatory Post-Generation Plan Review Gate (see §Post-Generation Plan Review Gate below); apply accepted fixes to the draft/source plan, regenerate, and revalidate until pass
-11. Summarize final feature table with review result and validation outcome
+10. Run the mandatory Local Generated-Plan Review Gate (see §Local Generated-Plan Review Gate below); apply accepted fixes to the draft/source plan, regenerate, and revalidate until pass
+11. Summarize final feature table with local review result and validation outcome
 
 ### Checkpoints (Mandatory Gates)
 
@@ -266,11 +266,11 @@ Checkpoints catch cascading errors early — skipping one means the next phase b
 | **CP-FP-2** | Feature Proposals | Feature set with titles+deps identified (pre-validation) | 3-5 |
 | **CP-FP-3** | DAG Validity | No cycles, dependencies resolved (validation dry-run) | 5 |
 | **CP-FP-3.1** | Browser Interaction Applied | Qualifying features have `browser_interaction` field; user confirmed or opted out | 4 |
-| **CP-FP-3.2** | Testing Defaults Applied | All features have appropriate `critic`, `critic_count`, and testing expectations | 7 |
+| **CP-FP-3.2** | Testing Defaults Applied | All features have appropriate testing expectations and no retired `critic`/`critic_count` fields | 7 |
 | **CP-FP-3.3** | Completeness Review Passed | All features reviewed for description adequacy and cross-feature gaps | 6 |
 | **CP-FP-4** | `.prizmkit/plans/feature-list.json` Generated | Schema validates, all required keys present | 7-8 |
 | **CP-FP-5** | Final Validation Pass | Python script returns `"valid": true` with zero errors | 9 |
-| **CP-FP-6** | Plan Review Passed | `/prizmkit-code-review` reviewed only newly added/changed feature entries; accepted fixes were regenerated and revalidated | 10 |
+| **CP-FP-6** | Local Plan Review Passed | Local generated-plan review loaded `${SKILL_DIR}/references/generated-plan-review.md`, reviewed only newly added/changed feature entries, applied accepted fixes through draft/source data, regenerated, and revalidated | 10 |
 
 **Resume Detection**: If existing artifacts are found, read `${SKILL_DIR}/references/error-recovery.md` §Resume Support for checkpoint-based resumption.
 
@@ -320,7 +320,7 @@ For simple incremental planning, skip detailed Phase 2-3 analysis:
    ```bash
    python3 ${SKILL_DIR}/scripts/validate-and-generate.py generate --input .prizmkit/plans/feature-list.draft.json --output .prizmkit/plans/feature-list.json
    ```
-6. If valid → run the mandatory Post-Generation Plan Review Gate, then summarize and recommend next step
+6. If valid → run the mandatory Local Generated-Plan Review Gate, then summarize and recommend next step
 7. If invalid → apply fixes to the draft, re-run generate (max 2 attempts, then escalate to full workflow)
 
 ## Browser Interaction Planning
@@ -357,13 +357,12 @@ Key requirements:
 - `priority`: `"critical"`, `"high"`, `"medium"`, or `"low"` (string, NOT numeric)
 - new items default `status: "pending"`
 - English feature titles for stable slug generation
-- `critic` / `critic_count` defaults per Testing Defaults section
 - `browser_interaction` auto-generated for qualifying frontend features (with `tool` selection: `auto`/`playwright-cli`/`opencli`)
 - descriptions: minimum 15 words (error), recommended minimum 30/50/80/100+ for low/medium/high/critical (warning). No upper limit — more detail prevents AI guessing
 - `estimated_complexity` determines pipeline execution tier:
   - `low` / `medium` → **lite** (single agent, no subagents)
-  - `high` → **standard** (orchestrator + dev + reviewer, 3 agents)
-  - `critical` → **full** (full team + critic agents, 5 agents). Use for: architectural changes touching 10+ files, cross-module refactoring with API surface changes, features requiring multi-critic voting
+  - `high` → **standard** (orchestrator + reviewer guardrails, 3-agent metadata)
+  - `critical` → **full** (strongest orchestrator/reviewer guardrails). Use for: architectural changes touching 10+ files, cross-module refactoring with API surface changes, or safety/security/data-loss risk
 
 **IMPORTANT: Do NOT hand-write the final JSON file.** Instead:
 1. Write a draft JSON to a temporary path (e.g., `.prizmkit/plans/feature-list.draft.json`)
@@ -373,39 +372,36 @@ python3 ${SKILL_DIR}/scripts/validate-and-generate.py generate --input .prizmkit
 ```
 The script fills in defaults (`$schema`, `created_at`, `created_by`), validates all fields, and writes the final file only if validation passes. If validation fails, fix the draft and retry.
 
-## Post-Generation Plan Review Gate
+## Local Generated-Plan Review Gate
 
-User requirement preserved verbatim: `每次完成任务规划的时候，应该调用/prizmkit-code-review 对新增的计划内容进行review，确保生成新增的计划的正确行和完整性。`
+User requirement preserved verbatim: `there is a litter bug for prizm-code-review will to check git diff in working space and staged space , however the .prizmkit will be gitignored in most situation.  so do you think the content should be change to inline a new reference file instead of use prizmkit-code-review`
 
-Run this gate **after** `.prizmkit/plans/feature-list.json` passes the validation/generate script and **before** the final handoff summary recommends `feature-pipeline-launcher`. This gate applies to full workflow and fast-path incremental planning.
+Run this gate **after** `.prizmkit/plans/feature-list.json` passes the validation/generate script and **before** the final handoff summary recommends `feature-pipeline-launcher`. This gate applies to full workflow and fast-path incremental planning when the current session generated, appended, or rewrote final feature planning content. For validate-only, summary-only, or draft-save flows with no new final planning content, report: `Local generated-plan review: not applicable — no new final planning content written.`
 
-1. **Identify review scope**: compare the final validated feature list against the pre-session list when one existed. Review only newly added or changed feature entries. Do not re-review unchanged historical entries except when needed to verify dependency references.
-2. **Invoke `/prizmkit-code-review` as a planning-quality gate** with an explicit prompt that this is a plan-entry review, not an implementation review. The review must check:
-   - schema correctness and compatibility with `dev-pipeline-feature-list-v1`
-   - dependency/DAG soundness, including missing, invalid, circular, or poorly ordered dependencies
-   - description completeness and headless execution readiness
-   - acceptance criteria specificity and measurability
-   - preservation of user-provided wording in `description`, `acceptance_criteria`, and `user_context`
-   - task-scoped `user_context` isolation: no unrelated sibling feature descriptions, file references, or supplementary materials, and shared context appears on multiple items only when explicitly global
-   - priority/complexity calibration: every reviewed feature has a short priority rationale and complexity rationale, medium/low assignments are allowed when criteria fit, and high/high is not used merely because work is framework-related, multi-file, or user-requested
-3. **Keep the review planning-only**: do NOT start `feature-pipeline-launcher`, do NOT run the dev-pipeline, do NOT run tests/builds/installs, and do NOT implement source-code changes.
-4. **Apply accepted review fixes through the draft/source plan**: when a finding is accepted, update `.prizmkit/plans/feature-list.draft.json` or the in-memory draft representation first, then regenerate the final file with:
+1. **Load the local reference**: read `${SKILL_DIR}/references/generated-plan-review.md` and follow it as the source of truth for this planner-output review loop.
+2. **Read actual planning artifacts directly**: inspect `.prizmkit/plans/feature-list.json`, `.prizmkit/plans/feature-list.draft.json` when present, and any pre-session or in-memory draft snapshot. Do not rely on `git status`, `git diff`, or `git diff --cached`, because `.prizmkit` planning artifacts are often gitignored or untracked.
+3. **Identify review scope**: compare by stable feature IDs and item fields against the pre-session list when one existed. Ignore root generator metadata such as `$schema`, `created_at`, and `created_by`. Review only newly added or changed feature entries; preserve unchanged historical entries except when needed to verify dependency references.
+4. **Run the local checklist** from the reference: schema compatibility, dependency/DAG soundness, description completeness, headless execution readiness, acceptance criteria measurability, user-provided wording preservation, task-scoped `user_context` isolation, priority/complexity calibration, and browser interaction fields when applicable.
+5. **Keep the review planning-only**: do NOT start `feature-pipeline-launcher`, do NOT run the dev-pipeline, do NOT run tests/builds/installs, and do NOT implement source-code changes.
+6. **Apply accepted review fixes through the draft/source plan**: when a finding is accepted, update `.prizmkit/plans/feature-list.draft.json` or the in-memory draft representation first, then regenerate the final file with:
    ```bash
    python3 ${SKILL_DIR}/scripts/validate-and-generate.py generate --input .prizmkit/plans/feature-list.draft.json --output .prizmkit/plans/feature-list.json
    ```
    Do not hand-patch the final JSON as the source of truth; map final-output findings back to draft entries before regeneration.
-5. **Revalidate after every accepted fix batch**: the generate script must pass again before the planner can proceed. If validation fails, fix the draft and rerun until pass.
-6. **Report the gate outcome** in the final summary: include `/prizmkit-code-review` verdict, reviewed feature IDs, accepted fixes (or "none"), and final validation result.
+7. **Revalidate after every accepted fix batch**: the generate script must pass again before the planner can proceed. If validation fails, fix the draft and rerun until pass.
+8. **Report the gate outcome** in the final summary: include local generated-plan review verdict, reviewed feature IDs, accepted fixes (or "none"), and final validation result.
 
 ## Testing Defaults (Phase 8)
 
-Set default testing-related fields for each feature. The user can opt out.
+Set default testing-related fields for each feature. The user can opt out of generated testing expectations, but do not generate retired review-agent configuration fields.
 
-| Priority | `critic` | `critic_count` | Rationale |
-|----------|----------|----------------|-----------|
-| high | `true` | `3` | Multi-critic voting |
-| medium | `true` | `1` | Single critic review |
-| low | `false` | (omitted) | Skip critic |
+| Priority | Testing expectation | Rationale |
+|----------|---------------------|-----------|
+| high | Require scoped tests and review-gate evidence | Higher-risk feature behavior needs stronger verification. |
+| medium | Require focused tests for changed public behavior | Normal changes need meaningful boundary coverage. |
+| low | Require the smallest relevant verification | Low-risk changes should stay lightweight. |
+
+Never emit `critic` or `critic_count`; those fields are fully removed and the validator rejects them.
 
 For frontend features with `browser_interaction`, browser verification is enabled by default. The `tool` field uses the user's choice from the mandatory browser tool question in Phase 4.2 (see §Browser Interaction Planning → Default Behavior).
 
@@ -445,11 +441,11 @@ When the session appears to be ending:
 
 ## Handoff Message Template
 
-After successful validation and the Post-Generation Plan Review Gate, report:
+After successful validation and the Local Generated-Plan Review Gate, report:
 1. Output file path
 2. Total features + newly added features
 3. Dependency and priority highlights
-4. Review result: `/prizmkit-code-review` verdict, reviewed feature IDs, accepted fixes (or "none"), and final validation result
+4. Local generated-plan review result: verdict, reviewed feature IDs, accepted fixes (or "none"), and final validation result
 5. Recommended next action: `feature-pipeline-launcher`
 
 Then apply the post-planning handoff in §Scope Boundary (ask before proceeding; never auto-execute).

package/bundled/skills/feature-planner/assets/planning-guide.md

@@ -123,7 +123,7 @@ Complexity is an execution-scope estimate, not a priority or importance signal.
 | low | 1 module/layer, 1-3 files, no public API/schema change, shallow dependencies, <=5 acceptance criteria, clear existing tests | 1-2 API endpoints, 1-2 pages, focused config or copy behavior | lite (1 agent) |
 | medium | 2-3 modules/layers, 3-6 files, bounded API/interface changes, moderate dependency depth, 4-8 acceptance criteria, standard test updates | 3-5 API endpoints, 2-4 pages, normal integration work | lite (1 agent) |
 | high | 3+ modules/layers plus public API/interface or schema impact, deep dependencies, weak test coverage, complex state, third-party integration risk, or 8+ acceptance criteria | 5+ API endpoints, complex interactions, cross-cutting behavior | standard (3 agents) |
-| critical | System-wide architecture, new infrastructure, 10+ files with multi-module API surface changes, safety/security/data-loss risk requiring multi-critic review | System-wide refactoring, new infrastructure + app logic | full (5 agents + critic) |
+| critical | System-wide architecture, new infrastructure, 10+ files with multi-module API surface changes, safety/security/data-loss risk requiring strongest review and test gates | System-wide refactoring, new infrastructure + app logic | full (5 agents + critic) |
 
 ### Complexity Indicator Checklist
 
@@ -152,7 +152,7 @@ Consider splitting a feature if it exhibits any of the following:
 - If a feature is marked as `low` complexity, it should not have more than 5 acceptance criteria and should have no public API/schema changes.
 - If a feature is marked as `medium` complexity, explain why the scope is bounded even if it touches multiple files.
 - If a feature is marked as `high` complexity, it must have a clear concrete justification (e.g., "payment processing with webhook idempotency across API, persistence, and worker modules").
-- Use `critical` complexity only for features requiring architectural changes that touch 10+ files, involve cross-module API surface changes, or need multi-critic voting for safety.
+- Use `critical` complexity only for features requiring architectural changes that touch 10+ files, involve cross-module API surface changes, or need stronger review and test gates for safety.
 - When in doubt between two levels, choose the higher level only when the concrete scope indicators support it; do not use `high` as a safe default.
 
 ### Mixed Calibration Examples

package/bundled/skills/feature-planner/references/generated-plan-review.md

@@ -0,0 +1,63 @@
+# Generated Plan Review — Feature Planner
+
+Use this local review loop after `.prizmkit/plans/feature-list.json` has been generated and validated. This is a planner-output review, not an implementation/code-diff review.
+
+## Trigger
+
+Run only when the current `feature-planner` session generated, appended, or rewrote final feature planning content. For validate-only, summary-only, or draft-save flows with no new final planning content, report: `Local generated-plan review: not applicable — no new final planning content written.`
+
+## Direct Artifact Reads
+
+Planning artifacts may be gitignored, untracked, or absent from staged and unstaged diffs. Read the actual files directly:
+
+- Final list: `.prizmkit/plans/feature-list.json`
+- Draft/source list when present: `.prizmkit/plans/feature-list.draft.json`
+- Pre-session final list snapshot if captured in memory before edits
+- In-memory draft object if the session has not written a draft file yet
+
+Do not rely on `git status`, `git diff`, or `git diff --cached` to decide whether planner output exists or changed. Do not invoke `/prizmkit-code-review` for this planner-output gate; `/prizmkit-code-review` remains the implementation/code-diff review gate after `/prizmkit-implement`.
+
+## Review Scope
+
+1. If a pre-session final list exists, compare by stable feature IDs (`F-*`).
+2. Treat features as changed only when item fields changed. Ignore root generator metadata and formatting-only differences such as `$schema`, `created_at`, and `created_by`.
+3. Review newly added feature IDs and changed feature IDs.
+4. Preserve unchanged historical features. Read unchanged entries only when needed to verify dependency references from reviewed features.
+5. If no snapshot exists, review all feature entries produced by the current generation flow.
+
+## Review Checklist
+
+For every reviewed feature entry, check:
+
+- Schema compatibility with `dev-pipeline-feature-list-v1` and `.prizmkit/dev-pipeline/templates/feature-list-schema.json`
+- Dependency/DAG soundness: dependencies exist, no cycles, no poorly ordered prerequisite chains
+- Description completeness and headless execution readiness
+- Acceptance criteria specificity, measurability, and coverage of the described behavior
+- User-provided wording preservation in `description`, `acceptance_criteria`, and `user_context`
+- Task-scoped `user_context` isolation: no unrelated sibling feature descriptions, file references, or supplementary materials; shared context appears on multiple items only when explicitly global
+- Priority/complexity calibration: every reviewed feature has short priority and complexity rationales, medium/low assignments are allowed when criteria fit, and high/high is not used merely because work is framework-related, multi-file, or user-requested
+- Browser interaction fields for qualifying frontend/fullstack features when applicable
+
+## Fix Loop
+
+1. Present findings with IDs, severity, evidence, and suggested draft/source changes.
+2. Accept only findings that improve planner correctness, completeness, or downstream execution readiness.
+3. Apply accepted fixes to `.prizmkit/plans/feature-list.draft.json` or the in-memory draft object first.
+4. Regenerate the final list through the existing generator:
+
+```bash
+python3 ${SKILL_DIR}/scripts/validate-and-generate.py generate --input .prizmkit/plans/feature-list.draft.json --output .prizmkit/plans/feature-list.json
+```
+
+5. Re-run validation/generation until valid. Do not hand-patch `.prizmkit/plans/feature-list.json` as the source of truth.
+6. Repeat the local review only for entries changed by accepted fixes.
+
+## Report Format
+
+Report in the final handoff summary:
+
+- `Local generated-plan review: PASS` or `NEEDS_FIXES`
+- Reviewed feature IDs
+- Accepted fixes, or `none`
+- Final validation result
+- Note when review was not applicable because no new final planning content was written

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

@@ -335,17 +335,14 @@ def validate_feature_list(data, is_new_plan=True):
         # -- Sub-features --
         subs = feat.get("sub_features")
 
-        # -- Critic fields (optional but validated if present) --
-        critic = feat.get("critic")
-        if critic is not None and not isinstance(critic, bool):
-            errors.append(
-                "{}: 'critic' must be a boolean, got {}".format(label, type(critic).__name__)
-            )
-        critic_count = feat.get("critic_count")
-        if critic_count is not None and critic_count not in (1, 3):
-            errors.append(
-                "{}: 'critic_count' must be 1 or 3, got {}".format(label, critic_count)
-            )
+        # -- Retired fields --
+        for retired_field in ("critic", "critic_count"):
+            if retired_field in feat:
+                errors.append(
+                    "{}: '{}' field is retired; remove it from feature-list data".format(
+                        label, retired_field
+                    )
+                )
 
         # -- Browser interaction check (warning for frontend features) --
         has_frontend = bool(

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

@@ -140,7 +140,7 @@ Detect database and deployment signals, then ask 1-2 brief questions. This phase
    - If "SaaS platform": follow up with platform selection (Vercel / Railway / Fly.io / Cloudflare / AWS / Other)
 
 3. **Write results**:
-   - Append `### Infrastructure` section to the detected platform instruction file (`AGENTS.md` for Codex, `CLAUDE.md` for Claude Code, `CODEBUDDY.md` for CodeBuddy) with detection results and user answers. Format:
+   - Append `### Infrastructure` section to the detected **main** platform instruction file (`AGENTS.md` for Codex, `CLAUDE.md` for Claude Code, `CODEBUDDY.md` for CodeBuddy). Do not write Infrastructure to `AGENTS.private.md`, `CLAUDE.private.md`, or `CODEBUDDY.private.md`; private files are reserved for PrizmKit framework protocol imports. Format:
      ```markdown
      ### Infrastructure
 
@@ -302,7 +302,7 @@ Layer Detection:
 Infrastructure Quick Scan:
   Database: PostgreSQL (Prisma) — detected from dependencies
   Deployment: Vercel — detected from vercel.json
-  → Written to the detected platform instruction file `### Infrastructure`
+  → Written to the detected main platform instruction file `### Infrastructure` (not `.private.md`)
 
 Rules Quick Entry:
   Matched layers: frontend (React), backend (Express.js), database (Prisma) → keeping default rules

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

@@ -96,7 +96,21 @@ Steps:
    - Polish tasks when needed
    - Checkpoint tasks between phases when integration risk exists
 3. Mark parallel tasks with `[P]` only when they can safely run independently.
-4. Run the verification checklist from `${SKILL_DIR}/references/verification-checklist.md` and fix issues before output.
+4. Run the verification checklist from `${SKILL_DIR}/references/verification-checklist.md` and fix issues before the planning quality gate.
+
+### Phase 3: Plan/Spec Review Loop
+
+Run this phase every time `spec.md` and `plan.md` are created or updated, before reporting the plan or handing off to implementation.
+
+1. Explicitly read `${SKILL_DIR}/references/review-plan-spec-loop.md`.
+2. Execute that guide against the current `spec.md` and `plan.md`.
+3. Apply all resolvable `BLOCKER` fixes and accepted `SHOULD_FIX` fixes directly to `spec.md` and/or `plan.md`.
+4. Treat `OPTIONAL` findings as non-blocking.
+5. Rerun the review once when fixes were applied, respecting the guide's maximum of 2 total rounds.
+6. If unresolved `BLOCKER` findings remain, stop and ask targeted clarification questions in interactive mode; in non-interactive mode, record the blocker and stop. Do not escalate to a Critic agent.
+7. Only proceed to `/prizmkit-implement` handoff after the loop has no unresolved blockers.
+
+The review loop is planning-only. It must not start implementation, run tests/builds, launch a pipeline, create a separate skill, or require a Critic agent.
 
 ## Output
 

package/bundled/skills/prizmkit-plan/references/review-plan-spec-loop.md

@@ -0,0 +1,101 @@
+# Review Plan/Spec Loop
+
+## Purpose
+
+Run this local planning-quality gate after `spec.md` and `plan.md` are drafted or updated, before handing off to `/prizmkit-implement`.
+
+This is not a separate skill and it does not use a Critic agent. It is a bounded review loop executed inside `prizmkit-plan` to improve the planning artifacts only.
+
+## Non-Goals
+
+Do not do any of the following from this guide:
+
+- Start implementation or edit product/source code.
+- Run tests, builds, lint, or package commands.
+- Launch a feature, bugfix, or refactor pipeline.
+- Spawn or require a Critic agent.
+- Create a separate review-loop skill.
+- Expand scope beyond improving `spec.md` and `plan.md`.
+
+## Required Inputs
+
+- `spec.md` in the selected artifact directory.
+- `plan.md` in the selected artifact directory.
+- Relevant Prizm docs and source summaries already loaded by `prizmkit-plan`.
+
+Use source reads sparingly. Prefer the context already loaded for planning. Read additional source only when a finding cannot be classified without confirming an existing interface, naming pattern, dependency, or constraint.
+
+## Review Dimensions
+
+Review both artifacts against these dimensions:
+
+| Dimension | Check |
+|---|---|
+| Ambiguity | Requirements, scope, terms, or expected behavior are unclear or internally inconsistent. |
+| Acceptance criteria completeness | Each goal has verifiable acceptance criteria; edge/error cases are included when meaningful. |
+| Missing constraints | Security, data, compatibility, performance, platform, deployment, migration, or non-goal constraints are absent where relevant. |
+| Task ordering errors | Tasks are sequenced before their prerequisites, checkpoints are misplaced, or dependency order is unsafe. |
+| Dependency assumptions | The plan assumes missing APIs, schemas, files, services, packages, auth, environment variables, or generated artifacts without evidence. |
+| Scope drift | The plan adds unrelated work, backlog items, nice-to-haves, or implementation beyond the spec. |
+| Overengineering | The plan introduces abstractions, services, agents, workflows, data stores, or cross-module rewrites that the spec does not justify. |
+| Implementation readiness | Tasks are actionable, file-scoped when possible, testable, and resumable; blockers are explicit. |
+| Source-reading overhead | The implementation plan avoids broad rereads and identifies the minimum context/files needed for execution. |
+
+## Finding Classification
+
+Use exactly these classifications:
+
+### BLOCKER
+
+A finding is `BLOCKER` when implementation would likely fail, produce the wrong behavior, or require user clarification before a safe plan exists.
+
+Examples:
+- Acceptance criteria contradict each other.
+- A required interface/data model decision is unresolved.
+- The task order starts implementation before required schema/context decisions.
+- The plan includes scope that conflicts with explicit non-goals.
+
+### SHOULD_FIX
+
+A finding is `SHOULD_FIX` when the artifact can be improved directly without changing user intent or requiring clarification.
+
+Examples:
+- Add missing acceptance criteria derived from the stated goal.
+- Clarify a constraint already implied by the task context.
+- Reorder dependent tasks.
+- Remove an unjustified overengineered step.
+- Add a minimal file/context note to reduce source-reading overhead.
+
+### OPTIONAL
+
+A finding is `OPTIONAL` when it is a nice-to-have improvement that does not block implementation readiness.
+
+Examples:
+- Extra detail that could help but is not necessary.
+- Alternative task grouping with no correctness impact.
+- A lower-risk cleanup suggestion outside current scope.
+
+Optional findings do not block handoff.
+
+## Loop Algorithm
+
+1. Read this guide, then review the current `spec.md` and `plan.md` together.
+2. Produce a concise internal finding list grouped by `BLOCKER`, `SHOULD_FIX`, and `OPTIONAL`.
+3. Apply fixes directly to `spec.md` and/or `plan.md` for:
+   - every `BLOCKER` that can be resolved from existing task context;
+   - every `SHOULD_FIX` that is accepted as aligned with the user's intent.
+4. Do not apply `OPTIONAL` findings unless they clearly improve readiness without expanding scope.
+5. If any fixes were applied, rerun this review once.
+6. Stop after at most 2 total review rounds.
+7. If unresolved `BLOCKER` findings remain after the final round, stop planning and ask targeted clarification questions. Do not escalate to a Critic agent.
+8. If no unresolved blockers remain, report that the planning quality gate passed and hand off to `/prizmkit-implement`.
+
+## Output Summary
+
+At handoff, include a short summary:
+
+- Review rounds run: `1` or `2`.
+- Fixes applied to `spec.md`: short list or `none`.
+- Fixes applied to `plan.md`: short list or `none`.
+- Optional findings deferred: short list or `none`.
+- Unresolved blockers: `none` before handoff.

package/bundled/skills/prizmkit-prizm-docs/references/op-init.md

@@ -13,7 +13,7 @@ STEPS:
    - HIERARCHY RULE: directory X inside top-level module M maps to .prizmkit/prizm-docs/<M>/<X>.prizm, never to .prizmkit/prizm-docs/<X>.prizm.
    - Exclude .git/, node_modules/, vendor/, build/, dist/, __pycache__/, target/, bin/, .claude/, .codebuddy/, .prizmkit/, .prizmkit/prizm-docs/, dev-pipeline/. If total module count > 30, ask user for include/exclude patterns.
 3. Create .prizmkit/prizm-docs/ directory structure mirroring the source tree exactly. For each top-level module M that has sub-modules, create the subdirectory .prizmkit/prizm-docs/<M>/.
-4. Generate root.prizm (L0) with PROJECT, LANG, FRAMEWORK, BUILD, TEST, ENTRY, MODULE_INDEX with multi-level entries as needed for efficient navigation (constrained by 4KB limit), RULES extracted from CODEBUDDY.md/CLAUDE.md/README/linter configs, PATTERNS, and CROSS_CUTTING (cross-module concerns spanning 2+ modules). Set PRIZM_VERSION: 4. Max 4KB. No CHANGELOG sections/files, UPDATED/date metadata, feature/bug/refactor/task/session/run/pipeline/workflow IDs, branch names, absolute worktree paths, or `.prizmkit/specs` / `.prizmkit/dev-pipeline` artifact paths — git tracks history.
+4. Generate root.prizm (L0) with PROJECT, LANG, FRAMEWORK, BUILD, TEST, ENTRY, MODULE_INDEX with multi-level entries as needed for efficient navigation (constrained by 4KB limit), RULES extracted from user-facing main memory files (AGENTS.md, CLAUDE.md, CODEBUDDY.md), README, and linter configs. Do not extract RULES from AGENTS.private.md, CLAUDE.private.md, or CODEBUDDY.private.md because those files contain PrizmKit framework protocol text. Include PATTERNS and CROSS_CUTTING (cross-module concerns spanning 2+ modules). Set PRIZM_VERSION: 4. Max 4KB. No CHANGELOG sections/files, UPDATED/date metadata, feature/bug/refactor/task/session/run/pipeline/workflow IDs, branch names, absolute worktree paths, or `.prizmkit/specs` / `.prizmkit/dev-pipeline` artifact paths — git tracks history.
    - If `.prizmkit/plans/project-brief.md` exists: add `PROJECT_BRIEF: .prizmkit/plans/project-brief.md` to root.prizm (generated by prizmkit-init). If not present, skip — prizmkit-init Phase 7 will add it later.
    - If module count > 15: use MODULE_GROUPS format instead of MODULE_INDEX — group modules by functional domain (3-8 domains, inferred from directory structure and module responsibilities). See prizm-docs-format.md for MODULE_GROUPS format.
    - For each module entry, auto-generate 3-6 keyword tags by scanning the module's key source files for: exported function/class names, imported library names, domain-specific terms in file/directory names. Add tags in square brackets after the module name (e.g., `- auth [login, session, jwt]: ...`). Tags are optional but recommended for projects with 10+ modules.

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

@@ -166,12 +166,12 @@ Detect user intent from their message, then follow the corresponding workflow:
    - Off — Skip post-task test verification (faster but riskier)
 
    **Question 4 — Advanced config?** (multiSelect: false):
-   - No (default) — Use defaults for critic review and failure behavior
-   - Yes — Configure critic review, stop-on-failure, and reasoning effort options
+   - No (default) — Use defaults for failure behavior
+   - Yes — Configure stop-on-failure, deploy-after-completion, and reasoning effort options
 
    Note: Refactor filter defaults to all refactor items. Runtime selects eligible refactors in stable list order after dependencies are completed; planners should order unrelated refactors by user priority before launch. If the user selects "Other" on any option, handle their custom input.
 
-   **If user chose "Yes" to Advanced config**, run the advanced configuration round (a second `AskUserQuestion` round, plus a reasoning-effort follow-up). It applies to a minority of sessions, so the full question set lives in `${SKILL_DIR}/references/configuration.md` → **Advanced Configuration Round**. Default Critic to Off unless refactor items have `priority: "critical"` (in which case default to On).
+   **If user chose "Yes" to Advanced config**, run the advanced configuration round (a second `AskUserQuestion` round, plus a reasoning-effort follow-up). It applies to a minority of sessions, so the full question set lives in `${SKILL_DIR}/references/configuration.md` → **Advanced Configuration Round**.
 
    Read `${SKILL_DIR}/references/configuration.md` for the current environment-variable mapping and advanced environment-variable tables.
 
@@ -184,7 +184,7 @@ Detect user intent from their message, then follow the corresponding workflow:
    ```
    Selected-options example:
    ```bash
-   VERBOSE=1 STRICT_BEHAVIOR_CHECK=1 ENABLE_CRITIC=true MAX_RETRIES=5 STOP_ON_FAILURE=1 ENABLE_DEPLOY=1 PRIZMKIT_EFFORT=high \
+   VERBOSE=1 STRICT_BEHAVIOR_CHECK=1 MAX_RETRIES=5 STOP_ON_FAILURE=1 ENABLE_DEPLOY=1 PRIZMKIT_EFFORT=high \
      python3 ./.prizmkit/dev-pipeline/cli.py refactor run .prizmkit/plans/refactor-list.json
    ```
 
@@ -195,7 +195,7 @@ Detect user intent from their message, then follow the corresponding workflow:
    Selected-options example:
    ```bash
    python3 ./.prizmkit/dev-pipeline/cli.py daemon refactor start .prizmkit/plans/refactor-list.json \
-     --env "VERBOSE=1 STRICT_BEHAVIOR_CHECK=1 ENABLE_CRITIC=true MAX_RETRIES=5 STOP_ON_FAILURE=1 ENABLE_DEPLOY=1 PRIZMKIT_EFFORT=high"
+     --env "VERBOSE=1 STRICT_BEHAVIOR_CHECK=1 MAX_RETRIES=5 STOP_ON_FAILURE=1 ENABLE_DEPLOY=1 PRIZMKIT_EFFORT=high"
    ```
 
    **Manual mode**: Print the assembled command(s) and **stop here**. Do not execute anything. Do not proceed to step 8.

package/bundled/skills/refactor-pipeline-launcher/references/configuration.md

@@ -13,7 +13,6 @@ Translating user responses to env vars:
 | Max retries: N | `MAX_RETRIES=N` |
 | Strict behavior: On | `STRICT_BEHAVIOR_CHECK=1` |
 | Strict behavior: Off | `STRICT_BEHAVIOR_CHECK=0` |
-| Critic: On | `ENABLE_CRITIC=true` |
 | Stop on failure: On | `STOP_ON_FAILURE=1` |
 | Deploy: Yes | `ENABLE_DEPLOY=1` |
 | Effort: value | `PRIZMKIT_EFFORT=<value>` |
@@ -54,17 +53,13 @@ Not exposed in interactive menu, pass via `--env`:
 
 Only run this when the user answered "Yes" to the **Advanced config?** question in step 6. It applies to a minority of sessions.
 
-Ask a second round of `AskUserQuestion` with these 3 questions:
+Ask a second round of `AskUserQuestion` with these 2 questions:
 
 **Question 1 — Stop on failure** (multiSelect: false):
 - Off (default) — Pipeline continues to next task after failure
 - On — Pipeline halts immediately when a task exhausts all retries (`STOP_ON_FAILURE=1`)
 
-**Question 2 — Critic review** (multiSelect: false):
-- Off (default) — Skip adversarial review
-- On — Enable adversarial critic review: an independent AI agent reviews the refactor plan for completeness and the implementation for regressions, missed edge cases, and behavior violations. Adds ~5-10 min per refactor task.
-
-**Question 3 — Deploy after completion?** (multiSelect: false):
+**Question 2 — Deploy after completion?** (multiSelect: false):
 - No (default) — Skip deployment after pipeline completes
 - Yes — Run /prizmkit-deploy automatically after all refactors complete successfully (`ENABLE_DEPLOY=1`). Deployment is blocked if any refactor did not complete successfully (status not 'completed' or manually 'skipped').
 

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

@@ -265,12 +265,12 @@ See `${SKILL_DIR}/references/planning-phases.md` for the full 5-step review chec
    ```
    The script fills in defaults (`$schema`, `created_at`, `created_by`), validates all fields, and writes the final file only if validation passes.
 3. If validation fails -> fix the draft and retry (max 3 attempts)
-4. If validation passes -> run the mandatory Post-Generation Plan Review Gate (see §Post-Generation Plan Review Gate below); apply accepted fixes to the draft/source plan, regenerate, and revalidate until pass
+4. If validation passes -> run the mandatory Local Generated-Plan Review Gate (see §Local Generated-Plan Review Gate below); apply accepted fixes to the draft/source plan, regenerate, and revalidate until pass
 5. If review and validation pass -> present final summary
 
 **CHECKPOINT CP-RP-6**: `.prizmkit/plans/refactor-list.json` generated and validated.
 
-**CHECKPOINT CP-RP-7**: `/prizmkit-code-review` reviewed only newly added/changed refactor entries; accepted fixes were regenerated and revalidated.
+**CHECKPOINT CP-RP-7**: Local generated-plan review loaded `${SKILL_DIR}/references/generated-plan-review.md`, reviewed only newly added/changed refactor entries, applied accepted fixes through draft/source data, regenerated, and revalidated.
 
 ## Checkpoints (Mandatory Gates)
 
@@ -283,32 +283,26 @@ See `${SKILL_DIR}/references/planning-phases.md` for the full 5-step review chec
 | **CP-RP-4** | Items Confirmed | User confirmed/modified/skipped each item | 5 |
 | **CP-RP-5** | Completeness OK | DAG valid, preservation strategies declared, no gaps | 6 |
 | **CP-RP-6** | Output Valid | `.prizmkit/plans/refactor-list.json` passes validation script | 7 |
-| **CP-RP-7** | Plan Review Passed | `/prizmkit-code-review` reviewed only newly added/changed refactor entries; accepted fixes were regenerated and revalidated | 7 |
-
-## Post-Generation Plan Review Gate
-
-User requirement preserved verbatim: `每次完成任务规划的时候，应该调用/prizmkit-code-review 对新增的计划内容进行review，确保生成新增的计划的正确行和完整性。`
-
-Run this gate **after** `.prizmkit/plans/refactor-list.json` passes the validation/generate script and **before** the final handoff summary recommends `refactor-pipeline-launcher`. This gate applies to full workflow, Mode B from analysis, and fast-path refactor planning.
-
-1. **Identify review scope**: compare the final validated refactor list against the pre-session list when one existed. Review only newly added or changed refactor entries. Do not re-review unchanged historical entries except when needed to verify dependency references or behavior-preservation interactions.
-2. **Invoke `/prizmkit-code-review` as a planning-quality gate** with an explicit prompt that this is a refactor-plan-entry review, not an implementation review. The review must check:
-   - schema correctness and compatibility with `dev-pipeline-refactor-list-v1`
-   - dependency/DAG soundness, including safe behavior-preserving order
-   - description completeness and headless execution readiness
-   - acceptance criteria specificity and measurable behavior-preservation verification
-   - `behavior_preservation` strategy quality and target scope consistency
-   - preservation of user-provided wording in `description`, `acceptance_criteria`, and `user_context`
-   - task-scoped `user_context` isolation: no unrelated sibling refactor goals, target files, constraints, or supplementary materials, and shared context appears on multiple items only when explicitly global
-   - priority/complexity calibration: every reviewed refactor has a short priority rationale and complexity rationale, medium/low assignments are allowed when criteria fit, and high/high is not used merely because the work is cleanup, framework-related, multi-file, or user-requested
-3. **Keep the review planning-only**: do NOT start `refactor-pipeline-launcher`, do NOT run the refactor pipeline, do NOT run tests/builds/installs, and do NOT implement source-code refactors.
-4. **Apply accepted review fixes through the draft/source plan**: when a finding is accepted, update `.prizmkit/plans/refactor-list.draft.json` or the in-memory draft representation first, then regenerate the final file with:
+| **CP-RP-7** | Local Plan Review Passed | Local generated-plan review loaded `${SKILL_DIR}/references/generated-plan-review.md`, reviewed only newly added/changed refactor entries, applied accepted fixes through draft/source data, regenerated, and revalidated | 7 |
+
+## Local Generated-Plan Review Gate
+
+User requirement preserved verbatim: `there is a litter bug for prizm-code-review will to check git diff in working space and staged space , however the .prizmkit will be gitignored in most situation.  so do you think the content should be change to inline a new reference file instead of use prizmkit-code-review`
+
+Run this gate **after** `.prizmkit/plans/refactor-list.json` passes the validation/generate script and **before** the final handoff summary recommends `refactor-pipeline-launcher`. This gate applies to full workflow, Mode B from analysis, and fast-path refactor planning when the current session generated, appended, or rewrote final refactor planning content. For validate-only, summary-only, or draft-save flows with no new final planning content, report: `Local generated-plan review: not applicable — no new final planning content written.`
+
+1. **Load the local reference**: read `${SKILL_DIR}/references/generated-plan-review.md` and follow it as the source of truth for this planner-output review loop.
+2. **Read actual planning artifacts directly**: inspect `.prizmkit/plans/refactor-list.json`, `.prizmkit/plans/refactor-list.draft.json` when present, and any pre-session or in-memory draft snapshot. Do not rely on `git status`, `git diff`, or `git diff --cached`, because `.prizmkit` planning artifacts are often gitignored or untracked.
+3. **Identify review scope**: compare by stable refactor IDs and item fields against the pre-session list when one existed. Ignore root generator metadata such as `$schema`, `created_at`, and `created_by`. Review only newly added or changed refactor entries; preserve unchanged historical entries except when needed to verify dependency references or behavior-preservation interactions.
+4. **Run the local checklist** from the reference: schema compatibility, dependency/DAG soundness, safe behavior-preserving order, description completeness, headless execution readiness, acceptance criteria measurability, `behavior_preservation` strategy quality, user-provided wording preservation, task-scoped `user_context` isolation, and priority/complexity calibration.
+5. **Keep the review planning-only**: do NOT start `refactor-pipeline-launcher`, do NOT run the refactor pipeline, do NOT run tests/builds/installs, and do NOT implement source-code refactors.
+6. **Apply accepted review fixes through the draft/source plan**: when a finding is accepted, update `.prizmkit/plans/refactor-list.draft.json` or the in-memory draft representation first, then regenerate the final file with:
    ```bash
    python3 ${SKILL_DIR}/scripts/validate-and-generate-refactor.py generate --input .prizmkit/plans/refactor-list.draft.json --output .prizmkit/plans/refactor-list.json
    ```
    Do not hand-patch the final JSON as the source of truth; map final-output findings back to draft entries before regeneration.
-5. **Revalidate after every accepted fix batch**: the generate script must pass again before the planner can proceed. If validation fails, fix the draft and rerun until pass.
-6. **Report the gate outcome** in the final summary: include `/prizmkit-code-review` verdict, reviewed refactor IDs, accepted fixes (or "none"), and final validation result.
+7. **Revalidate after every accepted fix batch**: the generate script must pass again before the planner can proceed. If validation fails, fix the draft and rerun until pass.
+8. **Report the gate outcome** in the final summary: include local generated-plan review verdict, reviewed refactor IDs, accepted fixes (or "none"), and final validation result.
 
 ## Output Rules
 
@@ -326,16 +320,18 @@ Run this gate **after** `.prizmkit/plans/refactor-list.json` passes the validati
 - `model` field is optional — omitting it means the pipeline uses $MODEL env or CLI default
 - `scope` object with nested structure: `files` array (target file paths) and `modules` array (module names)
 
-## Adversarial Critic Defaults
+## Verification Defaults
+
+Set behavior-preservation and testing expectations for each refactor item. Do not generate retired review-agent configuration fields.
 
-Set default critic fields for each refactor item. The user can override per-item.
+| Priority | Complexity | Verification expectation |
+|----------|-----------|--------------------------|
+| critical | high | Strong behavior-preservation evidence plus scoped tests and review gate |
+| critical | medium/low | Focused behavior-preservation evidence plus review gate |
+| high | high | Scoped tests for changed boundaries plus review gate |
+| other combinations | any | Smallest meaningful behavior-preservation check |
 
-| Priority | Complexity | `critic` | `critic_count` |
-|----------|-----------|----------|----------------|
-| critical | high | `true` | `3` |
-| critical | medium/low | `true` | `1` |
-| high | high | `true` | `1` |
-| other combinations | any | `false` | (omitted) |
+Never emit `critic` or `critic_count`; those fields are fully removed and validators reject them.
 
 ---
 
@@ -444,10 +440,10 @@ Prevent accidental session exit without deliverable completion.
 
 ## Handoff Message Template
 
-After successful validation and the Post-Generation Plan Review Gate, report:
+After successful validation and the Local Generated-Plan Review Gate, report:
 1. Output file path
 2. Total refactor items
 3. Dependency ordering highlights (which items must run first)
 4. Behavior preservation strategy distribution (N items with test-gate, M with snapshot, etc.)
-5. Review result: `/prizmkit-code-review` verdict, reviewed refactor IDs, accepted fixes (or "none"), and final validation result
+5. Local generated-plan review result: verdict, reviewed refactor IDs, accepted fixes (or "none"), and final validation result
 6. Recommended next action: `refactor-pipeline-launcher`

package/bundled/skills/refactor-planner/references/fast-path.md

@@ -34,7 +34,7 @@ For simple refactoring with minimal scope.
    ```bash
    python3 ${SKILL_DIR}/scripts/validate-and-generate-refactor.py generate --input .prizmkit/plans/refactor-list.draft.json --output .prizmkit/plans/refactor-list.json
    ```
-5. If valid -> run the mandatory Post-Generation Plan Review Gate from the main `refactor-planner` skill before summarizing or recommending `refactor-pipeline-launcher`.
+5. If valid -> run the mandatory Local Generated-Plan Review Gate from the main `refactor-planner` skill before summarizing or recommending `refactor-pipeline-launcher`.
 6. If invalid -> apply fixes to the draft, re-run generate (max 2 attempts, then escalate to full workflow)
 
 ## When NOT to Use Fast Path
@@ -53,6 +53,6 @@ AI: [Uses AskUserQuestion with options: "Fast-path", "Full workflow"]
 User: [Selects "Fast-path"]
 AI: "Drafting R-001..."
 AI: [Validates immediately]
-AI: [Runs the Post-Generation Plan Review Gate on R-001 only]
+AI: [Runs the Local Generated-Plan Review Gate on R-001 only]
 AI: "Ready to proceed to dev-pipeline."
 ```