security-bounty-hunter
by affaan-msecurity-bounty-hunter helps you find bounty-worthy vulnerabilities in repositories, with a focus on remotely reachable, user-controlled issues that are likely to survive triage. Use it for Security Audit work when you want practical reportable findings instead of noisy local-only concerns.
This skill scores 68/100, which means it is listable and likely useful for agents doing bounty-oriented security triage, but users should expect moderate workflow gaps. The repository clearly narrows the task to remotely reachable, bounty-worthy issues and gives concrete vulnerability patterns, yet it lacks supporting files and a full end-to-end operational scaffold that would make installation decisions easier.
- Strong task focus on bounty-relevant, remotely reachable vulnerabilities instead of broad theoretical review.
- Concrete in-scope patterns with CWE mappings and typical impact help an agent target useful findings quickly.
- Clear 'When to Use' guidance makes the trigger more actionable for disclosure and bounty workflows.
- No scripts, references, resources, or install command, so operational support and reproducibility are limited.
- The truncated 'Skip These' section and lack of auxiliary files leave some edge-case handling and execution details unclear.
Overview of security-bounty-hunter skill
security-bounty-hunter is a focused skill for finding bounty-worthy vulnerabilities in real repositories, with an emphasis on issues that are remotely reachable, user-controlled, and likely to survive triage. It is best for people doing Security Audit work who need more than a generic “look for bugs” prompt and want a workflow that favors reportable findings over noisy, local-only concerns.
What it is built to find
The security-bounty-hunter skill prioritizes exploitable paths such as SSRF, auth bypass, SQL injection, command injection, path traversal, remote deserialization, upload-to-RCE chains, and auto-triggered XSS. That makes it useful when the real question is whether a finding can support a responsible disclosure or bounty submission.
Who should use it
Use this security-bounty-hunter skill if you are reviewing an app, package, or API and need fast triage on whether there is a plausible security report. It is especially useful for researchers, red teamers, bug bounty hunters, and engineers checking whether a codebase has high-impact exposure.
What makes it different
The main value is judgment: it pushes the model to ignore patterns that are technically unsafe but unlikely to matter in an actual submission. That keeps attention on reachable attack paths, exploitability, and impact, which is what usually blocks a bounty from being accepted.
How to Use security-bounty-hunter skill
Install and activate it
Use the security-bounty-hunter install command in your skill manager, then point it at the repository you want assessed. The key is to frame the task as a security audit with a bounty lens, not as a broad code review.
Give it the right input
Start with a concrete target, scope, and goal. Strong prompts look like: “Audit this Node API for remotely reachable bugs that could qualify for a bounty; prioritize auth bypass, injection, file access, and SSRF; ignore style issues and low-impact local-only findings.” That input helps the skill make the same tradeoffs a bounty reviewer would make.
Read the right files first
Begin with SKILL.md, then inspect README.md, AGENTS.md, metadata.json, and any rules/, resources/, references/, or scripts/ folders if they exist. For this repository, the key source is SKILL.md; there are no extra support folders, so most of the useful guidance comes from the skill body itself.
Use a workflow that narrows quickly
A good security-bounty-hunter usage flow is: identify the app surface, locate trust boundaries, trace user input into sensitive operations, and then test whether the path is reachable without privileged access. Ask for “bounty-worthiness” explicitly so the output weighs exploitability, exposure, and submission value, not just theoretical weakness.
security-bounty-hunter skill FAQ
Is security-bounty-hunter only for advanced auditors?
No. It is beginner-friendly if you already know the target stack or can describe the repository clearly. The skill does the most work when you give it a specific codebase and ask it to focus on practical exploit paths rather than abstract hardening advice.
How is this different from a normal prompt?
A normal prompt often produces a broad checklist. The security-bounty-hunter skill is narrower: it biases analysis toward findings that are remotely reachable, impactful, and more likely to be accepted in Security Audit or bug bounty contexts.
When should I not use it?
Do not use it when you want general secure coding guidance, compliance review, or a full architecture assessment. It is also a poor fit if you need exhaustive coverage of every minor issue instead of a ranked search for reportable vulnerabilities.
Will it work on any repository?
It works best on web apps, APIs, services, and codebases with clear request handling or data flows. It is less useful on static content, tiny utilities, or repos where there is no realistic attack surface to audit.
How to Improve security-bounty-hunter skill
Give stronger scope and constraints
The best security-bounty-hunter results come from specifying what matters: target language, entry points, auth model, deployment context, and what counts as in scope. For example, “Review only internet-facing endpoints and ignore internal-only admin tooling” produces better prioritization than a vague “find vulnerabilities.”
Ask for report-ready output
If you want a useful Security Audit result, request evidence, exploitability, impact, and why the issue is bounty-worthy. That encourages the skill to explain attack paths instead of just naming CWE labels.
Provide code paths, not just a repo name
If you already know suspicious files, handlers, or routes, include them in the prompt. A prompt like “Inspect src/routes/upload.ts and anything it calls for path traversal or SSRF” is much stronger than asking the model to search blindly.
Iterate on the first pass
Use the first output to prune low-value leads, then ask for deeper validation on the best candidates. The most common failure mode is overbroad scanning; the best fix is to narrow the search to one attack class, one trust boundary, or one endpoint family at a time.