Reverse Engineer Anything: Use REA to Trace One App Feature

Select a local sample application you own or an open-source example with clear reuse terms. Define the behavior before collecting a large amount of output. “Explain the filename produced when I export two images with the same title” is a more testable question than “rebuild this editor.” Keep unrelated assets and account data outside the sample.

• Official REA repository and target requirements

The current repository specifies Node.js 22.x from 22.19, 24.x from 24.11, or 26 and later, plus npm. Static JavaScript analysis does not require a native decompiler. On Linux, the current instructions also require a procps-compatible ps for ownership checks. Requirements differ for other target types, so use the section matching your task.

npx rea-agents@latest setup

This is the documented interactive setup command, not a command executed for this guide. Setup offers agent integrations and previews configuration changes; the installation guide distinguishes npm’s package-download prompt from approval of REA’s own setup plan. Inspect the proposed paths, select the intended agent, and restart it after setup completes.

Record the installed package version with the analysis. The repository’s main branch can describe work newer than the published package. If a documented command is missing, check the installed release before changing the target or adding another analysis engine. Preserve the setup record so a colleague can reproduce the same environment.

• REA installation, version boundaries, and setup

REA’s official JavaScript guide illustrates an Electron export crossing renderer, preload, and main-process boundaries. Its static result pairs a literal IPC invocation with a matching handler and supplies source locations. Computed channel names or ambiguous handlers can remain unresolved. The example’s own findings are not evidence about a different application.

For your asset tool, begin at the observed Export button. Ask which handler receives the action, which values it passes, and where the destination filename is assembled. Follow the data until it reaches the write operation. If the final step is a remote request, record that boundary instead of inventing a server-side implementation.

Inspect the sample application at /absolute/path/to/my-asset-tool.
Trace how Export names a PNG when two assets have the same title.
For each finding, cite the file and function that supports it.
Separate code-derived conclusions from observed runtime behavior.
List unresolved branches and propose the smallest verification case.
Do not modify the application during the investigation.

Save the target version and file digest with the cited locations. A line number without a version can point at a different function after an update. Keep the original output and your short explanation together, but do not mistake a large analysis report for proof that the specific export branch has been traced.

• Official Electron analysis example

Use a separate copy of the sample and a disposable export directory for runtime checks. Start with two distinct titles, then two identical titles. Inspect both filenames and file contents: a UI message reporting two exports could hide one overwritten file. Add a title with punctuation and a deliberately unavailable destination to expose assumptions about naming and failure handling.

When observation disagrees with the static explanation, revise the explanation. The running app may use another branch, configuration, or library version. Mark the conflict explicitly and reduce the case until one variable explains it. Do not resolve it by asking the agent to write a more confident summary.

Only then write a behavior specification for your own implementation. Describe inputs, outputs, collision handling, and errors in your own terms. Decide which behavior is desirable for your product rather than copying every accident of the sample. Keep source observations separate from design decisions so future changes remain understandable.

REA is not an SJolt model or a native SJolt analysis endpoint. If you are building your own asset manager, SJolt can supply a separate generation stage: Nano Banana 2.1 supports text-to-image and reference-guided image editing. The naming and export logic belongs in your application after the task completes.

For an offline prototype, use a small fixture manifest containing invented task IDs and local sample filenames. Test the collision rules against those fixtures before making any generation request. A task that is still running should remain pending; it should not become an empty image file or trigger an automatic duplicate paid submission.

When connecting the documented API later, retain the returned task ID, query its status, and consume successful data.output_urls. Save the chosen image under your own stable asset ID and keep the display title separately. Test missing downloads and repeated completion handling with fixtures as well. This produces an original, reviewable media tool without claiming REA supplies a generation backend or an automatic application clone.

• SJolt Nano Banana 2.1 API
• Generation and task-status guide
• Current pricing