REA

Use REA when a claim depends on a shipped binary or package, decompilation,

passive application runtime evidence, or comparison with

behavior not established by available source. For ordinary analysis of a

complete source repository, use normal repository tools and do not run REA

readiness or provider commands.

Connect only when needed

Installing this skill supplies instructions; it does not register the REA MCP

server, install analysis engines, or add tools to an already-running agent.

If REA tools are available and their registration is not known to be stale,

proceed directly to the target. Do not run diagnostics or setup before every

investigation. Use the connected server's actual tool list and input schemas;

a skill installed from repository main may describe capabilities absent from

an older npm release. Keep complete inline Evidence when that server does not

advertise retained references.

If tools are absent, a call is blocked by the client, or a required provider is

unavailable, read [connection and recovery](references/connection-and-recovery.md).

Diagnose the observed blocker, continue useful supported work, and resume the

original task after repair. Client approval, shell PATH, registration and engine

availability have different remedies; avoid repeating setup for all of them.

Prefer an existing rea CLI. When none is installed and REA package acquisition

is within the authorized scope, use npx -y rea-agents@latest in its place.

Configuration repair starts with a read-only setup plan; show paths, backups and

skill replacement before applying authorized changes. Preserve existing approval

and target-execution boundaries. REA setup never installs or upgrades unrelated

software, including Node.js, npm, Homebrew, Java, Ghidra, IDA, JADX, Binwalk or Unblob.

Route the target first

Choose the first tool from the target the user supplied. Use open_binary for

active-target native or archive workflows; target-free tools take their own

explicit path or endpoint and do not need it.

• ASAR or extracted JavaScript/Electron tree:

analyze_javascript_application.

• Archive/package member inventory (ZIP/APK/IPA/MSIX/AppX or DMG):

open_binary with the supplied local path; use inspect_artifact when its

graph and findings help answer the question.

• Android APK code, classes, methods, or incoming references:

inspect_android_package, then focused Android tools when advertised.

Archive member inventory still uses the archive route above.

• Managed PE/CLI assembly: inspect_managed_artifact.
• Firmware image: inspect_firmware_regions when advertised. Use

extract_firmware when extraction is requested, with a caller-selected new

absolute output directory. These tools use caller-supplied Binwalk/Unblob on

Linux; see the firmware guide.

• .NET NativeAOT PE/ELF: native Ghidra analysis. Native code can yield pseudocode;

consult the NativeAOT workflow in references/native-and-artifacts.md for

optional metadata recovery and its supported host/layout boundary.

• User-owned browser page already open: list_browser_targets.
• Retained HAR/native mitmproxy capture: inspect_web_network_capture. Select

original record ordinals when useful; inspect producer fields and byte/number

sidecars without fetching recorded URLs or claiming live attribution. See

historical captures for the exact upstream

profile and credential exclusions.

• User-owned Electron runtime already open: list_electron_targets.
• Explicit local WebAssembly artifact: inspect_wasm_artifact. Supply WABT 1.0.42

through REA_WABT_BIN_DIRECTORY; retain exact byte/tool identity and decoded WAT.

Select JavaScript glue and candidate paths explicitly and preserve URL/path

ambiguity. No implicit fetch or target execution; WAT is not original source.

See the WASM guide.

• Explicit local EVM bytecode carrier: inspect_evm_interface with caller-selected

raw or hex encoding. Preserve carrier/decoded digests and treat selectors,

argument strings and mutability as inferred candidates; this performs no chain

lookup or target execution. See the

EVM bytecode guide.

• Embedded Go compiler, module or build-setting metadata: inspect_go_binary

with the explicit local file. This built-in target-free inspection requires no

Go installation or disassembler. Preserve raw module bytes and source ranges;

absent metadata does not prove a binary is not Go, and unparsed text records

remain explicit. See the

Go binary guide.

• Explicit Linux ELF file for offline layout, symbols, relocations or static

mitigation evidence: inspect_binary_layout. This target-free operation uses

caller-supplied pwntools without opening a disassembler database. Preserve its

raw locations and inference/coverage limits; see the

offline binary guide.

• Supplied Linux x86-64 ELF core: inspect_recorded_crash. Read every recorded

thread, raw note and source-bound register without opening a live target.

Historical PIDs do not select live processes. Request include_debugger_context

only when core-only mapping candidates help; see the

recorded crash guide.

• PE resource type/name/language trees and static icon group references:

inspect_pe_resources with an explicit path. This portable operation requires

no active target or engine; opaque payloads retain file ranges and SHA-256.

• Native executable, library, or analysis database: open_binary, then

use focused analysis tools directly; call binary_overview when metadata or

inventory context is useful and available from the selected provider.

For an existing IDA MCP configuration, use open_binary with the original

input binary and provider_id: "ida"; do not pass an .idb or .i64 database.

The legacy attached profile binds the already-open GUI input by SHA-256 and

leaves its database open. The modern headless profile creates and closes an

owned private database without saving. Installation and registration reuse

mrexodia/ida-pro-mcp; see the

IDA provider guide.

Proceed directly to analyze_function, pseudocode, or function/string searches

after opening; IDA does not supply binary_overview. Consult session availability

when composing broader workflows. Modern direct callers and unsupported dossier

facets remain unknown; live IDA results are not replayed from snapshots.

If the user says only "my app" without a name, path, or target already selected

for this task, ask which app before searching for artifacts. Paths in unrelated

saved reports and nearby test fixtures do not select the user's target. Resolve

an actual human-readable app name to one clear installed artifact when possible;

