Scoped Security Workflows with src-hunter-skill in Claude Code

A security Skill can go wrong faster than a normal coding Skill. If the agent starts with payloads instead of scope, it can drift from authorized testing into noise, risky traffic, or a report that cannot be defended.

That is why src-hunter-skill is a useful seed to rescue. The repository is not just a pile of bug bounty tricks. It gives Claude Code a five-phase path, makes playbook reads mandatory, and carries compliance rules that should stop the workflow before a finding is overstated.

The five phases are the product

The README describes a fixed path: intake, recon, enum, hunt, and report. That structure is the reason this article should exist. A free-form prompt can ask for bug bounty ideas, but it rarely preserves state well enough to prove scope, passive recon, active enum, test evidence, and report quality in order. src-hunter turns the workflow itself into the artifact. The article angle is not 'Claude finds bugs.' The useful claim is narrower: Claude Code gets a checklist that can stop itself when scope, source files, or evidence are missing.

Scope comes before every payload

SKILL.md makes Phase 1 a hard checkpoint. Before recon, the operator must list in-scope assets, out-of-scope exclusions, program rules such as safe harbor or required test headers, and the timebox. If any item is missing, the Skill is supposed to ask instead of guessing. That is the right boundary for Claude Code. A security workflow that cannot name what is allowed should not run active tests. The strongest adoption pattern is to paste the program scope first, ask src-hunter to restate it, and only then allow passive recon.

Install it like a Skill, not like a scanner

The repository gives two install paths: /plugin marketplace add MyuriKanao/src-hunter-skill followed by /plugin install src-hunter@src-hunter, or git clone https://github.com/MyuriKanao/src-hunter-skill.git ~/.claude/skills/src-hunter. The invocation examples are /src-hunter:src-hunter <target> for the Marketplace plugin and /src-hunter <target> for a plain git Skill. Treat those commands as a workflow loader, not a vulnerability scanner. The Skill still needs program authorization, test accounts, headers, and human review before any target-specific action.

Run the first session as a setup test

A safe first session should prove that the Skill asks for the right inputs before it does anything interesting. Step 1: install with the Marketplace commands from the README or clone into ~/.claude/skills/src-hunter. Step 2: invoke /src-hunter <target> with a deliberately incomplete note. Step 3: verify that Claude asks for the four SKILL.md intake fields: in-scope assets, out-of-scope exclusions, program rules, and timebox. Step 4: add the missing fields and stop after the intake checkpoint. Step 5: only then allow passive recon. This setup test is more important than checking whether the Skill can produce a long list of test ideas.

The playbook rule is an anti-hallucination control

SKILL.md says not to invent payloads from memory. Before suggesting SQLi, RCE, SSRF, XSS, or similar tests, Claude must read the relevant references/playbooks/ file. That is the key quality feature. The README gives the headline numbers: 19 attack-class playbooks, 305 structured payloads, WAF and EDR bypass variants, disclosed HackerOne High and Critical report data, and WooYun statistical residue. But numbers alone do not make the Skill safe. The safety comes from forcing the agent to cite the file path it read and to carry the playbook's 'what not to do' section into the next step.

MCP tools need a second gate

references/tools/mcp-jshook.md is powerful enough to deserve caution. It maps hunt-stage needs to browser automation, CDP debugging, network interception, JS hooks, AST deobfuscation, Frida checks, WASM analysis, source-map reconstruction, Android adb, and SSL-pinning workflows. It also says tool names should use mcp__jshook__<tool> and that the default search profile is the normal path. Keep it that way. The map warns that a full profile can cost 40K+ tokens; more important, broad tool activation can make Claude more capable than the current authorization needs. Search, activate the top few tools, run the one evidence step, then turn back to the report.

The red lines are publication-grade material

references/compliance.md is what turns this from a payload article into a usable security article. It says to withdraw or retest if the target is out of scope, if PII was captured, if traffic went past a tiny proof, if someone else's data was modified, or if the claim lacks HTTP packet, screenshot, or video evidence. It also requires test headers when the program asks for them, self-owned accounts for IDOR, private OOB infrastructure for SSRF or XXE, and CVSS 4.0 review before severity claims. Those rules should be in the article because they are the difference between an authorized workflow and a risky agent run.

The real failure mode is authority drift

The dangerous failure is not that Claude suggests a weak payload. It is that the conversation slowly treats a target as more authorized than it is. A user starts with a public URL, Claude finds adjacent assets, an MCP tool makes testing easier, and suddenly the session is acting outside the original program. src-hunter's best design choice is that it gives the operator several places to stop that drift: Phase 1 scope, passive-only Phase 2, playbook reads before Phase 4, and references/compliance.md before Phase 5. That is an editorial reason to preserve the topic. It is a case study in how Skills should narrow an agent, not just make it faster.

Where this Skill does not belong

Do not use src-hunter for a random public site, a CTF, or a white-box code audit. The Skill file itself says CTF should stay in general conversation and white-box source audit should use a different code-audit path. It is also a poor fit when the operator cannot provide scope or when the only goal is to generate payload ideas. The tool is strongest when the target is an authorized bug bounty program and the user wants Claude Code to maintain the process: scope, passive recon, active enum, playbook read, evidence capture, and report review.

How it compares to a normal checklist

A normal checklist is easier to review because it cannot act. A Claude Code Skill can carry state and call tools, so it needs stronger stops. src-hunter is worth using only when that extra agency is useful: the operator wants Claude to remember the current phase, point to the next reference file, and refuse to report without evidence. If a team already has a mature bug bounty runbook, src-hunter should be a translation layer into Claude Code, not a replacement for the runbook. If the team has no runbook, start by copying the intake and compliance gates, not by enabling MCP tools.

A practical first run

For a first run, do not give the Skill a production target and a broad instruction. Create a small authorized test note with four fields: in-scope assets, out-of-scope assets, program rules, and timebox. Install the Skill, invoke /src-hunter <target>, and stop after Phase 1. Check whether Claude asks for missing scope instead of assuming it. Then allow Phase 2 passive recon. Only after that should a single playbook be read for one candidate surface. If a finding appears, open references/compliance.md before writing the report and remove any claim that lacks direct evidence.

Save src-hunter-skill as a scoped Claude Code security workflow. Do not publish it as a payload library or shortcut to bug bounty results.

Practical takeaway

Install with /plugin marketplace add MyuriKanao/src-hunter-skill and /plugin install src-hunter@src-hunter, or clone it into ~/.claude/skills/src-hunter. Run /src-hunter <target> first with a scoped authorization note, confirm Claude asks for in-scope assets, out-of-scope exclusions, rules, and timebox, then stop. Require the matching playbook file before any test idea, keep MCP tools in search mode unless repeated use is justified, and compare every candidate finding with references/compliance.md before reporting.