prizmkit 1.1.120 → 1.1.122

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

@@ -1,56 +1,53 @@
 ---
 name: "prizmkit-code-review"
-description: "Iterative review-fix loop against spec and plan. Always uses an independent inline reviewer subagent in the active checkout with a skill-owned prompt reference and no worktree/copy/remote isolation; the Main Agent filters findings and applies accepted fixes directly. If the platform cannot start an active-checkout inline reviewer, stop with checkout-isolation incompatibility instead of falling back to Main-Agent self-review. Loops until PASS or max 3 rounds. Use after /prizmkit-implement for Full path quality gate or when the user says 'review', 'check code', 'code review', or 'is it ready to commit'. (project)"
+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)"
 ---
 
 # PrizmKit Code Review
 
-An iterative review-fix loop that checks workspace changes against the task spec and plan. It separates review judgment from fix application by requiring an independent inline reviewer subagent launched from the active checkout with a prompt loaded from this skill's references. Main Agent applies accepted fixes directly after filtering reviewer findings.
+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.
 
 Review modes:
-- `inline-reviewer-active-checkout`: required mode. Always spawn an independent reviewer subagent in the current active checkout with no worktree, copied checkout, remote checkout, or branch isolation.
+- `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.
 
-If the platform cannot launch an inline reviewer subagent in current-workspace / active-checkout / no-worktree mode, stop with this checkout-isolation incompatibility message:
+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`.
 
-```text
-Cannot run /prizmkit-code-review because this platform cannot start an inline reviewer subagent in the active checkout without worktree, copy, remote, or branch isolation.
-```
+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 only when risk, scope, or user request warrants review
-- User says "review", "check code", "review my implementation", or "is it ready to commit"
+- 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
 
 ### 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
+- 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
 
 ## Input
 
 | Parameter | Required | Description |
 |-----------|----------|-------------|
-| `artifact_dir` | No | Directory containing `spec.md` + `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`. 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. |
 
-## Phase 0: Context Loading
+## Phase 0: Context and Snapshot
 
 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 scoped `/prizmkit-test` report when present:
+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 test report exists, pass `No scoped /prizmkit-test report found` as informational context. Do not treat missing tests as a review finding unless the current lifecycle path explicitly required testing.
+   - 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 active checkout workspace context:
-   - `git status`
-   - `git diff`
-   - `git diff --cached`
-   - full paths for untracked and renamed files
-   - expected active checkout git top-level from `git rev-parse --show-toplevel`
-   - 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, and review mode `not-run-no-changes`.
+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`.
 
 ## Phase 1: Review-Fix Loop
 
@@ -70,42 +67,43 @@ python3 --version 2>/dev/null && echo "SCRIPT_MODE" || echo "TEXT_MODE"
 - `round = 1`
 - `max_rounds = 3`
 - `findings_history = []`
-- `review_mode = inline-reviewer-active-checkout` after confirming an inline reviewer subagent can launch in the active checkout
+- `review_mode = independent-reviewer-verified-snapshot` after snapshot verification succeeds
 
-### Step 1: Launch Required Inline Reviewer
+### Step 1: Establish Independent Review
 
-Always spawn an independent reviewer subagent using this skill-owned inline contract:
+Use the skill-owned review contract:
 
 ```yaml
 prompt_reference: ${SKILL_DIR}/references/reviewer-agent-prompt.md
