paranoid: attack your own running app

README and SECURITY.md state localhost-only, authorized, non-destructive testing and claim the skill will decline out-of-scope requests; the CI workflow shows least privilege (contents: read), SHA-pinned actions, and persist-credentials: false, which are visible positives. However, the actual skill instructions (skills/paranoid), commands/hack-me.md, and references are absent from the evidence, so the promises of refusal, non-destructiveness, and minimal patches cannot be verified at the instruction level. The tool patches user code directly with no described backup, diff confirmation, or rollback path, and there is no statement on how sensitive artifacts captured during proof (passwords, tokens) are handled. Each item scores 1: asserted but not verifiable.

The README describes a coherent find→prove→patch→re-verify→sweep loop and honestly discloses a real failure (the DVWA run where sweep missed a sibling injection), which supports self-consistency. But the skill body is missing, so the described flow cannot be checked against implementation. On dependencies, the project claims 'no dependencies, no network calls', yet benchmark/harness/run.py imports and executes solution code it is pointed at, as SECURITY.md itself admits — an execution risk not surfaced in the main README narrative. Failure messages and error-handling paths are not evidenced. All three score 1.

Audience and scenarios are well described: developers on Claude Code / Codex / Cursor, 12 framework guides, 24 vulnerability classes, and explicit applicability notes for three independent targets (VAmPI, DVWA, VulnShop) — this earns 2. Capability boundaries are also stated clearly (own code only, localhost only, no third-party targeting, no live malware) — 2. Trigger precision rests only on README examples (/paranoid:hack-me, /hack-me); commands/hack-me.md is not provided, so trigger conditions, arguments, and preconditions cannot be judged. Environment fit (port discovery, how the app is started, non-HTTP cases) also lacks verifiable detail. Both score 1.

Information architecture is strong: a complete README with Quickstart, Receipts, Scope & ethics, Roadmap, Contributing, License, and links into references, checklists, benchmark, and examples — 2. Install notes are concrete (plugin marketplace and npx skills paths) — 2. Examples and FAQ-level material are extensive, with tabulated findings and reproduction commands — 2. Known limitations are stated honestly (v0.1, two task classes not yet model-scored, VulnShop's upstream README naming the classes, the sweep miss) — 2. LICENSE is a full MIT text — 2. Naming stability cannot be assessed because the skill files are absent; versioning is a single 'v0.1' with no CHANGELOG; maintenance responsibility points only to issues/PRs and a Security Advisory with no maintainer commitment or response target. Those three score 1.

For output usability, the README shows report samples and before/after status tables, but the actual HACKME_REPORT.md files and the skill's output template are not in evidence, so it is unclear whether output is directly consumable in an engineering workflow — 1. Marginal value has unusually honest evidence: the author published a negative benchmark result (security advice gave zero benefit on isolated functions for a capable model) and pivoted to runtime attack accordingly, which raises credibility; but that same result indicates limited marginal value in some settings, and there is no independent third-party reproduction — 1. On cost/benefit, the claimed zero-dependency Markdown form is cheap, but patches modify user code and require a running app with potentially destructive requests, and the trade-off is not quantified — 1.

Key claims (6 VAmPI bugs, 4 ledgerlite bugs, 5 VulnShop bugs, 22/24 benchmark classes) point to in-repo files, so traceability is intended, but the cited examples/*/HACKME_REPORT.md, benchmark results, and skill files are all absent from this evidence, so nothing can be cross-checked — claim_traceability and cross_source_corroboration each score 1. Fact/inference separation is handled well: the author explicitly distinguishes 'proven', 'same pattern fixed but not separately proven', and 'task classes not yet model-scored', which is a genuine positive, but again lacks verifiable raw records, so it also scores 1.