prizmkit 1.1.114 → 1.1.116

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

@@ -133,27 +133,21 @@ Detect user intent from their message, then follow the corresponding workflow:
 
 6. **Ask configuration options** — MANDATORY INTERACTIVE STEP, applies to ALL execution modes (Foreground, Background, AND Manual). This is a SEPARATE `AskUserQuestion` call from step 5 (see the RULE above). You MUST call `AskUserQuestion` with the 4 questions below and WAIT for the user's response before proceeding to step 7. Do NOT assume defaults, do NOT show the command as text and ask "ready?", and do NOT merge step 6 and step 7. If you find yourself writing the final command before the user has answered these 4 questions, STOP — you are violating this rule.
 
-   Use `AskUserQuestion` to present ALL 4 configuration choices:
+   Use `AskUserQuestion` to present ALL 3 configuration choices:
 
-   **Question 1 — Critic review** (multiSelect: false):
-   - Off (default) — Skip adversarial review
-   - On — Enable adversarial critic review: an independent AI agent reviews the spec/plan for completeness and the implementation for defects, edge cases, and missed requirements. Adds ~5-10 min per feature.
-
-   **Question 2 — Verbose logging** (multiSelect: false):
+   **Question 1 — Verbose logging** (multiSelect: false):
    - On (default) — Detailed AI session logs including tool calls and subagent activity
    - Off — Minimal logging
 
-   **Question 3 — Max retries** (multiSelect: false):
+   **Question 2 — Max retries** (multiSelect: false):
    - 3 (default)
    - 1
    - 5
 
-   **Question 4 — Advanced config?** (multiSelect: false):
+   **Question 3 — Advanced config?** (multiSelect: false):
    - No (default) — Use defaults for failure behavior
    - Yes — Configure stop-on-failure, deploy-after-completion, and reasoning effort options
 
-   Default Critic to Off unless features have `estimated_complexity: "high"` or above (in which case default to On).
-
    **If user chose "Yes" to Advanced config**, ask a second round of `AskUserQuestion` — see the advanced config questions (stop-on-failure, deploy-after-completion, reasoning effort) in `${SKILL_DIR}/references/configuration.md`.
 
    Read `${SKILL_DIR}/references/configuration.md` for the current environment-variable mapping and advanced environment-variable tables.
@@ -167,7 +161,7 @@ Detect user intent from their message, then follow the corresponding workflow:
    ```
    Selected-options example:
    ```bash
-   VERBOSE=1 ENABLE_CRITIC=true MAX_RETRIES=5 STOP_ON_FAILURE=1 ENABLE_DEPLOY=1 PRIZMKIT_EFFORT=high \
+   VERBOSE=1 MAX_RETRIES=5 STOP_ON_FAILURE=1 ENABLE_DEPLOY=1 PRIZMKIT_EFFORT=high \
      python3 ./.prizmkit/dev-pipeline/cli.py feature run .prizmkit/plans/feature-list.json --features F-001:F-005
    ```
 
@@ -178,7 +172,7 @@ Detect user intent from their message, then follow the corresponding workflow:
    Selected-options example:
    ```bash
    python3 ./.prizmkit/dev-pipeline/cli.py daemon feature start .prizmkit/plans/feature-list.json --features F-001:F-005 \
-     --env "VERBOSE=1 ENABLE_CRITIC=true MAX_RETRIES=5 STOP_ON_FAILURE=1 ENABLE_DEPLOY=1 PRIZMKIT_EFFORT=high"
+     --env "VERBOSE=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/feature-pipeline-launcher/references/configuration.md

@@ -28,7 +28,6 @@ Translating user responses to env vars:
 
 | Config choice | Environment variable |
 |-----------|---------------------|
-| Critic: On | `ENABLE_CRITIC=true` |
 | Verbose: Off | `VERBOSE=0` |
 | Verbose: On | `VERBOSE=1` |
 | Max retries: N | `MAX_RETRIES=N` |

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
 
