bmad-plus 0.12.2 → 0.14.0

package/src/bmad-plus/packs/pack-dev-studio/categories/implementation/code-review-steps/step-01-gather-context.md

@@ -1,85 +1,18 @@
----
-diff_output: '' # set at runtime
-spec_file: '' # set at runtime (path or empty)
-review_mode: '' # set at runtime: "full" or "no-spec"
-story_key: '' # set at runtime when discovered from sprint status
----
+# Review compatibility guide — gather scoped evidence
 
-# Step 1: Gather Context
+This retained path corresponds to procedure step 1 of
+[code-review](../code-review.md). The main workflow is complete; these guides do
+not form an execution chain. Follow the common
+[execution guide](../../../shared/execution.md).
 
-## RULES
+Identify the actual base and target revision or working-tree snapshot. Read the
+request, diff, relevant callers, tests and constraints. Preserve existing edits
+and record the paths and evidence that were inspected.
 
-- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
-- The prompt that triggered this workflow IS the intent — not a hint.
-- Do not modify any files. This step is read-only.
+Clarify the reviewed behavior and acceptance criteria. A diff without surrounding
+context may be insufficient to establish a defect; state what is missing instead
+of inventing context.
 
-## INSTRUCTIONS
-
-1. **Find the review target.** The conversation context before this skill was triggered IS your starting point — not a blank slate. Check in this order — stop as soon as the review target is identified:
-
-   **Tier 1 — Explicit argument.**
-   Did the user pass a PR, commit SHA, branch, spec file, or diff source this message?
-   - PR reference → resolve to branch/commit via `gh pr view`. If resolution fails, ask for a SHA or branch.
-   - Commit or branch → use directly.
-   - Spec file → set `{spec_file}` to the provided path. Check its frontmatter for `baseline_commit`. If found, use as diff baseline. If not found, continue the cascade (a spec alone does not identify a diff source).
-   - Also scan the argument for diff-mode keywords that narrow the scope:
-     - "staged" / "staged changes" → Staged changes only
-     - "uncommitted" / "working tree" / "all changes" → Uncommitted changes (staged + unstaged)
-     - "branch diff" / "vs main" / "against main" / "compared to <branch>" → Branch diff (extract base branch if mentioned)
-     - "commit range" / "last N commits" / "<from-sha>..<to-sha>" → Specific commit range
-     - "this diff" / "provided diff" / "paste" → User-provided diff (do not match bare "diff" — it appears in other modes)
-   - When multiple keywords match, prefer the most specific (e.g., "branch diff" over bare "diff").
-
-   **Tier 2 — Recent conversation.**
-   Do the last few messages reveal what the user wants to be reviewed? Look for spec paths, commit refs, branches, PRs, or descriptions of a change. Apply the same diff-mode keyword scan and routing as Tier 1.
-
-   **Tier 3 — Sprint tracking.**
-   Look for a sprint status file (`*sprint-status*`) in `{implementation_artifacts}` or `{planning_artifacts}`. If found, scan for stories with status `review`:
-   - **Exactly one `review` story:** Set `{story_key}` to the story's key (e.g., `1-2-user-auth`). Suggest it: "I found story <story-id> in `review` status. Would you like to review its changes? [Y] Yes / [N] No, let me choose". If confirmed, use the story context to determine the diff source (branch name derived from story slug, or uncommitted changes). If declined, clear `{story_key}` and fall through.
-   - **Multiple `review` stories:** Present them as numbered options alongside a manual choice option. Wait for user selection. If a story is selected, set `{story_key}` and use its context to determine the diff source. If manual choice is selected, clear `{story_key}` and fall through.
-   - **None:** Fall through.
-
-   **Tier 4 — Current git state.**
-   If version control is unavailable, skip to Tier 5. Otherwise, check the current branch and HEAD. If the branch is not `main` (or the default branch), confirm: "I see HEAD is `<short-sha>` on `<branch>` — do you want to review this branch's changes?" If confirmed, treat as a branch diff against `main`. If declined, fall through.
-
-   **Tier 5 — Ask.**
-   Fall through to instruction 2.
-
-   Never ask extra questions beyond what the cascade prescribes. If a tier above already identified the target, skip the remaining tiers and proceed to instruction 3 (construct diff).
-
-2. HALT. Ask the user: **What do you want to review?** Present these options:
-   - **Uncommitted changes** (staged + unstaged)
-   - **Staged changes only**
-   - **Branch diff** vs a base branch (ask which base branch)
-   - **Specific commit range** (ask for the range)
-   - **Provided diff or file list** (user pastes or provides a path)
-
-3. Construct `{diff_output}` from the chosen source.
-   - For **staged changes only**: run `git diff --cached`.
-   - For **uncommitted changes** (staged + unstaged): run `git diff HEAD`.
-   - For **branch diff**: verify the base branch exists before running `git diff`. If it does not exist, HALT and ask the user for a valid branch.
-   - For **commit range**: verify the range resolves. If it does not, HALT and ask the user for a valid range.
-   - For **provided diff**: validate the content is non-empty and parseable as a unified diff. If it is not parseable, HALT and ask the user to provide a valid diff.
-   - For **file list**: validate each path exists in the working tree. Construct `{diff_output}` by running `git diff HEAD -- <path1> <path2> ...`. If any paths are untracked (new files not yet staged), use `git diff --no-index /dev/null <path>` to include them. If the diff is empty (files have no uncommitted changes and are not untracked), ask the user whether to review the full file contents or to specify a different baseline.
-   - After constructing `{diff_output}`, verify it is non-empty regardless of source type. If empty, HALT and tell the user there is nothing to review.
-
-4. **Set the spec context.**
-   - If `{spec_file}` is already set (from Tier 1 or Tier 2): verify the file exists and is readable, then set `{review_mode}` = `"full"`.
-   - Otherwise, ask the user: **Is there a spec or story file that provides context for these changes?**
-     - If yes: set `{spec_file}` to the path provided, verify the file exists and is readable, then set `{review_mode}` = `"full"`.
-     - If no: set `{review_mode}` = `"no-spec"`.
-
-5. If `{review_mode}` = `"full"` and the file at `{spec_file}` has a `context` field in its frontmatter listing additional docs, load each referenced document. Warn the user about any docs that cannot be found.
-
-6. Sanity check: if `{diff_output}` exceeds approximately 3000 lines, warn the user and offer to chunk the review by file group.
-   - If the user opts to chunk: agree on the first group, narrow `{diff_output}` accordingly, and list the remaining groups for the user to note for follow-up runs.
-   - If the user declines: proceed as-is with the full diff.
-
-### CHECKPOINT
-
-Present a summary before proceeding: diff stats (files changed, lines added/removed), `{review_mode}`, and loaded spec/context docs (if any). HALT and wait for user confirmation to proceed.
-
-
-## NEXT
-
-Read fully and follow `./step-02-review.md`
+Record the scope and input ledger in the report. On resume, compare the current
+snapshot with the reviewed one and invalidate affected conclusions. Continue at
+the first incomplete part of the main procedure.

