Building Claude Skills as a Bug Bounty Hunter

Two hosts wrestle openly with whether talking about Claude Code skills gives away their edge, then do it anyway. What comes out is a concrete, opinionated playbook for turning Claude Code into a pair-hacking partner without dumbing it down into a copy of yourself.

What a Claude skill actually is (and the RAG misconception)

The hosts use “skill” loosely, and clarify it early. A skill is almost always just a skill.md Markdown file carrying information, sometimes bundled with a command-line tool or script that the file tells Claude how to invoke. The key mechanical detail: the front matter of skill.md holds a name and a description, and that front matter is auto-injected into the system prompt at launch, for every skill (they estimate this scales cleanly to at least 35-50 skills). So the trigger rules (“use this skill when…”) belong in the description field, because that is the only part Claude sees before deciding to load the skill.

They explicitly correct the loose talk of Claude “ragging” skills into context. This is not RAG in the embeddings-search sense; Claude Code does no embeddings-based retrieval by default. It is a load-of-skill event driven by the front-matter description, which is why you see the “loading skill” line in the terminal. Related terminology hygiene: one host refuses to let “training” be used for giving Claude a prompt or context, insisting on “guide / inform / equip” instead. When a bundled tool is needed, they let Claude write it in Bun/TypeScript, on the intuition that Claude makes fewer mistakes in the language it prefers (Anthropic having acquired Bun), even though neither host is a TypeScript person.

When to build a skill versus letting Claude figure it out

The central tension of the episode: does codifying a skill hamper Claude by boxing it in, when its whole value is figuring out nuance on its own? The resolution is a set of buckets for when a skill earns its place.

First, things Claude simply cannot know. Custom infrastructure (a VPS at a specific IP, a specific user, where to save output, SSH/SCP destinations) has to be told to it, via a skill or a CLAUDE.md line. Second, secret or non-public knowledge: private gadgets and primitives (for example an ID-to-username oracle for a specific program), or techniques from something like last year’s DEF CON talk that never made it into the training data. The model may eventually work these out, but a skill gives it a head start. Third, gated tools it literally cannot access otherwise: software behind enterprise sales. Once you have credentials or an API token, wrapping them in a skill hands Claude a capability it could not have had at all. Fourth, large solution spaces where you want one specific method. Making an HTTP request can be done with curl, JavaScript, Python, Caido, wget, Chrome DevTools, or Playwright; if you want it done through Caido specifically (so you get request history, screenshots, and POC material), a skill enforces that.

The counterexample they keep is Caido “Kaito” mode itself: without a skill, Claude might burn half a five-hour Max window teaching itself the SDK by hunting docs and GitHub source. The escape hatch against over-constraining is a single CLAUDE.md line: invoke the skill, but if it is not comprehensive, fails, or does not work, do not stop there; use your own creativity and keep going. The host runs “POC or GTFO” and “try harder” in his CLAUDE.md for exactly this reason, wanting a fully validated end-to-end POC rather than “this looks vulnerable.” Both note that studies have shown badly written CLAUDE.md or skill files actively degrade output quality, so restraint matters.

Tiered fallback design and the determinism-versus-creativity split

The most reusable architectural pattern discussed is tiered fallback, observed in the Caido skill. Claude first tries the documented binaries/scripts; if that fails it drops to invoking the underlying client TypeScript library directly (chaining actions into a written script for complex tasks); if that fails it falls back to driving Caido over GraphQL. Interestingly, nobody hard-coded this cascade into the skill. The hosts attribute the emergent retry behavior to fine-tuning on a year of real Claude Code sessions where the ideal trajectory was fail, retry, fail, retry, succeed, rather than the old one-shot models that stopped at the first error. The deliberate version of the same idea (try method A, else B, else C) they confirm gives much higher odds of success, and one host has implemented something similar for hard bug bounty problems.

