Lean Rea: 8 KB Skill That Replaces REA

Lean Rea is an 8 KB skill file that matched REA’s accuracy on four reverse-engineering tasks while using 38% less wall time and 35% less money. It has no MCP server, no tool definitions and no npm package. Its author ran the benchmark on one Mac, with one model, three times per task.

That is a narrower claim than “replaces REA”, and the narrow version is the interesting one. It says something real about where the intelligence in an agentic workflow lives. It does not yet say that a short note can do everything a 207-tool platform does.

The idea is simple. Coding agents like Claude Code already have a shell. If the right tools are installed, they can run otool, nm, asar, go version -m, jadx, apktool, tshark, binwalk and sqlite3 themselves. REA puts an MCP layer between the agent and analysis tooling. Lean Rea removes that layer and writes down, in one short file, which command is fastest for which target.

What REA actually is

REA (Reverse Engineer Anything) is a large, actively maintained MIT project from the morluto team. Version 6.5.0, the one tested, ships as a 25 MB npm package (rea-agents) plus an MCP server. It also includes a 23.5 KB skill with 48.8 KB of reference docs. It exposes 207 tools, and their definitions weigh 3.35 MB of JSON.

REA is more than a wrapper around command-line tools. It does three different things:

• Built-in static parsers. Go build info, Rust cargo-auditable metadata, Flutter snapshot hashes, .NET metadata and SQLite are parsed by REA itself. No Go toolchain is needed to read a Go binary.

• Orchestration of external tools. JADX, Apktool, tshark, Binwalk, WABT and others, with process-ownership checks and output limits.

• Native decompiler bridges. Hopper, Ghidra and IDA provide pseudocode, cross-references and call graphs for native binaries. This is REA’s main strength for deep native work.

Every result comes back in a structured format with its evidence and limitations attached. It covers more than 20 target categories, including Windows, EVM bytecode, Linux crash dumps, Android devices over ADB, logic-analyzer recordings and live browser observation.

So the honest framing is not “REA just calls tools you already have”. It is this: for many common targets, the agent can run the underlying tool directly and skip the layer. The question is how much the layer costs and what you lose without it.

The context cost, measured

With Claude Code’s default tool search, REA’s context overhead is small. With every tool loaded up front, it is enormous. The author sent one message, “Reply with exactly OK”, under five configurations:

The fourth row is the fair comparison with Lean Rea, because the benchmark’s REA arm used both the MCP server and REA’s skill. The gap there is 8.2k tokens per session: real, but modest.

The last row is where the structural argument lives. An agent that loads every tool definition at session start pays about 369k extra tokens before reading a single byte of the target. REA’s raw tool list breaks down into 745 KB of input schemas, 2.46 MB of output schemas and 90 KB of descriptions. Output schemas make up most of it.

The lesson is not that MCP is bad. Tool definitions are a cost, and whether you pay it depends on your agent. Claude Code users with tool search on barely notice it. Users of agents without lazy loading pay it on every session.

What’s inside the 8 KB skill

The skill is one SKILL.md file of 66 lines (8.18 KB). The author built it by reading REA’s source, mapping each feature to the plain command that does the same job, and keeping the fastest one per target. It has four parts.

Rules. Work on a copy of the target. Identify the file type with file and magic bytes before choosing a path. Never read a big minified file; slice around a search hit instead. Batch independent probes into one shell call. Aim for two to four tool calls in total. Mark every claim as seen (with a file offset, symbol or string), inferred, or unknown. A fact the model did not find is unknown, not absent. That small distinction is a large part of what makes the output trustworthy.

The router. A table mapping target type to fastest command. It covers Electron and asar, minified bundles and source maps, Hermes and bytenode, Mach-O, ELF and PE, Go, Rust, .NET, Android APKs, Flutter, WASM, SQLite, plists, pcap and HAR, firmware, websites and runtime tracing. Note that a row in the router is a suggested route, not a tested capability. Only three of these families were benchmarked.

First moves. Paste-and-run commands. For a Mach-O binary, one call returns the file type, architectures, linked libraries, exports, imports, strings, a disassembly dump and function labels. Fewer calls mean fewer turns, and turns are where agents lose time.

Speed patterns and traps. Start from strings and imports. Find who uses a string through otool’s literal-pool comments. Read call sequences rather than every instruction. Diff inventories before diffing code. The Flutter snapshot hash is the 32 hex characters at +20 bytes after the f5 f5 dc dc marker in libapp.so. Two traps are written down because models miss them:

• ripgrep skips hidden folders by default, and Electron bundlers put code in dot-folders like .webpack/ and .vite/. The skill says to search extracted trees with rg -uu.

• In zsh, a bare word starting with = triggers command-path expansion, so an unquoted == output marker breaks the command. The skill’s markers are quoted.

The benchmark

Against REA, Lean Rea used 38% less wall time, 35% less money, 56% fewer turns and 60% fewer tokens, scoring 74/75 against REA’s 75/75. In speed terms, 38% less time means roughly 1.6 times faster.

