prizmkit 1.1.123 → 1.1.125

package/bundled/skills/prizmkit-code-review/SKILL.md

@@ -1,166 +1,169 @@
 ---
 name: "prizmkit-code-review"
-description: "Iterative independent review-fix loop against spec, plan, workspace changes, and test evidence. Establishes a verified review snapshot using any platform-supported subagent strategy while keeping review judgment separate from Main-Agent filtering and fixes. Use after /prizmkit-implement as a Full path quality gate or when the user asks to review, check code, validate implementation, or decide whether changes are ready to commit. Loops until PASS or max 3 rounds. (project)"
+description: "Run a practical convergence-driven independent code review against the current spec, plan, workspace changes, applicable rules, contracts, and test evidence. Use after /prizmkit-implement, before commit when review is required, or whenever the user asks to review code, validate an implementation, find defects, assess regressions, or decide whether changes are ready. Each completed round launches one fresh read-only non-delegating Reviewer; the Main Agent filters findings, directly repairs accepted issues, and repeats until no accepted finding remains or the ten-round safety fuse stops review. (project)"
 ---
 
 # PrizmKit Code Review
 
-Run an iterative review-fix loop against the current change. Keep review judgment independent from fix application: an independent read-only Reviewer evaluates a verified snapshot, then the Main Agent filters findings and applies accepted fixes.
+Run an independent review-fix loop over the complete current change. A fresh Reviewer discovers candidate defects; the Main Agent adjudicates every finding, directly repairs accepted issues, and owns the final verdict.
 
-Review modes:
-- `independent-reviewer-verified-snapshot`: an independent Reviewer verified that its review snapshot is equivalent to the Main Agent's current change.
-- `not-run-no-changes`: no workspace changes were detected.
+## When to Use
 
-The skill defines review invariants rather than platform tool parameters. Choose any platform-supported subagent launch and snapshot transport strategy that satisfies `${SKILL_DIR}/references/reviewer-workspace-protocol.md`.
-
-If no independent Reviewer can receive and verify an equivalent snapshot, stop normal review and report the workspace verification failure. Do not replace the independent review with Main-Agent self-review because that would remove the separation between judgment and implementation.
-
-### When to Use
 - After `/prizmkit-implement` as the Full path quality gate
-- For Fast path when risk, scope, or the user warrants review
-- When the user says "review", "check code", "review my implementation", or "is it ready to commit"
-- Before `/prizmkit-committer` when the chosen lifecycle path requires review
+- For Fast path when scope, risk, or the user warrants review
+- When the user asks to review code, validate implementation, find defects, check regressions, or assess commit readiness
+- Before `/prizmkit-committer` when the selected lifecycle requires review
+
+## When Not to Use
 
-### When NOT to Use
-- Direct edit or low-risk Fast path where review is not required
-- No `spec.md` or `plan.md` exists and there is no clear task goal to review against
-- Trivial typo, formatting, or config-only changes that the user wants committed directly
+- Direct edit or low-risk Fast path where review is intentionally skipped
+- No task goal, specification, plan, or other review contract can be identified
+- Trivial changes the user explicitly wants committed without review
 
 ## Input
 
 | Parameter | Required | Description |
-|-----------|----------|-------------|
-| `artifact_dir` | No | Directory containing `spec.md` and `plan.md`. If omitted, scan `.prizmkit/` subdirectories for the most recently modified directory with a completed `plan.md`. When invoked as a handoff step, reuse the caller's `artifact_dir` rather than re-detecting. |
+|---|---|---|
+| `artifact_dir` | No | Directory containing `spec.md` and `plan.md`. Reuse a caller-provided directory. Otherwise locate the most recently modified completed change artifact under `.prizmkit/`. |
 
-## Phase 0: Context and Snapshot
+## Required Assets
 
