AI has become integral to many bug hunters’ workflows. You can use it to speed up recon, make sense of an unfamiliar codebase, spot suspicious patterns and dig into a target faster than you could alone.
And once you actually find something, the same assistant is right there to help you write it up – but that’s where it can quietly turn against you.
Left to itself, it can inflate the impact, invent details or pad reports with boilerplate.
The problem isn't using AI per se. It’s that a large language model (LLM), left unsupervised, tends to fill technical gaps with plausible-sounding slop – wasting triagers’ time, slowing down remediation and risking the hunter’s credibility.
A triager wants findings they can reproduce. Hand them unsubstantiated claims instead of verifiable evidence and the report will be rejected.
We built a Claude Code plugin to address this problem: the YesWeHack Claude Kit. It doesn’t try to find bugs; it keeps the assistant honest about the ones you already found, so your report goes into the queue as solid evidence and comes back validated instead of rejected. This article explains what the plugin is, why it works the way it does, and how to use it on your own findings.
What the YesWeHack Claude Kit does
The YesWeHack Claude Kit is a single Claude Code plugin that adds two layers to your setup.
The first is an always-on layer of guardrails. From the first prompt of every session, a set of rules keeps the assistant from doing the things that get your reports rejected: inventing facts about a target, writing theoretical impact, padding with boilerplate, or validating a lead you haven't actually proven. These rules apply while you investigate, draft and run your final checks – silently, without you having to invoke anything.
The second is a set of three on-demand skills, loaded only when you need them:
- write shapes a confirmed finding into the report structure YesWeHack expects, section by section, drafting only from the facts you give it
- triage runs a full pre-submission review of your draft and returns a verdict (
READY/NEEDS FIXES/DO NOT SUBMIT) with concrete fixes - gotchas holds per-class knowledge: what your Proof of Concept has to show for each vulnerability class, which reports get auto-closed, and which impact claims will get cut
Why a plugin, not a prompt
You could paste a ‘be a strict triager’ instruction into a chat to get these benefits. The problem is that these rules needs to apply at every step, not just when you remember to ask for it, and it needs to survive across sessions without any effort on your part.
That's what a plugin gives you. Once installed, the rules are enforced from the first message of every session, and the skills are always one command away. There’s nothing to re-paste, nothing to keep in sync, and nothing that quietly stops applying halfway through a long session while you’re deep in a target. The guardrails become part of your environment instead of one more thing you have to remember to maintain.
How the plugin works under the hood
The key implementation detail is how the plugin delivers this ‘always-on’ behaviour, because Claude Code plugins can’t ship a CLAUDE.md that loads automatically. As the plugins reference for Claude puts it, plugins “contribute context through skills, agents, and hooks rather than CLAUDE.md”.
So the always-on rules ship as a bundled SessionStart hook. Every time a session starts, resumes or compacts, the hook prints the rules file into the model's context. That reproduces the ‘loads once per session’ behaviour a workspace CLAUDE.md would give you, except it travels with the plugin and needs no setup on your side. Install the plugin and the rules are ready to go.
The three skills use Claude Code’s skill system directly. Each is a namespaced command (/ywh:write, /ywh:triage, /ywh:gotchas), so they never clash with skills you've written yourself. The model can also invoke them on its own when your phrasing matches – for example asking “is this ready to submit?” nudges it toward triage.
There’s one design choice worth flagging, because it keeps the plugin lightweight. The unverified-output checklist – the long list of LLM tells that can leak into a report – isn’t a separate skill you have to remember to run. It lives as an internal reference file that the triage skill reads automatically during its review. This is progressive disclosure: the checklist stays out of context until triage actually needs it, then it’s pulled in on demand. You get the full check on every triage run without ever invoking it directly.
A single principle is enforced by every rule and skill: draft from your verified facts, never over the gaps. Give the assistant a URL, a payload and a response, and it will help you turn that into clean prose with clear alternatives to choose from – keeping you in control as the author. If a fact is missing, it asks instead of inventing one. That single rule is what separates a drafting aid you can trust from one that quietly fills your report with claims you can’t defend.
Putting it to the test
Rules only matter if they change the assistant’s behaviour, so we put the plugin through a testbench of flawed drafts, each paired with a fictional program scope.
We start with the blunt question you ask before hitting submit: are these ready?
It reads the scope and returns one verdict per draft: the XSS write-up has no real proof behind it (DO NOT SUBMIT), the SSRF proves a DNS lookup but not reach (incomplete), the coupon-race file is still just notes, and the IDOR is the closest to ready. Nothing gets waved through.
So we drill into the IDOR one, where “looks fine to me” and “survives triage” part ways.
The core finding is real, and the toolkit says so. What it won’t let you submit is the headline. The draft claimed a “mass data breach affecting the entire userbase,” but the proof shows a single cross-account read using a random UUIDv4. A non-guessable ID can't be enumerated at scale, so it’s AC:H, not AC:L, and the mass-breach claim isn’t supported. The plugin re-scores the inflated 9.1 down to a defensible Medium severity and points to exactly what proof would justify going higher.
The toolkit doesn't only critique. Hand it raw lab notes on a coupon race condition and it helps you write them up, and this is where the honesty rule earns its place.
It maps your notes onto the report sections and flags what’s missing. The concurrency method and doubled cart total are there; the persisted post-state isn’t. Your notes only show the double discount in the cart response, never confirmed at checkout, so it refuses to draft the Impact section: there is no financial impact to claim until you prove the discount survives to the charged amount.
When it does draft, the guidance stays grounded in your notes, and it draws a hard line on impact: it won't write “attacker could get unlimited discounts” when you only tried two parallel requests. Claim exactly what you landed. A generic assistant writes the impressive sentence because it reads well; this one writes the sentence you can defend.
The knowledge that makes it work: per-class gotchas
The triage and write skills enforce general rigour. The gotchas skill is where class-specific knowledge lives: the stuff that decides whether a report gets accepted or auto-closed. There’s one section per vulnerability class, each with three parts: the minimum proof your Proof of Concept (PoC) must show, the common false positives that get closed on sight and the impact overclaim traps.
A few examples, because these are the kind of reports that get rejected again and again:
- CORS misconfigurations often look like serious findings but then turn out to be non-issues. The gotchas skill spells out the trap:
Access-Control-Allow-Origin: *withoutAccess-Control-Allow-Credentials: trueleaks nothing a browser will send credentials to. Without a reflected origin, credentials, sensitive session data and a PoC page that actually reads a victim’s response, it isn't a finding – no matter how alarming the header looks. - Race conditions need a broken invariant persisted in state, not just several 200 responses arriving quickly. The skill explicitly warns against scaling a burst into a denial-of-service just to ‘prove’ impact.
- IDOR on a non-guessable UUID is scored AC:H, and any mass-exploitation claim needs a demonstrated way to obtain other users’ IDs.
- SSRF that only resolves DNS proves a lookup, not a request. “Cloud metadata access” needs the metadata response body, not speculation about what might be accessible.
- Open redirect chained to OAuth token theft that you can’t actually reproduce without an account is theoretical and non-reproducible – the skill tells you to report only what you can prove.
- Information disclosure: a leaked key is only reportable if it’s valid and you can show what it unlocks. Public, publishable keys designed to ship in the client (Google Maps browser keys, Firebase config, Stripe
pk_keys) aren’t findings on their own.
The gotchas skill currently covers 14 classes, from XSS and SQLi to path traversal/LFI and SSTI, including the client-side template injection trap where {{7*7}} in Angular is XSS, not server-side remote code execution.
Every section tells the assistant to prove the primitive and stop – never to push you into destructive post-exploitation to demonstrate reach. That keeps you safe as well as accurate: it won't nudge you toward dumping a database or running a fork bomb to ‘show impact’, because that breaks program rules and gets you penalised, not paid.
Installing and using the YesWeHack Claude Kit
The plugin ships as its own marketplace (https://github.com/yeswehack/claude-kit). Installation is two commands inside Claude Code:
1/plugin marketplace add yeswehack/claude-kit2/reload-plugins
Run /plugin to confirm it’s enabled. Both layers are now active. By default it installs at user scope, so the rules apply across all your projects; add --scope project if you’d rather keep it to a dedicated hunting workspace.
A typical session looks like this:
- Investigate as usual. The always-on rules keep the assistant from validating leads you haven’t proven. Suspicious behaviour gets “not yet a bug, here’s what would prove it”, not a green light to writing up a non-finding.
- Once you've confirmed a bug, ask “how should I structure this finding?” and
writeshapes it from your notes, flagging anything missing instead of filling the gap for you. - Before you submit, run
/ywh:triagefor a verdict and line-by-line fixes, checked against the program scope you provide.
That's the loop. Nothing about it replaces your judgement; it just makes it much harder to submit something you can’t defend – which will boost your accepted-report rate.
What the YesWeHack Claude Kit is not
The YesWeHack Claude Kit does not find vulnerabilities. It adds no scanner, no exploit-generation capability, nothing that manufactures a finding out of nothing. Everything it does starts from evidence you already have. If you feed it nothing, it produces nothing – by design.
It’s a guardrail, not a guarantee. The rules make common failure patterns much less likely, but a language model can still be wrong, and you remain the author of every sentence. The bar applies to both you and the toolkit: every claim has to hold up to a triager. If a claim can’t, that's a signal to cut the line – not to trust it just because the tool wrote it.
Used this way, the assistant becomes a more disciplined teammate: the kind that tells you your proof is thin before a triager does, instead of papering over gaps in your evidence with confident, unsubstantiated prose.
Try it – then help us improve it
The toolkit closes the distance between AI-written reports and ones triagers can validate without sending them back. Its rules and per-class checks are built to address the reasons AI-assisted reports are typically rejected: overclaimed impact, unproven PoCs, inflated severity and boilerplate. It helps catch those problems before you submit, rather than leaving the triager to catch them afterwards.
The plugin is open source under GPL-3.0, installs in two commands, and is meant to be improved by the hunters who use it. If there’s a false-positive pattern or an overclaim trap costing you reports that gotchas doesn’t cover yet, that's exactly the kind of contribution that makes it sharper for everyone. The whole point is to turn the feedback you’d normally get after a rejection into feedback you get before you submit.
