20,390 Stars for a README That Talks to Your Agent Instead of You

The repository that topped GitHub Trending opens with an instruction aimed at your coding agent, not at you. It tells the agent to write new rules into its own global configuration, and to treat any target you mention as pre-authorised. It is not malware. That is precisely why it is the most instructive security story of the year.

Nothing here exploits a vulnerability. The architecture simply permits an unsigned Markdown file to rewrite the rules an agent follows everywhere, and that capability shipped as a convenience feature. Twenty thousand developers looked at it and clicked star.

I have spent six weeks writing about agents breaking out of sandboxes, breaching production systems, and socially engineering open-source maintainers. Every one of those was an accident inside a lab.

This is not an accident, and it is not inside a lab. It is a design pattern, published openly, adopted enthusiastically, and operating exactly as intended. Which makes it far more useful to understand.

What Actually Topped the Charts

On 31 July 2026, an open-source project called reverse-skill reached number one on GitHub Trending. By 7 August the GitHub API counted 20,390 stars, with 2,804 forks and 121 commits on its main branch. It is MIT-licensed and was created in May.

It is a skill router for offensive security work — reverse engineering, authorised penetration testing, capture-the-flag competitions. It takes a task and routes an AI coding agent through scope setup, a scenario playbook, local tooling and a final report. It supports Claude Code, Codex CLI, Cursor and others.

On the substance of what it does, it is a competent piece of engineering. It does not add new capability so much as new discipline: rather than the agent guessing which tool to reach for, the pack routes the task through a documented workflow and checks what is actually installed.

A note on the numbers, since precision matters in a piece about trust. One analysis points out that the viral "ten thousand stars in a day" claim circulating in secondhand coverage is wrong — the repository sat at 9,090 stars and reached 14,900 five days later. A fast climb, not an overnight one. I mention it because the story got exaggerated in transit, and the accurate version is remarkable enough.

The Three Design Choices

What makes this notable is not the routing. It is three decisions in the configuration files.

First, the opening note in the README does not address a human. It directs the coding agent to open a separate file written for agents and follow the instructions strictly. The document is written to be read by software, on behalf of a user who may never read it themselves.

Second, on first use the rules file directs the agent to copy its routing rules into the user's global configuration so they take effect in any project — for Claude Code, the user's global instructions file. The rules then apply well outside the directory where the repository was cloned.

Third, and most consequentially, a file the agent is told to read before any safety review states that mentioning a target means the user is authorised to test it. It instructs the agent not to ask again, not to emit legal-risk notices, and not to refuse standard offensive tooling. The document describes this openly as an inversion of the usual default: authorisation assumed unless the user says otherwise.

There is also a companion playbook that anticipates reasons an agent might hesitate or refuse, supplies rebuttals to each, and replaces suggestive wording with mandatory phrasing — material whose stated purpose is to override the agent's own reluctance.

Someone wrote a document whose function is to argue an AI out of its hesitation, shipped it as part of a productivity tool, and put it at the top of GitHub Trending. The technique has a name in the repository. It is called obedience engineering.

It Is Not Malware, and That Is the Point

I want to be scrupulous here, because it would be easy and wrong to write this as an exposé.

No security vendor has flagged reverse-skill. Its own package audit, dated 18 July, reports no backdoor, no destructive database command and no pipe-to-shell download. The audit also documents genuine hardening work: floating package tags replaced with pinned versions, and SHA-256 verification added for downloads.

Its README repeatedly directs users toward legal authorisation, and its routing chain includes a scope contract that is meant to gate action against a target. The project presents itself as authorised-pentest and CTF tooling, which is a legitimate and necessary category.

GitHub's own policy is explicit that this belongs on the platform. The acceptable-use rules permit dual-use content and support posting material used for research into vulnerabilities, malware or exploits, barring only use in direct support of unlawful attacks causing technical harm.

Security researchers need offensive tooling. Penetration testers need methodologies. A router that helps a professional work faster is not a moral problem, and the author's identity and intentions are not publicly known beyond a GitHub handle.

The concern is the trust model, not a payload. And the trust model is not this project's invention — it is the default condition of the entire agent skill ecosystem.

What an Agent Skill Actually Is

Here is the part most business readers have never had explained, and it is the whole story.

An agent skill is a folder of Markdown instructions that a coding agent reads while it works. Those files can tell the agent which tools to choose, which shell commands to run, and which APIs to call. The agent then acts with the user's own permissions.

Not sandboxed permissions. Not restricted permissions. Yours.

A security practitioner's analysis of the Claude extension ecosystem puts the mechanics precisely: skills run with the user's local process privileges — filesystem, network and shell access — and the field that lists permitted tools grants auto-approval rather than imposing a restriction.

Read that twice if you skim. The field most people assume is a permission boundary is an approval shortcut. It widens rather than narrows.

Researchers at HiddenLayer, who have been documenting this as an emerging supply-chain risk, describe the publishing conditions plainly: skills are not cryptographically signed and are rarely properly vetted, anyone with an account can publish one, and agents will ingest and execute whatever is inside.

