VulnHunter is mostly prompt files, and its batch mode has one scope control

Two of the three skills are prompt files, and the third files issues

The repository layout is worth reading as a statement about what the tool is. The `vulnhunt/` scanner skill is prompt-only, a `SKILL.md` plus its phases, with no code. The `vulnhunt-fix-verify/` verifier is also prompt-only. The `vulnhunter-fix/` remediation skill is the one that ships code, a companion Python helper package with tests. Then there are two runtimes rather than skills: `vulnhunter-agent/`, described as a config-driven headless runtime wrapper that runs scans and files GitHub issues, and `harness/`, developer tooling for large batch scans and benchmarking detection accuracy. So the analysis itself is a prompt, the orchestration is a Python wrapper, and the one component that writes to a system outside your repository is the unattended one.

The batch mode's scope control is a sentence you tell yourself

This is where the tool widens its own reach, and it is worth being explicit about. The page notes that for running the loop unattended at scale, the headless runtime wraps the scanner while the harness drives it across multiple repositories in batch. Against that, the only scope control named anywhere on the page is a bullet in the prerequisites telling you to ensure you are only scanning code bases you are explicitly authorized to analyze. There is no dry-run, no allowlist of repositories, no rate limit and no kill switch described, in a component whose documented behaviour includes filing GitHub issues. Nothing here says the tool decides its own targets, and the intent is clearly local analysis, but the enforcement is prose. If you enable the unattended path, the repository list is the thing you are choosing, and it is worth choosing deliberately.

Your model account can be the thing that gets flagged

The page carries a cyber-safeguard disclaimer that is more specific than most project warnings. VulnHunter performs dual-use cybersecurity work, described as vulnerability discovery and exploitation. If you run it against an Anthropic account that is not enrolled in the vendor's Cyber Verification Program, real-time cyber safeguards may block requests, and your usage may be flagged for cyber abuse. If you intend to use it on the vendor's first-party platforms, the page strongly recommends enrolling through the verification portal first. That is an operational cost nobody mentions in a comparison: the analysis runs inside someone else's inference, and that inference layer has its own view of what dual-use work is acceptable. Read it before the first unattended run, not after a request is blocked.

The scanner starts at entry points and reasons forward

The methodological claim is a direction change. Conventional tools, the page argues, rely on sink-first analysis: they look at potentially dangerous code patterns and search backward for a hypothetical attacker, which floods teams with false positives. VulnHunter inverts that and simulates a bad actor's exact journey. It begins at entry points an attacker can actually reach, and the three named are APIs, network messages and file uploads, then reasons forward to evaluate whether an attacker can truly break through. The framing of the claim is about provability rather than pattern density, and the tagline on the page says as much, moving from pattern-matching to provability. The honest reading is that this is a prompt-level change in what the model is asked to do, and the accuracy of it is whatever the model does with the instruction.

A finding has to survive a step whose only job is to refute it

After a candidate vulnerability is found, the falsification engine runs a structured workflow designed to disprove its own argument: it searches for flawed assumptions, logic gaps, or security controls that would block the attack, and is intended to discard findings resting on unsupported assumptions immediately. The hunt skill describes its pipeline in four stages, Recon, Parallel Hunt, Adversarial Disprove, and Capability Filter, and emits only verified issues with an executable exploit and a proposed fix. The fix side is developer-led and test-driven: write an exploit demo, create a failing security test, implement the fix, verify the exploit is blocked without regressions, and cut a reviewable pull request. The third skill is a completely separate read-only agent that independently validates the remediation and emits a per-finding verdict.

The skills are copies, so you re-run the installer after every pull

Installation is a clone and a script, and the script's behaviour is explained rather than assumed:

git clone https://github.com/capitalone/vulnhunter.git
cd vulnhunter

# Copy skills into ~/.claude/skills/
./install.sh

# (Optional) To clean up or remove installed skills
# ./uninstall.sh

The note under it says the scripts copy files directly rather than symlinking, because symlinks can break `find` and `glob` functionality inside subagents, and that you must re-run the install script after pulling updates to refresh your local environment. So the skills directory in your home is a snapshot, not a view of the repository, and a `git pull` alone changes nothing until you run it again. On Windows the same steps exist as `.cmd` equivalents writing to `%USERPROFILE%\.claude\skills\`.

Two commands use the short name and one uses the full one, on purpose

The page pre-empts the obvious misreading. The suite is VulnHunter, but the core scanner command is `/vulnhunt` and the verifier is `/vulnhunt-fix-verify`, and the shorter form is intentional rather than a typo, while the remediation skill and the runtime keep the full spelling. The dependencies differ per component, which is also worth knowing. The skills need the Claude Code CLI authenticated to Opus, and the page is explicit that you supply your own model access. Python 3.12 or higher is required only for the runtime agent and the benchmarking harness. The fixer additionally needs `git`, the GitHub CLI authenticated to your target repositories, and its own helpers installed with an editable install from inside its directory. On the timeline there is a single release, v0.1.0 labelled Initial Launch on 2026-07-18, with the last push on 2026-08-15.

Editorial conclusion

VulnHunter suits a team with Claude Code and Opus access that wants an attacker-first pass over source it owns and a verifier that has to earn the fix, rather than another list of pattern matches. It does not suit you if you need the scanner to run cheaply on a smaller model, since the page states the framework requires frontier Opus-class models and you supply the access, or if you want an unattended batch job with a technical scope limit, because the only scope control named anywhere is a responsibility check you perform yourself. Before you point the headless runtime at anything, enrol in the vendor's cyber verification programme if your model access sits behind a real-time safeguard, and decide explicitly which repositories it may touch, because its documented job includes filing GitHub issues.

Frequently asked questions

Official sources

1. capitalone/VulnHunter on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases