Reverse Engineer Anything: REA setup, skills and limits

What Reverse Engineer Anything actually does

Reverse Engineer Anything, usually shortened to REA, gives coding agents tools and instructions for investigating shipped applications. The useful starting question is specific: what evidence explains this feature, format or runtime behaviour? A request to reproduce an entire application hides too many separate questions to be a good first investigation.

The canonical project is morluto/rea. Its project website is rea.tools and its npm package is rea-agents. This guide uses the 6.8.0 release, published on 25 October 2026. REA existed before October; the release is the dated reference for the setup and behaviour discussed here, not a claim that the project launched that day.

REA spans multiple kinds of investigation. A native application, an Electron package and a browser capture expose different evidence and require different tools. The project connects those tools to an agent through CLI and MCP interfaces. Its skill helps the agent decide what to inspect, preserve evidence and distinguish a conclusion from an unresolved hypothesis.

That distinction matters more than a long supported-format list. A plausible explanation of an interface is not the same as evidence about how the application implements it. Equally, a code fragment does not necessarily explain what happens in a live session. An investigation should connect the question, the evidence and the limits of the result.

Separate the skill, service and analysis provider

There are three layers to keep straight:

The reviewed SKILL.md explicitly separates skill installation from tool registration. The service and the instructions also need compatible versions. A newer instruction file can describe an operation that an older service does not expose.

For the broader distinction, see Agent Skills vs MCP. Skills describe a procedure; tool access supplies the ability to act. Both are useful, but substituting one for the other creates confusing installation failures.

The directory listing links to the reviewed skill folder. Treat that as a way to inspect the workflow and its supporting references. Read the tool setup instructions before assuming that copying the folder makes an investigation ready to run.

Install REA using the documented setup route

The upstream setup entry point is:

npx rea-agents setup

This is a setup command, not a read-only inspection. Review its proposed configuration changes and any provider installation it offers. The installation guide covers client registration, provider configuration, release availability and recovery.

To install only the investigation instructions, the same guide documents:

npx skills add morluto/rea --skill reverse-engineer-anything

That second command has a narrower purpose. It does not register the MCP server, install analysis engines or add newly configured tools to an already-running agent session. After setup, reconnect or restart the client as its documentation requires, then check what tools are actually available.

Keep the reviewed release and the installed service version in your investigation notes. If you deliberately choose the latest release, read its changes before reusing instructions from this guide. A version label is useful because it turns a vague report such as “REA cannot do this” into a reproducible statement about a particular installation and target.

Do not install every optional provider at the start. Choose the question and target first. The project's connection and recovery reference explains that static JavaScript inspection and ordinary ZIP inventory do not require Hopper or Ghidra. Native decompilation and other specialised operations have their own prerequisites.

Start with a bounded investigation question

A good first task asks for an explanation you can check. For example, you might investigate search behaviour in a small application you own, using a synthetic dataset rather than a real personal library.

The following is an illustrative prompt, not a claim about a tested application:

Investigate how search behaves in this authorised sample application.
Start with static inspection. Ask before launching or instrumenting it.
Separate observed facts, inferences and unanswered questions.
For each conclusion, point to the supporting evidence.
Do not implement a replacement yet.

This prompt separates the investigation from implementation. It also makes runtime interaction a distinct step. If the answer is available from static material, there may be no reason to run the target. If runtime evidence is necessary, the agent should explain which missing fact it would establish.

Write down the decision you want the answer to support. “Can our replacement preserve case-insensitive search?” is easier to validate than “understand search”. The former leads to examples, edge cases and acceptance checks. The latter can produce a long explanation that never resolves a practical question.

Keep a target identifier, version and scope with the findings. An observation from one build should not quietly become a statement about every release. Likewise, a result from a synthetic dataset may reveal a mechanism without establishing performance or behaviour on production-scale data.

Keep observations separate from conclusions

An evidence record needs enough context for a reviewer to understand what it supports. Consider this invented investigation note:

Question: Does search ignore letter case?
Observation: Three synthetic mixed-case queries matched the same item.
Inference: This tested route appears case-insensitive for those inputs.
Unknown: Locale-specific casing and server-side search were not covered.
Next check: Add a separate case for the locale behaviour we need.

The observation is deliberately narrow. It does not claim that every search path behaves the same way. That makes the note useful when it becomes a requirement later: the team knows which behaviour was observed and which still needs a decision.

REA's evidence workflow reference describes evidence identifiers, retained views, explicit unknowns and bounded comparisons. It also distinguishes exhausting a page of retained results from establishing complete coverage of the source. An empty result from a partial inventory is not proof that a feature is absent.

Preserve contradictory evidence. If one route behaves differently from another, the discrepancy is part of the finding. Removing it to produce a cleaner explanation makes the later implementation less reliable. The useful output is a defensible account of the behaviour, including where the evidence disagrees.

Understand the October 6.8 changes in context

The 6.8.0 release highlights retained summaries, additional shipped formats and local agent environments derived from captures or scenarios. These are separate capabilities. None means that an arbitrary application can be fully reconstructed without further work.

For a large investigation, a retained summary can reduce the amount of detail presented at once. The engineering question is whether the reviewer can still trace a claim to the underlying evidence. A concise response is useful when it preserves that route; it is less useful when it drops uncertainty or the conditions under which an observation was made.

The environment reference is the appropriate starting point for capture-derived environments. Keep this distinct from connecting an agent to the original production service. A local environment represents the state and behaviour supported by the available recordings and rules, not every possible response the original service might produce.

When evaluating such an environment, ask what is represented, what is replayed and what remains unavailable. A successful scenario can establish that one path works in that environment. It cannot establish that unrecorded permissions, failures or external integrations are faithfully reproduced.

Add Reconstruction Companion when you need a build plan

REA Reconstruction Companion is a separate project. It helps translate findings into requirements, implementation work and validation. That is useful once you have a reason to build something, but it is unnecessary overhead for every explanation or diagnostic question.

The companion's v1.3.56 instructions allow work from live REA tools or supplied evidence, with the access limits stated. An agent that receives a report should not imply it independently ran the investigation.

Think of the handoff as three decisions. First, which observed behaviours matter to the intended product? Second, which behaviours are deliberate new design choices? Third, how will the implementation be checked? These categories prevent accidental claims of parity and stop the implementation from inheriting irrelevant quirks simply because they were observed.

The installation workflow distinguishes a companion-only installation from optional integration that changes the installed REA instructions. From an inspected release checkout, a preview of the former is:

node install.mjs --client claude-code --integration off --dry-run

Review the preview before applying it. Do not run that command from an unrelated repository and assume the expected installer is present. Keep installer integration, skill-folder installation and future update checks as separate choices.

Troubleshoot the observed failure

“REA does not work” is too broad to choose a repair. Start with the layer that failed:

Avoid reinstalling everything in response to a single unavailable operation. Repeated setup can change working configuration while leaving the actual blocker untouched. The upstream recovery reference maps specific symptoms to different remedies and warns against treating a client timeout as proof that the underlying operation stopped.

Before retrying an operation that could change a target, establish what happened on the first attempt. A missing response does not necessarily mean nothing ran. Preserve the current investigation notes and any available evidence while resolving the connection.

Review the result before implementing from it

Ask a reviewer to trace one important conclusion from the final explanation back to the evidence. They should be able to identify the target, the observation, the inference and any unresolved condition. If that chain is missing, request a narrower conclusion or the missing evidence before using it as a requirement.

Then inspect the proposed implementation checks. A few happy-path examples do not cover cancellation, persistence, permissions, malformed inputs or recovery after failure. Choose those checks from the requirements of your own product. Do not describe them as proving global equivalence with the original application.

Finally, keep local execution and information handling separate. REA's local analysis model does not prevent the surrounding agent from sending derived results to a remote model. The agent skills security guide explains why instructions, executable tools and data access deserve separate review.

For the reusable skill itself, read the SKILL.md format guide. For an investigation, start with one authorised target and one answerable question. That gives you a result you can check before committing to a larger reconstruction.