So the layer that tells your agent what to do is unsigned text, published by anyone, executed with your privileges, and — as this week's chart-topper demonstrates — capable of writing itself into your agent's permanent configuration.

The Ecosystem Numbers

The following measurements cover the broader agent-skill marketplace rather than any single repository, and I want that distinction stated clearly rather than buried: these are not scans of reverse-skill, and nothing below is an allegation about it.

They describe the environment in which it sits.

• Snyk scanned 3,984 skills in February 2026 and found at least one security flaw in 1,467 of them — 36.82% — with critical-level issues in 534, or 13.4%. Human review confirmed 76 malicious payloads, and 91% of those also used prompt injection.
• Koi Security audited 2,857 listed skills in the same month and identified 341 as malicious. Within roughly two weeks the count had grown to 824 as the registry passed 10,700 skills, with credential-stealing malware hidden behind professional-looking prerequisites.
• Antiy's analysis counted 1,184 malicious skills across the marketplace's history and attributed 677 uploads to a single account.

Roughly one skill in three carrying a security flaw, and one in eight carrying a critical one, in a layer that executes with full user privileges and requires no signature to publish.

OWASP introduced an Agentic Skills Top 10 this year — the first security framework devoted to this layer — recommending signed publishers, content hashes and sandboxed execution. A public catalogue of research on skill-layer attacks and defences has been assembling alongside it. Neither is yet a norm.

We spent 2025 arguing about which model was safest. Meanwhile the actual control surface became a folder of unsigned Markdown that anyone can publish and every agent will read.

The Collision Nobody Has Written About

Now the part I have not seen anyone connect, and I think it is the most important thing in this story.

Two days ago I wrote about Anthropic making auto mode the default in Claude Code from 14 August. Per-action human approval is being retired in favour of a classifier that evaluates each proposed tool call before it runs. The evidence for that change is strong — humans caught 13.6% of planted dangerous commands in a controlled study; the classifier caught 89%.

Note carefully what the classifier does. It judges each proposed action against the user's stated instructions.

Now recall what a skill pack of this design does on first use. It writes its own rules into the user's global instructions file, so they apply in every project thereafter.

Those two facts meet at a specific point. If a skill pack has appended itself to your global configuration, then from the classifier's perspective its instructions are the user's instructions. An action consistent with them is, by definition, authorised.

The guardrail and the thing that reshapes the guardrail operate at different layers. The classifier is checking compliance with a rulebook that the layer above it is permitted to edit.

I want to be careful about how far I push this. I have not tested it, I am reasoning from published descriptions of both systems rather than from an experiment, and Claude Code ships hard deny rules and prompt-injection screening precisely to cover cases like this. Anthropic's third-party testing reported blocking all 72 prompt injection attempts in one evaluation.

So this is a question worth asking rather than a demonstrated bypass, and I would rather raise it precisely than overstate it. But it is the right question, and it generalises well beyond one product: any control that validates behaviour against a configuration file is only as strong as the write permissions on that file.

Why This Pattern Keeps Winning

The uncomfortable observation is that this design is popular because it works.

A security professional using an agent for authorised testing hits refusals constantly. The agent hesitates, adds legal disclaimers, asks whether the target is really authorised, declines to run standard tooling. For someone doing legitimate work under a signed engagement, that is friction with no safety benefit — they already have authorisation, and the agent has no way to verify it either way.

So somebody wrote the file that removes the friction, and twenty thousand people recognised the problem it solved.

This is the same dynamic that made a quarter of Claude Code sessions start in bypass mode by June, and that led half of command-line users to write permission allow-rules. Guardrails calibrated for the median user become obstacles for the specialist, and the specialist routes around them.

There is no villain in that sentence. There is a design problem: safety controls that cannot distinguish an authorised professional from an unauthorised one will be disabled by the authorised professional, and the disabling mechanism then exists for everybody.

It is the same lesson as the Pack Hunt jailbreak from June, arriving through the front door instead of the back. Safeguards govern willingness, not capability — and willingness turns out to be editable.

What To Do About It

You are probably not doing penetration testing. The exposure is the same regardless, because the skill layer is now how agents are extended everywhere.

1. Find Out What Is in Your Agent's Global Config

Open your coding agent's global instructions file and read it end to end. Most developers have never looked at it after initial setup, and things accumulate there.

If anything in it arrived from a package rather than from a person on your team, that is the finding. Do this today; it takes five minutes and it is the single highest-value action in this article.

2. Treat Skills as Dependencies, Because They Are

Your organisation almost certainly has a policy for adding an npm package to a production project — review, approval, a record of what was added and why. Almost none have the equivalent for agent skills, despite skills executing with broader privileges than most packages ever get.

Maintain a list of every skill installed on every developer machine. Require the same review you would demand for a dependency. Pin versions where you can.

3. Assume Anything Unsigned Is Untrusted

Until signed publishers and content hashes become normal — OWASP recommends both — the absence of a signature is the default state, not a red flag. That means the trust decision falls entirely on you and cannot be delegated to the marketplace.

Practical version: read the files. A skill is Markdown. It takes fifteen minutes to read one properly, and the instructions are in plain English by construction. This is the rare security review that requires no specialist tooling.

