reverse-skill: 44 routing rules and a scope gate

The unit of work is a routing rule, not a tool

The whole flow is six lines, and they are printed in the README About section:

User task
  → RULES.md
  → MASTER-ROUTING / master-route.ps1 (PRIMARY)
  → case-init / scope.md (auth + network_profile; no target ACT until ready)
  → Scenario skill → tools / MCP / scripts
  → timeline + Evidence→Finding→Path → report + field-journal

A task arrives, `RULES.md` applies, the primary ladder in `skills/MASTER-ROUTING.md` decides which scenario applies, the scenario directory supplies the method, and the output is a report plus a field journal. The status table gives the scale: 44 routing rules numbered R0 through R45, 45 tracked skill modules, and a client model described as client-neutral, with the routing core kept separate from optional client adapters. The stated reason for the package is that agents do not know whether to reach for jadx, apktool, Frida, IDA or BurpSuite on a given task, and that experience is not reused. So the artefact being distributed is a decision procedure. One oddity in the document: between the About section and Getting Started sit three sponsor entries carrying vendor copy, which is worth knowing before you weigh how much of the page is project documentation.

scope.md blocks the run until auth and a network profile exist

Line four of the ladder is the one to sit with. The case is initialised, a `scope.md` is written carrying auth and a network profile, and the note on that same line says no target action until ready. Read as a mechanism, that is an authorization gate placed before any tool runs, and it is the most consequential thing in the repository. An agent that has been told to work on a binary, a capture or a service has to produce a scope record first, which means the run stops and asks rather than proceeding on inference. The ladder line itself does not show how the authorization is verified or who checks `scope.md`, so until you read the rules behind it, treat the gate as a prompt-level control that depends on the client following the ladder.

The tool index is a file you regenerate, not a live probe

Installation is a clone:

git clone https://github.com/zhaoxuya520/reverse-skill.git

Then the tool index is refreshed per platform, and the three commands are not variations of one script. Windows runs a PowerShell script, Linux and macOS run a bash script, and Kali has its own tree with a third:

powershell -File skills/scripts/refresh-tool-index.ps1

bash skills/scripts/refresh-tool-index.sh

bash kali/scripts/refresh-tool-index.sh

Whatever runs writes `skills/tool-index.md`, and that file is how you see which tools were detected. The consequence is that the router's picture of your machine is a snapshot taken the last time you ran one of those scripts. Install a disassembler after the refresh and the ladder still does not know about it, so the failure mode is a routing decision made against a stale inventory rather than a crash. The second consequence is maintenance: three entry points across two directory trees, and the Kali one lives under a separate `kali/` path with its own documentation.

Three runtimes, each tied to a different toolchain

The prerequisites are short and each line exists for a reason. A Java or JDK is required for jadx and apktool. Node.js 22.12 or newer is required for the JS toolchain and the MCP servers. Python 3 is required for Frida and the helper scripts. And you need a code AI client, with Claude Code, Codex, Cursor and OpenCode named as the compatible ones. Read as a dependency list that is three interpreters deep, none of which the router itself runs on. The router itself is rule files plus a PowerShell script; Java, Node and Python are there for the tools it dispatches to. So a reader deciding whether this fits has to ask a specific question: which of my target types am I actually going to analyse. An Android APK needs the Java line, since jadx and apktool need a JDK. A frontend bundle with encrypted parameters needs the Node line.

The scenario table is a directory index with a PowerShell entry

Scenarios map one to one onto directories. APK and Android analysis is `skills/apk-reverse/`, iOS and mobile is `skills/mobile-reverse/`, executables, DLLs, SOs and ELFs go to `skills/ida-reverse/` or `skills/radare2/`, Binary Ninja with HLIL and MLIL is `skills/binary-ninja-reverse/`, .NET and C# is `skills/dotnet-reverse/`, frontend JS and encrypted parameters is `skills/js-reverse/`, custom opcode VMs have their own directory under `skills/reverse-engineering/dsl-vm-reverse/`, and malware work with YARA is `skills/malware-analysis/`. The tools named under Built With are IDA Pro, radare2, Ghidra and Binary Ninja, which tells you which analysers the playbooks assume. Now look at the shape of the entry point. The primary route is `master-route.ps1`, a PowerShell script, and the repository's primary language is PowerShell, while the tool index refresh has a bash script for POSIX.

175 regression cases back 44 rules, on two CI platforms

The current status table claims a regression benchmark of 175 cases, 45 tracked modules, and CI on Windows and Ubuntu. That is the mechanism keeping a 44-rule decision table honest, and it is the strongest thing in the repository, because a routing table that silently rots is worse than no table. Read the arithmetic carefully though. 175 cases spread over 44 rules is under four per rule,. Then compare the CI platforms with the platform documentation. There is a document for Kali, one for Ubuntu and Debian, and one for macOS, but the CI pair named is Windows and Ubuntu. So a macOS user has a written path and no automated coverage behind it, and a Kali user has both a separate install script and a separate document but also no named CI run.

README_AI.md, AGENTS.md and CLAUDE.md are three instruction surfaces

The project is written to be read by a client before a person. The About section opens with a line addressed to an AI agent, telling it to jump to `README_AI.md` and follow the instructions strictly, and the top level holds `AGENTS.md`, `CLAUDE.md` and `RULES.md` as separate instruction files, with `RULES_zh.md`, `README_zh.md` and `README-kali.md` as the parallel Chinese and Kali versions. So the tree contains `plugins/`, `skills/`, `scripts/`, `docs/`, `examples/` with a `ctf-demo/`, a `CTF-Sandbox-Orchestrator/`, a `reports/` directory for output, `burp-mcp-full/`, plus `SECURITY.md`, `CHANGELOG.md` and a `VERSION` file. The maintenance shape follows from that. The last push to the main branch was on 2026-09-22 and the only tag is v1.0.1 from 2026-08-08, so the tree moves on a different clock from the releases, and anyone tracking this by version number is looking at a seven-week-old snapshot of a prompt pack.

Editorial conclusion

Adopt this if your reverse engineering work already happens inside an AI coding client and you want the method chosen for you, and if you can live with the router only knowing about tools that were present the last time you refreshed the index. Do not adopt it expecting macOS to be covered the way Ubuntu is, because the CI pair is Windows and Ubuntu while macOS has documentation only. Before the first run, read RULES.md and README_AI.md, and note the tree moved on 2026-09-22 while the only tag is v1.0.1 from 2026-08-08.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes