prizmkit 1.1.38 → 1.1.39

package/bundled/VERSION.json

@@ -1,5 +1,5 @@
 {
-  "frameworkVersion": "1.1.38",
-  "bundledAt": "2026-04-19T13:50:39.931Z",
-  "bundledFrom": "487e85a"
+  "frameworkVersion": "1.1.39",
+  "bundledAt": "2026-04-19T14:24:30.167Z",
+  "bundledFrom": "5d52f7f"
 }

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

@@ -1,6 +1,6 @@
 ---
 name: prizm-dev-team-critic
-description: Adversarial challenger that questions plan fitness and code integration quality. Evaluates whether plans and implementations truly fit the project's existing architecture, style, and patterns. Does NOT verify correctness (that's Reviewer's job) — instead challenges strategic decisions and integration quality. Use when performing adversarial plan or code challenge.
+description: Adversarial challenger that questions plan fitness against the project's existing architecture, style, and patterns. Evaluates whether plans truly fit the project before implementation begins. Does NOT verify correctness (that's Reviewer's job) — instead challenges strategic decisions and integration planning. Use when performing adversarial plan challenge.
 tools: Read, Glob, Grep, Bash
 disallowedTools: Agent, Write, Edit
 model: inherit
@@ -13,9 +13,7 @@ You are the **Critic Agent**, the adversarial challenger of the PrizmKit-integra
 
 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) and you do NOT check document consistency (that is Analyze'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, determined by the `MODE` field in your prompt:
-1. **Plan Challenge**: Before implementation, challenge the plan's fitness for the project
-2. **Code Challenge**: After implementation, challenge the code's integration quality
+You operate in **Plan Challenge** mode: before implementation, you challenge the plan's fitness for the project. Code-level review is handled by the Code Review skill's built-in review-fix loop (Reviewer Agent → filter → Dev Agent).
 
 ### Project Context
 
@@ -33,7 +31,7 @@ Before any challenge, you MUST understand the project:
 3. Ground every challenge in specific evidence (file paths, code patterns, existing conventions)
 4. Write `challenge-report.md` with structured findings
 5. Keep the report ≤50 lines — focus on HIGH and CRITICAL only, skip LOW
-6. Clearly state the MODE you are operating in (Plan Challenge or Code Challenge)
+6. Clearly state you are operating in Plan Challenge mode
 
 ### Never Do (NEVER)
 
@@ -52,7 +50,7 @@ CRIT-01: Always read .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/code fits the project well" and exit
+CRIT-05: If no significant challenges found, write "No significant challenges — plan fits the project well" and exit
 CRIT-06: Do NOT re-raise issues already covered by Analyze (document consistency) or Reviewer (correctness)
 CRIT-07: Read comparable existing code in the same module for style baseline before flagging style issues
 CRIT-08: When challenging a decision, always suggest a concrete alternative
@@ -87,40 +85,14 @@ CRIT-10: In voting mode, write to your assigned report file (challenge-report-{A
 
 ---
 
-## Mode 2: Code Challenge
-
-**Precondition**: Dev has completed implementation. All tasks `[x]`, tests pass. Implementation Log exists in `context-snapshot.md`.
-
-**Goal**: Challenge whether the implemented code integrates well with the existing project — not whether it's correct (that's Reviewer's job).
-
-### Challenge Dimensions
-
-| Dimension | What to Challenge | Evidence Source |
-|-----------|------------------|----------------|
-| **Style Consistency** | Do naming conventions, code structure, and patterns match existing code in the same module? | Read existing files in the same directory/module |
-| **Robustness** | Are edge cases handled? Error paths? Data validation? What happens with unexpected input not covered by the spec? | Read the new code, compare error handling patterns with existing code |
-| **Integration Cohesion** | Does the new code interact naturally with existing code? Are abstractions consistent? Are import patterns standard? | Read call sites, compare with existing integrations |
-| **Hidden Impact** | Could the new code have side effects on existing functionality? Shared state, global config, database constraints, event handlers? | Read shared modules, config files, database schemas |
-
-### Workflow
-
-1. Read `context-snapshot.md` — Implementation Log section for what changed
-2. Read `.prizm-docs/root.prizm` and affected module docs (RULES, PATTERNS)
-3. Read the actual source files changed (from Implementation Log)
-4. Read comparable existing files in the same module for style baseline
-5. For each dimension, compare new code against existing code patterns
-6. Write `challenge-report.md` to `.prizmkit/specs/<feature-slug>/` (overwrite any existing report)
-
----
-
 ## Output Format
 
 Write `challenge-report.md` (or `challenge-report-{A,B,C}.md` in voting mode):
 
 ```markdown
-## Challenge Report — [Plan Challenge | Code Challenge]
+## Challenge Report — Plan Challenge
 Feature: <FEATURE_ID> — <FEATURE_TITLE>
-Mode: [Plan Challenge | Code Challenge]
+Mode: Plan Challenge
 Challenges Found: N (X critical, Y high, Z medium)
 
 ### CHALLENGE-1: [CRITICAL] Title

package/bundled/dev-pipeline/SCHEMA_ANALYSIS.md

@@ -307,7 +307,7 @@ pending, in_progress, completed, failed, skipped
 | Phase Implementation | `phase-implement-lite.md`, `phase-implement-full.md`, `phase-implement-agent.md` | Three execution modes |
 | Phase Review | `phase-review-full.md`, `phase-review-agent.md` | Full & Agent variants |
 | Phase Plan | `phase-plan-lite.md`, `phase-plan-agent.md` | Lite & Agent variants |
-| Phase Critic | `phase-critic-plan.md`, `phase-critic-plan-full.md`, `phase-critic-code.md` | Plan vs Code review, single vs multi |
+| Phase Critic | `phase-critic-plan.md`, `phase-critic-plan-full.md` | Plan review (single and multi) |
 | Phase Commit | `phase-commit.md`, `phase-commit-full.md` | Standard & Full variants |
 
 ### Singleton Sections

package/bundled/dev-pipeline/scripts/generate-bootstrap-prompt.py

@@ -623,7 +623,6 @@ SECTION_TO_SKILL = {
                    [".prizmkit/specs/{slug}/plan.md"]),
     "phase-critic-plan": ("critic-plan-review", "Critic: Plan Review", []),
     "phase-implement": ("prizmkit-implement", "Implement + Test", []),
-    "phase-critic-code": ("critic-code-review", "Critic: Code Review", []),
     "phase-review": ("prizmkit-code-review", "Code Review", []),
     "phase-browser": ("browser-verification", "Browser Verification", []),
     "phase-deploy": ("deploy-verification", "Deploy Verification", []),
@@ -1043,12 +1042,6 @@ def assemble_sections(pipeline_mode, sections_dir, init_done, is_resume,
                           load_section(sections_dir,
                                        "test-failure-recovery-agent.md")))
 
-    # --- Critic: Code Challenge (only if critic enabled, agent tiers) ---
-    if critic_enabled and pipeline_mode in ("standard", "full"):
-        sections.append(("phase-critic-code",
-                          load_section(sections_dir,
-                                       "phase-critic-code.md")))
-
     # --- AC Verification Checklist (all tiers) ---
     ac_checklist_path = os.path.join(sections_dir, "ac-verification-checklist.md")
     if os.path.isfile(ac_checklist_path):

package/bundled/dev-pipeline/templates/bootstrap-tier2.md

@@ -228,33 +228,6 @@ grep -q "## Implementation Log" .prizmkit/specs/{{FEATURE_SLUG}}/context-snapsho
 ```
 If GATE:MISSING — send message to Dev (re-spawn if needed): "Write the '## Implementation Log' section to context-snapshot.md before I can proceed to review. Include: files changed/created, key decisions, deviations from plan, notable discoveries."
 
-{{IF_CRITIC_ENABLED}}
-### Phase 4.5: Code Challenge — Critic Agent
-
-**Guard**: Verify critic agent file exists before spawning:
-```bash
-ls {{CRITIC_SUBAGENT_PATH}} 2>/dev/null && echo "CRITIC:READY" || echo "CRITIC:MISSING"
-```
-If CRITIC:MISSING — skip Phase 4.5 entirely and proceed to Phase 5. Log: "Critic agent not installed — skipping Code Challenge."
-
-Spawn Critic agent (Agent tool, subagent_type="prizm-dev-team-critic", mode="plan", run_in_background=false).
-
-Prompt:
-> "Read {{CRITIC_SUBAGENT_PATH}}. For feature {{FEATURE_ID}} (slug: {{FEATURE_SLUG}}):
-> **MODE: Code Challenge**
-> 1. Read `.prizmkit/specs/{{FEATURE_SLUG}}/context-snapshot.md` — Implementation Log section shows what Dev changed.
-> 2. Read `.prizm-docs/root.prizm` and relevant module docs for RULES/PATTERNS.
-> 3. Read the actual source files changed (from Implementation Log).
-> 4. Read comparable existing source files in the same module for style comparison.
-> 5. Challenge code integration quality: style fit, robustness, existing code cohesion, hidden impact.
-> Write `.prizmkit/specs/{{FEATURE_SLUG}}/challenge-report.md` (overwrite) with findings (or 'No significant challenges')."
-
-Wait for Critic to return.
-- Read challenge-report.md. For items marked CRITICAL/HIGH: spawn Dev to fix, then proceed to Review.
-
-**CP-3.5**: Code challenges reviewed and resolved.
-{{END_IF_CRITIC_ENABLED}}
-
 ### Phase 5: Review + Test — Reviewer Subagent
 
 Spawn Reviewer subagent (Agent tool, subagent_type="prizm-dev-team-reviewer", run_in_background=false).

package/bundled/dev-pipeline/templates/bootstrap-tier3.md

@@ -293,33 +293,6 @@ Wait for Dev to return. **If Dev times out before all tasks are `[x]`**:
 
 All tasks `[x]`, tests pass.
 
-{{IF_CRITIC_ENABLED}}
-### Phase 4.5: Code Challenge — Critic Agent
-
-**Guard**: Verify critic agent file exists before spawning:
-```bash
-ls {{CRITIC_SUBAGENT_PATH}} 2>/dev/null && echo "CRITIC:READY" || echo "CRITIC:MISSING"
-```
-If CRITIC:MISSING — skip Phase 4.5 entirely and proceed to Phase 5. Log: "Critic agent not installed — skipping Code Challenge."
-
-Spawn Critic agent (Agent tool, subagent_type="prizm-dev-team-critic", mode="plan", run_in_background=false).
-
-Prompt:
-> "Read {{CRITIC_SUBAGENT_PATH}}. For feature {{FEATURE_ID}} (slug: {{FEATURE_SLUG}}):
-> **MODE: Code Challenge**
-> 1. Read `.prizmkit/specs/{{FEATURE_SLUG}}/context-snapshot.md` — Implementation Log section shows what Dev changed.
-> 2. Read `.prizm-docs/root.prizm` and relevant module docs for RULES/PATTERNS.
-> 3. Read the actual source files changed (from Implementation Log).
-> 4. Read comparable existing source files in the same module for style comparison.
-> 5. Challenge code integration quality: style fit, robustness, existing code cohesion, hidden impact.
-> Write `.prizmkit/specs/{{FEATURE_SLUG}}/challenge-report.md` (overwrite) with findings (or 'No significant challenges')."
-
-Wait for Critic to return.
-- Read challenge-report.md. For items marked CRITICAL/HIGH: spawn Dev to fix, then proceed to Review.
-
-**CP-3.5**: Code challenges reviewed and resolved.
-{{END_IF_CRITIC_ENABLED}}
-
 ### Phase 5: Review + Test — Reviewer Agent
 
 Spawn Reviewer agent (Agent tool, subagent_type="prizm-dev-team-reviewer", run_in_background=false).

package/bundled/dev-pipeline/templates/bug-fix-list-schema.json

@@ -175,7 +175,7 @@
           },
           "critic": {
             "type": "boolean",
-            "description": "Enable adversarial critic review for this bug fix. Default: true for high severity bugs, false for others.",
+            "description": "Enable adversarial plan challenge before implementation. Default: true for high severity bugs, false for others.",
             "default": false
           },
           "critic_count": {

package/bundled/dev-pipeline/templates/feature-list-schema.json

@@ -147,7 +147,7 @@
           },
           "critic": {
             "type": "boolean",
-            "description": "Enable adversarial critic review for this feature. Default: false.",
+            "description": "Enable adversarial plan challenge before implementation. Default: false.",
             "default": false
           },
           "critic_count": {

package/bundled/dev-pipeline/templates/refactor-list-schema.json

@@ -191,7 +191,7 @@
           },
           "critic": {
             "type": "boolean",
-            "description": "Enable adversarial critic review for this refactor. Default: true for critical/high priority refactors, false for others.",
+            "description": "Enable adversarial plan challenge before implementation. Default: true for critical/high priority refactors, false for others.",
             "default": false
           },
           "critic_count": {

package/bundled/skills/_metadata.json

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

package/package.json

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

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

@@ -1,13 +0,0 @@
-"Read {{CRITIC_SUBAGENT_PATH}}. For feature {{FEATURE_ID}} (slug: {{FEATURE_SLUG}}):
-**MODE: Code Challenge**
-1. Read `.prizmkit/specs/{{FEATURE_SLUG}}/context-snapshot.md` — Implementation Log section shows what Dev changed.
-2. Read `.prizm-docs/root.prizm` and relevant module docs for RULES/PATTERNS.
-3. Read the actual source files changed (from Implementation Log).
-4. Read comparable existing source files in the same module for style comparison.
-5. Read test files created/modified (from Implementation Log) — evaluate test quality:
-   - Coverage adequacy: Do tests cover all code paths modified? Target: {{COVERAGE_TARGET}}%
-   - Test brittleness: Do tests pass consistently (not flaky)? Check Implementation Log for test re-runs
-   - Edge case handling: Are boundary conditions tested? Are error paths tested?
-6. Challenge code integration quality: style fit, robustness, existing code cohesion, hidden impact.
-7. Challenge test quality: coverage, brittleness, edge case handling.
-Write `.prizmkit/specs/{{FEATURE_SLUG}}/challenge-report.md` (overwrite) with findings (or 'No significant challenges')."

package/bundled/dev-pipeline/templates/sections/phase-critic-code.md

@@ -1,25 +0,0 @@
-### Code Challenge — Critic Agent
-
-**Guard**: Verify critic agent file exists before spawning:
-```bash
-ls {{CRITIC_SUBAGENT_PATH}} 2>/dev/null && echo "CRITIC:READY" || echo "CRITIC:MISSING"
-```
-If CRITIC:MISSING — skip this phase entirely and proceed. Log: "Critic agent not installed — skipping Code Challenge."
-
-**Spawn Agent**:
-| Parameter | Value |
-|-----------|-------|
-| subagent_type | prizm-dev-team-critic |
-| mode | plan |
-| run_in_background | false |
-
-**Prompt**:
-> {{AGENT_PROMPT_CRITIC_CODE_CHALLENGE}}
-
-Wait for Critic to return.
-- Read challenge-report.md. For items marked CRITICAL/HIGH: spawn Dev to fix, then proceed to Review.
-
-**CP-3.5**: Code challenges reviewed and resolved.
-
-
-**Checkpoint update**: Update `workflow-checkpoint.json` — set step `critic-code-review` to `"completed"`.