-1. Read `spec.md` from the artifact directory and extract goals plus acceptance criteria.
-2. Read `plan.md` from the artifact directory and extract architecture decisions plus completed tasks.
-3. Read a scoped `/prizmkit-test` report when present:
-   - If `{artifact_dir}/test-report-path.txt` exists, read the pointed report.
-   - Extract Scope, Generated / Updated Tests, In-Scope Failures, Baseline Failures, Out of Scope Gaps, Boundary Matrix / Boundary Completion Gate, and Verdict when present.
-   - If no report exists, pass `No scoped /prizmkit-test report found` as informational context. Treat missing tests as a finding only when the lifecycle path required testing before review.
-4. Read dev rules when configured: load `.prizmkit/prizm-docs/root.prizm`, then referenced `.prizmkit/rules/<layer>-rules.md` files if any exist.
-5. Capture the current workspace manifest and review payload according to `${SKILL_DIR}/references/reviewer-workspace-protocol.md`. Include:
-   - baseline repository and revision identity
-   - `git status`, `git diff`, and `git diff --cached` evidence
-   - staged, unstaged, untracked, deleted, and renamed path inventory
-   - changed content and stable content identities sufficient to detect missing, stale, or mixed snapshots
-   - relevant root Prizm rules and plan decisions
-6. If no changes are detected, skip Phase 1 and write `review-report.md` with verdict PASS, rounds 0, review mode `not-run-no-changes`, and snapshot verification `NOT_APPLICABLE`.
+Read before starting the loop:
 
-## Phase 1: Review-Fix Loop
+- `${SKILL_DIR}/references/reviewer-agent-prompt.md`: complete Reviewer input and output contract
+- `${SKILL_DIR}/references/review-report-template.md`: final report contract
+- `${SKILL_DIR}/assets/reviewer-role.json`: semantic read-only and non-delegating Reviewer boundary used by platform adapters
 
-### Gate Mode Detection
+The contract defines semantic capabilities rather than depending on a platform-specific tool or Agent name.
 
-Check Python availability:
+## Phase 0: Collect Review Context
 
-```bash
-python3 --version 2>/dev/null && echo "SCRIPT_MODE" || echo "TEXT_MODE"
-```
+1. Read `spec.md` and extract goals plus acceptance criteria when it exists.
+2. Read `plan.md` and extract architecture decisions plus completed tasks when it exists.
+3. Read scoped `/prizmkit-test` evidence when `{artifact_dir}/test-report-path.txt` exists. Preserve its verdict, in-scope failures, baseline failures, gaps, and boundary evidence.
+4. Read `.prizmkit/prizm-docs/root.prizm`, applicable progressive docs, and project rules.
+5. Inspect and capture the complete current Git change:
+   - staged and unstaged tracked changes;
+   - untracked files;
+   - deleted and renamed files;
+   - the base revision and relevant unchanged callers, dependents, contracts, and tests.
+6. Prepare the Reviewer input with staged and unstaged Git diffs plus the full content of every untracked file. Include deleted and renamed states explicitly. The Reviewer role may have file-reading capabilities without shell or Git execution, so a changed-path inventory alone is insufficient.
+7. If no changes exist, skip Reviewer launch, write a zero-round `PASS` report, and finish.
 
-- Script mode: use `${SKILL_DIR}/scripts/check_loop.py` for round tracking, max-round enforcement, and divergence detection.
-- Text mode: follow §Text Fallback Constraints manually with identical behavior.
+### Checkout Access
 
-### Step 0: Initialize Loop State
+Prefer a Reviewer that can read the active checkout directly. Give it the repository path, staged and unstaged Git diffs, the full content of every untracked file, and the changed-path inventory. Direct checkout access lets the Reviewer perform targeted surrounding-context reads without requiring shell or Git execution.
 
-- `round = 1`
-- `max_rounds = 3`
-- `findings_history = []`
-- `review_mode = independent-reviewer-verified-snapshot` after snapshot verification succeeds
+If the platform forces an isolated worktree:
 
-### Step 1: Establish Independent Review
+1. provide the same staged and unstaged diffs, untracked file contents, and changed-path states used for active-checkout review;
+2. tell the Reviewer to use the worktree only for baseline and surrounding-context reads;
+3. clearly label supplied changed content separately from unchanged context;
+4. do not require the Reviewer to prove that the two physical checkouts are identical.
 
-Use the skill-owned review contract:
+If required changed content is missing, supply it before consuming the review. If essential context cannot be made available, return `BLOCKED` with a concise infrastructure reason.
+
+## Phase 1: Convergence Loop
+
+Track only:
 
 ```yaml
-prompt_reference: ${SKILL_DIR}/references/reviewer-agent-prompt.md
-workspace_protocol: ${SKILL_DIR}/references/reviewer-workspace-protocol.md
-reviewer_contract: independent, read-only, workspace-equivalent
+round: 1
+completed_rounds: 0
+final_verdict: null
+findings: []
 ```
 
-1. Read both references and fill the Reviewer prompt with Phase 0 context plus the workspace manifest and payload.
-2. Choose a subagent launch and snapshot transport strategy supported by the current platform. Strategy choice belongs to the Main Agent because platforms expose different capabilities; do not treat a particular tool parameter, checkout layout, branch name, or transport as part of the skill contract.
-3. Require the Reviewer to verify snapshot equivalence before reviewing. Different physical paths or execution environments are acceptable when the verified review view is content-equivalent to the captured Main-Agent workspace.
-4. If the Reviewer returns `WORKSPACE_MISMATCH`, repair or replace the strategy only when equivalence can be established safely. Otherwise write a `NEEDS_FIXES` report with the verification failure unresolved and stop; do not perform Main-Agent self-review.
-5. After the Main Agent applies fixes, capture and verify a fresh snapshot for the next round because the previous snapshot is stale by definition.
+The safety fuse is fixed at ten completed rounds. It is not caller-configurable and never converts unresolved defects into `PASS`.
 
-### Step 2: Run Review
+### Step 1: Launch One Fresh Reviewer
 
-Round context:
-- Round 1: examine all current changes comprehensively.
-- Round 2+: verify prior fixes, look for regressions introduced by the fixes, and identify accepted findings that remain.
+1. Select an execution mechanism that actually limits the Reviewer to read-only inspection and prevents workspace mutation, downstream execution creation, delegation, orchestration re-entry, and skill invocation.
+2. Launch exactly one fresh foreground Reviewer for this round.
+3. Provide the complete current review input using `${SKILL_DIR}/references/reviewer-agent-prompt.md`.
+4. Do not provide previous-round findings, verdicts, filtering decisions, rejection reasons, or repair explanations.
 
-Review result:
-- `PASS`: no findings.
-- `NEEDS_FIXES`: one or more findings with severity, dimension, location, problem, and suggested fix.
-- `WORKSPACE_MISMATCH`: snapshot equivalence was not established; this is a review transport failure, not a code verdict.
+Do not substitute Main-Agent self-review. If the Reviewer cannot start or exits abnormally, return `BLOCKED`. This does not consume a completed round.
 
-### Step 3: Loop Exit Gate
+### Step 2: Complete Independent Review
 
-Call the gate only when:
+The Reviewer evaluates the complete current change, not only the latest repair. It checks requirements, implementation completeness, concrete failure scenarios, error handling, security, data integrity, concurrency, contracts, compatibility, tests, and project rules.
 
-1. Review returned `PASS`.
-2. The Main Agent has filtered `NEEDS_FIXES` findings.
+It may inspect unchanged callers, dependents, shared patterns, and tests when needed to establish a concrete issue. Prefer targeted read-only inspection over broad repository scans or redundant verification.
 
-Do not call the gate for `NEEDS_FIXES` before filtering because `accepted_count` is not known. Handle `WORKSPACE_MISMATCH` through Step 1 rather than passing it to the code-verdict gate.
+A usable result is either:
 
-Script mode invocation:
+- `PASS`: no concrete finding;
+- `FINDINGS`: one or more structured candidate defects.
 
