Claude Code Reverse Engineering Skill: Set Up REA for Agents
On this page
If you ask Claude Code to “reverse engineer this binary” with nothing installed, it will fall back to strings, file and guesswork. A reverse-engineering setup for an agent needs two separate things: tools the agent can call, and instructions that tell it when and how to call them. REA, the open-source project by morluto, ships both in one npm package (rea-agents): an MCP server for the tools and a bundled skill named reverse-engineer-anything for the instructions.
This guide is for developers who already use Claude Code (or Codex) and want a reverse-engineering workflow they can trust. You will learn:
- exactly what
npx rea-agents setupwrites for Claude Code in REA 6.4.0, and where, - what the skill does and, just as important, what it does not do,
- how to refresh only the skill, only the MCP registration, or both,
- how to write prompts that produce checkable answers,
- how to confirm the agent actually called REA instead of improvising.
If REA is not installed yet, start with Install REA MCP and connect Claude Code, Cursor and Codex. This article goes deeper on the Claude Code side and skips the general installation material.
Prerequisites
- Node.js 22.19+, 24.11+ or 26+ with npm. The 6.4.0 package declares
"node": "^22.19.0 || ^24.11.0 || >=26.0.0". - Claude Code installed and run at least once, so its configuration directory exists. Setup detects clients by looking for their configuration directories.
- A target you are allowed to analyze. The examples use
xor_gate, the small crackme you compile yourself in the CTF walkthrough. For native binaries you also need an analysis engine such as Ghidra; see REA + Ghidra.
Step 1: Understand the two pieces setup installs
Setup can install two things for Claude Code, and they fail in different ways, so it helps to keep them apart from the start.
| Piece | What it is | Where it goes (Claude Code) | What breaks without it |
|---|---|---|---|
| MCP registration | An entry named rea that tells Claude Code how to launch the REA MCP server |
~/.claude.json, or $CLAUDE_CONFIG_DIR/.claude.json if that variable is set |
The agent has no REA tools at all |
| Skill | SKILL.md plus six reference guides with workflow instructions |
~/.claude/skills/reverse-engineer-anything/, or $CLAUDE_CONFIG_DIR/skills/reverse-engineer-anything/ |
The tools exist, but the agent uses them poorly: wrong first tool, oversized results, no Evidence discipline |
The skill states this split in its own words: “Installing this skill supplies instructions; it does not register the REA MCP server, install analysis engines, or add tools to an already-running agent.” If you install the skill from somewhere else (for example the skill-only route), you still have no tools until the MCP registration exists.
The 6.4.0 skill bundle contains exactly these files:
reverse-engineer-anything/
├── SKILL.md
└── references/
├── connection-and-recovery.md
├── native-and-artifacts.md
├── javascript-applications.md
├── android-applications.md
├── runtime-observation.md
└── evidence-workflows.md
SKILL.md carries metadata.version: "37" and tool_count: 170. rea doctor compares the installed copy against these values, which is how it tells you the skill is stale (Step 5).
Step 2: Preview the plan before writing anything
Run a dry run scoped to Claude Code:
npx rea-agents@latest setup --client claude_code --dry-run
Why start here: --dry-run resolves the full plan and prints it without applying it. In 6.4.0 a dry run always produces structured output, and setup reports status planned. The plan for Claude Code contains up to two actions:
configure_client:claude_code, with the target path of your.claude.json. Its detail line reads “Add the REA MCP registration for Claude Code; preserve unrelated configuration” and shows the exact command that will be registered. If the file already exists, the plan lists a backup path.install_skill:claude_code, labelled “REA skill for Claude Code”, with the target~/.claude/skills/reverse-engineer-anything. Setup plans this only if any of the seven skill files differ from the bundled copy.
If the plan shows nothing for a piece, that piece is already current. That is a valid answer, not an error.
Step 3: Apply setup for Claude Code
Interactively, run npx rea-agents setup and pick Claude Code in the agent list. When you select at least one agent, setup adds the skill to the plan automatically, then asks you to approve the whole plan.
For a scripted or repeatable run, approve the same scope explicitly:
npx rea-agents@latest setup --client claude_code --yes
--yes approves only the actions in the scope you named. Pairing it with --client keeps it from touching other agents.
What setup writes, based on the 6.4.0 source:
The MCP entry. Setup adds an rea key under the top-level mcpServers object in .claude.json and leaves your other servers and settings alone. The launch command depends on how you ran setup:
-
Through
npx, the entry is pinned to the exact version that ran setup:{ "mcpServers": { "rea": { "command": "npx", "args": ["-y", "[email protected]", "mcp"] } } }On Windows the same command is wrapped as
cmd.exe /d /c npx -y [email protected] mcp. -
Through a globally installed
rea, the entry points at the absolute path of thatreaexecutable with the argumentmcp.
If setup finds provider settings such as GHIDRA_INSTALL_DIR, it adds them under env. Existing env overrides in the entry are kept.
The skill files. Setup writes whichever of the seven files above differ from the bundled copy. Before overwriting a file that already exists, it saves a copy next to it with a .rea.backup suffix. It then reads each written file back and compares it with the bundled content. If anything fails, it restores the originals.
Restart Claude Code. Exit the session and start a new one. A session that was already running will not pick up the new server or skill.
Useful variations
Only the MCP registration, no skill (for example, if you maintain your own instructions):
npx rea-agents@latest setup --client claude_code --skill=false --dry-run
Only the skill, leaving MCP registrations alone. This is handy after you edited .claude.json by hand and do not want setup near it:
rea setup --skill-client claude_code --yes
--skill-client is repeatable and accepts any supported client ID or shared. Without a global install, use npx -y rea-agents@latest setup --skill-client claude_code --yes.
Codex, Gemini CLI and Qwen Code
The same commands work with --client codex, --client gemini_cli or --client qwen_code. The skill destinations differ:
- Claude Code:
~/.claude/skills - Gemini CLI:
.agents/skillsunder its home ($GEMINI_CLI_HOMEor~) - Antigravity:
~/.gemini/config/skills - Codex, Qwen Code and most others: the shared
~/.agents/skills
A mixed selection, such as --client claude_code --client codex, plans one install per distinct directory. For Codex, setup also adds startup_timeout_sec = 30 to the registration. 6.4.0 also added setup support for Pi, Hermes and Qwen Code.
Some MCP clients cap the size of each tool’s input schema. Kimi/Moonshot is the example in the 6.4.0 changelog. For those, add REA_MCP_INPUT_SCHEMA_PROFILE=compact to the env of the rea entry. The compact profile advertises input schemas without nested annotation prose, and REA still validates inputs against the full schema. Claude Code does not need it.
Step 4: Know what the skill tells the agent
Reading SKILL.md once shows you what behaviour to expect, and makes it easier to spot when the agent drifts. The main rules:
- Use REA only when the question depends on a shipped artifact. For a normal source repository, the skill tells the agent to use ordinary repository tools and not to run REA readiness checks.
- Connect only when needed. If REA tools are present, the agent should go straight to the target. It should not run doctor or setup before every investigation.
- Route by target type. An ASAR or extracted Electron tree starts with
analyze_javascript_application. An APK starts withinspect_android_package. A managed .NET assembly starts withinspect_managed_artifact. A native executable starts withopen_binary, followed by focused tools such asanalyze_function. - Work summary-first. For large JavaScript applications or ELF layouts, request
"detail": "summary", then drill down withinspect_analysis_view. Do not repeat an identical analysis. - Separate observations, inferences and unknowns. Every conclusion cites Evidence IDs. Static analysis must not be described as observed execution.
- Close what you opened. Native sessions end with
close_binary.
The six reference files load only when relevant, which keeps the agent’s context small on normal runs.
Step 5: Verify the installation
After restarting Claude Code, check both pieces from a terminal:
rea doctor --client claude_code --skill --json
(Without a global install: npx -y rea-agents@latest doctor --client claude_code --skill --json.)
--client claude_code makes the Claude Code registration a required check. --skill requires the installed skill to match the bundled instructions and references. In the JSON, look at identity.skill.state. aligned means the installed skill matches this REA release. If it is not aligned, doctor’s remediation is “Run rea setup to update the installed REA skill.”
Doctor checks configuration on disk. It cannot see whether your running Claude Code session connected to the server. For that, check inside Claude Code:
- Run
/mcpin a Claude Code session and confirmreais listed and connected. - Or from a shell,
claude mcp get reashows the registered command.
If doctor says the registration is aligned but /mcp shows no tools, restart Claude Code. If they are still missing, look at the server’s launch error. Do not rerun setup in a loop; the skill’s recovery guide gives the same advice.
Step 6: Write prompts that produce checkable answers
The skill handles tool routing, so your prompt does not need to list tools. Spend the words on the target, the question, and what counts as “done”. This template works for most investigations:
Use REA to analyze <absolute path to target>.
Question: <one concrete question about behaviour>.
For each conclusion, cite the REA Evidence ID it relies on, and label it as
an observation, an inference, or an unknown.
List what you could not determine and why.
Done means: <a check I can run myself>.
Applied to the practice crackme:
Use REA to analyze ./xor_gate.
Question: what input does the check function accept, and how is it validated?
For each conclusion, cite the REA Evidence ID it relies on, and label it as
an observation, an inference, or an unknown.
List what you could not determine and why.
Done means: a solver script whose output the original binary accepts.
Why each line is there:
- “Use REA” points the agent at the right tools. The skill’s description already triggers on reverse-engineering requests, but naming REA removes ambiguity when other tools are installed.
- One concrete question keeps the investigation bounded. “Explain everything” invites a long tour with shallow evidence. For broad requests, the skill makes the agent build a checklist of questions first, and you can supply that checklist yourself.
- Evidence IDs and labels force the agent to separate what REA returned from what the model concluded. This is the cheapest guard against confident hallucination.
- Unknowns give the agent explicit permission to say “not determined”. Without it, gaps tend to get filled with plausible guesses.
- A runnable “done” moves the final judgement from the model to you.
Give the agent the goal, not the method. If you dictate “decompile main, then look for XOR”, you have already constrained it to your hypothesis. If the target is an Electron app rather than a native binary, the same template works; the Notion clipboard-bridge showcase shows what a feature trace through preload and IPC looks like when done well.
For the reasoning behind these habits, see the CTF article’s section on giving the agent a goal, not a method.
Step 7: Confirm the agent really called REA
An answer that sounds like reverse engineering is not proof that REA ran. Check these, in order of effort:
- Look at the tool calls in the transcript. Claude Code names MCP tools
mcp__<server>__<tool>, so REA calls appear asmcp__rea__open_binary,mcp__rea__analyze_function,mcp__rea__analyze_javascript_applicationand so on. If the transcript shows only Bash calls tostrings,objdumporxxd, the answer did not come from REA. The skill itself says “only actual REA output supplies REA Evidence”. - Check that Evidence IDs exist. Ask the agent to call
get_evidence_bundlewithdetail: "summary"for the current session and list the Evidence IDs it cited. An ID that is not in the session ledger was made up. - Export the session. Ask the agent to call
export_evidence_bundleto a path you choose. The file is a portable record you can inspect later withrea inspect-evidence-bundle. Evidence, snapshots and version comparison covers this in depth. - Run your “done” check yourself. For the crackme, run the original binary with the solver’s output. For a feature trace, open the cited source location and read it.
When a claim matters, ask “which Evidence ID supports that?” A well-behaved agent answers with an ID or calls the claim an inference.
Anti-patterns to avoid
- Running
doctorbefore every task. The skill explicitly says not to. If tools are present, use them. Diagnose only when something is actually missing or blocked. - Mixing a main-branch skill with an older npm release. The skill warns that “a skill installed from repository main may describe capabilities absent from an older npm release.” If you copied
SKILL.mdfrom GitHub, it may mention tools your installed server does not have. Letsetupinstall the skill that matches your package version, and trust the connected server’s actual tool list. - Letting the agent approve setup for you. Read the plan yourself. Setup never installs Node.js, npm, Homebrew, Java, Ghidra, IDA, JADX, Binwalk or Unblob, and nothing should ask you to.
- Asking for “the source code” of something you do not own. Keep targets to your own builds, open-source software, CTF challenges and official showcases, and read the project’s DISCLAIMER. For runtime capture, device access or network work, get authorization first.
Troubleshooting and FAQ
Claude Code shows the skill but no REA tools. The skill does not register MCP. Run rea doctor --client claude_code --json, then rea setup --client claude_code --dry-run if the registration is missing or stale.
Doctor reports the skill as stale after an update. rea update updates the CLI but does not rewrite registrations or the skill. Run the setup command it prints, or npx rea-agents@latest setup --client claude_code.
I edited SKILL.md and setup overwrote it. Setup keeps your previous version as SKILL.md.rea.backup beside it. If you maintain custom instructions, put them in your own skill or project instructions instead of editing REA’s managed files.
A tool returns provider_unavailable. The skill is working; the engine is missing. Native decompilation needs Ghidra, Hopper or IDA. See REA + Ghidra.
Next steps
- Practise the full prompt-to-proof loop on a crackme: Solve CTF reversing challenges with REA and an AI agent.
- Learn how to page, export and compare Evidence: REA Evidence, snapshots and version comparison.
- Add a free native engine: REA + Ghidra for native binaries.
- Compare approaches: REA vs GhidraMCP vs IDA Pro MCP.
- Make sure you installed the genuine package: Is REA safe? Install the real Reverse Engineer Anything.