-isolation: current-workspace / active-checkout / no-worktree
-subagent_kind: inline reviewer prompt, not a platform-installed named agent
+workspace_protocol: ${SKILL_DIR}/references/reviewer-workspace-protocol.md
+reviewer_contract: independent, read-only, workspace-equivalent
 ```
 
-1. Read `${SKILL_DIR}/references/reviewer-agent-prompt.md` and fill it with the active-checkout context from Phase 0.
-2. The captured git diff, staged diff, untracked files, spec, plan, dev rules, and scoped test report are the primary review scope.
-3. Never use worktree isolation, remote isolation, copied checkouts, branch switching, broad repository exploration, or a generic code explorer as a substitute for the required inline reviewer prompt. Do not request or create tool-managed worktrees, pipeline-managed worktrees, copied repositories, or remote checkouts. Do not use `.claude/worktrees/...` or `.prizmkit/state/worktrees/...`. Pipeline runner `USE_WORKTREE` controls outer infrastructure only; it does not change this skill's active-checkout reviewer requirement.
-4. Never perform Main-Agent self-review or fallback review; the Main Agent's job is filtering and fixing, not acting as the reviewer.
-5. If the platform cannot launch the reviewer in the active checkout without worktree/copy/remote/branch isolation, stop with the checkout-isolation incompatibility message from this skill's introduction.
+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.
 
 ### Step 2: Run Review
 
 Round context:
 - Round 1: examine all current changes comprehensively.
-- Round 2+: focus on whether prior fixes are correct, whether fixes introduced new issues, and whether accepted findings remain.
+- Round 2+: verify prior fixes, look for regressions introduced by the fixes, and identify accepted findings that remain.
 
 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.
 
 ### Step 3: Loop Exit Gate
 
-Call the gate only in these cases:
+Call the gate only when:
 
 1. Review returned `PASS`.
-2. Main Agent has filtered `NEEDS_FIXES` findings.
+2. The Main Agent has filtered `NEEDS_FIXES` findings.
 
-Do not call the gate for `NEEDS_FIXES` before filtering because `accepted_count` is not known yet.
+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.
 
 Script mode invocation:
 
@@ -113,7 +111,7 @@ Script mode invocation:
 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
 ```
 
-Gate output determines whether to end the loop. If `divergenceWarning` is true, warn the user that the loop may not be converging.
+The gate output determines whether to end the loop. If `divergenceWarning` is true, warn the user that the loop may not be converging.
 
 ### Text Fallback Constraints
 
@@ -130,36 +128,39 @@ When Python is unavailable, apply these rules manually:
 
 For each finding, decide whether it is reasonable:
 
-- Is this relevant to the current changes?
-- Is this a real problem rather than subjective style preference?
-- Would fixing this improve the code without broad out-of-scope refactoring?
-- Does it conflict with spec, plan, dev rules, or current test evidence?
+- 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?
 
 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 current task.
+- Rejected: record a short reason such as out of scope, not a defect, or too risky for the current task.
 
 After filtering, call the Loop Exit Gate. If `endLoop=true`, proceed to Phase 2.
 
 ### Step 5: Main Agent Applies Accepted Fixes
 
-The Main Agent applies accepted findings directly in the active checkout. Do not spawn a separate implementation subagent for review fixes.
+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.
 
-If an accepted finding cannot be safely fixed within scope, record the reason and carry it into `review-report.md` as unresolved.
+If an accepted finding cannot be fixed safely within scope, record the reason and carry the finding into `review-report.md` as unresolved.
 
-After fixes are complete, record results, increment the round, and return to Step 2.
+After fixes are complete, record results, increment the round, capture a fresh workspace snapshot, and return to Step 1.
 
 ## Phase 2: Output
 
-Always write `review-report.md` to the artifact directory, including no-change PASS results. Read `${SKILL_DIR}/references/review-report-template.md` for the full output format.
+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.
 
 Required report fields:
 - Verdict: `PASS` or `NEEDS_FIXES`
-- Review Mode: `inline-reviewer-active-checkout` or `not-run-no-changes`
+- 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 summary:
 - `PASS`: hand off to `/prizmkit-retrospective` when docs or durable knowledge changed, otherwise `/prizmkit-committer`.
-- `NEEDS_FIXES`: inform the caller of remaining unresolved findings.
+- `NEEDS_FIXES`: inform the caller of unresolved code findings or snapshot-verification blockers.

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

@@ -1,13 +1,16 @@
 # Review Report Output Template
 
-Used in Phase 2 of `/prizmkit-code-review`. Always write `review-report.md` to the artifact directory using this format.
+Used in Phase 2 of `/prizmkit-code-review`. Write `review-report.md` to the artifact directory using this format.
 
 ```markdown
 # Review Report
 
 ## Verdict: <PASS|NEEDS_FIXES>
-## Review Mode: <reviewer-agent-active-checkout|not-run-no-changes>
-## Rounds: <number of review rounds completed; use 0 for no-change PASS>
+## 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>
 
 ## Round <N>
@@ -15,18 +18,20 @@ Findings: <count> | Accepted: <count>, Rejected: <count>
 
 ### Finding <N>: <short title>
 - Severity: <high|medium|low>
-- Dimension: <goal-alignment|defect|completeness|consistency|security|rules-compliance>
+- Dimension: <goal-alignment|defect|completeness|consistency|security|test-quality|rules-compliance>
 - Location: <filepath:line or project-level>
 - Problem: <what was wrong and why it mattered>
 - Status: <fixed (round N)|rejected — reason|unresolved — reason>
 
 ## Final Summary
-<One to three sentences summarizing the review outcome, including no-change PASS when applicable.>
+<One to three sentences summarizing the review outcome, snapshot verification, and any remaining blocker.>
 ```
 
-For `PASS` with no findings, write `Total findings: 0 → Fixed: 0, Rejected: 0, Unresolved: 0` and `## Round 0: PASS — no workspace changes to review` or `## Round N: PASS — no issues found`.
+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`.
+
+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.
 
 ## Verdict Rules
 
-- `PASS`: Reviewer returned no findings, no workspace changes existed, or all remaining findings were rejected as unreasonable.
-- `NEEDS_FIXES`: Max rounds completed but accepted findings remain unresolved.
+- `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.

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

@@ -1,9 +1,9 @@
 # Reviewer Subagent Prompt Template
 
-Used in Phase 1 Step 1 of `/prizmkit-code-review`. The orchestrator fills `{goals}`, `{plan decisions}`, `{scoped test report}`, `{workspace context}`, `{dev rules}`, `{round N}`, and `{round_context}` before spawning an independent inline reviewer subagent from the active checkout.
+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`.
 
 ```
-You are an independent PrizmKit reviewer subagent launched by `/prizmkit-code-review` from the active checkout. Review workspace changes against the spec goals, plan decisions, scoped test evidence, and per-layer dev rules. Do not modify files and do not apply fixes; the Main Agent will filter findings and apply accepted fixes directly.
+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.
 
 ## Spec Goals
 {goals and acceptance criteria from spec.md}
