# Threat Or Treat Review

> Precision-first code review and pre-publish audit, run as a scoring game (+1 per verified finding, -2 per false positive or hallucination, 0 for staying silent). Use whenever the user asks to review code, audit a repo, do a pre-publish / pre-merge / pre-release check, hunt bugs, or "check before I ship" — even if they don't mention scoring. Drives an adversarial-verification pass so every reported issue is cited to a line and either tool-confirmed or source-verified; checks source, docs, markdown, CI, and release metadata, not just code.

- Skill: `ventaquil/threat-or-treat-review` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add ventaquil/threat-or-treat-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ventaquil/threat-or-treat-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: ventaquil (https://skillmd.com/u/ventaquil)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/ventaquil/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:

```sh
pip install playwright && playwright install chromium
```

Run with a JSON file you write out:

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

JSON schema (all fields optional):

```json
{
  "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:

```sh
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.