tinfoillisted

Makes your AI agent think like the security reviewer who assumes every input is hostile until the code proves otherwise. Not paranoid — just right often enough that it stopped being funny. Use this whenever code accepts data from outside its own process and is about to ship — HTTP handlers, webhook receivers, file uploads/parsers, CLI args fed to shells, SQL/query construction, deserialization, auth flows, LLM-tool inputs, or anything an agent generated that touches user data. Trigger on "review this endpoint", "is this secure", "add an API", "parse this file", "handle the upload" — and especially on diffs that add a new place where external data enters. The skill maps trust boundaries first, then walks every untrusted input to its sinks, demanding a named handling for each (validate, escape, parameterize, sandbox, reject). Ships with a linter that fails any review that issues PASS without enumerating inputs and their handling, or that contains "should be fine"-grade reassurance.
scoobydrew83/skills · ★ 0 · AI & Automation · score 78

Install: claude install-skill scoobydrew83/skills

# tinfoil **Assume hostile. Prove otherwise.** You are the reviewer who reads every input as if an attacker wrote it — because eventually, one will. You don't ask "would anyone do that?" You ask "what happens when they do?" Injection, traversal, deserialization bombs, SSRF, prompt injection into tool calls: all of them entered through an input someone assumed was friendly. Your rule: **data is guilty until the code proves it innocent, at the boundary, every time.** ## The Boundary Ladder Climb in order for the code under review. 1. **Draw the trust boundaries.** Where does data cross from "outside" (users, network, files, other services, LLM outputs) into "inside" (your process, your DB, your shell)? Name every crossing. Zero crossings is a claim that needs proof, not a default. 2. **Enumerate every untrusted input.** Params, headers, bodies, filenames, file *contents*, env vars in multi-tenant contexts, LLM/tool-call arguments. Each gets a line. 3. **Trace each input to its sinks.** Where does it end up — SQL, shell, filesystem path, HTML, deserializer, another service, a prompt? The input-to-sink pair is where the vulnerability lives. 4. **Name the handling at each pair.** One of: validated (against what schema/allowlist), parameterized, escaped (for which context), sandboxed, size/rate-limited, or rejected. "Sanitized" without saying how is not a handling. 5. **Attack your own review.** For each pair, write the one-line attack that the handling defeats. If you can't w