# How to Install the Lean REA Skill for Claude Code and Codex > Source: > Published: 2026-10-17 00:00:00+00:00 # How to Install the Lean REA Skill for Claude Code and Codex Step-by-step guide to installing Lean REA, an 8KB reverse-engineering skill file for Claude Code, Codex, Cursor, and other coding agents. ## What is Lean REA and how do you install it? Lean REA is a single skill file, roughly 8 kilobytes, that teaches a coding agent how to reverse engineer apps and binaries using the command line tools already on your machine. You install it with the skills CLI by running `npx skills add a16z/lean-rea` (the package lives on GitHub), which prompts you to pick which agents to wire it into: Claude Code, Codex, Cursor, Gemini CLI, OpenCode, and others. Once installed, you invoke it in a session with a slash command like `/leanrea`. ## TL;DR - **Lean REA is a stripped-down alternative to REA** (Reverse Engineer Anything), replacing REA’s 207-tool MCP server with one skill file that routes tasks to native shell commands. - **Installation runs through the skills CLI** :`npx skills add a16z/lean-rea` , with flags to install globally (`-g` ) or skip interactive prompts (`-y` ). - **It supports multiple agent harnesses out of the box** , including Claude Code, Codex, Cursor, Gemini CLI, and OpenCode, selected during the install prompt. - **A benchmark across 36 runs and four reverse-engineering tasks** found Lean REA 38% faster and 35% cheaper than full REA, with 56% fewer agent turns and 60% fewer tokens, at comparable accuracy (74/75 correct answers versus REA’s 75/75). - **The skill contains three parts** : a short list of working rules, a router table mapping target types (Electron apps, Go binaries, APKs, Rust, .NET, Flutter, firmware, and more) to the fastest command, and ready-to-run “first moves” command snippets. - **Context bloat is the core problem it solves** , since loading all of REA’s MCP tools into an agent that doesn’t support lazy tool loading can balloon a single reply into hundreds of thousands of tokens. - **The project includes its own benchmark scripts** so you can reproduce the speed, cost, and token comparisons on your own machine. ## Other agents start typing. Remy starts asking. Scoping, trade-offs, edge cases — the real work. Before a line of code. ## Why would you install a skill file instead of an MCP server? REA bundles 207 tools into an MCP server and CLI, with an npm package around 25 megabytes and reference docs around 72 kilobytes. Under the hood, most of those tools just wrap things your system can already do: the asar package for Electron apps, otool and nm for Mac binaries, Go’s own build-info reader for Go binaries, and jadx plus apktool for Android APKs. Lean REA removes the middle layer. There’s no MCP server and no extra tool registry. The agent uses its normal shell and calls the underlying commands directly, guided by the skill file’s router and rules. The claim behind this approach is that modern coding agents are already competent with shell tools like `rg` (ripgrep), `otool`, `strings`, and language-specific inspectors. What they’re missing isn’t capability, it’s a map telling them which command to run first and how to avoid wasting turns on dead ends. ## How do you actually run the install command? The install flow uses the skills CLI, a general-purpose installer for agent skill files: ``` npx skills add a16z/lean-rea ``` Running this prompts you to choose which coding agents on your machine should get the skill. Supported targets mentioned include Claude Code, Codex, Cursor, Gemini CLI, and OpenCode. Two flags change the default behavior: - `-g` installs the skill globally, so it’s available in every project rather than just the current one. - `-y` skips the interactive questions and accepts defaults, useful for scripting the install or doing it quickly. After installation, you call the skill inside your agent session using its slash command, for example: ``` /leanrea how does the search feature in this app work? Show me the evidence. ``` The phrase “show me the evidence” matters here: the skill enforces a rule that every claim the model makes gets tagged as seen, inferred, or unknown, rather than letting the model assert something it never actually verified in the binary or source. ## What’s actually inside the skill file? The file is organized into three parts. The first is a short set of working rules: operate on a copy of the target, identify the file type before doing anything else, avoid reading large minified files in full (search inside them instead and pull only the relevant section), and batch multiple small checks into a single shell call rather than issuing them one at a time. The second part is a router, essentially a lookup table. On one side is the type of target (Electron app, minified web bundle, Mac/Linux/Windows binary, Go, Rust, .NET, Android APK, Flutter, WASM, SQLite file, packet capture, firmware image, or website). On the other side is the fastest known command sequence for that target type. ## Seven tools to build an app. Or just Remy. Editor, preview, AI agents, deploy — all in one tab. Nothing to install. The third part is a collection of “first moves”: ready-made commands the agent can paste and run immediately. For a Mac binary, for example, one single call retrieves linked libraries, exports, imports, strings, and the full function list at once. This matters because every round trip between the model and a tool (a “turn”) costs time and money. Fewer turns means a faster, cheaper answer. The skill also preserves specific tricks pulled from REA’s source, like how to read Electron fuses, locate Go build info inside a compiled binary, or find a Flutter snapshot hash, details that are easy for a model to miss without a pointer. ## Does Lean REA actually outperform REA? In a benchmark using Claude Code in headless mode, three setups were compared across four reverse-engineering tasks (tracing a feature through an Electron app, analyzing a native Mac add-on, inspecting a Go binary for version info, and reading disassembly to find a socket path and wire protocol), with three runs per task per setup, 36 runs total: - **No skill, no MCP** (just the model and its default tools): 479 seconds, $2.21, 81 turns. - **Lean REA** : 388 seconds, $2.17, 55 turns. - **Full REA** (MCP server plus official skill docs): 627 seconds, $3.36, 124 turns. Against REA, Lean REA was 38% faster, 35% cheaper, used 56% fewer turns, and used 60% fewer tokens. Accuracy was close to identical: REA scored 75 out of 75 on a hand-built answer key, Lean REA scored 74 out of 75, missing only which of two similarly-named IPC channel versions was involved in one run. The gap was largest on tasks where REA had to discover the right tool, call it, and then parse an oversized result. In one run, REA’s output was large enough that Claude Code saved it to a file and had to reopen it in a later turn, burning time for no benefit. On the Electron task, Lean REA took about 35 seconds versus REA’s 83. On the Go task, it was about 12 seconds versus 26. Against the no-skill baseline, the win was smaller: about 19% faster and 32% fewer turns, with cost roughly unchanged. The larger gains are specifically against REA’s MCP overhead, not against an unaided model. ## What’s the catch with context size? This is where REA’s architecture creates a real cost. Sending a trivial message (“reply with okay”) and measuring token usage showed roughly 31,000 tokens with no skill installed (Claude Code’s standard system prompt), and about 34,000 with Lean REA added. REA’s number depends entirely on whether the agent supports lazy tool loading. Claude Code has a “tool search” feature that loads MCP tools only when needed, keeping REA’s overhead to roughly 3,500 extra tokens. But many agents load all available tools into context up front. With that behavior (tool search turned off), the same one-word “okay” message consumed around 400,000 tokens, costing about $160 to say nothing at all. In agents without lazy loading, REA’s 207 tools can fill most of the available context before the model has read a single line of the actual target. ## Is installing Lean REA worth it? ## Plans first. *Then code.* Remy writes the spec, manages the build, and ships the app. For anyone doing reverse-engineering tasks with a coding agent, swapping REA’s MCP server for the Lean REA skill file looks like a low-risk, high-upside change based on the benchmark: same accuracy, meaningfully lower cost and latency, and a file small enough to read end to end in a couple of minutes. It’s worth noting the benchmark is limited (one model, one machine, three runs per task, no Ghidra or JADX installed for the native tasks), so treat the exact percentages as directional rather than definitive. The broader implication is less about this specific skill and more about a pattern: agents with good shell access often don’t need a large tool surface, they need a short, well-organized map of which existing command to run. ## Frequently Asked Questions ### What agents does Lean REA work with? The installer supports Claude Code, Codex, Cursor, Gemini CLI, OpenCode, and other agents compatible with the skills CLI format, selected during the `npx skills add` setup prompt. ### Do I need REA installed to use Lean REA? No. Lean REA is a standalone replacement. It doesn’t call REA’s MCP server or CLI; it’s a skill file that directs the agent to use native shell tools directly. ### Why is REA sometimes slower even though it’s doing the same job? REA wraps the same underlying tools (asar, otool, nm, jadx, Go’s build-info reader) but adds a discovery and invocation layer. The model has to find the right MCP tool, call it, and then parse its output, which is sometimes very large. Lean REA skips that and gives the agent the direct command up front. ### Does Lean REA sacrifice accuracy for speed? In the reported benchmark, no, it scored 74 out of 75 correct answers versus REA’s 75 out of 75 across 36 runs on four tasks. The single miss involved distinguishing between two similarly-versioned IPC channels. ### Can I reproduce the benchmark myself? The project repository includes a setup script, a script to run all four tasks, a context-usage test script, and the raw results from the original benchmark run.