package/src/bmad-plus/packs/pack-dev-studio/categories/implementation/code-review-steps/step-02-review.md

@@ -1,35 +1,18 @@
----
-failed_layers: '' # set at runtime: comma-separated list of layers that failed or returned empty
----
+# Review compatibility guide — inspect behavior
 
-# Step 2: Review
+This retained path supports procedure steps 2 through 4 of
+[code-review](../code-review.md). Follow the common
+[execution guide](../../../shared/execution.md).
 
-## RULES
+Inspect intended behavior, invariants and relevant failure boundaries in the actual
+code. Trace each suspicion to a triggering condition and observable consequence.
+Seek counterevidence and use a focused reproduction where useful and authorized.
 
-- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
-- The Blind Hunter subagent receives NO project context — diff only.
-- The Edge Case Hunter subagent receives diff and project read access.
-- The Acceptance Auditor subagent receives diff, spec, and context docs.
-- All review subagents must run at the same model capability as the current session.
+Independent perspectives require actual host-supported reviewers. Record their
+assignments and evidence; otherwise label the work as one assistant's sequential
+review. An absent reviewer cannot supply a clean result.
 
-## INSTRUCTIONS
-
-1. If `{review_mode}` = `"no-spec"`, note to the user: "Acceptance Auditor skipped — no spec file provided."
-
-2. Launch parallel subagents without conversation context. If subagents are not available, generate prompt files in `{implementation_artifacts}` — one per reviewer role below — and HALT. Ask the user to run each in a separate session (ideally a different LLM) and paste back the findings. When findings are pasted, resume from this point and proceed to step 3.
-
-   - **Blind Hunter** — receives `{diff_output}` only. No spec, no context docs, no project access. Invoke via the `bmad-review-adversarial-general` skill.
-
-   - **Edge Case Hunter** — receives `{diff_output}` and read access to the project. Invoke via the `bmad-review-edge-case-hunter` skill.
-
-   - **Acceptance Auditor** (only if `{review_mode}` = `"full"`) — receives `{diff_output}`, the content of the file at `{spec_file}`, and any loaded context docs. Its prompt:
-     > You are an Acceptance Auditor. Review this diff against the spec and context docs. Check for: violations of acceptance criteria, deviations from spec intent, missing implementation of specified behavior, contradictions between spec constraints and actual code. Output findings as a Markdown list. Each finding: one-line title, which AC/constraint it violates, and evidence from the diff.
-
-3. **Subagent failure handling**: If any subagent fails, times out, or returns empty results, append the layer name to `{failed_layers}` (comma-separated) and proceed with findings from the remaining layers.
-
-4. Collect all findings from the completed layers.
-
-
-## NEXT
-
-Read fully and follow `./step-03-triage.md`
+Do not change product code during review unless fixes are within the user's task.
+Record supported findings, unresolved questions and refuted suspicions. Continue
+the main procedure at the next unfinished part; this guide does not spawn agents
+or load another step by itself.

