prizmkit 1.1.114 → 1.1.115

package/bundled/dev-pipeline/tests/test_unified_cli.py

@@ -793,9 +793,6 @@ def test_session_preamble_writes_redacted_start_command_for_all_launch_profiles(
 
 def test_headless_subagent_prompt_guidance_keeps_no_worktree_boundary_visible():
     guidance_files = [
-        REPO_ROOT / "dev-pipeline" / "templates" / "sections" / "phase-critic-plan.md",
-        REPO_ROOT / "dev-pipeline" / "templates" / "sections" / "phase-critic-plan-full.md",
-        REPO_ROOT / "dev-pipeline" / "templates" / "agent-prompts" / "critic-plan-challenge.md",
         REPO_ROOT / "dev-pipeline" / "templates" / "bootstrap-tier2.md",
         REPO_ROOT / "dev-pipeline" / "templates" / "bootstrap-tier3.md",
         REPO_ROOT / "core" / "skills" / "prizmkit-skill" / "prizmkit-code-review" / "SKILL.md",
@@ -1029,12 +1026,13 @@ def test_compact_progress_line_hides_stale_until_no_progress(tmp_path):
 
     session_log = tmp_path / "session.log"
     progress = tmp_path / "progress.json"
+    checkpoint = tmp_path / "workflow-checkpoint.json"
     progress.write_text(
         json.dumps(
             {
                 "child_total_bytes": 2 * 1024 * 1024,
                 "subagent_spawn_count": 5,
-                "current_phase": "retrospective",
+                "current_phase": "stream-derived-phase",
                 "current_tool": "Read",
                 "message_count": 465,
                 "total_tool_calls": 412,
@@ -1042,20 +1040,28 @@ def test_compact_progress_line_hides_stale_until_no_progress(tmp_path):
         ),
         encoding="utf-8",
     )
+    checkpoint.write_text(
+        json.dumps({"steps": [
+            {"id": "S01", "skill": "plan", "name": "Plan", "status": "completed"},
+            {"id": "S02", "skill": "retro", "name": "Retrospective", "status": "pending", "depends_on": "S01"},
+        ]}),
+        encoding="utf-8",
+    )
     running = HeartbeatState(last_seen_epoch=1.0, stale=False, details="progress", stale_seconds=0, log_size=4 * 1024 * 1024)
     brief_pause = HeartbeatState(last_seen_epoch=1.0, stale=False, details="no progress", stale_seconds=125, log_size=4 * 1024 * 1024)
     paused = HeartbeatState(last_seen_epoch=1.0, stale=True, details="no progress", stale_seconds=15 * 60, log_size=4 * 1024 * 1024)
     resumed = HeartbeatState(last_seen_epoch=3.0, stale=False, details="progress", stale_seconds=0, log_size=5 * 1024 * 1024)
 
-    running_line = _compact_progress_line(0, session_log, progress, running, stale_threshold_seconds=15 * 60)
-    brief_pause_line = _compact_progress_line(0, session_log, progress, brief_pause, stale_threshold_seconds=15 * 60)
-    paused_line = _compact_progress_line(0, session_log, progress, paused, stale_threshold_seconds=15 * 60)
-    resumed_line = _compact_progress_line(0, session_log, progress, resumed, stale_threshold_seconds=15 * 60)
+    running_line = _compact_progress_line(0, session_log, progress, running, checkpoint_path=checkpoint, stale_threshold_seconds=15 * 60)
+    brief_pause_line = _compact_progress_line(0, session_log, progress, brief_pause, checkpoint_path=checkpoint, stale_threshold_seconds=15 * 60)
+    paused_line = _compact_progress_line(0, session_log, progress, paused, checkpoint_path=checkpoint, stale_threshold_seconds=15 * 60)
+    resumed_line = _compact_progress_line(0, session_log, progress, resumed, checkpoint_path=checkpoint, stale_threshold_seconds=15 * 60)
 
     assert "▶ [HEARTBEAT]" in running_line
     assert "log: 4MB" in running_line
     assert "child: 2MB/5" in running_line
-    assert "phase: retrospective" in running_line
+    assert "phase: Retrospective" in running_line
+    assert "stream-derived-phase" not in running_line
     assert "tool: Read" in running_line
     assert "msgs: 465" in running_line
     assert "412 tool calls" in running_line
@@ -1068,6 +1074,31 @@ def test_compact_progress_line_hides_stale_until_no_progress(tmp_path):
     assert "log: 5MB" in resumed_line
     assert "stale:" not in resumed_line
 
+def test_compact_progress_line_omits_phase_without_valid_checkpoint(tmp_path):
+    from prizmkit_runtime.heartbeat import HeartbeatState
+    from prizmkit_runtime.sessions import _compact_progress_line
+
+    session_log = tmp_path / "session.log"
+    progress = tmp_path / "progress.json"
+    malformed = tmp_path / "bad-checkpoint.json"
+    invalid = tmp_path / "invalid-checkpoint.json"
+    progress.write_text(
+        json.dumps({"current_phase": "legacy-plan", "current_tool": "Edit"}),
+        encoding="utf-8",
+    )
+    malformed.write_text("{bad", encoding="utf-8")
+    invalid.write_text(json.dumps({"steps": [{"id": "S01", "skill": "x", "name": "X", "status": "done"}]}), encoding="utf-8")
+    state = HeartbeatState(last_seen_epoch=1.0, stale=False, details="progress", stale_seconds=0, log_size=12)
+
+    missing_line = _compact_progress_line(0, session_log, progress, state, checkpoint_path=tmp_path / "missing.json")
+    malformed_line = _compact_progress_line(0, session_log, progress, state, checkpoint_path=malformed)
+    invalid_line = _compact_progress_line(0, session_log, progress, state, checkpoint_path=invalid)
+
+    for line in (missing_line, malformed_line, invalid_line):
+        assert "phase:" not in line
+        assert "legacy-plan" not in line
+        assert "tool: Edit" in line
+
 
 def test_heartbeat_observation_stale_accumulates_by_elapsed_time_and_resets_on_progress(tmp_path, monkeypatch):
     import prizmkit_runtime.heartbeat as heartbeat

package/bundled/skills/_metadata.json

@@ -1,5 +1,5 @@
 {
-  "version": "1.1.114",
+  "version": "1.1.115",
   "skills": {
     "prizmkit": {
       "description": "Full-lifecycle dev toolkit. Covers spec-driven development, Prizm context docs, code quality, debugging, deployment, and knowledge management.",

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

@@ -414,14 +414,15 @@ Bug List (by priority):
 
 ---
 
-## Adversarial Critic & Browser Verification
+## Verification Defaults
 
-When configuring critic settings or browser verification for bugs, read `${SKILL_DIR}/references/critic-and-verification.md` for default behavior tables and verification type guidance.
+When configuring bug verification, read `${SKILL_DIR}/references/verification.md` for verification type and browser verification guidance.
 
 Key points:
-- Critic is enabled by default for critical/high severity, disabled for medium/low
-- Users can override critic settings per-bug during Phase 2 or Phase 3
+- Critical/high severity bugs require clear automated, manual, or hybrid verification evidence.
+- Medium/low severity bugs use the smallest verification that proves the fix and guards against regression.
 - `browser_interaction` is supported for UI-reproducible bugs; `verification_type` still declares whether verification is automated, manual, or hybrid.
+- Do not generate `critic` or `critic_count`; those fields are fully removed and validators reject them.
 
 ---
 

package/bundled/skills/bug-planner/references/verification.md

@@ -0,0 +1,29 @@
+# Bug Verification Guidance
+
+## Verification Defaults
+
+All bug fixes need verification that matches severity, reproduction clarity, and risk.
+
+| Severity | Default verification expectation | Rationale |
+|---|---|---|
+| critical | Automated or hybrid verification with explicit regression coverage | Crash/data-loss/security bugs need durable proof. |
+| high | Automated or hybrid verification for the broken core path | Core-feature failures need regression protection. |
+| medium | Focused automated or manual verification | Workaround cases need proof without over-scoping. |
+| low | Smallest meaningful check | Cosmetic or minor edge cases should stay lightweight. |
+
+## Verification Type
+
+- `automated`: use when a unit, integration, or E2E test can reliably reproduce the bug and prove the fix.
+- `manual`: use when reproduction needs external state or human judgment and no stable automated check is practical.
+- `hybrid`: use when automated regression coverage is possible but final confidence needs manual/browser confirmation.
+
+## Browser Verification
+
+Use `browser_interaction` for UI-reproducible bugs.
+
+- `tool: auto` lets the runtime choose the best browser tool.
+- `tool: playwright-cli` is best for local dev-server verification in an isolated browser.
+- `tool: opencli` is best when an existing Chrome login/session or third-party integration cookies are needed.
+- `verify_steps` should describe what to prove, not low-level click scripts.
+
+Do not emit `critic` or `critic_count`; those fields are retired and validators reject them.

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

@@ -139,6 +139,14 @@ def validate(data, feature_ids=None):
     for i, bug in enumerate(bugs):
         prefix = "bugs[{}]".format(i)
 
+        for retired_field in ("critic", "critic_count"):
+            if retired_field in bug:
+                errors.append(
+                    "{}: '{}' field is retired; remove it from bug-fix-list data".format(
+                        prefix, retired_field
+                    )
+                )
+
         # Required fields
         bug_id = bug.get("id", "")
         if not bug_id:

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

@@ -123,7 +123,7 @@ Detect user intent from their message, then follow the corresponding workflow:
    ```
    Selected-options example:
    ```bash
-   VERBOSE=1 ENABLE_CRITIC=1 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 bugfix run .prizmkit/plans/bug-fix-list.json
    ```
 
@@ -134,7 +134,7 @@ Detect user intent from their message, then follow the corresponding workflow:
    Selected-options example:
    ```bash
    python3 ./.prizmkit/dev-pipeline/cli.py daemon bugfix start .prizmkit/plans/bug-fix-list.json \
-     --env "VERBOSE=1 ENABLE_CRITIC=1 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 7.

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

@@ -11,7 +11,6 @@ Translating user responses to env vars:
 | Verbose: Off | `VERBOSE=0` |
 | Verbose: On | `VERBOSE=1` |
 | Max retries: N | `MAX_RETRIES=N` |
-| Critic: On | `ENABLE_CRITIC=1` |
 | Stop on failure: On | `STOP_ON_FAILURE=1` |
 | Deploy: Yes | `ENABLE_DEPLOY=1` |
 | Effort: value | `PRIZMKIT_EFFORT=<value>` |
@@ -43,15 +42,11 @@ Present these via `AskUserQuestion` in step 5. Round 1 is one `AskUserQuestion`
 - 1
 - 5
 
-**Question 3 — Critic review** (multiSelect: false):
-- Off (default) — Skip adversarial review (`ENABLE_CRITIC=0`)
-- On — Enable adversarial critic review (`ENABLE_CRITIC=1`): an independent AI agent reviews the diagnosis/plan for completeness and the fix for defects, edge cases, and regression risks. Adds ~5-10 min per bug.
-
 **Question 4 — Advanced config?** (multiSelect: false):
 - No (default) — Use defaults for failure behavior
 - Yes — Configure stop-on-failure, deploy, and reasoning effort options
 
-Note: Bug filter defaults to all bugs. Runtime selects eligible bugs in stable list order after dependencies are completed; planners should order unrelated bugs by severity/priority before launch. Default Critic to Off unless bugs have `severity: "critical"` or `severity: "high"` (in which case default to On). If the user selects "Other" on any option, handle their custom input.
+Note: Bug filter defaults to all bugs. Runtime selects eligible bugs in stable list order after dependencies are completed; planners should order unrelated bugs by severity/priority before launch. If the user selects "Other" on any option, handle their custom input.
 
 ### Round 2 (only if Advanced config = Yes)
 

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):