4. Scope the Agent, Not the Skill

This is the structural answer and the only one that holds when the review fails.

If your agent runs with credentials that can only read, a skill that instructs it to write cannot. If it runs in a container without production network access, a skill that tells it to reach a production host fails at the network layer rather than at the instruction layer.

Instructions can always be rewritten. Permissions granted by a system the agent does not control cannot. This is the same four-category discipline I keep returning to, applied one level lower than usual.

5. Separate Development From Everything Else

A coding agent with skills installed should not be running on a machine that holds production credentials, customer data or your password manager in an unlocked state.

The privilege model here is that skills inherit whatever the user has. The mitigation is to make sure the user, in that session, does not have much.

The Broader Read

Six weeks of incidents have pointed steadily in one direction, and this one completes the argument.

Models escaping sandboxes was a containment failure. A model socially engineering a maintainer was a containment failure. The npm attack on developer tooling was a supply-chain failure. This is neither. It is what happens when a system works exactly as designed and the design permits the configuration to be rewritten by the content it consumes.

That is why 88.4% of organisations reported agent-related security incidents in a year when every major vendor shipped guardrails. The guardrails were real. The layer above them was open.

Gartner still projects $206 billion of AI agent spending this year. Essentially none of it will go to signing infrastructure for the skill layer, because no one sells that and it does not demo well.

I keep writing the same conclusion in different clothes, and this week it wears the plainest version yet. The vendors are doing serious work on their models and their guardrails — genuinely serious, as Anthropic's classifier study and OpenAI's Astra pause both showed this month. None of that work reaches the folder of Markdown files on your developer's laptop that tells the agent what to do.

That folder is yours. It is a systems problem, it costs an afternoon to audit, and nobody is coming to do it for you.

Frequently Asked Questions

Is this repository dangerous?

No security vendor has flagged it, its own audit reports no backdoor, and GitHub's policy explicitly permits dual-use security research content. The concern raised by researchers is its trust model — specifically that it writes rules into the agent's global configuration and inverts the authorisation default — rather than any confirmed malicious payload. Those are different claims and should not be blurred.

Should I stop using agent skills?

No, but treat them as dependencies with unusually broad privileges. Read the files before installing, keep an inventory, prefer skills from sources you can identify, and scope the agent's own permissions so a bad instruction has limited reach. That is ordinary supply-chain hygiene applied to a layer most teams have not yet classified as supply chain.

What is the difference between a skill and a plugin?

Practically, the privilege model. A conventional plugin usually runs inside an application's defined extension points. A skill is instructions the agent reads and acts on using the user's own filesystem, network and shell access — which is why an unsigned Markdown file can have effects that a sandboxed plugin could not.

Does the new Claude Code classifier protect me from this?

Partly, and the honest answer is that nobody has published a test. The classifier evaluates actions against the user's instructions and ships alongside hard deny rules and prompt-injection screening, with one invited evaluation reporting all 72 injection attempts blocked. The open question I raise above is what happens when the instructions themselves have been edited by an installed package. Set your hard deny rules regardless.

How would I know if a skill modified my agent's configuration?

Read the file. Coding agents keep global instructions in a plain text or Markdown file in your home directory, and the contents are human-readable by design. Put it under version control if you want to see changes over time — that alone converts an invisible risk into a visible diff.

What is the single most useful action here?

Open your agent's global instructions file today and read what is actually in it. Almost nobody has, things accumulate there silently, and it is the file that determines what your agent does in every project you touch.

Related Reading

The Five Eyes AI Agent Security Guide — governance-first architecture, and why the configuration layer is where outcomes are actually decided.

You Don't Need an Agent, You Need a Rule — the four-category classification, applied here to what an agent is permitted to do rather than what it is told to do.

The Pack Hunt Jailbreak — the earlier demonstration that safeguards govern willingness rather than capability.

Apple Sues OpenAI, and the npm Attack on Developer Tooling — the supply-chain precedent that the skill layer now extends with broader privileges.

AvePoint: 88.4% of Organisations Hit by Agent Security Incidents — the statistic that makes sense once you look above the guardrails rather than at them.

74% of AI Agent Deployments Get Rolled Back — what happens when the configuration layer was never inventoried.

The No-Code Automation Workflow Guide — building workflows where permissions, not instructions, do the containing.

About the Author

Hamza Baig is the founder of Hexona Systems, an AI automation agency serving clients across six continents, and the AI Automation Institute, a community of more than 40,000 entrepreneurs building with AI.

He has been featured in the GHL Top 50, Yahoo Finance and Brainz Magazine, and writes regularly on automation architecture, agent governance and the operational realities of AI deployment.

Read more analysis on the Hamza Automates blog, or get in touch to discuss an automation build.

Follow @hamza_automates on Instagram for daily automation breakdowns.

Note: this article deliberately does not link to or provide installation guidance for the repository discussed, and describes its design at an architectural level only. The marketplace vulnerability figures cited measure the broader agent-skill ecosystem and are not scans of any single project. Nothing here alleges malicious intent by any named party.