# To Fuzz > Distill a fuzzing plan out of the current conversation and codebase — the targets worth fuzzing, each with its entry point, input model, and failure oracle — and write it to an in-repo doc. Use when the user wants to fuzz-test something, harden a parser or decoder against untrusted input, find crashes/panics/UB, turn invariants into fuzz targets, or plan a fuzzing campaign. - **Type:** Skill - **Install:** `agentstack add skill-officialunofficial-skills-to-fuzz` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [officialunofficial](https://agentstack.voostack.com/s/officialunofficial) - **Installs:** 0 - **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills) - **Latest version:** 0.1.0 - **License:** Apache-2.0 - **Upstream author:** [officialunofficial](https://github.com/officialunofficial) - **Source:** https://github.com/officialunofficial/skills/tree/main/skills/engineering/to-fuzz ## Install ```sh agentstack add skill-officialunofficial-skills-to-fuzz ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About Take the current conversation and codebase understanding and produce a **fuzzing plan**: the set of targets worth fuzzing, each pinned to a concrete failure **oracle**. Do NOT interview the user — synthesize what you already know. Then write the plan and, when the harness is obvious, scaffold the target stubs. A fuzz target is three things: an **entry point** (the function under test), an **input model** (how bytes become that function's arguments), and an **oracle** (the check that decides a run *failed*). The oracle is the whole game — a fuzzer that only catches segfaults wastes most of its runs. If `/to-invariants` has already produced `docs/INVARIANTS.md`, mine it: every enforceable invariant is a ready-made oracle. ## Process ### 1. Map the attack surface Find the code that turns untrusted or complex input into internal state — that's where fuzzing pays. Sweep for: - **Parsers / deserializers / decoders** — anything named `parse`, `decode`, `from_bytes`, `read_*`, or that takes `&[u8]`/`string` from outside. Highest ROI; fuzz these first. - **State machines** — sequences of operations where the *order* can violate an invariant (a fuzzer drives random valid-ish op sequences). - **Encoders paired with decoders** — candidates for a round-trip oracle. - **Arithmetic / indexing / allocation sized by input** — overflow, panic, quadratic blowup, OOM. - **Trust boundaries** — any input crossing a network, file, or IPC edge. ### 2. Choose an oracle per target Pick the strongest oracle you can compute cheaply. In rough order of value: - **Differential** — run two implementations that must agree (a reference vs the optimized one; the old version vs the new; a spec model vs the code) and assert equal outputs. Catches *wrong* answers, not just crashes. - **Round-trip / inverse** — `decode(encode(x)) == x`, `parse(print(x)) == x`. Cheap, total, catches whole classes of corruption. - **Invariant** — assert a property from `docs/INVARIANTS.md` holds on the output/state. Reuse it directly. - **Crash / assertion** — panics, `unwrap`, UB, failed `assert`, memory errors under a sanitizer. The default floor; combine with one of the above rather than relying on it alone. - **Resource** — a wall-clock/allocation ceiling to catch algorithmic-complexity blowups. A target with only a crash oracle is weak — say so and note the stronger oracle it *could* have. ### 3. Define the input model - **Structured** (preferred where the input is typed): derive/implement an `Arbitrary`-style generator so the fuzzer explores valid-shaped inputs and spends fewer runs on the parser rejecting garbage. - **Raw bytes**: for parsers whose whole job is to survive arbitrary bytes — feed the raw buffer. - **Seed corpus**: list concrete starting inputs — a minimal valid case, a known tricky case, a past regression. Seeds are the single biggest lever on how fast a fuzzer finds bugs. - Note a **dictionary** (format keywords/magic bytes) when the format has them. ### 4. Pick the harness Match the stack (see [HARNESSES.md](HARNESSES.md) for scaffolding per tool): cargo-fuzz/libFuzzer or `Arbitrary` + `proptest` (Rust), native `go test` fuzzing (Go), Jazzer (JVM), Atheris (Python), libFuzzer/AFL++ (C/C++), fast-check or jsverify (JS/TS). If the project already fuzzes with one, use it. ### 5. Write the plan Write to `{{ARGUMENTS}}` or `docs/FUZZING.md`. Use the template. When the harness is unambiguous, also scaffold each target's stub file (entry point + input model wired up, oracle as a TODO or filled if trivial) and say where you put them. ### 6. Report List the targets, which oracle each got, and the **surface you chose not to fuzz** with the reason. Offer to run the campaign or wire it into CI (don't unless asked). # Fuzzing plan > Targets worth fuzzing, each with an entry point, an input model, and an oracle. > Scope: ## Targets ### FUZZ-1: - **Oracle:** — - **Input model:** — - **Seeds:** - **Harness:** ## Not fuzzed (and why) - — ## Notes - ## What makes a good fuzz target - **Strong, total oracle.** It can judge *every* run, and it catches wrong answers, not only crashes. If the only thing that can fail is a segfault, the target is under-powered. - **Narrow entry point, close to the untrusted input.** Fuzz the parser directly, not the whole app around it — shorter path from bytes to bug, faster iterations. - **Deterministic.** Same input → same result. No clocks, threads, or network in the loop, or the fuzzer chases ghosts and can't minimize. - **Seeded.** Ships with a corpus that already reaches interesting states. FUZZ: decode() on arbitrary bytes; oracle = round-trip encode(decode(x)) re-encodes to the same canonical bytes, AND no panic. Narrow entry point, total oracle that catches corruption (not just crashes), raw-byte input model — ideal. FUZZ: run the whole request handler on random bytes; oracle = "doesn't crash". Entry point too wide (most runs die in the HTTP layer before reaching logic), oracle too weak (silent wrong answers pass). Narrow to the body parser; add a differential or invariant oracle. Task: distill the fuzzing plan from the current context and write it to the doc. {{ARGUMENTS}} ## Source & license This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code. - **Author:** [officialunofficial](https://github.com/officialunofficial) - **Source:** [officialunofficial/skills](https://github.com/officialunofficial/skills) - **License:** Apache-2.0 Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-officialunofficial-skills-to-fuzz - Seller: https://agentstack.voostack.com/s/officialunofficial - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.