Transilience community tools: a Claude Code skill suite for authorized security testing

The deliverable is markdown, not a tool

The repository is described as open source Claude Code skills and agents for AI powered penetration testing, bug bounty hunting, AI threat testing and security reconnaissance, and the overview gives the count precisely, 26 skills and 3 tool integrations covering the penetration testing lifecycle from reconnaissance to reporting. What makes it unusual is what the skills actually are. They are structured markdown files that describe a method to an agent, and the Python tools are small helpers, env-reader.py, nvd-lookup.py and slack-send.py. There is no scanner in this repository and nothing you point at a target. The premise is that the reasoning about how to test a class of vulnerability is the reusable asset, so it is written down once and applied to many targets. The README frames the suite as consolidated and MIT licensed for commercial and personal use, with an announcement about a paper describing the method behind it, and a companion site at transilience.ai.

A benchmark score and a loop that writes its own curriculum

The announcement section is the most interesting part of the README, and it describes a result rather than a feature. The authors built an autonomous pentesting agent that scores 100 percent, 104 out of 104, on a published CTF benchmark suite, using only structured markdown skill files and no fine-tuning. The method was a loop of roughly 15 iterations: run the benchmarks, find a failure, diagnose the missing technique, write it into a skill file, and run again, starting from a bare 89.4 percent baseline. The paper is included in the repository as papers/practice-makes-perfect.pdf, and the README says the repository contains the full skill set described in it. Two transfer numbers are given, with Claude Sonnet 4.6 reaching 96.2 percent and Claude Haiku 4.5 reaching 62.5 percent. That spread is the interesting part for an evaluator, since it says the skill files carry most of the capability but not all of it, and that a smaller model degrades sharply on the same skills. These are the authors' own measurements on a benchmark suite, so treat them as a claim about the method rather than as an independent evaluation, but the mechanism they describe is reproducible in principle, since the loop is nothing more than running a suite, reading the failures and writing down what was missing.

Three agent roles and a dynamic spawn

The architecture is described in a couple of sentences and it tells you how the suite is meant to run. Agent roles, coordinator, executor and validator, are defined in skills/coordination/ with supporting notes in skills/coordination/reference/, and they are spawned dynamically via Agent(prompt=...). The coordinator decides what to do, the executor carries out a piece of work, and the validator checks the result, which is a three-way split that matches how a human penetration test is organised and, more usefully, gives the model separate prompts for separate jobs instead of one long instruction. The separation also gives you a place to intervene, since a coordinator prompt is a decision point you can review. The canonical definitions live at the repository root in skills/ and tools/, and each project under projects/ symlinks only the ones it needs, which is a deliberate way to keep a project surface small and to make the same skill reusable across projects without copying it.

Twenty six skills across five categories

The skills catalogue is the substance, and it is organised by category. The vulnerability testing group has ten skills, /injection covering SQL, NoSQL, OS command, template and XML entity and LDAP or XPath injection, /client-side covering cross site scripting in its reflected, stored and DOM forms along with CSRF, clickjacking, CORS and prototype pollution, /server-side covering SSRF, HTTP smuggling, path traversal, file upload, deserialization and host header issues, /authentication covering auth bypass, JWT, OAuth, password attacks, two factor weaknesses and automated verification abuse, /api-security for GraphQL, REST, WebSockets and web LLM surfaces, /web-app-logic for business logic, race conditions, access control, cache poisoning and IDOR, /cloud-containers for AWS, Azure, GCP, Docker and Kubernetes, /system for Active Directory, privilege escalation on Linux and Windows and exploit development, /infrastructure for port scanning, DNS, man in the middle, VLAN hopping, IPv6, SMB and NetBIOS, and /social-engineering for phishing, pretexting, vishing and physical security. Three reconnaissance skills cover subdomain and endpoint discovery, OSINT with repository enumeration and secret scanning, and passive tech stack inference across 17 intelligence domains. Five specialised skills cover OWASP LLM top 10 risks, smart contract security, CVE research with proof of concept generation, DFIR with PCAP analysis and AD attack detection, and static analysis with CWE top 25 and dependency CVEs. Two platform integrations cover HackerOne and HackTheBox workflows.

The Kali container and how the tool set is installed

