prizmkit 1.1.114 → 1.1.115

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.115",
   "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')."

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

@@ -1,22 +0,0 @@
-### Plan Challenge — Critic Agent
-
-**Guard**: Verify critic agent file exists before spawning:
-
-```bash
-{{RUNTIME_HELPER_CMD}} artifact exists {{CRITIC_SUBAGENT_PATH}} --exists-marker CRITIC:READY --missing-marker CRITIC:MISSING
-```
-
-If `CRITIC:MISSING`, mark `critic-plan-review` as `skipped` and continue.
-
-**Focus**: Challenge the bug diagnosis and fix plan before implementation:
-- Is the root cause actually supported by the evidence?
-- Does the reproduction test prove the bug before the fix?
-- Is the fix minimal, or does it mask the symptom?
-- Are adjacent regressions likely?
-- Does manual/hybrid verification policy match `{{VERIFICATION_TYPE}}`?
-
-Spawn `prizm-dev-team-critic` with default/no worktree isolation. Do not request AI tool-created worktree isolation.
-
-The Critic writes `.prizmkit/bugfix/{{BUG_ID}}/challenge-report.md`. Resolve CRITICAL/HIGH findings before implementation, or document why the plan stands.
-
-**Checkpoint update**: Set step `critic-plan-review` to `completed` after challenges are resolved, or `skipped` when critic is unavailable.

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

@@ -1,61 +0,0 @@
-### Plan Challenge — Critic Agent(s)
-
-**Guard**: Verify critic agent file exists before spawning:
-```bash
-{{RUNTIME_HELPER_CMD}} artifact exists {{CRITIC_SUBAGENT_PATH}} --exists-marker CRITIC:READY --missing-marker CRITIC:MISSING
-```
-If CRITIC:MISSING — skip this phase entirely and proceed. Log: "Critic agent not installed — skipping Plan Challenge."
-
-**Choose ONE path based on `{{CRITIC_COUNT}}`:**
-
-**Agent spawn failure policy**:
-- If spawning Critic fails with team/config/lock errors, retry at most once.
-- If the second attempt fails, do not keep spawning variants. Either create the required team once (when team tooling is available) or perform the plan challenge inline and write the required challenge report yourself.
-- Record the fallback in the report; do not burn multiple minutes on repeated identical spawn failures.
-
-**No silent report polling**:
-- Do NOT run a long no-output loop waiting for `challenge-report*.md`.
-- If you need to wait for a report file, use a short bounded check (≤120s) that prints elapsed time and reports present on every iteration.
-- If reports are still missing after the bounded check, request one status update; if still missing, perform the missing challenge lens inline and continue.
-
-**If {{CRITIC_COUNT}} = 1 → Single Critic** (skip to CP-2.5 after this):
-
-**Spawn Agent**:
-| Parameter | Value |
-|-----------|-------|
-| subagent_type | prizm-dev-team-critic |
-| mode | plan |
-| run_in_background | false |
-| isolation | default/no worktree; do not request worktree isolation |
-
-No-worktree boundary: this prevents AI tool-created `.claude/worktrees/...` subagent worktrees. It does not disable PrizmKit pipeline-managed linked git worktrees under `.prizmkit/state/worktrees/...`, which are controlled separately by `USE_WORKTREE`.
-
-**Prompt**:
-> {{AGENT_PROMPT_CRITIC_PLAN_CHALLENGE}}
-
-**If {{CRITIC_COUNT}} = 3 → Multi-Critic Voting** (skip Single Critic above):
-
-Spawn 3 Critic agents in PARALLEL (issue all 3 Agent tool calls in the SAME message turn). Do NOT wait for one before spawning the next. Each with mode="plan", run_in_background=false, and default/no worktree isolation; do not request worktree isolation.
-
-No-worktree boundary: default/no worktree isolation prevents AI tool-created `.claude/worktrees/...` subagent worktrees. It does not disable PrizmKit pipeline-managed linked git worktrees under `.prizmkit/state/worktrees/...`, which are controlled separately by `USE_WORKTREE`.
-
-Critic-A prompt (append to base prompt above):
-> "**Focus Lens: Architecture & Scalability.** Prioritize: architectural pattern fit, scalability implications, over-engineering risks, component boundary design.
-> Write `.prizmkit/specs/{{FEATURE_SLUG}}/challenge-report-A.md`."
-
-Critic-B prompt (append to base prompt above):
-> "**Focus Lens: Data Model & Edge Cases.** Prioritize: data model design fit, entity relationships, edge cases in business logic, missing boundary conditions.
-> Write `.prizmkit/specs/{{FEATURE_SLUG}}/challenge-report-B.md`."
-
-Critic-C prompt (append to base prompt above):
-> "**Focus Lens: Security & Performance.** Prioritize: security attack surface, authentication/authorization gaps, performance bottlenecks, resource leaks.
-> Write `.prizmkit/specs/{{FEATURE_SLUG}}/challenge-report-C.md`."
-
-After all critics return, read all 3 reports:
-- Challenge raised by **2/3 or more** critics → **must respond** (adjust plan or justify why not)
-- Challenge raised by **1/3 only** → logged in context-snapshot but not blocking
-- Max 1 plan revision round.
-
-**CP-2.5**: Plan challenges reviewed and resolved.
-
-

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

