How to Reverse Engineer Anything with Opus 5.5

`Want to access all premium content?`

Become a paying subscriber to get access to all courses, guides like this, prompts and skills library, and $500+ worth of AI tools.

Upgrade to Paid

REA is a free, open-source tool that helps coding agents inspect software. Ask what a button does, and it follows the relevant code, shows the evidence, and identifies what it couldn't confirm.

This guide starts with JavaScript apps, which don't require a disassembler. Along the way you'll trace one feature, test its behavior, and write a plain-language spec. You'll need Claude Code with Opus 5.5, a supported Node.js version, and a Mac with Terminal.

Step 1: Check Node. Make sure your version is supported.

Step 2: Install REA. Connect it to Claude Code.

Step 3: Trace a button. Follow a click through the practice app.

Step 4: Test the prediction. Compare Claude's explanation with the Node.js output.

Step 5: Inspect your app. Apply the same process to another feature.

Step 1: Check Node

REA installs through npm, so check Node.js first:

node -v

Supported versions are 22.19 or later in the 22 release line, 24.11 or later in the 24 line, and 26 or later.

If Terminal can't find the command, or your version falls outside those ranges, install a supported version from nodejs.org. Open a new Terminal window and check again.

To open Terminal, press Command + Space and search for it.

Step 2: Install REA

Create a test folder:

mkdir -p ~/Desktop/rea-test && cd ~/Desktop/rea-test

Run setup:

npx rea-agents@latest setup

Choose Claude Code, read the proposed changes, and approve them. Setup backs up your existing configuration before making changes.

Start a fresh Claude Code session in the same folder:

claude

Open the model picker and choose Opus 5.5:

/model

Check that REA is available:

List the REA tools available in this session by name.

If none appear, run /mcp and check whether rea is connected. Restart Claude Code if needed.

You can also check from Terminal with claude mcp list and look for a line that starts with rea. If it is missing, setup did not finish for Claude Code, so run npx rea-agents@latest setup again and approve the plan.

The supplied setup notes also include this read-only diagnostic command; its flags still need checking on your device:

npx -y rea-agents@latest doctor --client claude_code --json

Step 3: Trace a button

Start with the REA team's practice app and its Export notes button.

Download https://rea.tools/examples/notes-example.zip into a new example folder and unpack it.

Use REA to trace what happens when I click Export notes.

Show where notes.csv is saved, which fields it contains, and the relevant files and line numbers.

If Claude can't download it, use your browser, unzip the file, and provide the folder path.

Expect a chain of four files. The page handles the click, the bridge passes a notes:export message, the main process chooses the destination, and a helper formats the CSV. Allow a few minutes and several tool calls for the trace.

The file should be saved as notes.csv in Downloads with two columns: id and title.

Check that Claude shows the handler and formatter lines supporting its explanation. Ask for any missing evidence. Line numbers matter here, because they let you open the file and check the claim yourself.

Step 4: Test the prediction

Reading the code suggests what should happen. Running a test checks that explanation for a specific input.

Predict the CSV output for a note with id 1 and title Hello, "REA".

Then run the example's toCsv formatter with Node.js.

Show the prediction and the Node.js output side by side.

The comma means the title needs a quoted field, and the quotation marks inside it should be doubled:

id,title
1,"Hello, ""REA"""

Compare the Node.js output with the prediction. If they differ, ask Claude to explain why using the formatter's code. A match on one input is a start, so try a second title with a comma and no quotation marks.

Step 5: Inspect your app

Try an app you built or the fictional taskbox app from the kit. It uses a similar structure: a page, a bridge, a main process, and a storage helper.

Check the app's license and your permission to inspect it before starting. Pick one button, one export or one rule, and ask about only that feature.

Use REA to inspect the taskbox folder. Trace what happens when I click Archive done tasks.

Show the relevant files and lines. Label each claim observed, inferred, or unknown, and list what you couldn't confirm.

Read the unknowns first. They show where more evidence or testing is needed. Save the list, since it becomes your test plan for the next round.

For an installed Electron app, JavaScript code is often packaged in app.asar inside its Resources folder. Give Claude the app's name and ask it to locate the package.

Use cases

Use case #1: Find saved files

Locate the destination and contents of an export or backup.

Use REA to trace Backup tasks. Find its output folder, filename, and saved fields. Show the supporting files and lines.

Compare the answer with the code and, where practical, a test export.

Use case #2: Uncover a rule

Find the condition behind behavior the interface doesn't explain.

Find the rule used by Archive done tasks.

Quote the condition with its file and line number. Predict what happens to a task completed three days ago and one completed ten days ago.

Then ask Claude to run the function with both inputs and compare the results.

Use case #3: Inspect outgoing requests

Find network requests visible in the app's code.

Use REA to identify the web addresses taskbox contacts.

For each, show the file, line, and data sent. Flag dynamically built addresses or requests you couldn't fully resolve.

Check the evidence for each request. A code search alone may not reveal every address contacted at runtime.

Use case #4: Build from a spec

Turn the observed behavior into a description another developer could work from.

Write a one-page spec for Archive done tasks covering inputs, rules, outputs, and edge cases.

Use plain language without copying code from the app. Mark unconfirmed details as unknown. Save it as spec.md.

Open a fresh Claude Code session in a new folder containing only spec.md:

Read spec.md and build the archiver it describes. Don't inspect other folders.

Test the three-day and ten-day examples against the new version. Matching results confirm those cases; add tests for the other rules and edge cases in the spec.

Confirmed limitations

REA can inspect local program files, but those files don't reveal what happens inside a remote server.

Minified or compiled code can lose names and comments. Treat explanations as provisional until the evidence and tests support them.

Native software may need a disassembler such as Ghidra, Hopper, or IDA. That adds setup, and some tools require paid licenses. This guide stays with JavaScript.

Use REA for software you're authorized to examine and follow its stated terms for research, education, interoperability, and preservation. Keep copied code and assets out of the implementation built from your spec.

Claude Code sends the code it reads to its model, so keep private code out of test runs.

REA is free and open source. You'll still need access to Claude Code and Opus 5.5.

Closing

Start with the practice app and compare the predicted CSV with the Node.js output. That gives you a small, checkable example before you inspect a larger program.

Then trace one feature in an app you built. Keep the evidence, record the unknowns, and write the spec before starting a new implementation.

See you in the next one :)