code-change-verification

name	code-change-verification
description	Review a commit, PR, or merged patch when the user requests ordinary code-change verification. Do not combine with adversarial-validation; use that skill instead for explicitly adversarial, substantial, or high-risk RustFS reviews.

Code Change Verification

Use this skill for an ordinary requested review. If the root policy or user calls for adversarial validation, use adversarial-validation instead of running both.

Quick Start

1. Read the scope: commit, PR, patch, or file list.
2. Map each changed area by risk and user impact.
3. Inspect each risky change in context.
4. Report findings first, ordered by severity.
5. Close with residual risks and verification recommendations.

Core Workflow

1) Scope and assumptions

• Confirm change source (diff, commit, PR, files), target branch, language/runtime, and version.
• If context is missing, state assumptions before deeper analysis.
• Focus only on requested scope; avoid reviewing unrelated files.

2) Risk map

• Prioritize in this order:
  • Data correctness and user-visible behavior
  • API/contract compatibility
  • Security and authz/authn boundaries
  • Concurrency and lifecycle correctness
  • Performance and resource usage
• Give higher priority to stateful paths, migration logic, defaults, and error handling.

3) Evidence-based inspection

• Read each modified hunk with neighboring context.
• Trace call paths and call-site expectations.
• Check for:
  • invariant breaks and missing guards
  • unchecked assumptions and null/empty/error-path handling
  • stale tests, fixtures, and configs
  • hidden coupling to shared helpers/constants/features
• If a point is uncertain, mark it as an open question instead of guessing.

Rust-specific checks (apply to all Rust changes)

Run the full checklist in rust-code-quality — the canonical Rust review checklist for the unwrap/casting/cloning/locking/recursion/error-type/serde/test rules and the reuse-and-necessity checks (duplicated helpers, defensive branches without a nameable trigger, redundant error wrapping). Do not restate those rules here; carry its P0–P3 ratings over unchanged and use this skill's output format.

4) Findings-first output

• Order findings by severity:
  • P0: critical failure, security breach, or data loss risk
  • P1: high-impact regression
  • P2: medium risk correctness gap
  • P3: low risk/quality debt
• For each finding include:
  • Severity
  • path:line reference
  • concise issue statement
  • impact and likely failure mode
  • specific fix or mitigation
  • validation step to confirm
• If no issues exist, explicitly state No findings and why.

5) Close

• Report assumptions and unknowns.
• Suggest targeted checks (tests, canary checks, logs/metrics, migration validation).

Output Template

1. Findings
2. No findings (if applicable)
3. Assumptions / Unknowns
4. Recommended verification steps

Finding Template

• [P1] Missing timeout for downstream call
  • Location: path/to/file.rs:123
  • Issue: ...
  • Impact: ...
  • Fix suggestion: ...
  • Validation: ...