@@ -1,38 +0,0 @@
-### Plan Challenge — Critic Agent
-
-**Guard**: Verify critic agent file exists before spawning:
-```bash
-{{RUNTIME_HELPER_CMD}} artifact exists {{CRITIC_SUBAGENT_PATH}} --exists-marker CRITIC:READY --missing-marker CRITIC:MISSING
-```
-If CRITIC:MISSING — skip this phase entirely and proceed. Log: "Critic agent not installed — skipping Plan Challenge."
-
-**Spawn Agent**:
-| Parameter | Value |
-|-----------|-------|
-| subagent_type | prizm-dev-team-critic |
-| mode | plan |
-| run_in_background | false |
-| isolation | default/no worktree; do not request worktree isolation |
-
-No-worktree boundary: this prevents AI tool-created `.claude/worktrees/...` subagent worktrees. It does not disable PrizmKit pipeline-managed linked git worktrees under `.prizmkit/state/worktrees/...`, which are controlled separately by `USE_WORKTREE`.
-
-**Prompt**:
-> {{AGENT_PROMPT_CRITIC_PLAN_CHALLENGE}}
-
-**Agent spawn failure policy**:
-- If spawning Critic fails with team/config/lock errors, retry at most once.
-- If the second attempt fails, do not keep spawning variants. Either create the required team once (when team tooling is available) or perform the plan challenge inline and write `challenge-report.md` yourself.
-- Record the fallback in the report; do not burn multiple minutes on repeated identical spawn failures.
-
-**No silent report polling**:
-- Do NOT run a long no-output loop waiting for `challenge-report.md`.
-- If you need to wait for the report file, use a short bounded check (≤120s) that prints elapsed time and whether the report exists on every iteration.
-- If the report is still missing after the bounded check, request one status update; if still missing, perform the challenge inline and continue.
-
-Wait for Critic to return.
-- Read challenge-report.md. For items marked CRITICAL/HIGH: decide whether to adjust plan.md or document why the plan stands.
-- Max 1 plan revision round.
-
-**CP-2.5**: Plan challenges reviewed and resolved.
-
-

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

@@ -1,22 +0,0 @@
-### Plan Challenge — Critic Agent
-
-**Guard**: Verify critic agent file exists before spawning:
-
-```bash
-{{RUNTIME_HELPER_CMD}} artifact exists {{CRITIC_SUBAGENT_PATH}} --exists-marker CRITIC:READY --missing-marker CRITIC:MISSING
-```
-
-If `CRITIC:MISSING`, mark `critic-plan-review` as `skipped` and continue.
-
-**Focus**: Challenge behavior preservation and plan safety before implementation:
-- Is observable behavior clearly defined and protected?
-- Do existing/new tests cover the behavior affected by this refactor?
-- Is the plan too broad for the stated scope?
-- Are file moves/renames safe for imports, public APIs, and integrations?
-- Is rollback realistic?
-
-Spawn `prizm-dev-team-critic` with default/no worktree isolation. Do not request AI tool-created worktree isolation.
-
-The Critic writes `.prizmkit/refactor/{{REFACTOR_ID}}/challenge-report.md`. Resolve CRITICAL/HIGH findings before implementation, or document why the plan stands.
-
-**Checkpoint update**: Set step `critic-plan-review` to `completed` after challenges are resolved, or `skipped` when critic is unavailable.

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

@@ -1,44 +0,0 @@
-# Adversarial Critic Review & Browser Verification
-
-## Adversarial Critic Review (Testing Defaults)
-
-All bug fixes support optional critic review for additional quality assurance. The planner enables critic review by default for critical/high severity bugs and leaves it disabled for medium/low bugs; users can override per bug.
-
-### Default Critic Behavior
-
-| Severity | `critic` | `critic_count` | Rationale |
-|----------|----------|----------------|-----------|
-| critical | `true` | `1` | Single critic review for critical bugs |
-| high | `true` | `1` | Single critic review for high-severity bugs |
-| medium | `false` | (omitted) | Skip critic for medium-severity bugs |
-| low | `false` | (omitted) | Skip critic for low-severity bugs |
-
-- `critic: true` — Enable adversarial review after fix implementation
-- `critic_count: 1` — Single critic agent reviews the fix
-- Critic verifies: fix addresses root cause, no regressions introduced, acceptance criteria met
-
-**User Override**: During Phase 2 or Phase 3, users can opt to enable/disable critic on a per-bug basis.
-
-## Browser Verification
-
-Bug fixes can use `browser_interaction` when the bug is reproducible through a UI. The `verification_type` field still declares the overall verification mode:
-
-- `verification_type: automated` — Use unit/integration tests to verify the fix
-- `verification_type: manual` — Describe manual testing steps in acceptance criteria (including any browser verification steps)
-- `verification_type: hybrid` — Combine automated tests with manual browser verification steps
-
-For UI-related bugs, add `browser_interaction.verify_steps` when concrete browser goals are known. Also keep acceptance criteria measurable so the bugfix session can verify the fix without asking the user.
-
-### Example
-
-```
-Bug Title: Login error message not displaying
-Verification Type: manual
-Acceptance Criteria:
-  1. Navigate to /login with invalid credentials
-  2. Verify error message "Invalid email or password" appears below the email field
-  3. Verify error message is red (#FF0000)
-  4. Verify form fields are still enabled and can be re-submitted
-```
-
-The bugfix pipeline AI will use these criteria during manual verification.