ask when matches are ambiguous. Never choose an example app on the user's behalf.

In a target-free session, use open_binary to bind any archive/package or

native target whose analysis tool operates on the active target. Do not call an

unadvertised tool; inspect binary_session with {} and its

result.tool_availability for availability reasons and remediation. Expand each

group's names into entries, inheriting the inventory-level client requirements

unless the group overrides them. In its closed effect and annotation vocabularies,

listed flags are true and omitted known flags are false. The grouped name union

is the complete tool inventory; use tools/list for canonical tool schemas.

Provider candidate facts describe possible providers, while top-level session

capabilities describe the current route and analysis_provider_binding names the

selected provider. Do not treat those scopes as interchangeable.

Work summary-first

Start with the default result and use its inline Evidence and graph context.

For a JavaScript application or ELF layout whose size is unknown or large,

call analyze_javascript_application or inspect_binary_layout with

"detail": "summary", then inspect the retained parent_evidence_id with

inspect_analysis_view.

Page module identities and select the returned node_id before requesting an

item; a single file path can represent several graph roles. Do not repeat an

identical analysis or rejected call without a changed input or resolved blocker.

Recheck session state when a lifecycle change makes that status useful.

Make a focused follow-up only when the

returned result leaves a specific question unanswered.

If MCP reports resource_constraint with details.resource: "transport", call

inspect_analysis_view with its reported same-session Evidence reference for a

summary, one section/module, or a stable page. Use trace_application_feature

once a seed is known, or call export_evidence_bundle to write the complete

session to a selected path. The analysis remains complete in the ledger; avoid

repeating it merely to request the same oversized response. Complete CLI JSON

output also streams without a single MCP frame.

When the retained parent ID is unknown, use get_evidence_bundle with

detail: "summary" and exact filters for operation, target SHA-256,

analysis-profile digest or canonical procedure address. Select its returned

Evidence ID for the next view instead of requesting the complete bundle.

retention: "complete-record" means the whole record is stored; native

value-flow truncation and unknown metadata remain separate. For an exported

portable bundle, use rea inspect-evidence-bundle with JSON containing path,

detail: "summary" and the same filters. Reading that file still requires

validating its full contents within the local memory budget.

A client can also truncate a successful tool result without a REA transport

error. Treat that preview as incomplete; use the retained parent ID for smaller

views or export when the full record is needed. Do not parse the preview as

canonical JSON or repeat the producer. For JavaScript, read the

[module-view and trace recipes](references/javascript-applications.md) before

drilling into a large graph; a broad bidirectional trace can expand unrelated

containment relationships even after summary analysis.

Every conclusion must distinguish observations, inferences, and unknowns. Cite

Evidence IDs, preserve limitations and incomplete coverage, and never imply

that static analysis observed execution. Runtime requests execute the declared

target and lifecycle; do not broaden the target or action beyond those fields.

Within the user's requested investigation, call available analysis tools

directly. REA does not require permission grants or per-call approval flags.

The agent client can independently require approval. Follow the declared request

scope and the host's actual access requirements; use the recovery guide for an

observed client-policy rejection.

Plan broader investigations

For requests that span multiple features or subsystems, use a staged workflow:

1. Turn the request into a checklist of questions and the evidence each answer

needs. Resolve target identity and constraints from the conversation and

workspace before asking for information again.

1. Inspect the current REA session, artifact identity, saved analysis database,

bookmarks, and prior evidence. Reuse matching state; do not open duplicate

sessions or repeat identical analysis.

1. Start with the smallest useful overview or inventory. Follow each question

from its entry point through relevant data and state changes to its result.

Batch related operations around a specific hypothesis, then expand only when

the returned evidence leaves a concrete gap.

1. Inspect relevant packaged resources and configuration alongside code when

they affect the question. Use format-aware inventory and parsers; do not

infer behavior from filenames, strings, or layout alone.

1. Corroborate a conclusion with the evidence type it requires. Use runtime

observation only when static evidence cannot answer the question and the

required host runtime and OS access are available. For JavaScript behavior,

run probes against the actual app through the available browser, Electron,

or process capture workflow.

1. Decompose work into independent questions. When parallel workers are

available and the questions do not depend on one another, assign distinct

scopes, point workers to existing evidence, and ask them to return sources,

conclusions, and unresolved gaps. Otherwise, work sequentially.

1. Keep a concise finding ledger linking each conclusion to Evidence IDs,

confidence/evidence type, search boundary, and remaining unknowns. Update

the shared index or investigation report so later passes can reuse results.

Before finishing, revisit the original checklist. Mark each question as

answered, partially answered, or unresolved based on its evidence; keep

bounded negative searches bounded, and do not describe a broad investigation

as complete while required questions remain open.

Read only the relevant guide

• Native binaries, managed assemblies, archives, and extraction:

[references/native-and-artifacts.md](references/native-and-artifacts.md)

• ASARs, extracted JavaScript, feature tracing, and version comparison:

[references/javascript-applications.md](references/javascript-applications.md)

• Android APK declarations, classes, methods, and static references:

[references/android-applications.md](references/android-applications.md)

• Passive browser/Electron observation and static/runtime reconciliation:

[references/runtime-observation.md](references/runtime-observation.md)

• Evidence paging, comparisons, residual unknowns, and verification:

[references/evidence-workflows.md](references/evidence-workflows.md)

Finish the task

Explain findings in plain language and tie them to returned evidence. When the

user asks to build something, use normal coding tools and separate observed

behavior from design choices. Close an opened native session with

close_binary when the investigation is complete.