-```bash
-echo '{"reviewer_result":"NEEDS_FIXES","accepted_count":2,"findings_count":3,"round":1,"findings_history":[],"max_rounds":3,"filtering_done":true}' | python3 ${SKILL_DIR}/scripts/check_loop.py
+If output is partial, malformed, or cannot be understood safely, return `BLOCKED`. This does not consume a completed round.
+
+### Step 3: Main Agent Filters Findings
+
+A usable Reviewer result completes the current round. Increment `completed_rounds` before adjudication.
+
+For every finding, classify it as:
+
+- `accepted`: current code and governing evidence support the concrete failure scenario;
+- `rejected`: code, requirements, contracts, or tests concretely disprove it, or show that it is outside scope with no regression path.
+
+Record a concise evidence-based reason for every rejected finding. Do not reject a finding because it is inconvenient, uncertain, low severity, or expensive to repair. When a potentially real defect cannot be refuted, accept it or leave it unresolved.
+
+Apply these rules exactly:
+
+```text
+Reviewer returns PASS                         -> PASS
+Reviewer returns findings and accepted = 0  -> PASS
+Reviewer returns findings and accepted > 0  -> repair or stop
 ```
 
-The gate output determines whether to end the loop. If `divergenceWarning` is true, warn the user that the loop may not be converging.
+When all findings are rejected, `accepted = 0`; the review is `PASS` because the Reviewer found no valid defect. Do not launch another Reviewer merely because the raw Reviewer result contained findings.
 
-### Text Fallback Constraints
+### Step 4: Repair or Stop
 
-When Python is unavailable, apply these rules manually:
+When `accepted > 0`:
 
-1. `PASS` exits with verdict PASS.
-2. `NEEDS_FIXES` continues to filtering before any all-rejected or max-round exit.
-3. If all findings are rejected after filtering, exit with verdict PASS.
-4. If `round >= 3` after filtering and accepted findings remain, exit with verdict NEEDS_FIXES.
-5. If findings count strictly increases for 3 consecutive recorded rounds, warn about possible divergence.
-6. Record `findings_history` once per round and increment `round` after a complete review/filter/fix cycle.
+1. If `completed_rounds` is ten, return `NEEDS_FIXES` and record the accepted findings as unresolved.
+2. Otherwise the Main Agent directly repairs every accepted finding that can be fixed safely within scope. Do not launch a Fixer or implementation subagent.
+3. Run the narrowest meaningful verification for the repair.
+4. If a finding cannot be repaired safely, return `NEEDS_FIXES` and record why it remains unresolved.
+5. Recollect the complete current change, increment `round`, and launch a fresh Reviewer with no previous-round findings or repair history.
 
-### Step 4: Main Agent Filters Findings
+## Phase 2: Persist Final Report
 
-For each finding, decide whether it is reasonable:
+Write exactly one required review artifact:
 
-- Is the finding relevant to the current changes?
-- Is it a real problem rather than a subjective style preference?
-- Would the fix improve the code without broad out-of-scope refactoring?
-- Does the finding conflict with the spec, plan, dev rules, or current test evidence?
+```text
+{artifact_dir}/review-report.md
+```
 
-Output per finding:
-- Accepted: queue for direct Main Agent fix work.
-- Rejected: record a short reason such as out of scope, not a defect, or too risky for the current task.
+Use `${SKILL_DIR}/references/review-report-template.md`. The report records:
 
-After filtering, call the Loop Exit Gate. If `endLoop=true`, proceed to Phase 2.
+- `PASS`, `NEEDS_FIXES`, or `BLOCKED`;
+- completed round count;
+- findings and their `fixed`, `rejected`, or `unresolved` disposition;
+- a concise final summary;
+- an infrastructure reason when blocked.
 
-### Step 5: Main Agent Applies Accepted Fixes
+Do not create a separate persisted review state file. Raw Reviewer output remains in the session log.
 
-The Main Agent applies accepted findings directly in its current workspace. Keeping fix ownership with the Main Agent prevents the read-only Reviewer from becoming a second, conflicting implementation authority.
+The report may be rendered directly or with the optional helper by sending minimal JSON on standard input:
 
-If an accepted finding cannot be fixed safely within scope, record the reason and carry the finding into `review-report.md` as unresolved.
+```bash
+python3 ${SKILL_DIR}/scripts/render_review_report.py \
+  {artifact_dir}/review-report.md < review-report-input.json
+```
 
-After fixes are complete, record results, increment the round, capture a fresh workspace snapshot, and return to Step 1.
+The input may be transient; it is not a required artifact.
 
-## Phase 2: Output
+## Final Outcomes
 
-Write `review-report.md` to the artifact directory, including no-change PASS and workspace-verification failure results. Read `${SKILL_DIR}/references/review-report-template.md` for the full output format.
+- `PASS`: no changes existed, the Reviewer returned `PASS`, or a completed round left `accepted = 0`, including when all findings are rejected.
+- `NEEDS_FIXES`: accepted findings remain unresolved or the tenth completed round still has accepted findings.
+- `BLOCKED`: Reviewer execution or essential review input failed before a usable result was obtained.
 
-Required report fields:
-- Verdict: `PASS` or `NEEDS_FIXES`
-- Review Mode: `independent-reviewer-verified-snapshot` or `not-run-no-changes`
-- Reviewer Strategy: concise strategy summary without relying on platform-specific parameter names
-- Snapshot Verification: `VERIFIED`, `FAILED`, or `NOT_APPLICABLE`
-- Snapshot Identity: manifest identity or failure reason
-- Rounds and total findings
-- Fixed, rejected, and unresolved findings
-- Final summary
+Completion handoff:
 
-Completion summary:
-- `PASS`: hand off to `/prizmkit-retrospective` when docs or durable knowledge changed, otherwise `/prizmkit-committer`.
-- `NEEDS_FIXES`: inform the caller of unresolved code findings or snapshot-verification blockers.
+- `PASS`: run `/prizmkit-retrospective` when structural docs or durable knowledge changed; otherwise proceed to `/prizmkit-committer`.
+- `NEEDS_FIXES`: report unresolved code findings and stop.
+- `BLOCKED`: report the infrastructure reason and allow retry without consuming the code-convergence budget.

package/bundled/skills/prizmkit-code-review/assets/reviewer-role.json

@@ -0,0 +1,19 @@
+{
+  "protocol_version": 2,
+  "role_name": "prizmkit-code-reviewer",
+  "description": "Use only as the one fresh independent read-only Reviewer for a completed /prizmkit-code-review round.",
+  "observational_capabilities": [
+    "read-files",
+    "search-content",
+    "search-paths"
+  ],
+  "unavailable_capabilities": [
+    "workspace-mutation",
+    "shell-execution",
+    "downstream-execution-creation",
+    "delegation-equivalent-behavior",
+    "orchestration-reentry",
+    "skill-invocation"
+  ],
+  "execution_mode": "foreground-independent-review"
+}

package/bundled/skills/prizmkit-code-review/references/review-report-template.md

@@ -1,37 +1,40 @@
 # Review Report Output Template
 
-Used in Phase 2 of `/prizmkit-code-review`. Write `review-report.md` to the artifact directory using this format.
+Write the final result to `{artifact_dir}/review-report.md`. This is the only required persisted review artifact.
 
 ```markdown
 # Review Report
 
