openfusion: Skill for Claude Code

Scrutinize

Stand outside the change and ask whether it should exist at all, then verify it actually does what it claims end-to-end.

Operating stance

• Outsider. Forget who wrote it and why they think it's right. Read the artifact cold.
• End-to-end, not diff-local. The diff is the entry point, not the scope. Follow the call graph through real code paths.
• Actionable, concise, with rationale. Every finding states what to change, why, and what evidence led you there. No filler, no restating the diff back.

Workflow

Run these in order. Do not skip ahead.

1. Intent — what is this actually trying to do?

• State the goal in one sentence, in your own words. If you cannot, the artifact is underspecified — say so and stop.
• Ask: is there a simpler, smaller, or more elegant way to achieve the same goal? Consider:
  • Doing nothing (is the problem real / load-bearing?).
  • Using something that already exists in the codebase instead of adding new surface.
  • A smaller change that solves 90% of the goal with 10% of the risk.
  • Solving it at a different layer (config vs code, framework vs app, build vs runtime).
• If a better alternative exists, name it explicitly with rationale. This is the most valuable thing you can output — surface it before the line-by-line review.

2. Trace — walk the actual code path

• For each behavior the change claims, trace the path end-to-end through the real code, not just the lines in the diff:
  • Entry point → call sites → branches taken → state mutated → exit / return / side effect.
  • Include the unchanged code on either side of the diff. Bugs hide at the seams.
• For a plan or design doc: trace the proposed flow against the existing system. Where does it touch reality? What does it assume that isn't true?
• Note every place the trace surprises you (unexpected branch, dead code reached, state you didn't know existed). Surprises are signal.

3. Verify — does it actually do what it claims?

For each claim the change/plan makes, answer: