REA

REA is investigation guidance for claims that depend on a shipped application, binary, package or runtime evidence. It covers decompilation, evidence-backed feature traces, version comparisons and investigation-guided reconstruction. The skill tells you how to route a target to the right analysis tool, how to work summary-first, and how to report what was actually seen.

Every conclusion has to separate observations, inferences and unknowns. Findings cite Evidence IDs, keep limitations and incomplete coverage visible, and never imply that static analysis observed execution. For broad requests the skill prescribes a staged workflow: turn the request into a checklist of questions, reuse existing sessions and prior evidence, start with the smallest useful overview, corroborate with the evidence type each answer needs, and keep a finding ledger that links each conclusion to its Evidence, confidence, search boundary and remaining unknowns. Before finishing, each question is marked answered, partially answered or unresolved.

Use it when a claim depends on a shipped binary or package, decompilation, passive application runtime evidence, or behavior that available source cannot establish. Skip it for ordinary analysis of a complete source repository: there, use normal repository tools and do not run REA readiness or provider commands.

The skill supplies guidance only. It does not register the REA MCP server or install analysis engines. Static analysis does not establish runtime behavior or recover original source code. Native-analysis availability depends on the selected provider, host and target format; Hopper is separate licensed software, and Ghidra and IDA are bring-your-own. REA runs analysis locally, but the connected model provider may have separate data-handling policies.

The input is a target you supply: an ASAR or extracted JavaScript tree, an archive or package (ZIP, APK, IPA, MSIX, AppX, DMG), an Android package, a managed PE/CLI assembly, a firmware image, a native executable or library, a retained HAR or mitmproxy capture, a recorded Linux core file, an EVM bytecode carrier, or a browser page or Electron runtime you already have open. The skill routes each to a first tool, for example analyze_javascript_application for JavaScript trees, inspect_android_package for APK code, inspect_managed_artifact for managed assemblies, and open_binary for native targets and archive member inventory.

The output is a plain-language explanation tied to returned Evidence, with a clear split between observed behavior, inference and unknowns. If a large result hits a transport limit, you page through it with inspect_analysis_view or export the full session with export_evidence_bundle. If the app is missing, the skill asks which app to inspect and never picks an example for you. Open native sessions are closed with close_binary when you finish.

REA works through its MCP server, with registration supported for clients including Cursor, Gemini CLI, Windsurf, VS Code and many other coding clients. When tools are missing or stale, the skill walks through a read-only diagnosis with the doctor command, a dry-run setup plan with exact paths and backups, approval, and a restart. Native analysis can use Hopper, Ghidra or IDA; Android inspection has its own bring-your-own JADX and Java prerequisites; firmware work uses caller-supplied Binwalk or Unblob on Linux. Setup never installs Node.js, npm, Homebrew, Java, Ghidra, IDA, JADX, Binwalk or Unblob.

When no MCP registration is available, a CLI fallback handles a JavaScript tree or ASAR without any native engine:

npx -y rea-agents@latest analyze-javascript-application /absolute/path/to/app --json

The CLI returns the Evidence record directly; this fallback does not show that MCP is configured.

Security researchers, developers and analysts who need to explain what a shipped application does, compare versions, trace a feature, or reconstruct behavior when source is unavailable, and who want conclusions they can defend with cited evidence rather than guesses.