What Is reverse-skill? A Security Skill Router

reverse-skill is an open-source routing package that tells an AI coding agent which security methodology and which tools to use when it is handed an APK, a binary, obfuscated frontend JavaScript, a CTF challenge, or an authorized penetration testing target. It doesn't add new capability so much as new discipline: instead of the agent guessing whether to reach for jadx, Frida, IDA or Burp Suite, the package routes the task to a documented workflow and checks which tools are actually installed on the machine.

It crossed 14,900 GitHub stars on August 3, 2026, having sat at 9,090 stars five days earlier. That surge is what put it in front of most people, and it's worth being precise about, because the number circulating in secondhand coverage is wrong.

Key Takeaways:

• reverse-skill is a router, not a toolkit. It ships methodology, routing rules and tool detection, and calls existing tools like jadx, Frida, radare2 and Ghidra rather than replacing them.
• It didn't get 10,000 stars in a day. It was created May 13, 2026 and took roughly eleven weeks to cross 10,000, then added roughly 5,800 in the last five days.
• It isn't an isolated event. A 6,631-star Android reverse-engineering skill has existed since February 2026, three months before this project started.
• Its own rules file enforces a hard authorization gate: no action against a target until authorization status is granted.
• The same rules file also contains explicit techniques for suppressing the agent's independent judgment, including a document named agent-obedience-engineering.md. That tension is the most interesting thing about the project.

What is reverse-skill?

The project describes itself as a "Cybersecurity Skills Router." The problem it targets is one that anyone who has pointed a coding agent at a binary will recognize.

The README states it plainly. AI agents don't know whether to use jadx, apktool, Frida, IDA or Burp Suite for a given task. APK, ELF, JavaScript, packet capture and CTF tasks each need different playbooks. Tools, MCP servers and helper scripts are scattered across machines and installed inconsistently. And because nothing is written down between sessions, the same mistakes get repeated.

So reverse-skill sits in front of the agent as a decision layer. A task arrives, global rules classify it, a routing table maps it to a scenario workflow, the package checks a generated index of which tools this machine actually has, and the agent then follows a documented procedure that ends in a structured report rather than a transcript.

It's MIT licensed at the top level, written largely in PowerShell with Python, Node and shell components, and requires a JDK, Node 22.12 or newer, Python 3, and a code AI client such as Claude Code, Codex CLI or Cursor. Two dependencies carry different terms worth knowing before any commercial use: the bundled CTF orchestrator is GPLv3, and Pentest Swarm AI is AGPL-3.0 and is invoked rather than vendored.

Why reverse-skill is trending now

The claim going around is that this project earned 10,000 stars in a single day. Archived snapshots of the repository page show that isn't what happened, and the real curve is more interesting anyway.

Read across, the project took about eleven weeks to reach 10,000 stars, not one day. What actually happened is a three-phase pattern: a first surge in late June that roughly tripled it in eleven days, a four-week plateau adding around 70 stars a day, and then a second acceleration starting around July 29 running at roughly 1,070 a day.

The current wave is real and it's happening now; it's simply not the origin story, and the distinction matters if you're trying to read what the ecosystem is telling you. A repository that explodes on day one is a marketing event; a repository that plateaus for a month and then re-accelerates is usually responding to something that changed around it.

What is actually in the package

At the top sits a global rules file and a master routing ladder. Below that are roughly twenty scenario areas: Android and iOS application analysis, binary reverse engineering, .NET, obfuscated frontend JavaScript, custom virtual machine deobfuscation, traffic capture and replay, malware and YARA analysis, penetration testing, attack chain orchestration, firmware and IoT, patch diffing, exploit development, EDR evasion research, API and GraphQL security, supply chain and SBOM analysis, LLM and AI security, and a CTF orchestrator that the README says carries more than forty sub-skills.

Three design choices are worth reporting on because they're unusual, and because they say more about where agent tooling is heading than the tool list does.

A generated tool index. The package scans the machine and writes a file recording which tools exist and where. The rules then forbid the agent from guessing a tool path, on the grounds that installation locations differ between machines. This is a small thing that quietly fixes a large share of the failures people hit when agents run real toolchains.

An evidence chain instead of a chat log. Findings are supposed to move through a defined structure, evidence to finding to path, with a timeline and work items alongside. The output is a report, not a conversation. That's closer to how professional security work is actually documented than to how agents usually behave.