On methodology, the recommendation is to do both and compare, because tokens are cheap and subsidized right now. Hard-code your front-end analysis methodology into a skill for determinism, so Claude cannot silently skip steps you always run (loading source maps, source-map enumeration, beautifying with Prettier); a free-roaming agent might never load source maps and then report “found nothing,” and you would not notice because you are off hacking something else. But run a separate, unconstrained instance with none of that, then compare. Whatever the free agent found that your hard-coded workflow missed, ask how it did it and fold that technique back into the skill. The comparison method matters: do not paste both reports into a fresh agent (that is lossy). Instead have one agent summarize what it tried and found, paste that into the other agent which still holds its own context, and ask it for gaps in both directions (“what did it find that you didn’t, what did you try that it didn’t”). An even stronger variant: a third agent reads both agents’ context files and cross-references what each tried against each output. When the comparison surfaces something useful, tell the agent to add it to the workflow so it is not missed next time, including telling the skill outright “do not limit yourself to this workflow; if you find something interesting, go down the rabbit hole and come back.”

A working skill stack and the note funnel

Several concrete skills are named. The Caido/Kaito mode skill is called the single highest-value, outsized-return move: hand it a batch of JavaScript files and have it recreate every HTTP request as Caido replay sessions, drive Replay, and (when hacking locally) pipe straight to the Findings tab so you get the red-dot notification. session-search is a small CLI wrapper around ripgrep across all local session logs (the host is at ~4 GB of Cloud Code logs), used to recover a past conversation or grep out a mislaid HackerOne API token from an old bbscope command. zero-day research, built by JDX/Doctor from Eugene’s book and public content, is strong at reading source code and binaries (executables, macOS DMGs), a case of secret expert-monologue knowledge not yet in the training set. A personal content-creator / report-writer skill is recommended for everyone: seed it with examples of your best reports, tell it to stay concise, technical, and flavorless, and give it exact fields to fill every time. For scope data the model cannot fetch itself, bbscope and Patrick’s H1 Brain (an MCP, not a plain skill) pull the policy page, scope, and disclosed public reports so the agent stops going out of scope and gets a heuristic for what is likely vulnerable.

The organizing structure for output is a funnel of note types: notes, leads (interesting findings), gadgets/primitives (they suggest “primitives” as the more training-set-native word), findings, and reports. Volume is highest at the bottom and narrows upward as notes graduate into leads or gadgets, then findings, then reports. Sitting in that pipeline is a validator, and this is the one place the hosts endorse a sub-agent over a skill, precisely because you want it unbiased by the rest of the session context. Feed the validator real calibration examples: CORS issues are often false positives, blind XSS is not valid just because it bypasses the WAF unless you get an actual trigger callback, and it should stay skeptical rather than rating everything critical or high. Where notes physically live is a per-hunter choice the skill should pin down: Notion (Grapnel’s preference), Obsidian, a database, or an API such as a personal api.example.com endpoint so leads and gadgets are reachable no matter whether Claude is running on the VPS or the laptop.

Runtime setup: Claude MD, folders versus agents, persistence

Two CLAUDE.md essentials. Give it context about you (a bug bounty hunter doing ethical testing, everything asked is in scope but try to stay in scope, no destructive actions unless on accounts you own) which reduces refusals and out-of-scope drift. And specify the note structure and destination.

For separating hacking from everyday use, the hosts compare agents and folders. An agent in Claude Code is a specific system prompt plus a whitelisted set of skills/tools (for example a dedicated pen-tester agent). The slightly preferred alternative is folder-based loading: Claude Code reads the .claude folder in the launch directory first and cascades up to the parent/home .claude, so a dedicated hacking folder loads all your skills and prompts only when you launch from inside it, keeping normal home-directory use clean. This enables target-specific folders: a flow where “start hacking on X” makes Claude create a target folder, pull the HackerOne policy page, and write it into that folder’s CLAUDE.md, so every later launch from there auto-loads target-specific context.

On persistence, the anticlimactic best practice: literally tell it “I’m going to bed, don’t ask me any questions, don’t stop hacking, keep going deeper,” and it runs 4+ hours. It survives compaction because Claude writes itself a fresh starting prompt when it compacts; still, tell it to keep good notes since it will compact. The critical failure mode is a compaction deadlock: if the context limit is hit immediately on emerging from compaction with no intervening step, it cannot roll back or compact again, and overnight you cannot manually jump back because there is no message to return to. This is triggered by spawning many sub-agents, so the fix is to cap sub-agents at two to three; anything at four or more risks the deadlock, forcing a fresh instance to re-read the stuck session’s context. Working modes described: ~50% Cloud Code CLI in iTerm on the desktop, ~50% a Discord bot that mimics Cloud Code in a thread (used for VPS and automated runs, convenient from a phone in the school pickup line). The other host runs four tmux panes on different targets, rarely uses sub-agents, and interacts constantly, which is why he never hits the compaction deadlock. Security posture noted: --dangerously-skip-permissions on everything, running locally with broad access, but deliberately no email and no 1Password access.

Where AI breaks down in bug bounty

The report-writer recommendation comes with a sharp warning: it is dangerous advice for anyone who has not already written a thousand-plus reports by hand, because they will not catch the failures. AI reports fall apart in specific ways. They blend two or three distinct bugs into one incoherent report. Their threat modeling is still poor: a real example was 30-plus paywall bypasses (access to essentially any pro/enterprise feature) where the agent escalated the narrative to “complete degradation of security” because some unlocked features let you change object settings that made the product less secure, a conclusion that does not hold up. The remedy is to read every report for accuracy (not tone) and correct it; a hunter with strong intuition edits his own rarely, but that is earned.

A couple of practical friction points and pro tips. To point Claude at a specific request, copy the top two lines of the HTTP history entry (host and path) and paste them, rather than trusting the left-hand ID to match anything in the database. The Claude Code desktop app and TUI are still rough (Ctrl+O shows only the most recent command’s output and can lock the machine on large outputs), and remote-control functionality, while improving fast, is not yet perfect. The broader “hurts” theme is laziness: it is easy to hand Claude a brute-force list and let it spin up replay sessions when you could have run it in Caido’s automate yourself in seconds. The subsidized-token economics (“$20 Cloud Max, don’t even think about the tokens”) is called both overpowered and a trap.

Key takeaways

• A skill is usually a skill.md file (optionally plus a tool); its front-matter name/description is auto-injected at launch, so trigger rules go in the description. This is not RAG.
• Build skills for what Claude cannot know or access: custom infra, secret gadgets/primitives, gated enterprise tools with creds, and large solution spaces where you want one specific method.
• Always add an escape-hatch line telling it not to be boxed in by the skill; badly written skills/CLAUDE.md measurably degrade output.
• Use tiered fallback (method A, else B, else C) for hard problems; Caido’s cascade goes binaries to TS client library to GraphQL.
• Hard-code your methodology for determinism, but run a separate free-roaming agent, compare via context (not lossy report-paste), and fold missed techniques back into the skill.
• Highest-value single move: the Caido/Kaito skill hooked into your proxy; other useful ones are session-search, zero-day research, a report-writer, bbscope, and H1 Brain (MCP) for scope/policy/disclosed reports.
• Organize output as a funnel: notes, leads, gadgets/primitives, findings, reports, with a validator as an unbiased sub-agent calibrated against false positives (CORS, blind XSS).
• Folder-based .claude loading (with target-specific folders) is a clean alternative to dedicated agents.
• For overnight runs, tell it not to ask questions and cap sub-agents at two to three to avoid post-compaction deadlock.
• Read AI-written reports for accuracy: they blend bugs and over-claim impact; do not delegate reporting until you can catch the failures.

Sources

• Watch/listen: youtube.com/watch?v=qTX9u-EsjmM
• Full transcript: claude-skills-for-bug-bounty
• Related: bug-bounty-roadmap-with-ai, ai-recon-500-bug