The viral Reverse Engineer Anything repo: what it installs, the five-step method he uses, and why to label findings seen, inferred or unknown

What the project is, per its README

The REA repository describes an MCP tool set for reverse engineering: "one MCP for reverse engineering across binaries, applications, and runtime behavior". Your agent calls it to inspect a target and trace relevant code, and results "include the evidence and limitations behind each conclusion".

npx rea-agents setup                 # registers REA with your agent and installs workflow instructions
npm install --global rea-agents      # installs the rea command
npx -y rea-agents@latest analyze-javascript-application /absolute/path/to/app --json

Supported targets include native binaries (through Hopper, Ghidra or IDA), Go and Rust binaries, WebAssembly, JavaScript and Electron apps, websites, .NET assemblies, Android APKs, firmware and packet captures, each with its own prerequisites. Similarly named repositories exist, so check you have this one.

His five steps

1. Pick a feature, not the whole app. "Go reverse engineer Loom" is too broad; "how does Loom's camera bubble move and resize while recording" works.
2. Route by build. What the app is built with decides which tools the agent should use, so tell the agent the tech stack.
3. Summary first. The raw analysis of one app ran over a gigabyte, so it is distilled into a short summary of what works, how, and what couldn't be worked out. Keep and reuse it rather than re-running analysis.
4. Label findings seen, inferred or unknown. Seen means found and cited; inferred means the code or data points that way but it is a guess; unknown means it couldn't be seen. Don't build on inferred items as if they were fact.
5. Rebuild and test. Build your own version, run test cases and iterate until behaviour matches, rather than shipping once it looks done.

The README does not describe these five steps or the seen, inferred and unknown labels in those words, so treat them as his working method and check the installed skill's instructions.

The wider idea: reverse engineer the output

• He built an Instagram Reels editing skill by having the agent analyse about 30 of his best Reels frame by frame, then used the same approach on a motion-design video someone else made. Opus alone couldn't have invented that design; shown it, it could reproduce much of it.
• The same applies to documents: for a Friday report skill, have it study five good reports.
• His Loom-style recorder cloned the functionality (movable, resizable camera bubble, countdown, window choice) rather than the look, and stores files locally.
• In a side test, the agent that used the repo finished later but with better results.
• A model you have already paid to analyse can sometimes be followed by a cheaper one to build, since the findings already exist.

Gotchas & Caveats

• Authorization. The README says REA is for "analysis of software you own or are authorized to examine", and that commercial tools such as IDA Pro, Hopper and JEB need their own licences.
• Don't copy code or assets. His own advice is to recreate behaviour, not code, and to stay within what you can legitimately inspect.
• Data policy. REA analyses locally, but your agent's model provider has its own data policy.
• Results depend on the model doing the analysis; the repo doesn't make a weak model build everything.

Key Takeaways

• Install with npx rea-agents setup, then point the agent at one feature at a time.
• Keep a short summary, and label every finding seen, inferred or unknown.
• Use it only on software you're allowed to inspect, and rebuild functionality rather than copying.