A written record between sessions. A field journal directory is meant to accumulate what worked and what didn't, so the next run doesn't repeat the same dead ends. This is the same instinct behind the memory and skills layers appearing in agent harnesses generally, applied to a single domain.

There's also a README written specifically for AI agents rather than humans, with an instruction at the top of the main README telling any agent that reads it to go there and follow it strictly. Repositories that address the reader as a machine are still rare enough to notice.

The bigger picture: security skills are coming to AI agents

The easy reading of reverse-skill is that one project got popular. The data doesn't support treating it as a one-off.

The largest project in this category isn't reverse-skill at all. SimoneAvogadro/android-reverse-engineering-skill has 6,631 stars and was created February 2, 2026, more than three months before reverse-skill existed. Alongside it sit incogbyte's Android skill from March and its iOS counterpart from later that month, both small but steadily maintained. On the defensive side, hackersifu/reverse-engineering-skills packages malware analysis workflows for multiple AI clients.

So the pattern is at least six months old and moving in two directions at once. Offensive and analysis-oriented skills are consolidating into routers like reverse-skill, and defensive skills are being packaged the same way. What changed in 2026 isn't that people started pointing AI at binaries; it's that the packaging format stabilized, and a skill became a thing you could publish, install and star.

That has a straightforward consequence. Security methodology used to live in practitioners' heads and in training courses; it's now shipping as installable files with version numbers, which lowers the floor for competent work and lowers the floor for incompetent work by exactly the same amount.

The legal and ethical line: authorized use only

Everything in this category lives or dies on one distinction: whether you have permission to analyze the target.

The clearest statement of the line comes from the sibling Android project, whose disclaimer is the most legally specific in the group. It restricts use to lawful purposes including security research, authorized penetration testing, and "interoperability analysis permitted under applicable law (e.g., EU Directive 2009/24/EC, US DMCA §1201(f))," then states that "unauthorized reverse engineering of software you do not own or do not have permission to analyze may violate intellectual property laws and computer fraud statutes in your jurisdiction."

That's the correct framing, and it's worth internalizing rather than skimming. Interoperability analysis of software you own has a specific, narrow legal carve-out in both US and EU law. Analyzing someone else's production system without written authorization doesn't, and no tooling changes that.

reverse-skill encodes the same principle procedurally rather than as a disclaimer. Its rules file makes authorization step zero of the behavior chain, ahead of everything else including the safety review, and requires that a case be initialized with an explicit scope contract. The instruction is unambiguous: the agent must not act against targets until authorization status is granted and a network profile is set. Its security boundary section requires that penetration testing confirm legal authorization through a bug bounty program, a security response center, the user's own system, or a CTF, forbids expanding the attack surface beyond the specified target range, and requires stopping to inform the user when a high-severity finding appears.

Two honest observations. Procedurally, that's a stronger control than a paragraph of legal text at the bottom of a README, because it sits in the execution path. But reverse-skill's own README carries no disclaimer section at all, and the authorization gate is self-enforced by the same agent doing the work. A gate the model can route around is a convention, not a control.

The part worth arguing about: obedience engineering

Reading the rules file in full turns up something that deserves more attention than the star count.

The same document that enforces the authorization gate is also built to override the agent's reluctance. It opens by telling the model that replying "understood" without taking action means it has failed. It includes a rebuttal table pairing common model hesitations with scripted responses: against "based on my judgment, this isn't necessary," the answer is "your judgment does not apply here." It documents where to place instructions based on how LLM attention decays across a context window, putting mandatory actions in the first and last ten percent. The file the agent is told to consult when it wants to skip a step is named agent-obedience-engineering.md.

The sharpest example is a section on parameter stability. It recommends passing certain parameters as opaque code words rather than readable values, explicitly to reduce the model's tendency to "semantically optimize" them. The stated scope includes dangerous action switches, approval status values and scan scope boundaries, and the worked example maps alpha to --scope authorized-only, beta to --approval required, and gamma to --destructive false.

The engineering rationale is legitimate and I want to state it fairly: models do rewrite strict flags into lenient synonyms, and a scope boundary that silently loosens itself mid-run is a genuine failure mode. Encoding it opaquely does prevent that drift.

The side effect is that the agent can no longer reason about the safety-relevant parameter it is passing, because it can't read it. Applied to approval status and scope boundaries specifically, that removes the model's ability to notice that something has gone wrong. Combine it with a rules file whose stated goal is to defeat hesitation, and you have a package that hardens its guardrails against the model and hardens the model against its own caution, in the same document.

