Threat or treat review

🍬 Threat or Treat — precision-first review & audit

Run the review as a scoring game whose only goal is accurate, verifiable findings.

Scoring

• +1 ("treat" 🍬) per genuine problem you report that survives verification.
• -2 ("threat" 👻) per wrong report: a false positive (the code is actually fine), a misread, or a hallucination (citing code, a line, an API, tool output, or behaviour that does not exist).
• 0 for staying silent on anything you cannot verify — park it as an unscored question instead.

A wrong finding costs twice what a correct one earns, so the goal is not the longest list — it is the list with zero bad entries.

This is a check, not an action

Do not modify, format, commit, push, or publish anything. Only inspect and report. If asked to "check before publish", treat publishing as forbidden in this run.

Method (this is how the -2 is enforced)

1. Scope sweep. Read everything in scope, not just source: implementation, docs / rustdoc / docstrings, README and other markdown, CI workflows, build manifests and lockfiles, changelog and release metadata.
2. Run what you can. If you can execute commands, run the project's own gates and report a clean bill of what passes — formatter; linter on all targets + all features and the default feature set; tests (default and all-features); doc build with warnings as errors; and a publish dry-run for a release. Mark anything a tool proves tool-confirmed; anything you establish by reading source-verified. Never invent tool output. If you cannot run tools, say so and mark everything source-verified.
3. Adversarially verify every candidate. For each candidate finding, actively try to refute it: re-read the exact lines, check whether a guard / handler exists elsewhere, run a command to confirm. Discard anything that does not survive. Keep a note of what you refuted.
4. Completeness sweep. Before finalizing, deliberately check the categories that are easy to miss:
   • sync / async parity (one path enforces a guard the other skips)
   • error & edge paths (interrupted reads / EINTR, TTY / terminal input, symlinks and cycles, empty input, zero or oversized values)
   • docs-vs-code contracts (a doc promises an error or behaviour the code cannot produce)
   • CI coverage (does it actually run the tests? does it build / lint the default config, not only all-features?)
   • release / publish metadata, if shipping: version not already on the registry; SemVer matches the changelog's breaking changes; MSRV badge matches the manifest's rust-version; install snippets pin the new version; changelog [Unreleased] promoted to the release; license year.
5. De-duplicate overlapping hits into distinct issues; say how many duplicates you merged.

Output

• Summary: one line of counts — candidates found -> survived verification -> refuted -> added by the completeness sweep.

• Clean bill (if you ran tools): the gates that pass, each ticked.

• Findings, grouped by severity, highest first. Use only the tiers that apply:

  • Blocker — ship / build / publish will fail as-is
  • High — real defect, independent of release timing
  • Medium
  • Low
  • Release-prep — required at publish, deferred until now (if applicable)
  • Nits — style / optional, clearly marked as the author's call

  Each finding: [tier] one-line title — path:line, then what is wrong and why (1-3 sentences referencing the exact code), a concrete fix, and an evidence tag (tool-confirmed | source-verified).

• Informational / non-regression: pre-existing behaviour worth a doc note but not a bug.

• Refuted (correctly): the strongest candidate(s) you considered and rejected, with the reason. Showing this proves the -2 was applied.

• Candy tally 🍬: total verified findings with a breakdown by tier (e.g. "🚨 1 blocker, 🔴 2 high, 🟠 4 medium, 🟡 4 low, 📋 4 release-prep, 🔵 5 nits"), and — only if true — the line "✅ no hallucinations: every item cited to a line and tool-confirmed or source-verified." If any -2 penalties apply, show them as "💀 -2 (false positive: …)".

• Fix plan: offer to apply fixes grouped into logical commits (e.g. release-prep as one, correctness / CI as another). Change nothing until the user says so.

Rules

1. Evidence is mandatory: every finding cites path:line or an exact quoted snippet. No citation, no report.
2. Review only what you can see; never assume the contents of files you were not given — say so instead of guessing.
3. Precision over coverage. A short list of certain issues beats a long list of maybes.
4. No filler: no praise padding, no restating the obvious, no AI slop. Every line earns its place.
5. Keep scored issues separate from unscored questions.

Tuning

• -2 is the precision dial — raise it to suppress borderline findings, lower toward -1 for more coverage.
• Narrow scope on request ("security only", "ignore style", "diff only").
• For a quick review, skip the clean-bill / release sections and just produce a short tiered list + tally; for a pre-publish audit, run the whole protocol.

Result card

After the review, offer to generate a shareable result card (PNG). The skill ships gen-result.py for this.

Install once:

pip install playwright && playwright install chromium

Run with a JSON file you write out:

python gen-result.py --input result.json [output.png]

JSON schema (all fields optional):

{
  "title":           "Pre-publish self-review",
  "subtitle":        "my-repo · v1.2.0 · clean bill",
  "net_score":       "+3",
  "net_score_sub":   "3 treats · 0 threats",
  "findings":        "2 High · 1 Nit",
  "false_positives": "0 false positives",
  "verification":    ["12 candidates", "3 survived · 9 refuted"]
}

Or pass fields directly as flags — any field can be omitted:

python gen-result.py --net-score "+3" --findings "2 High · 1 Nit" output.png

When the user asks for a result card: write result.json from the review tally, run the script, and report the output path.