Verify Findings

Verify Findings

Core Rules

• Do not modify files, run apply_patch, or create new files.
• Do not run formatters, generators, or commands that write to disk.
• If verification requires a write, running tests, network access, or a long-running command, ask first.
• Focus on evidence and reproducibility, not fixes.
• Do not use explorer subagents for finding verification or review adjudication.
• Keep verification in the current/main agent by default so it uses the best available model and full context.
• If the user explicitly asks for delegated independent verification, or a local instruction forces delegation, use the highest-quality non-explorer option available, such as a reviewer agent or a default agent that inherits the current model.
• Treat review-finding verification as targeted evidence checking, not broad codebase exploration.

Workflow

1. Restate the findings as a numbered checklist if the input is unstructured.
2. Investigate each finding with read-only commands (rg, ls, cat, git show) and code inspection.
3. Classify each finding as Confirmed, Likely, Unclear, Refuted, or Not applicable.
4. Capture evidence with file paths and line numbers or a concise snippet that proves the claim.
5. Report results and wait for the user to choose which findings to act on.

Response Format

• Format each finding as its own block.
• Put each field label on its own line. Do not inline multiple labels in one paragraph.
• Use this exact field order for each finding: Finding, Status, Evidence, Notes, Next step.
• Leave a blank line between finding blocks.
• Recommended template:

  1. Finding: <short restatement of the claim>
  Status: <Confirmed | Likely | Unclear | Refuted | Not applicable>
  Evidence: <file paths, line numbers, and short proof>
  Notes: <important nuance, scope, or uncertainty>
  Next step: <what the user should do next, or `None` if no action is needed>
  

• If anything is missing to verify, ask targeted questions.