This isn't an accusation of bad intent; it's the actual state of the art in getting agents to follow long procedures reliably, and every serious agent harness is solving some version of it. It's just a much more consequential trade-off in a package that routes penetration testing than in one that formats code, and nobody writing about this project has mentioned it.

What this means for the agent ecosystem

Three things follow, and they point at the same place.

Reliability is now the security story. The interesting risk in an agent doing security work isn't that it becomes capable; it's that it acts confidently on a wrong route, against the wrong target, and writes a convincing report about it. Routing packages exist because that failure mode is common.

Guardrails and obedience are being built by the same hands. Whoever writes the instruction file decides both what the agent must not do and how hard it should push past its own doubts. Those two goals are in tension and are currently unregulated by anything except the author's judgment.

Watching the agent is becoming a separate layer. This is why vendor-side work like Perplexity's Numbat matters in the same conversation. reverse-skill represents the community side, methodology packaged as installable skills. Numbat represents the vendor side, monitoring what the agent actually did at the endpoint, independent of what its instructions told it. Neither substitutes for the other. A self-enforced authorization gate and an external observer fail in different directions, which is precisely why serious deployments will end up wanting both.

The same logic applies one level down, to where the agent runs at all. A package that installs toolchains and writes into a client's global config is asking for a lot of trust in a laptop that also holds your production credentials. Running that kind of work somewhere disposable is the cheaper instinct, which is the lane hosted agents are built for, where the sandbox is the default rather than something you remember to configure.

What reverse-skill does not settle

The package is young and several things about it remain open.

There's no independent evaluation of routing quality. Every claim about the package choosing the right methodology comes from the package. Nobody has published a benchmark comparing an agent with this router against an agent without it, which means the core value proposition is currently untested in public.

Governance is unresolved. A skill router that installs toolchains, writes into a client's global configuration, and accumulates a knowledge base across sessions is a substantial amount of standing capability on a machine, and it's maintained by one author with a QQ group and a Discord.

And the authorization model assumes good faith. Every control described above protects a well-intentioned operator from an over-eager agent. None of them protect anyone from an operator who simply answers the authorization prompt untruthfully. That isn't a flaw specific to this project. It's the honest boundary of what tooling can do, and it's why the legal line, not the technical one, remains the one that counts.

FAQ

What is reverse-skill in one sentence?

An open-source routing package that directs an AI coding agent to the right security methodology and tools for a given task, covering reverse engineering, authorized penetration testing and CTF work, and producing a structured report rather than a chat transcript.

Did reverse-skill really get 10,000 stars in one day?

No. It was created on May 13, 2026 and crossed 10,000 stars around July 31, roughly eleven weeks later. Archived snapshots show a first surge in late June, a four-week plateau, then a sharp second acceleration that added roughly 5,800 stars in the five days to August 3, 2026. The current growth is real; the one-day framing is not.

Is it legal to use?

Using the software is legal. What you point it at determines everything else. Security research, authorized penetration testing under a written scope, bug bounty programs, your own systems and CTF challenges are the intended uses, and interoperability analysis has a narrow carve-out under US DMCA §1201(f) and EU Directive 2009/24/EC. Analyzing software or systems you neither own nor have permission to test can violate intellectual property and computer fraud law regardless of what tool you used.

Does it work with Claude Code and Cursor?

It targets code AI clients generally, naming Claude Code, Codex CLI, Cursor and Kiro among others, and needs a JDK, Node 22.12 or newer and Python 3 for the underlying toolchains. Support depth varies by client, and the package writes into the client's global configuration on first use, which is worth knowing before installing it on a work machine.

Is this the first security skill package for AI agents?

No, and that's the more useful takeaway. A 6,631-star Android reverse-engineering skill predates it by three months, and separate iOS and defensive malware-analysis skills have been maintained since early 2026. reverse-skill is the largest consolidation of the pattern so far, not the origin of it.

Last updated: August 3, 2026. Star counts, creation dates, licenses and dependency terms verified against the GitHub API and the projects' own repositories on that date. Historical star figures come from archived snapshots of the repository page, linked inline. Quotations describing routing behavior and authorization gates are drawn from the project's published rules file. This article reports on the project and its context; it's not a usage guide, and nothing here should be read as encouragement to analyze software or systems you do not own or have written permission to test.