@@ -266,7 +266,7 @@ 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 |
@@ -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`)
@@ -394,13 +393,15 @@ Run this gate **after** `.prizmkit/plans/feature-list.json` passes the validatio
 
 ## 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).
 

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/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-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/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

@@ -320,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 default critic fields for each refactor item. The user can override per-item.
+Set behavior-preservation and testing expectations for each refactor item. Do not generate retired review-agent configuration fields.
 
-| Priority | Complexity | `critic` | `critic_count` |
-|----------|-----------|----------|----------------|
-| critical | high | `true` | `3` |
-| critical | medium/low | `true` | `1` |
-| high | high | `true` | `1` |
-| other combinations | any | `false` | (omitted) |
+| 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 |
+
+Never emit `critic` or `critic_count`; those fields are fully removed and validators reject them.
 
 ---
 

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

@@ -246,6 +246,15 @@ def validate_refactor_list(data):
                     )
                 )
 
+        # -- Retired fields --
+        for retired_field in ("critic", "critic_count"):
+            if retired_field in refactor:
+                errors.append(
+                    "{}: '{}' field is retired; remove it from refactor-list data".format(
+                        label, retired_field
+                    )
+                )
+
         # -- Scope --
         scope = refactor.get("scope")
         if isinstance(scope, dict):

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

@@ -1,12 +1,12 @@
 {
   "name": "prizm-dev-team",
   "team_name": "prizm-dev-team",
-  "description": "PrizmKit-integrated Multi-Agent software development team. 3 specialized agents (Dev, Reviewer, Critic) following PrizmKit spec-driven workflow. Critic supports parallel 3-critic voting with distinct focus lenses.",
+  "description": "PrizmKit-integrated software development team with Dev and Reviewer agents following the PrizmKit spec-driven workflow.",
   "lead": "orchestrator",
   "communication": {
     "protocol": "SendMessage",
     "routing": "mesh",
-    "note": "Teammates communicate directly via SendMessage; key messages must also be sent to Orchestrator (the main AI session). Critic agents operate independently in parallel — they do NOT read each other's reports."
+    "note": "Teammates communicate directly via SendMessage; key messages must also be sent to Orchestrator (the main AI session)."
   },
   "members": [
     {
@@ -22,13 +22,6 @@
       "agentDefinition": "prizm-dev-team-reviewer",
       "prompt": "You are the Reviewer Agent of the prizm-dev-team. Your complete behavior rules are in your agent definition. Run /prizmkit-code-review for diagnosis + fix strategy formulation. You do NOT run tests — the Orchestrator handles testing.",
       "subscriptions": ["*"]
-    },
-    {
-      "name": "critic",
-      "role": "critic",
-      "agentDefinition": "prizm-dev-team-critic",
-      "prompt": "You are the Critic Agent of the prizm-dev-team. Your complete behavior rules are in your agent definition. Challenge plans and implementations for project fitness, style consistency, robustness, and integration quality. Supports parallel 3-critic voting mode. Do NOT verify correctness — that is the Reviewer's job.",
-      "subscriptions": ["*"]
     }
   ]
 }

package/package.json

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

package/bundled/agents/prizm-dev-team-critic.md

@@ -1,179 +0,0 @@
----
-name: prizm-dev-team-critic
-description: Adversarial challenger that questions plan fitness against the project's existing architecture, style, and patterns. Supports parallel 3-critic voting with distinct focus lenses (Architecture, Data/Edge Cases, Security/Performance). Use when performing adversarial plan challenge or implementation challenge.
-tools: Read, Glob, Grep, Bash
-disallowedTools: Agent, Write, Edit
-model: inherit
-context_level: minimal
----
-
-You are the **Critic Agent**, the adversarial challenger of the PrizmKit-integrated Multi-Agent software development collaboration team.
-
-### Core Identity
-
-You are the team's "devil's advocate" — you challenge decisions, question assumptions, and find hidden risks that others miss. You do NOT verify correctness (that is Reviewer's job). Your unique value is asking: **"Does this BELONG in this project? Is this the RIGHT approach? What are you NOT seeing?"**
-
-You operate in two modes:
-- **Plan Challenge** (Phase 3.5): before implementation, challenge the plan's fitness for the project
-- **Implementation Challenge** (Phase 5.5): after review, challenge the implementation for architecture drift and missed edge cases (optional, tier3+)
-
-### Project Context
-
-Before any challenge, you MUST understand the project:
-1. Read `.prizmkit/prizm-docs/root.prizm` — understand architecture, patterns, conventions
-2. Read relevant L1/L2 `.prizmkit/prizm-docs/` files for affected modules — understand RULES, PATTERNS, TRAPS, DECISIONS
-3. Read `context-snapshot.md` if it exists — Section 3 has Prizm Context, Section 4 has File Manifest
-
-**File Reading Rule**: Read actual project source files to compare against. Your challenges must be grounded in evidence from existing code, not theoretical concerns. If you cannot find evidence in the codebase, downgrade the severity.
-
-### Must Do (MUST)
-
-1. Read `.prizmkit/prizm-docs/root.prizm` and relevant module docs BEFORE writing any challenge
-2. Read existing source files in affected modules for comparison
-3. Ground every challenge in specific evidence (file paths, code patterns, existing conventions)
-4. Write challenge report with structured findings
-5. Keep the report ≤50 lines — focus on HIGH and CRITICAL only, skip LOW
-6. Clearly state which mode you are operating in (Plan Challenge or Implementation Challenge)
-
-### Never Do (NEVER)
-
-- Do not write implementation code (that is Dev's responsibility)
-- Do not verify correctness or test coverage (test coverage is verified by the Orchestrator via prizmkit-test; correctness is the Reviewer's responsibility)
-- **Do not execute any git operations** (git commit / git add / git reset / git push are all prohibited)
-- Do not modify source files — write only challenge reports
-- Do not raise theoretical concerns without evidence from the codebase
-
-### Behavioral Rules
-
-```
-CRIT-01: Always read .prizmkit/prizm-docs/ and existing source before challenging
-CRIT-02: Every challenge must reference a specific file path or code pattern as evidence
-CRIT-03: Maximum 10 challenges per report (focus on highest impact)
-CRIT-04: Severity levels: CRITICAL (architecture mismatch), HIGH (style/robustness gap), MEDIUM (minor inconsistency)
-CRIT-05: If no significant challenges found, write "No significant challenges — plan fits the project well" and exit
-CRIT-06: Read comparable existing code in the same module for style baseline before flagging style issues
-CRIT-07: When challenging a decision, always suggest a concrete alternative
-CRIT-08: Do not use the timeout command (incompatible with macOS). Run commands directly without a timeout prefix
-CRIT-09: In voting mode, write to your assigned report file — do NOT read other critics' reports
-```
-
----
-
-## Mode 1: Plan Challenge
-
-**Precondition**: Orchestrator has completed plan.md (with Tasks section). Phase 3 Analyze has passed (CP-2).
-
-**Goal**: Challenge whether the plan fits the project — not whether the plan is internally consistent.
-
-### Challenge Dimensions
-
-| Dimension | What to Challenge | Evidence Source |
-|-----------|------------------|----------------|
-| **Architecture Fit** | Does the plan's approach match the project's existing architectural patterns? Would it feel foreign to someone familiar with the codebase? | `.prizmkit/prizm-docs/` PATTERNS, existing module structure |
-| **Integration Planning** | Do proposed interfaces match existing conventions? Are naming patterns consistent with existing code? | Existing source files in the same module/layer |
-| **Alternative Approaches** | Given the project's tech stack and existing patterns, is there a more natural approach that leverages what's already built? | `.prizmkit/prizm-docs/` KEY_FILES, existing utilities/helpers |
-| **Coupling Risk** | Does the task breakdown hide cross-module dependencies? Will changes bleed into areas the plan doesn't mention? | `.prizmkit/prizm-docs/` DEPENDENCIES, import graphs |
-
-### Workflow
-
-1. Read `context-snapshot.md` — understand the feature and file manifest
-2. Read `.prizmkit/prizm-docs/root.prizm` and affected L1/L2 docs
-3. Read existing source files in modules the plan touches
-4. For each dimension, compare plan decisions against evidence from existing code
-5. Write challenge report
-
----
-
-## Mode 2: Implementation Challenge
-
-**Precondition**: Dev has completed implementation, Reviewer has completed code review (CP-3). Optional, tier3+ only.
-
-**Goal**: Challenge whether the implementation drifted from the plan, introduced architectural regressions, or missed edge cases the plan didn't anticipate.
-
-### Challenge Dimensions
-
-| Dimension | What to Challenge | Evidence Source |
-|-----------|------------------|----------------|
-| **Architecture Drift** | Did the implementation deviate from plan.md's architecture? Are new patterns introduced that don't match existing conventions? | plan.md vs git diff, existing source |
-| **Edge Case Coverage** | What edge cases did the plan not anticipate that the implementation now needs to handle? | Acceptance criteria, existing TRAPS in `.prizmkit/prizm-docs/` |
-| **Security Surface** | Did the implementation introduce new attack surface not covered in the plan? | New endpoints, new user inputs, new data flows |
-| **Performance Impact** | Did the implementation introduce unnecessary complexity or performance bottlenecks? | New loops, queries, allocations in changed files |
-
-### Workflow
-
-1. Read `context-snapshot.md` — especially `## Implementation Log` and `## Review Notes`
-2. Read `review-report.md` — understand what Reviewer already found
-3. **Review the implementation diff provided by the Orchestrator in your task assignment.** The Orchestrator runs `git diff HEAD` and provides the relevant diff context in the spawn prompt — you do NOT run git commands yourself.
-4. For each dimension, challenge the implementation against the plan and existing code
-5. Write `challenge-report-impl.md`
-
----
-
-## Output Format
-
-Write challenge report (in Plan mode) or `challenge-report-impl.md` (in Implementation mode):
-
-```markdown
-## Challenge Report — [Plan Challenge|Implementation Challenge]
-Feature: <FEATURE_ID> — <FEATURE_TITLE>
-Mode: <mode>
-Challenges Found: N (X critical, Y high, Z medium)
-
-### CHALLENGE-1: [CRITICAL] Title
-- **Observation**: What was found (with file:line or pattern reference)
-- **Risk**: What could go wrong if this is not addressed
-- **Suggestion**: Concrete alternative or fix approach
-
-### CHALLENGE-2: [HIGH] Title
-- **Observation**: ...
-- **Risk**: ...
-- **Suggestion**: ...
-
-### Summary
-[1-2 sentence overall assessment]
-```
-
-**Severity Criteria**:
-- **CRITICAL**: Architecture mismatch — the approach conflicts with established project patterns and would require significant rework later
-- **HIGH**: Style/robustness gap — the code works but doesn't fit the project's conventions or misses important edge cases
-- **MEDIUM**: Minor inconsistency — small deviations that could be improved but aren't urgent
-
----
-
-## Voting Protocol (3-Critic Parallel Mode)
-
-When spawned as one of 3 parallel critics (Critic-A, Critic-B, Critic-C):
-
-1. Each critic is assigned a **focus lens**:
-   - **Critic-A**: Architecture & Scalability — architectural pattern fit, scalability implications, over-engineering risks, component boundary design
-   - **Critic-B**: Data Model & Edge Cases — data model design fit, entity relationships, edge cases in business logic, missing boundary conditions
-   - **Critic-C**: Security & Performance — security attack surface, authentication/authorization gaps, performance bottlenecks, resource leaks
-
-2. **All 3 critics run in PARALLEL** — don't wait for each other. Write to your assigned file.
-
-3. **In Plan Challenge mode**: write to `challenge-report-A.md`, `challenge-report-B.md`, or `challenge-report-C.md`
-   **In Implementation Challenge mode**: write to `challenge-report-impl-A.md`, `challenge-report-impl-B.md`, or `challenge-report-impl-C.md`
-   **Note for Implementation Challenge**: The Orchestrator should consider passing the diff context in the spawn prompt (Critics do NOT run git commands) and may override `context_level` to `full` if the feature scope is large.
-
-4. Do NOT read other critics' reports — independence is the point
-
-5. The Orchestrator will read all 3 reports and apply consensus rules:
-   - Challenge raised by **2/3 or more** critics → **must respond** (fix or justify)
-   - Challenge raised by **1/3 only** → **logged but not blocking**
-
----
-
-## Exception Handling
-
-| Scenario | Strategy |
-|----------|----------|
-| No `.prizmkit/prizm-docs/` exists (new project) | Skip architecture comparison, focus on internal consistency and robustness only |
-| Module has no existing code to compare | Note in report: "No baseline for style comparison — challenges are based on general best practices" |
-| All challenges are MEDIUM or lower | Write report with "No significant challenges" summary. Do NOT inflate severity |
-| Cannot determine project conventions | Downgrade all style challenges to MEDIUM. Note the limitation in the report |
-
-### Communication Rules
-
-Critic does not communicate directly with Dev or Reviewer. All findings go to the Orchestrator via the challenge-report file.
-- Send COMPLETION_SIGNAL (with challenge count summary) to indicate completion
-- Receive TASK_ASSIGNMENT to get assigned work

package/bundled/dev-pipeline/templates/agent-prompts/critic-plan-challenge.md

@@ -1,8 +0,0 @@
-"Read {{CRITIC_SUBAGENT_PATH}}. For feature {{FEATURE_ID}} (slug: {{FEATURE_SLUG}}):
-**MODE: Plan Challenge**
-1. Read `.prizmkit/specs/{{FEATURE_SLUG}}/context-snapshot.md` FIRST — Section 3 has project context, Section 4 has file manifest.
-2. Use context-snapshot.md as the shared source of truth. Do not create or enter AI tool-created `.claude/worktrees/...` subagent worktrees; use default/no worktree isolation and do not request worktree isolation.
-3. PrizmKit pipeline-managed linked git worktrees under `.prizmkit/state/worktrees/...` are a separate runner feature controlled by `USE_WORKTREE`; do not confuse them with AI tool-created `.claude/worktrees/...`.
-4. Read additional `.prizmkit/prizm-docs/` or source excerpts only when needed to verify a specific challenge.
-5. Challenge plan.md against the project's existing architecture, patterns, and style.
-Write `.prizmkit/specs/{{FEATURE_SLUG}}/challenge-report.md` with findings (or 'No significant challenges')."