Setup. Claude Code 2.1.301 in headless mode (claude -p), Sonnet 5.5, macOS arm64, run on 2026-10-16. Three arms: no skill and no MCP; Lean Rea; and REA 6.5.0 (MCP server plus REA’s own skill). Each arm ran each task three times, 36 runs in total, each from a fresh copy of the targets. The arms ran side by side.

The tasks.

• electron: in Notion’s app.asar, trace microphone and meeting detection from the native function to the main-process class to the IPC channels.

• native: in Notion’s mac_utils.node addon, list the exports and explain a TCC permission check and the single-instance lock.

• go: from a stripped gh binary, extract the Go toolchain version, main path and two dependency versions.

• deep: from disassembly alone, recover the lock’s socket path format, wire protocol and peer authentication.

Totals (12 runs per arm).

Per task (median wall time per run; mean turns and cost).

What the numbers say.

• The biggest gains are on the simple tasks. On electron and go, one well-chosen command answers the question. With REA the model has to pick a tool, call it and read a large structured result. On the hardest task, deep, REA and Lean Rea were within 7 seconds.

• Lean Rea’s one miss named the older v1 IPC channel instead of v2. Both channels exist in the app.

• The no-skill score is entirely one refusal. All 8 points it lost come from a single deep-task run where the model declined, judging that the disassembly could help defeat a security check. Otherwise, the plain model was as accurate as the other two.

• Lean Rea does not beat the plain model everywhere. On native, no skill was faster (36.7 s vs 43.4 s) and cheaper. On go it was cheaper. Overall, Lean Rea beat it by 19% on wall time, 32% on turns and 23% on tokens, at the same total cost.

The microbenchmark, and why to read it carefully

Run outside the agent, raw commands were 9 to 80 times faster than REA’s CLI. But these are not identical jobs.

Three things to keep in mind:

• Startup cost dominates small operations. REA is a Node.js CLI, so every call includes a Node cold start. otool and nm are native binaries. Part of the 3.32 s vs 0.04 s gap is likely startup rather than analysis; the benchmark does not separate the two.

• The Electron row compares different scopes. REA ran a full application analysis: modules, imports, source maps and Electron boundaries, with evidence. The raw path ran a targeted IPC search. The raw path answered the benchmark question, which is what matters for the task. It is not the same job.

• REA’s output carries more. Structured results with evidence and limitations are larger by design. Whether that extra context helps or hurts depends on the task. In this benchmark it mostly hurt, because the model had to read through it.

The practical finding still stands: for a targeted question, a targeted command is far cheaper than a general-purpose analysis.

Caveats that matter

The benchmark is honest and reproducible, but small, and it was designed by the author of one of the contenders. The author lists several limits; a few more are worth adding.

• Small sample. Three runs per cell, one model (Sonnet 5.5), one machine, three target families, all on macOS. Per-task differences of a few seconds, like 43.4 s vs 36.7 s on native, are within noise.

• REA’s native engines were not installed. Ghidra, Hopper and IDA were absent, so REA used its built-in native path and Lean Rea used otool. REA’s main strength, decompiler-backed pseudocode, was never exercised. (The repo’s README says both arms used Xcode tools; its BENCHMARK.md gives the more precise version above.)

• The tasks and keys came from Lean Rea’s author. The skill was refined while testing on these same targets, while REA ran as shipped. That does not invalidate the result, but it favors the skill. An independent task set would be stronger evidence.

• Grading was by regex. Answers were matched against hand-written keys. One correct answer (“Go 1.27.1” instead of “go1.27.1”) was rejected and fixed by hand. For an open-ended task like deep, regex grading is coarse.

• Runs were in parallel. The arms ran side by side, so they competed for CPU and disk, which can affect wall time.

• Best case for REA’s context. Claude Code’s deferred tool search was on. An agent that loads all tools would add about 369k tokens per session to the REA arm.

• Version-bound keys. The answer keys match the app versions tested and a gh built with go1.27.1. Other versions need new keys.

What REA still gives you

Lean Rea wins on speed and cost for targeted questions on common targets. REA remains the better choice when you need what a short note cannot provide.

• Decompilers. Hopper, Ghidra and IDA integration for real pseudocode, cross-references and call graphs on large native binaries. Lean Rea mentions Ghidra headless and radare2, but leaves the setup to you.

• Targets outside the router. EVM bytecode, Linux crash dumps, logic-analyzer recordings, JEB projects, Android devices over ADB and recorded process behavior.

• Fewer installed dependencies for some formats. REA parses Go, Rust, Flutter and .NET metadata itself. Lean Rea needs go, cargo-audit, ilspycmd, jadx, apktool, wabt and others installed. On a fresh Mac, only the Xcode tools are there by default.

• Structured, auditable output. Every result includes its evidence and stated limitations, in a stable format that scripts and CI can consume.

• Windows and Linux support, with documented prerequisites per platform.

• Guardrails. Process-ownership checks, output caps and integrity checks on the target (the asar integrity error in the microbenchmark is one of them).

