Prove first

Prove First

Establish whether the claimed problem exists in the current repository before changing code. Treat a well-supported no-patch result as successful work, not as failure to act.

Apply the protocol

1. State the claim as one falsifiable sentence. Extract the expected behavior, actual behavior, and relevant environment from the request and repository.
2. Read the repository instructions and inspect the current implementation before choosing a probe.
3. Choose the cheapest decisive, non-destructive probe. Prefer an existing focused test, reproduction command, or direct observation over a broad suite.
4. Run the baseline before editing. Preserve the exact command and the observation that matters.
5. Classify the baseline:
   • confirmed: the material issue reproduces now.
   • partial: only a bounded part of the claim reproduces, or an existing fix covers only part of the required behavior.
   • no-patch: the claim does not reproduce, is already fixed, or requests behavior the repository already provides.
   • blocked: available evidence cannot decide the claim safely.
6. Treat only confirmed or partial as patch-eligible. This classification never expands the user's authorization: if the request is diagnosis-only, report the evidence and do not edit. When editing is authorized, limit the patch to the reproduced gap.
7. Re-run the same decisive probe after editing, then run proportionate regression checks.
8. Return a compact Prove Report using the fields in references/prove-report.schema.json.

Read references/protocol.md when the claim is ambiguous, the first probe is inconclusive, or the classification is disputed. Consult references/cases.md for boundary examples.

For authorized fix intent, do not stop at classification: attempt the bounded patch and verify it. For diagnosis-only intent, stop after reporting the evidence. Partition mixed requests by justification; apply this protocol only to defect-dependent changes and handle independent intentional changes under the normal repository workflow.

If the skill was invoked explicitly for a non-applicable mechanical task, state Protocol not applicable: the requested outcome is intentional, not defect-dependent. Then continue normally without a Prove Report.

Hold the line

• Do not patch first and reconstruct a justification afterward.
• Do not weaken, delete, or bypass a test to manufacture success.
• Do not treat one passing run as proof that a reported flaky failure is absent.
• Do not expand a partial reproduction into a broad cleanup.
• Do not use destructive probes or make external writes without authorization.
• Do not speculate around missing credentials, services, fixtures, hardware, or platform access. Return blocked and name the missing evidence.
• Before returning blocked, check safe local substitutes such as existing fixtures, mocks, logs, history, and static inspection; report which were insufficient.
• Do not expose hidden chain-of-thought. Report commands, observations, decisions, and remaining uncertainty.
• Do not turn a request to inspect, diagnose, review, or report into an implementation request.

Report the outcome

Use this human-readable shape unless the caller requests schema-valid JSON:

Prove Report
Protocol version: 1.0.0
Status: confirmed | partial | no-patch | blocked
Claim: <falsifiable claim>
Baseline: <command or observation and result>
Decision: <whether the evidence made a patch eligible, the user's authorized scope, and the exact boundary>
Execution: patched | diagnostic-only | no-patch | blocked
Changes: <files/behavior changed, or none>
Verification: <same probe plus regression evidence>
Missing evidence: <only when blocked or still uncertain>
Risks: <residual uncertainty or none>

For no-patch, state Changes: none and show the evidence that made inaction correct. For blocked, state exactly what input or access would unblock the decision.