package/src/bmad-plus/packs/pack-dev-studio/categories/implementation/code-review-steps/step-03-triage.md

@@ -1,49 +1,18 @@
----
----
+# Review compatibility guide — triage findings
 
-# Step 3: Triage
+This retained path supports procedure steps 5 and 6 of
+[code-review](../code-review.md). Follow the common
+[execution guide](../../../shared/execution.md).
 
-## RULES
+For each suspected issue, inspect the supporting code and counterevidence. Remove
+duplicates and distinguish a behavioral defect from a style preference. Retain
+the reason a suspicion was refuted so continuation does not repeat it.
 
-- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
-- Be precise. When uncertain between categories, prefer the more conservative classification.
+A retained finding needs a file/line, trigger, consequence, evidence, confidence
+and proportionate fix direction. Set severity from actual impact and likelihood.
+Unsupported speculation belongs in open questions.
 
-## INSTRUCTIONS
-
-1. **Normalize** findings into a common format. Expected input formats:
-   - Adversarial (Blind Hunter): markdown list of descriptions
-   - Edge Case Hunter: JSON array with `location`, `trigger_condition`, `guard_snippet`, `potential_consequence` fields
-   - Acceptance Auditor: markdown list with title, AC/constraint reference, and evidence
-
-   If a layer's output does not match its expected format, attempt best-effort parsing. Note any parsing issues for the user.
-
-   Convert all to a unified list where each finding has:
-   - `id` -- sequential integer
-   - `source` -- `blind`, `edge`, `auditor`, or merged sources (e.g., `blind+edge`)
-   - `title` -- one-line summary
-   - `detail` -- full description
-   - `location` -- file and line reference (if available)
-
-2. **Deduplicate.** If two or more findings describe the same issue, merge them into one:
-   - Use the most specific finding as the base (prefer edge-case JSON with location over adversarial prose).
-   - Append any unique detail, reasoning, or location references from the other finding(s) into the surviving `detail` field.
-   - Set `source` to the merged sources (e.g., `blind+edge`).
-
-3. **Classify** each finding into exactly one bucket:
-   - **decision_needed** -- There is an ambiguous choice that requires human input. The code cannot be correctly patched without knowing the user's intent. Only possible if `{review_mode}` = `"full"`.
-   - **patch** -- Code issue that is fixable without human input. The correct fix is unambiguous.
-   - **defer** -- Pre-existing issue not caused by the current change. Real but not actionable now.
-   - **dismiss** -- Noise, false positive, or handled elsewhere.
-
-   If `{review_mode}` = `"no-spec"` and a finding would otherwise be `decision_needed`, reclassify it as `patch` (if the fix is unambiguous) or `defer` (if not).
-
-4. **Drop** all `dismiss` findings. Record the dismiss count for the summary.
-
-5. If `{failed_layers}` is non-empty, report which layers failed before announcing results. If zero findings remain after dropping dismissed AND `{failed_layers}` is non-empty, warn the user that the review may be incomplete rather than announcing a clean review.
-
-6. If zero findings remain after triage (all rejected or none raised): state "✅ Clean review — all layers passed." (Step 3 already warned if any review layers failed via `{failed_layers}`.)
-
-
-## NEXT
-
-Read fully and follow `./step-04-present.md`
+Reconcile acceptance and review coverage. Missing tools, unrun checks and absent
+required reviewers remain incomplete. Zero findings is valid when supported by
+the inspected scope. Continue at the first incomplete part of the main procedure;
+triage does not itself repair the code.

