REA reverse engineering: Skill, MCP setup and first workflow

Use REA when the answer depends on a built artifact or behavior you cannot establish from the available source. Examples include inspecting an Electron ASAR, following a native function or comparing two packaged releases. If you have the complete source repository and only need its architecture explained, the official Skill recommends ordinary repository tools.

Our selection rule: name the artifact, one behavior and the evidence needed to explain it. “Explain this app” gives an agent too little direction; “identify which function normalizes this exported field” creates a question you can check.

Guided setup registers the server and installs matching instructions. A Skill-only install supplies instructions and references. That distinction explains a common failure: the Skill is visible, but no REA tool is available in the active session. See the installation guide.

This is a shortlist, not a claim that all formats work on all machines. Check the target matrix and your installed release. Static JavaScript inspection reads the supplied application files without running that application. Runtime capture can execute or interact with a target, so scope it separately.

Local analysis also does not make the entire agent conversation offline: tool results may be sent to the agent's model provider. Use software and data you are authorized to inspect, and choose a model configuration appropriate for that material.

At this source check, npm's published version was 6.4.0. It requires Node.js 22.19+ within 22.x, 24.11+ within 24.x, or 26+. The Skill's metadata version 39 is a separate version number. Repository main can describe features newer than the npm release. Package · Release boundary.

For a scoped Codex setup, first inspect the proposed configuration changes:

npx rea-agents@6.4.0 setup --client codex --dry-run --json

npx may download and execute the REA package even for a dry run; the dry run plans configuration changes. Review the destinations, backups and Skill replacement. Apply that plan when appropriate:

npx rea-agents@6.4.0 setup --client codex

Replace codex with claude_code or cursor for those clients, then restart or reconnect the selected agent. If tools are missing, inspect that client with npx rea-agents@6.4.0 doctor --client codex --json. Doctor checks configuration and prerequisites; confirm tool availability in the live agent session too. Working connections do not need setup repeated before every task.

For a direct static JavaScript inspection, replace the path with your own extracted directory or ASAR and save the result:

npx rea-agents@6.4.0 analyze-javascript-application /absolute/path/to/app --json > app-evidence.json

On Windows, a path such as "D:/apps/example" is suitable. Large results can be substantial: keep the Evidence file and read focused views instead of pasting everything into a model context. The CLI guide explains those views.

Start with your own packaged Electron app and a single export feature. Keep a copy of the target and record its version or hash so another person can inspect the same bytes. Here is an original task template, not a report of a run we performed:

Target: [absolute path to my application package]
Question: where is the exported CSV field “status” normalized?
Start with static inspection. Trace the relevant entry point,
IPC handoff, if present, and writer. Cite file locations or
function addresses for each conclusion. Separate observed
facts, inferences and unresolved questions. Do not run the
application or change files without asking first.
Deliver: a short call path, an evidence table and a proposed
test using an empty value, an unknown value and Unicode text.

Review three deliverables: the path from input to output, the evidence supporting each step, and the test that could disprove the explanation. A plausible narrative without locations is unfinished. A static path without an execution observation should remain labeled as a static inference.

If you later implement the behavior in your own project, test that implementation separately. Understanding an algorithm does not demonstrate that a generated replacement reproduces every edge case.

REA's Notion case study traces a clipboard request across Electron process boundaries. Its DX-Ball example investigates a sound-panning calculation and links the reconstruction's checks.

The practical lesson is to ask for the handoffs and testable calculation behind a feature. These are upstream examples with specific targets and versions, not OpenAgentSkill runtime tests or a success rate for arbitrary applications. Pseudocode is a starting point for investigation; callers, instructions and observed outputs can reveal what it misses.

Is REA free?

The repository uses the MIT license. Agent model usage and some analysis providers can have their own costs. An open-source license is not a promise that every configured workflow is free.

Does it work on Windows?

Check the target and provider combination. JavaScript analysis and a native Ghidra workflow have different prerequisites; the upstream documentation explicitly describes Windows Ghidra support as experimental. Do not infer universal support from a successful package install.

Can it recover the original source code?

Native analysis can produce pseudocode and assembly. Those do not necessarily preserve original identifiers, comments or project structure. Have the agent explain what is recovered and what is inferred.

Why is the Skill installed but its tools missing?

Skill installation, MCP registration and an active agent connection are separate states. Check the selected client's registration, restart the session and inspect its advertised tools. Install an additional engine only when the chosen target needs it.