proofline
TR

proof-review

Purpose

Reviews a code change (uncommitted work, a branch, or a PR) and reports only what it can prove.

Source Skill purpose

When to use it

Use proof-review for a change, branch or pull request that needs claims checked against code and evidence. It takes intent from the user, issue, pull request or frozen plan rather than guessing it from implementation. It checks newly introduced violations of written project rules and looks for defects in changed code and direct callers. A bug is reported only with a concrete trace or reproduction in a separate worktree. The reviewer describes findings and does not fix the code.

Source Skill purpose

How it works

Steps of the skill, in source orderEach numbered step follows the skill definition and links to its source.1. Choose the targetFlow2. Prepare an output folderFlow3. Check change sizeFlow4. Collect intent claimsFlow5. Show the checkpointFlow6. Review intentFlow7. Check written rulesFlow8. Find bug candidatesFlow9. Probe in a worktreeFlow10. Refute the evidenceFlow11. Clean upFlow12. Write the reportFlow
Steps of the skill, in source order

Source Flow

  1. Choose the target Inside a run review the task diff; otherwise resolve the requested change and its fixed comparison point.

    Source Flow

  2. Prepare an output folder Set up or resume an evidence folder and clear stale target folders as the method directs.

    Source Flow

  3. Check change size Measure the diff and present the prescribed options when it exceeds review limits.

    Source Flow

  4. Collect intent claims Take claims from the frozen plan inside a run or from user-provided sources outside it.

    Source Flow

  5. Show the checkpoint Before project execution outside a run, show the required scope and execution checkpoint.

    Source Flow

  6. Review intent Classify each claim against the change and identify behavior outside the requested scope.

    Source Flow

  7. Check written rules For rule-focused reviews, inspect only checkable project rules newly affected by the diff.

    Source Flow

  8. Find bug candidates For bug-focused reviews, trace changed code and its direct callers to concrete failure candidates.

    Source Flow

  9. Probe in a worktree Find project test commands and run the target in an isolated worktree with bounded time.

    Source Flow

  10. Refute the evidence Reproduce or trace candidates, then try to show each is safe before reporting it.

    Source Flow

  11. Clean up Remove evidence worktrees and confirm the user's working-tree state has not changed.

    Source Flow

  12. Write the report Validate findings and report proven bugs, rule breaches and claim results with their evidence.

    Source Flow

Key rules

  • Report a bug only with a concrete trace or reproduction; unproved ideas belong to suspicions.

    Source Hard rules

  • Review without editing the user's code; a later fixing step owns any repair.

    Source Hard rules

  • Run probes in a separate worktree rather than modifying the user's working directory.

    Source Hard rules

  • Take intent from an explicit source, never from the code being reviewed.

    Source Hard rules

  • Keep bug hunting to changed code and direct callers; report only newly introduced rule violations.

    Source Hard rules

Output and gate

Output

The skill definition states no output.

Source Skill definition

Gate

  • A missing claim, proven bug, newly broken rule or blocking unrequested behavior makes the review fail.

    Source Gate rule (focus runs inside a run)

  • Otherwise the review passes; unproved suspicions do not change its result.

    Source Gate rule (focus runs inside a run)

  • The findings validator recomputes the gate result and rejects an inconsistent document.

    Source Gate rule (focus runs inside a run)

Source

Source Skill definition

← All skills