package/src/bmad-plus/packs/pack-dev-studio/categories/implementation/code-review-steps/step-04-present.md

@@ -1,132 +1,17 @@
----
-deferred_work_file: '{implementation_artifacts}/deferred-work.md'
----
+# Review compatibility guide — present the conclusion
 
-# Step 4: Present and Act
+This retained path corresponds to procedure step 7 and continuation of
+[code-review](../code-review.md). Follow the common
+[execution guide](../../../shared/execution.md).
 
-## RULES
+Present actionable findings in impact order with evidence and locations. Follow
+them with the baseline, acceptance coverage, checks actually performed, refuted
+suspicions where useful and unresolved limitations.
 
-- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
-- When `{spec_file}` is set, always write findings to the story file before offering action choices.
-- `decision-needed` findings must be resolved before handling `patch` findings.
+Use findings, no-actionable-findings or incomplete as the scoped disposition.
+List partial findings even when some coverage is incomplete. Never present a
+missing review or a passing unrelated test as evidence that the change is clean.
 
-## INSTRUCTIONS
-
-### 1. Clean review shortcut
-
-If zero findings remain after triage (all dismissed or none raised): state that and proceed to section 6 (Sprint Status Update).
-
-### 2. Write findings to the story file
-
-If `{spec_file}` exists and contains a Tasks/Subtasks section, append a `### Review Findings` subsection. Write all findings in this order:
-
-1. **`decision-needed`** findings (unchecked):
-   `- [ ] [Review][Decision] <Title> — <Detail>`
-
-2. **`patch`** findings (unchecked):
-   `- [ ] [Review][Patch] <Title> [<file>:<line>]`
-
-3. **`defer`** findings (checked off, marked deferred):
-   `- [x] [Review][Defer] <Title> [<file>:<line>] — deferred, pre-existing`
-
-Also append each `defer` finding to `{deferred_work_file}` under a heading `## Deferred from: code review ({date})`. If `{spec_file}` is set, include its basename in the heading (e.g., `code review of story-3.3 (2026-03-18)`). One bullet per finding with description.
-
-### 3. Present summary
-
-Announce what was written:
-
-> **Code review complete.** <D> `decision-needed`, <P> `patch`, <W> `defer`, <R> dismissed as noise.
-
-If `{spec_file}` is set, add: `Findings written to the review findings section in {spec_file}.`
-Otherwise add: `Findings are listed above. No story file was provided, so nothing was persisted.`
-
-### 4. Resolve decision-needed findings
-
-If `decision_needed` findings exist, present each one with its detail and the options available. The user must decide — the correct fix is ambiguous without their input. Walk through each finding (or batch related ones) and get the user's call. Once resolved, each becomes a `patch`, `defer`, or is dismissed.
-
-If the user chooses to defer, ask: Quick one-line reason for deferring this item? (helps future reviews): — then append that reason to both the story file bullet and the `{deferred_work_file}` entry.
-
-**HALT** — I am waiting for your numbered choice. Reply with only the number. Do not proceed until you select an option.
-
-### 5. Handle `patch` findings
-
-If `patch` findings exist (including any resolved from step 4), HALT. Ask the user:
-
-If `{spec_file}` is set, present all three options:
-
-> **How would you like to handle the `<P>` `patch` findings?**
-> 1. **Apply every patch** — fix all of them now, no per-finding confirmation. Defer and decision-needed items are not touched.
-> 2. **Leave as action items** — they are already in the story file
-> 3. **Walk through each patch** — show details for each before deciding
-
-If `{spec_file}` is **not** set, present only options 1 and 2 (omit "Leave as action items" — findings were not written to a file):
-
-> **How would you like to handle the `<P>` `patch` findings?**
-> 1. **Apply every patch** — fix all of them now, no per-finding confirmation. Defer and decision-needed items are not touched.
-> 2. **Walk through each patch** — show details for each before deciding
-
-**HALT** — I am waiting for your numbered choice. Reply with only the number. Do not proceed until you select an option.
-
-- **Apply every patch**: Apply every patch finding without per-finding confirmation. Do not modify defer or decision-needed items. After all patches are applied, present a summary of changes made. If `{spec_file}` is set, check off the patch items in the story file (leave defer items as-is).
-- **Leave as action items** (only when `{spec_file}` is set): Done — findings are already written to the story.
-- **Walk through each patch**: Present each finding with full detail, diff context, and suggested fix. After walkthrough, re-offer the applicable options above.
-
-  **HALT** — I am waiting for your numbered choice. Do not proceed until you select an option.
-
-**✅ Code review actions complete**
-
-- Decision-needed resolved: <D>
-- Patches handled: <P>
-- Deferred: <W>
-- Dismissed: <R>
-
-### 6. Update story status and sync sprint tracking
-
-Skip this section if `{spec_file}` is not set.
-
-#### Determine new status based on review outcome
-
-- If all `decision-needed` and `patch` findings were resolved (fixed or dismissed) AND no unresolved HIGH/MEDIUM issues remain: set `{new_status}` = `done`. Update the story file Status section to `done`.
-- If `patch` findings were left as action items, or unresolved issues remain: set `{new_status}` = `in-progress`. Update the story file Status section to `in-progress`.
-
-Save the story file.
-
-#### Sync sprint-status.yaml
-
-If `{story_key}` is not set, skip this subsection and note that sprint status was not synced because no story key was available.
-
-If `{sprint_status}` file exists:
-
-1. Load the FULL `{sprint_status}` file.
-2. Find the `development_status` entry matching `{story_key}`.
-3. If found: update `development_status[{story_key}]` to `{new_status}`. Update `last_updated` to current date. Save the file, preserving ALL comments and structure including STATUS DEFINITIONS.
-4. If `{story_key}` not found in sprint status: warn the user that the story file was updated but sprint-status sync failed.
-
-If `{sprint_status}` file does not exist, note that story status was updated in the story file only.
-
-#### Completion summary
-
-> **Review Complete!**
->
-> **Story Status:** `{new_status}`
-> **Issues Fixed:** <fixed_count>
-> **Action Items Created:** <action_count>
-> **Deferred:** <W>
-> **Dismissed:** <R>
-
-### 7. Next steps
-
-Present the user with follow-up options:
-
-> **What would you like to do next?**
-> 1. **Start the next story** — run `dev-story` to pick up the next `ready-for-dev` story
-> 2. **Re-run code review** — address findings and review again
-> 3. **Done** — end the workflow
-
-**HALT** — I am waiting for your choice. Do not proceed until the user selects an option.
-
-## On Complete
-
-<!-- Adapted for BMAD+: original script dependency removed -->
-
-If the resolved `workflow.on_complete` is non-empty, follow it as the final terminal instruction before exiting.
+On updated code, verify each claimed resolution against actual changes and
+re-review affected behavior. Preserve prior findings and their resolution evidence.
+This guide does not imply approval to commit, publish or modify tracking statuses.

package/src/bmad-plus/packs/pack-dev-studio/categories/implementation/code-review.md

@@ -1,90 +1,64 @@
----
+---
 name: bmad-code-review
-description: 'Review code changes adversarially using parallel review layers (Blind Hunter, Edge Case Hunter, Acceptance Auditor) with structured triage into actionable categories. Use when the user says "run code review" or "review this code"'
+description: Review a scoped code change using reproducible findings and explicit evidence limits.
 ---
 
-# Code Review Workflow
-
-**Goal:** Review code changes adversarially using parallel review layers and structured triage.
-
-**Your Role:** You are an elite code reviewer. You gather context, launch parallel adversarial reviews, triage findings with precision, and present actionable results. No noise, no filler.
-
-## Conventions
-
-- Bare paths (e.g. `checklist.md`) resolve from the skill root.
-- `this skill directory` resolves to this skill's installed directory (where `agent configuration` lives).
-- `{project-root}`-prefixed paths resolve from the project working directory.
-- `{skill-name}` resolves to the skill directory's basename.
-
-## On Activation
-
-### Step 1: Resolve the Workflow Block
-
-<!-- Adapted for BMAD+: original script dependency removed -->
-
-**If the script fails**, resolve the `workflow` block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:
-
-1. `this skill file` — defaults
-2. `{project-root}/custom/{skill-name}.toml` — team overrides
-3. `{project-root}/custom/{skill-name}.user.toml` — personal overrides
-
-Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by `code` or `id` replace matching entries and append new entries, and all other arrays append.
-
-### Step 2: Execute Prepend Steps
-
-Execute each entry in `{workflow.activation_steps_prepend}` in order before proceeding.
-
-### Step 3: Load Persistent Facts
-
-Treat every entry in `{workflow.persistent_facts}` as foundational context you carry for the rest of the workflow run. Entries prefixed `file:` are paths or globs under `{project-root}` — load the referenced contents as facts. All other entries are facts verbatim.
-
-### Step 4: Load Config
-
-Load config from `{project-root}/project config` and resolve:
-
-- `project_name`, `planning_artifacts`, `implementation_artifacts`, `user_name`
-- `communication_language`, `document_output_language`, `user_skill_level`
-- `date` as system-generated current datetime
-- `sprint_status` = `{implementation_artifacts}/sprint-status.yaml`
-- `project_context` = `**/project-context.md` (load if exists)
-- CLAUDE.md / memory files (load if exist)
-- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
-
-### Step 5: Greet the User
-
-Greet `{user_name}`, speaking in `{communication_language}`.
-
-### Step 6: Execute Append Steps
-
-Execute each entry in `{workflow.activation_steps_append}` in order.
-
-Activation is complete. Begin the workflow below.
-
-## WORKFLOW ARCHITECTURE
-
-This uses **step-file architecture** for disciplined execution:
-
-- **Micro-file Design**: Each step is self-contained and followed exactly
-- **Just-In-Time Loading**: Only load the current step file
-- **Sequential Enforcement**: Complete steps in order, no skipping
-- **State Tracking**: Persist progress via in-memory variables
-- **Append-Only Building**: Build artifacts incrementally
-
-### Step Processing Rules
-
-1. **READ COMPLETELY**: Read the entire step file before acting
-2. **FOLLOW SEQUENCE**: Execute sections in order
-3. **WAIT FOR INPUT**: Halt at checkpoints and wait for human
-4. **LOAD NEXT**: When directed, read fully and follow the next step file
-
-### Critical Rules (NO EXCEPTIONS)
-
-- **NEVER** load multiple step files simultaneously
-- **ALWAYS** read entire step file before execution
-- **NEVER** skip steps or optimize the sequence
-- **ALWAYS** follow the exact instructions in the step file
-- **ALWAYS** halt at checkpoints and wait for human input
-
-## FIRST STEP
-
-Read fully and follow: `./steps/step-01-gather-context.md`
+# Code review
+
+Read the [execution guide](../../shared/execution.md) and
+[Oholiab's role](dev-agent.md). This page is the complete review procedure.
+
+## Inputs
+
+An explicit diff, change artifact or review request identifying the relevant
+project changes. Inspect the repository with host tools. Establish a base revision,
+target revision or working-tree snapshot rather than silently reviewing an
+arbitrary branch. Read the intended behavior and applicable project constraints.
+
+## Procedure
+
+1. Define the review scope and baseline. Inventory changed paths, related callers,
+   tests and requirements. Preserve existing edits and record unavailable context.
+   A supplied diff may omit the surrounding behavior needed to evaluate it.
+2. Review the intended behavior, invariants and relevant failure boundaries.
+   Check control flow, data changes, interface compatibility and test assertions.
+   Add concurrency, permissions, input validation, recovery or UX perspectives
+   where the change makes them relevant.
+3. Use actual independent reviewers only when the host supports them and the
+   scoped work benefits from delegation. Give each a bounded question and the
+   same baseline; record returned evidence. Otherwise perform sequential
+   perspectives and identify them as one assistant's work. Never invent a
+   teammate or treat an absent response as a clean review.
+4. Test each suspected defect against the code and requirements. Seek a concrete
+   triggering case and inspect counterevidence. Run a focused reproduction when
+   practical and within the task. Do not alter product code during a review
+   unless fixes are also authorized.
+5. Triage the results. Remove duplicates, distinguish defects from preferences,
+   and retain the reason when a suspicion is refuted. For a retained issue,
+   provide file/line, trigger, consequence, supporting evidence, confidence and a
+   proportionate fix direction. Severity follows impact and likelihood, not tone.
+6. Reconcile acceptance coverage and review limitations. Record checks actually
+   run, unresolved disputes and missing reviewer or environment evidence. A
+   missing required review makes that coverage incomplete.
+7. Deliver findings in impact order, followed by the scoped conclusion and
+   evidence limits. Zero findings is valid after inspection; it means no
+   actionable defect was found within that reviewed scope.
+
+## Output and acceptance
+
+Write the report for code-review with baseline and scope, inspected evidence,
+findings, refuted suspicions, acceptance coverage and next actions. Each retained
+finding must distinguish an observed defect from a supported inference. Speculation
+without enough evidence belongs in open questions, not an asserted failure.
+
+Use a disposition of findings, no-actionable-findings, or incomplete, and explain
+the scope of that disposition. List partial findings even when coverage is
+incomplete. A passing test suite does not establish a missing review perspective
+or an untested requirement.
+
+## Continue
+
+Compare the current diff and input hashes with the reviewed snapshot. Preserve
+prior findings and check their resolution against actual changes. Re-review
+affected behavior and invalidate conclusions that relied on changed inputs;
+do not rerun unchanged checks merely to refresh the report date.