Evidence Audit

Audit a response, handoff, PR note, release report, or teammate update for evidence-backed delivery claims.

Goal

Make ShipFrame reports trustworthy by separating what was actually proven from what was inferred, partially checked, or not checked.

Inputs

Accept either:

• pasted text from the user;
• a file path to a report, handoff, PR description, changelog, or release notes;
• the current draft response/report in the conversation.

If no text or file is provided, ask for the report to audit.

Claim classes

For each meaningful claim, assign exactly one class:

Risky claim triggers

Always inspect claims containing words or equivalents like:

• shipped, released, deployed, published, live, in production;
• merged, approved, closed, resolved;
• tested, verified, smoke-tested, validated, passing;
• works, fixed, complete, done;
• available, installed, submitted, accepted, official.

Treat these as risky until the report names concrete evidence.

Evidence rules

Prefer direct evidence over inferred evidence:

1. Exact production/staging URL response, timestamp, and route checked.
2. Version endpoint, visible version, tag, release object, package version, or deployed commit SHA.
3. CI/build/test job result tied to the exact branch or commit.
4. Local command output with command, environment, and pass/fail result.
5. Screenshots/log snippets as supporting evidence.

Configuration, code presence, an opened PR, or an intended deploy pipeline is not enough to say a behavior is live.

Generic core boundary

Keep this skill project-agnostic. Do not hardcode client/project-specific gates, tenants, paid providers, private URLs, or product rules here. Load those from project-profile, .shipframe/profile.md, or repo documentation when available.

Audit procedure

1. Identify every delivery, verification, release, or availability claim.
2. Extract the evidence quoted or referenced for each claim.
3. Compare the claim scope to the evidence scope:
   • local vs CI vs staging vs production;
   • public route vs authenticated/private behavior;
   • simulated provider vs paid/live provider;
   • branch/PR vs merged main vs deployed commit;
   • tag created vs release object published;
   • config present vs runtime behavior observed.
4. Mark overclaims where wording is stronger than evidence.
5. Rewrite risky wording into an evidence-honest version.
6. List missing checks needed to upgrade Partially verified or Unverified claims.

Output format

## Evidence Audit

### Verdict
<Trustworthy | Needs wording changes | Not enough evidence>

### Claim table
| Claim | Classification | Evidence found | Gap / risk | Safer wording |
|---|---|---|---|---|
| <claim> | <Verified/Partially verified/Unverified> | <evidence> | <gap> | <rewrite> |

### High-risk overclaims
- <claim and why it is risky, or "None">

### Missing evidence to collect
- <specific command, URL smoke, CI/deploy proof, or "None">

### Recommended final wording
<short evidence-honest summary the user can paste>

Completion rule

Do not approve a report that says “done”, “deployed”, “released”, “published”, or “works in production” unless the report contains exact-environment evidence for that claim.