-## Verdict: <PASS|NEEDS_FIXES>
-## Review Mode: <independent-reviewer-verified-snapshot|not-run-no-changes>
-## Reviewer Strategy: <platform-selected strategy summary|not-applicable>
-## Snapshot Verification: <VERIFIED|FAILED|NOT_APPLICABLE>
-## Snapshot Identity: <manifest identity or failure reason>
-## Rounds: <number of completed review rounds; use 0 for no-change PASS or pre-review snapshot failure>
-## Total findings: <total> → Fixed: <fixed>, Rejected: <rejected>, Unresolved: <unresolved>
+## Verdict: <PASS|NEEDS_FIXES|BLOCKED>
+## Rounds Completed: <number>
+## Total Findings: <total> → Fixed: <fixed>, Rejected: <rejected>, Unresolved: <unresolved>
 
-## Round <N>
-Findings: <count> | Accepted: <count>, Rejected: <count>
+## Findings
 
 ### Finding <N>: <short title>
+
 - Severity: <high|medium|low>
-- Dimension: <goal-alignment|defect|completeness|consistency|security|test-quality|rules-compliance>
-- Location: <filepath:line or project-level>
+- Location: <filepath:line|project-level>
 - Problem: <what was wrong and why it mattered>
-- Status: <fixed (round N)|rejected — reason|unresolved — reason>
+- Failure Scenario: <concrete input or state>
+- Disposition: <fixed in round N|rejected — concrete evidence|unresolved — reason>
 
-## Final Summary
-<One to three sentences summarizing the review outcome, snapshot verification, and any remaining blocker.>
-```
+## Blocker
 
-For `PASS` with no findings, write `Total findings: 0 → Fixed: 0, Rejected: 0, Unresolved: 0` and either `## Round 0: PASS — no workspace changes to review` or `## Round N: PASS — no issues found`.
+<Include only for BLOCKED: concise infrastructure failure and required action.>
 
-For snapshot verification failure, use verdict `NEEDS_FIXES`, snapshot verification `FAILED`, and record the mismatch as an unresolved review blocker rather than an ordinary code finding.
+## Summary
+
+<One to three sentences covering the final outcome. Do not expose private reasoning traces.>
+```
 
-## Verdict Rules
+## Report Rules
 
-- `PASS`: Reviewer returned no findings from a verified snapshot, no workspace changes existed, or all findings from a verified snapshot were rejected as unreasonable.
-- `NEEDS_FIXES`: Max rounds completed with accepted findings unresolved, or no independent Reviewer could verify an equivalent current snapshot.
+- A no-change review uses zero completed rounds and returns `PASS`.
+- A usable Reviewer result counts as one completed round.
+- Reviewer launch failure, abnormal exit, or unusable output returns `BLOCKED` and does not add a completed round.
+- `PASS` requires no accepted or unresolved finding. This includes a Reviewer `PASS` and a findings result where the Main Agent rejects every finding with concrete evidence.
+- The tenth completed round with accepted findings returns `NEEDS_FIXES`.
+- `BLOCKED` describes review infrastructure or missing essential context, not a code defect.
+- Overwrite the same report on each execution; keep raw round output only in the session log.
+- Do not persist a separate review state file.

package/bundled/skills/prizmkit-code-review/references/reviewer-agent-prompt.md

@@ -1,92 +1,120 @@
-# Reviewer Subagent Prompt Template
+# Reviewer Prompt Contract
 
-Used in Phase 1 Step 1 of `/prizmkit-code-review`. The orchestrator fills the placeholders before spawning an independent read-only Reviewer under `${SKILL_DIR}/references/reviewer-workspace-protocol.md`.
+Use this complete template for every Reviewer execution. Fill the documented placeholders with current-round context. Do not include previous-round findings, verdicts, filtering decisions, rejection reasons, or repair explanations.
 
-```
-You are the independent read-only Reviewer for `/prizmkit-code-review`. Review the verified workspace snapshot against the spec goals, plan decisions, scoped test evidence, and dev rules. Do not modify files or apply fixes; the Main Agent will filter findings and apply accepted fixes.
+```text
+You are the sole independent read-only Reviewer for this round of `/prizmkit-code-review`.
 
-## Spec Goals
-{goals and acceptance criteria from spec.md}
+## Execution Boundary
 
-## Plan Decisions
-{architecture decisions and task list from plan.md}
+Perform the complete review yourself.
 
-## Scoped Test Report
-{summary from artifact_dir/test-report-path.txt and test-report.md, including Scope, Generated / Updated Tests, In-Scope Failures, Baseline Failures, Out of Scope Gaps, Boundary Matrix / Boundary Completion Gate if present, and Verdict. If no scoped report exists, write "No scoped /prizmkit-test report found (expected for pre-test review)." Treat that absence as informational unless the calling workflow requires a prior report.}
+Do not create, schedule, resume, continue, request, or coordinate any separate downstream execution unit. Do not re-enter orchestration, invoke a skill, delegate review work, or ask the Main Agent to create a helper.
 
-## Workspace Manifest
-{repository and baseline identity, review-round identity, changed path inventory and statuses, staged/unstaged composition, untracked content entries, delete markers, rename pairs, and stable content identities captured by the Main Agent}
+Do not modify, create, delete, rename, stage, or commit workspace files. Use only read-only inspection capabilities.
 
-## Review Payload
-{the reviewable representation of every manifest entry, plus clearly identified unchanged context needed to evaluate callers, dependents, or shared patterns}
+If you cannot complete the review in this execution context, return `BLOCKED` with the missing capability or context. Do not delegate and do not return a partial `PASS`.
 
-## Reviewer Strategy
-{concise description of how the current platform made the snapshot available. This is diagnostic context, not a required parameter contract.}
+## Independent Input Boundary
 
-## Workspace Equivalence Guard
-Validate the supplied manifest and payload according to the Reviewer Workspace Protocol before normal review:
-- Every manifest path and state must be represented.
-- Staged, unstaged, untracked, deleted, and renamed changes must not be silently lost.
-- Changed content identities and review-round identity must match.
-- Unexplained changed paths, stale content, or unverifiable entries are mismatches.
+Review only the current state supplied below. No previous-round findings, verdicts, filtering decisions, rejection reasons, repair descriptions, or Reviewer reasoning are part of your input.
 
-Do not reject a snapshot merely because its physical path, checkout layout, branch label, host, or transport differs from the Main Agent's environment. Content equivalence is the invariant.
+## Goals and Acceptance Criteria
 
-If equivalence cannot be proven:
-- Stop before normal review.
-- Do not produce ordinary findings.
-- Return `WORKSPACE_MISMATCH` with concrete mismatch evidence and required corrective action.
+{goals and acceptance criteria from spec.md, or "No spec artifact found; infer the requested behavior from the user goal and current change."}
 
-## Dev Rules
-{rules from .prizmkit/rules/<layer>-rules.md, or "No custom dev rules configured — use general best practices."}
+## Plan and Intended Change
 
-## Review Round
-Round {N}. {round_context}
+{relevant architecture decisions and completed tasks from plan.md, or a concise current task description}
 
-## What to Review
-Use the verified workspace snapshot as the primary review scope:
-- Read the full content of new files.
-- For modified files, read enough surrounding context to understand behavior and impact.
-- Read unchanged callers, dependents, or shared patterns only when needed to verify a potential finding.
-- Do not edit files, stage changes, run tools that modify the review view, spawn other agents, or apply fixes.
-- Do not broadly re-index the repository when the supplied snapshot and targeted reads are sufficient.
+## Applicable Rules and Contracts
 
-## Review Dimensions
-Evaluate the relevant dimensions:
+{relevant Prizm docs, project rules, public and internal contracts, or "No additional project rules identified."}
 
-1. **Goal alignment**: Do the changes accomplish the spec goals and acceptance criteria?
-2. **Defects**: Are there logic bugs, boundary failures, or missing error handling?
-3. **Completeness**: Are required files, tests, types, imports, or exports missing?
-4. **Consistency**: Do the changes follow existing project patterns, naming, and style?
-5. **Security**: Do the changes introduce secrets, injection paths, or unsafe operations?
-6. **Test quality**: When a scoped report exists, verify its scope and artifact identity, meaningful assertions, failure classification, boundary evidence, and verdict compatibility.
-7. **Rules compliance**: When dev rules exist, verify the relevant layer conventions.
+## Test Evidence
 
-## Output Format
-Respond with exactly this structure:
+{current scoped test evidence, or "No scoped test report found."}
+
+## Current Change
+
+- Repository and Reviewer-visible checkout: {path or platform-visible location}
+- Base revision: {base revision when known}
+- Changed paths and states: {staged, unstaged, untracked, deleted, and renamed inventory}
+- Review access: {active checkout, or forced worktree used only for baseline and surrounding context}
+
+## Supplied Git Diff
+
+### Staged
+
+{complete staged diff, or "No staged changes."}
+
+### Unstaged
+
+{complete unstaged diff, or "No unstaged tracked changes."}
+
+## Supplied Untracked Files
+
+{path and full content of every untracked file, or "No untracked files."}
+
+Treat the supplied diffs, path states, and untracked file contents as the authoritative current change. Use read-only file inspection for targeted surrounding context, callers, dependents, contracts, and tests. Do not depend on shell or Git execution being available.
+
+If a platform-forced worktree does not contain the active checkout's dirty or untracked changes, use the worktree only for baseline and surrounding-context reads. You are not required to calculate hashes or prove equivalence between physical checkouts. If an essential changed file or diff is missing from the supplied input, return `BLOCKED` and identify exactly what is missing.
+
+## Complete Current-Change Review
+
+Review the complete current change independently. Do not limit inspection to one file or one suspected issue.
+
+Evaluate applicable dimensions:
 
-### Result: PASS | NEEDS_FIXES | WORKSPACE_MISMATCH
+1. Requirement and acceptance-criteria alignment
+2. Implementation completeness
+3. Correctness and concrete failure scenarios
+4. Error handling
+5. Security and authorization
+6. Data integrity
+7. Transaction and concurrency behavior
+8. Public and internal contracts
+9. Backward compatibility and regression risks
+10. Test adequacy and evidence compatibility
+11. Project-rule compliance
 
-### Snapshot Verification
-- Status: VERIFIED | FAILED
-- Identity: <manifest identity or mismatch summary>
+Use both directions in this review:
+
+- Code-forward: changed code → affected symbols → callers and dependents → concrete failure scenarios
+- Requirement-backward: requirements and contracts → required behavior → implementation path → side effects → test evidence
+
+Read unchanged callers, dependents, shared patterns, or tests when needed. Prefer targeted read-only inspection. Do not perform a broad repository scan without a concrete cross-cutting reason.
+
+## Finding Standard
+
+Report every concrete defect you find, including low-severity issues. Exclude pure style preferences and speculative concerns that lack a concrete wrong behavior, contract violation, regression path, security weakness, data-integrity risk, or misleading test result.
+
+## Output Contract
+
+Respond with exactly this structure:
+
+### Result: PASS | FINDINGS | BLOCKED
 
 ### Findings
-(If PASS, write "No issues found." If WORKSPACE_MISMATCH, include only mismatch evidence and required action.)
 
-#### Finding N
-- **Severity**: high | medium | low
-- **Dimension**: goal-alignment | defect | completeness | consistency | security | test-quality | rules-compliance
-- **Location**: filepath:line (or "project-level")
-- **Problem**: What is wrong and why it matters
-- **Suggestion**: Recommended fix approach
-- **Verification**: How to confirm the fix is correct
+If the result is `PASS`, write:
 
-### Summary
-One to two sentences about the snapshot and overall state of the changes.
-```
+No issues found.
+
+If the result is `BLOCKED`, write only the missing capability or essential context and the required action.
+
+If the result is `FINDINGS`, repeat this block for every concrete issue:
 
-## Round Context
+#### Finding N: <short title>
+- Severity: high | medium | low
+- Location: filepath:line (or "project-level")
+- Problem: concrete wrong behavior and why it matters
+- Failure scenario: inputs or state that produce the wrong result
+- Reasoning: concise evidence connecting the current code to the failure
+- Suggested repair: smallest safe repair approach
+- Verification: how to prove the repair
 
-- Round 1: "This is the first review. Examine all changes comprehensively."
-- Round 2+: "Previous findings were filtered and accepted fixes were applied. Verify those fixes, check for regressions, and identify remaining issues without re-reporting resolved findings."
+### Summary
+
+One or two sentences describing the current change and result. Do not expose private reasoning traces.
+```