A reasonable rule: start with the small skill for quick, targeted questions. Use REA when the job needs a decompiler, a target the skill does not cover, or results other tools must consume.

Install and reproduce

Lean Rea is on GitHub at aicodeking/leanrea, MIT licensed, and installs through the skills CLI:

npx skills add aicodeking/leanrea

It asks which agents to install for: Claude Code, Codex, Cursor, Gemini CLI, OpenCode and others the CLI supports. Common variants:

npx skills add aicodeking/leanrea -g                 # your user, every project
npx skills add aicodeking/leanrea -a claude-code -y  # Claude Code only, no prompts
npx skills add aicodeking/leanrea -g -a '*' -y       # every supported agent, user level
npx skills update leanrea                            # update later

Manual install: clone the repo and copy the leanrea directory into ~/.claude/skills. For an agent without skills support, paste SKILL.md into its rules or system prompt; it is plain text. Then:

/leanrea How does the search feature in Foo.app work? Show the evidence.

Before relying on it, install the tools the router expects for your targets (for example brew install jadx apktool radare2 binwalk wabt wireshark ghidra). A missing tool will not block the agent, but it will fall back to slower paths.

Reproducing the benchmark. The repo includes the full harness. You need macOS with Notion installed, gh from Homebrew, Node and a logged-in Claude Code. setup.sh installs rea-agents@6.5.0 and copies the targets. run_all.sh runs all 36 runs for about $8 on Sonnet. ctx.sh measures context overhead. Raw per-run metrics are in bench/results/final.jsonl.

This is the right way to publish a claim like “38% less time”: with a script anyone can rerun. The most useful next step would be someone else running it with their own tasks.

Responsible use

Reverse engineering is legal in many contexts and illegal in others. Analyze only software you own or are authorized to examine, for purposes like interoperability, security research, education or preservation. Check the license terms of the software and of any commercial tools you use, such as Hopper, IDA or JEB. REA’s own disclaimer sets out the same boundaries, and they apply equally to a skill file.

The benchmark noted that the plain model refused one run and the skill-guided runs did not. That is a single data point, not a feature. A refusal on security-sensitive disassembly can be the right call, depending on the target and the purpose.

What this actually shows

On targeted questions about common targets, a model with a shell and a short routing note matched a 207-tool MCP platform on accuracy and beat it on time, cost, turns and tokens.

The interesting question is where the intelligence in an agentic workflow lives. REA’s bet is on tooling: wrap each capability in a schema, return structured evidence, let the agent choose from a large menu. Lean Rea’s bet is on the model: it already knows what otool does, so it needs a routing table, a few traps written down and permission to use its own shell.

In this benchmark the second bet won for simple and medium tasks, and roughly tied on the hardest one. The mechanism behind it is general. Every tool definition you load is context the model cannot spend on your target. Every tool call is a turn you pay for in latency and in money. And a short skill is something you can read in two minutes and audit yourself.

The limits are just as clear. One model, one machine, four tasks chosen by the skill’s author, and REA’s decompiler integrations never switched on. “Replaces REA” is not established. “Is the better default for quick, targeted reverse-engineering questions” is well supported.

Bottom line. If you reverse-engineer software with a coding agent, install Lean Rea for everyday questions, and keep REA for decompiler work, unusual targets and structured output. Better still, run the benchmark on your own targets and see whether the numbers hold.

FAQ

Does Lean Rea require an MCP server? No. It adds no tools to the agent and runs everything through the agent’s shell, using tools like asar, otool, nm, go version -m, jadx and apktool. Those tools must be installed on your machine.

How large is the skill file? 8.18 KB, one SKILL.md of 66 lines. REA’s skill plus reference docs total about 72 KB, roughly nine times more, before counting its npm package or tool schemas.

Which targets does it cover? Its router suggests commands for Electron and asar, minified bundles, Hermes and bytenode, Mach-O, ELF and PE, Go, Rust, .NET, Android APKs, Flutter, WASM, SQLite, plists, packet captures, firmware, websites and runtime tracing. Only Electron, Mach-O and Go were benchmarked.

Is it as accurate as REA? On the four benchmark tasks, 74/75 vs 75/75. That is not evidence for deep native work with a decompiler, which was not tested.

Which agents does it work with? The skills CLI installs it for Claude Code, Codex, Cursor, Gemini CLI, OpenCode and more. Any agent can use it by pasting SKILL.md into its rules or system prompt.

Is Lean Rea affiliated with REA? No. Its repository says so, credits the morluto team, and notes that most of the skill’s gotchas came from reading REA’s code and docs. Both projects are MIT licensed.

Sources

Get REA only from its official sources. Similarly named repositories and copied READMEs are not official, as REA’s own README warns.

• Lean Rea on GitHub (aicodeking/leanrea)

• Lean Rea benchmark details (BENCHMARK.md)

• Lean Rea skill file (SKILL.md)

• REA official repository (morluto/rea)

• REA website (rea.tools)

• REA on npm (rea-agents)