@@ -12,53 +12,67 @@ You are an independent PrizmKit reviewer subagent launched by `/prizmkit-code-re
 {architecture decisions and task list from plan.md}
 
 ## 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 for a change artifact, write "No scoped /prizmkit-test report found (expected for pre-test review)." Treat that absence as informational unless the calling workflow explicitly requires a prior 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.}
 
-## Workspace Context
-{git status, unstaged diff summary, staged diff summary, current working directory, expected active checkout git top-level, and new-file paths captured by the Main Agent in Phase 0 from the active checkout. This is your primary review scope — use this context to understand what changed. Request targeted file reads only when you need specific line-level detail for a finding, not to re-discover or re-index the repository. Do not read files that are not in the workspace context unless you need them to verify impact (callers, dependents, shared patterns).}
+## 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}
 
-## Active Checkout Guard
-The orchestrator must provide the expected active checkout git top-level in Workspace Context. Before reviewing, verify that your current git top-level matches that expected active checkout.
+## Review Payload
+{the reviewable representation of every manifest entry, plus clearly identified unchanged context needed to evaluate callers, dependents, or shared patterns}
 
-If your current checkout is different, or appears to be under `.claude/worktrees/`, `.prizmkit/state/worktrees/`, a copied checkout, a remote isolated checkout, a temporary repository clone, or any branch/top-level other than the orchestrator-provided active checkout:
-- Stop immediately.
-- Do not review files.
-- Do not produce normal findings.
-- Report `WRONG_CHECKOUT` and state that `/prizmkit-code-review` cannot continue because the reviewer subagent was not started in the active checkout/no-worktree mode required by this skill.
+## Reviewer Strategy
+{concise description of how the current platform made the snapshot available. This is diagnostic context, not a required parameter contract.}
 
-Worktree, copied-checkout, remote-checkout, and branch-switched review are not supported by `/prizmkit-code-review`; do not continue even if the files appear similar. Do not request or create worktrees, copied repositories, branch switches, or remote checkouts.
+## 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.
 
-## Dev Rules (per-layer conventions)
+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.
+
+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.
+
+## Dev Rules
 {rules from .prizmkit/rules/<layer>-rules.md, or "No custom dev rules configured — use general best practices."}
 
 ## Review Round
 Round {N}. {round_context}
 
 ## What to Review
-Use the orchestrator-provided workspace context as the source of truth for changed files:
-- For new files listed in workspace status, read their full content.
-- For modified files, read enough surrounding context to understand the change.
-- Do not edit files, stage changes, run test suites, spawn other agents, or invoke tools that modify the workspace.
-- Do not request or create worktrees — you are reviewing the active checkout's changes. The orchestrator has already captured the full diff and status context; re-discovering the whole repository is wasteful and unnecessary.
+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.
 
 ## Review Dimensions
-Evaluate the changes across these dimensions (focus on what's relevant):
+Evaluate the relevant dimensions:
 
-1. **Goal alignment**: Do the changes accomplish all goals from spec.md? Anything missing or off-target?
-2. **Defects**: Logic bugs, missing error handling, boundary condition issues, incorrect behavior.
-3. **Completeness**: Files that should have been changed but weren't? Missing tests, types, imports, exports?
-4. **Consistency**: Do changes follow the project's existing patterns, naming conventions, and code style?
-5. **Security**: Hardcoded secrets, injection vulnerabilities, unsafe operations.
-6. **Test quality**: If a scoped `/prizmkit-test` report is present, verify the report scope is `this-change`, the artifact dir matches the reviewed change, generated/updated tests assert real behavior rather than mock success or empty assertions, in-scope failures are not mislabeled as baseline failures, baseline failures are genuinely unrelated or pre-existing, out-of-scope gaps were not turned into unrelated test changes, and the report verdict is compatible with proceeding.
-7. **Rules compliance**: (Skip this dimension if no dev rules were provided.) Do changes follow the per-layer dev rules? Flag violations of framework conventions, naming patterns, state management, or other rules defined for that layer.
+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.
 
 ## Output Format
-Respond with EXACTLY this format:
+Respond with exactly this structure:
+
+### Result: PASS | NEEDS_FIXES | WORKSPACE_MISMATCH
 
-### Result: PASS | NEEDS_FIXES | WRONG_CHECKOUT
+### Snapshot Verification
+- Status: VERIFIED | FAILED
+- Identity: <manifest identity or mismatch summary>
 
 ### Findings
-(If PASS, write "No issues found." If WRONG_CHECKOUT, include only checkout mismatch evidence and do not include normal review findings.)
+(If PASS, write "No issues found." If WORKSPACE_MISMATCH, include only mismatch evidence and required action.)
 
 #### Finding N
 - **Severity**: high | medium | low
@@ -69,10 +83,10 @@ Respond with EXACTLY this format:
 - **Verification**: How to confirm the fix is correct
 
 ### Summary
-One to two sentences about the overall state of the changes.
+One to two sentences about the snapshot and overall state of the changes.
 ```
 
 ## Round Context
 
 - Round 1: "This is the first review. Examine all changes comprehensively."
-- Round 2+: "Previous round found issues that were fixed. Focus on: (1) whether previous fixes are correct, (2) whether fixes introduced new problems, (3) any remaining issues. Do not re-report issues that have already been fixed."
+- 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."

package/bundled/skills/prizmkit-code-review/references/reviewer-workspace-protocol.md

@@ -0,0 +1,90 @@
+# Reviewer Workspace Protocol
+
+Use this protocol whenever `/prizmkit-code-review` delegates review to an independent Reviewer. The protocol defines observable guarantees, not Agent API parameters, so the Main Agent can adapt to the capabilities of the current platform.
+
+## Protocol Invariants
+
+1. **Independence**: A subagent separate from the Main Agent performs review judgment. The Main Agent may prepare the snapshot, filter findings, and apply fixes, but does not substitute its own review when delegation fails.
+2. **Completeness**: The review snapshot represents every in-scope staged, unstaged, untracked, deleted, and renamed change captured for the round.
+3. **Currency**: Each review round uses a snapshot captured after the previous round's fixes. Never reuse a prior-round snapshot as evidence of current state.
+4. **Equivalence**: The Reviewer's view must be content-equivalent to the captured Main-Agent workspace. Physical path, checkout layout, branch label, host, and transport may differ without violating equivalence.
+5. **Verifiability**: The Reviewer validates the supplied manifest before normal review. Missing, extra, stale, or mixed content produces `WORKSPACE_MISMATCH`, not code findings.
+6. **Read-only review**: The Reviewer does not modify files or apply fixes. This keeps review evidence stable and preserves clear fix ownership.
+
+## Strategy Selection
+
+Choose a platform-supported strategy that can satisfy all protocol invariants. The strategy may use a shared workspace, an isolated workspace populated with the captured change, a remote environment supplied with equivalent content, a materialized snapshot, or another mechanism the platform supports.
+
+Do not encode a particular Agent type, model, isolation value, branch convention, directory prefix, or transport command into the skill contract. Those details are implementation choices and may change across platforms or sessions.
+
+Prefer the least elaborate strategy that can prove equivalence. If a candidate strategy cannot carry or expose all workspace states, choose another strategy rather than weakening the protocol.
+
+## Workspace Manifest
+
+Create a manifest for each round containing enough information to detect an incomplete or stale review view:
+
+- repository identity and baseline revision
+- round number or equivalent monotonic round identity
+- changed path inventory and each path's status
+- staged and unstaged composition when both exist for a path
+- untracked file content required for review
+- deleted-path markers
+- rename source and destination pairs
+- stable content identities for changed content and any review-critical context
+- relevant spec, plan, dev-rule, and scoped-test evidence identities or embedded content
+
+The exact encoding is implementation-defined. Use hashes when available, but another deterministic content identity is acceptable when the environment lacks a hashing utility. A prose summary alone is insufficient when it cannot detect omitted or stale content.
+
+## Review Payload
+
+Provide the Reviewer with both:
+
+1. The manifest used for verification.
+2. A reviewable representation of every manifest entry.
+
+A reviewable representation may be workspace files, complete file content, patches plus required base content, or an equivalent materialization. Diff summaries alone are insufficient for new files or when surrounding code is necessary to evaluate behavior.
+
+Supply targeted dependency or caller context when required to verify impact. Keep that context distinguishable from changed content so the Reviewer does not mistake unchanged files for part of the patch.
+
+## Reviewer Verification
+
+Before normal review, the Reviewer checks:
+
+1. Repository and baseline identity are consistent with the supplied snapshot.
+2. Every changed path in the manifest is available in the review payload.
+3. No unexplained changed path appears outside the manifest.
+4. Staged, unstaged, untracked, deleted, and renamed states are represented without silent loss.
+5. Content identities match the manifest.
+6. The snapshot belongs to the current review round.
+
+When all checks pass, report snapshot verification as `VERIFIED` and proceed with review.
+
+When a check cannot be completed or fails, stop normal review and return:
+
+```text
+### Result: WORKSPACE_MISMATCH
+
+### Snapshot Verification
+- Status: FAILED
+- Mismatch: <missing, extra, stale, or unverifiable manifest entries>
+- Required action: <what the Main Agent must re-capture, transport, or verify>
+```
+
+Do not emit ordinary code findings after `WORKSPACE_MISMATCH`, because findings from an unverified snapshot could misrepresent the current change.
+
+## Round Refresh
+
+After accepted fixes are applied:
+
+1. Discard the previous manifest as current evidence.
+2. Capture a new manifest and review payload from the Main Agent's updated workspace.
+3. Establish a fresh independent Reviewer view using any valid strategy.
+4. Repeat Reviewer verification before the next review.
+
+A platform may reuse an existing Reviewer session only when the refreshed payload replaces stale state and equivalence is verified again.
+
+## Failure Boundary
+
+Retry or change strategy when the mismatch is repairable. Stop when the platform cannot provide an independent Reviewer with a verifiable equivalent snapshot.
+
+Record the failure as an unresolved review blocker with verdict `NEEDS_FIXES`, snapshot verification `FAILED`, and the mismatch evidence. Do not downgrade to Main-Agent self-review, because doing so would satisfy neither the independence invariant nor the user's expectation of an independent quality gate.