There are two setup paths and the Docker one is the recommended. The script builds a Docker image with Kali Rolling, Node.js, Claude Code, Playwright and Chromium, mounts the project workspace and launches Claude Code with skipped permission checks, and it is invoked with a project path argument.

bash scripts/kali-claude-setup.sh projects/pentest

A --rebuild flag forces a fresh image build, which matters when you change the skill files and want to be sure the image reflects them. The local path is the alternative, and it needs Claude Code, Playwright for client side testing and browser based evidence capture, Python 3 for the three tools, and optionally the Kali command line tools such as nmap, gobuster, ffuf, sqlmap and testssl if you want network and infrastructure testing. Playwright is installed as a global package with its own browser download, and the README says the browser automation is used for HackTheBox and HackerOne automation as well as for client side evidence capture.

The local workflow is a clone and a directory change, then launching the agent from inside the project directory so it picks up the symlinked skills.

git clone https://github.com/transilienceai/communitytools.git
cd communitytools/projects/pentest

Inside the session you drive it with slash commands.

Pentest https://target.com            # Full penetration test (skills/coordination/)
/hackthebox                          # HackTheBox challenge automation
/hackerone                           # Bug bounty workflow
/techstack-identification            # Passive tech stack recon
/reconnaissance target.com           # Attack surface mapping
/source-code-scanning ./app          # Static code analysis

Reporting, references and the model gateway configuration

The reporting and reference machinery is what separates a method from a checklist. The feature list promises complete OWASP top 10 and OWASP LLM top 10 coverage, professional reporting with CVSS 4.0 as the primary scoring version and v3.1, v3.0 and v2.0 as fallbacks, CWE identifiers, MITRE ATT&CK mapping and branded PDF reports, and 160 or more reference files with inline techniques from PayloadsAllTheThings. The scoring version fallback matters in practice, since a bug bounty programme may require a specific CVSS version, and having a primary and a fallback in the report generator avoids rewriting the finding for each programme. The reference files are the payload and technique corpus that the skills point at, which is why the repository is useful even if you run your own agent. The top level of the tree also shows a litellm_config.yaml, an mcp/ directory, a formats/ directory, a benchmarks/ directory, a papers/ directory and a .claude-plugin/ directory, which indicates the suite is packaged as a Claude Code plugin as well as a project. The .env.example file is worth reading because it shows the credential model, with a bridge token, a LiteLLM master key and an optional HuggingFace token for model downloads, plus a Modal bridge endpoint in a specific URL format, and the comment explains that the anonymous model pulls are heavily rate limited, which is the kind of detail that saves an afternoon when a model download stalls.

Where this suite is the wrong tool

Three limits are worth naming. The first is that the deliverable is a method, so it does nothing for you unless you are comfortable supervising an agent that is making security decisions. If your requirement is a scanner with a command line interface, a report you can hand to a client, or something that runs unattended across a range, this repository is the wrong shape and you want software. The second is the permission model, which the README states plainly when it describes the container launching Claude Code with skipped permission checks. That is a reasonable choice inside a disposable container for a target you own, and an unreasonable one anywhere else, and the same applies to the idea of pointing an autonomous agent at a bug bounty programme's scope, where the platform's rules about automated testing and disclosure timing are the actual constraint. The third is the maintenance picture, and it is genuinely mixed. The repository is not archived, the last push was on 2026-07-29, there are no GitHub releases, and the announcement paper is dated March 2026, so the project has real depth but a release history you cannot pin to. For a security tool, the honest reading is that you should read the skills before you run them, and you should treat the 104 out of 104 result as a description of one team's method on one benchmark rather than a claim about what the suite will do on your target.

Editorial conclusion

Adopt this skill suite if you already use Claude Code and want a repeatable, documented method for authorized penetration testing and bug bounty triage instead of an ad hoc prompt, and you are comfortable supplying your own API access and running an agent with skipped permission checks. Skip it if you need a scanning tool you point at a target, since the deliverable here is methodology rather than software, and skip it if you work in an environment where an agent running with skipped permissions inside a Kali container is not acceptable. Verify first that you have written authorisation for every target you point it at, that the model provider and Playwright are configured as the setup expects, and which of the bundled skills and reference files you actually want in scope.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. transilienceai/communitytools on GitHub