reverse-engineer-anything skill

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.

When tools are absent or registration is stale:

npx -y rea-agents@latest doctor --client codex --json. Substitute the current supported client: claudecode, claudedesktop, codex, cursor, geminicli, windsurf, devin, opencode, antigravity, copilotcli, commandcode, vscode, grokbuild, omp, or grokbot. grok_bot has no local file registration: doctor reports the Grok Bot chat step, and setup does not write mcp.json. If the client is unknown, use doctor --json and inspect its registration results before choosing a setup scope.

1. Diagnose without changing files. For Codex, run

scoped configuration repair. An aligned registration with no tools in the active session needs a restart/reconnection; doctor cannot prove that the current agent has connected. A missing provider affects only tasks requiring that provider: static JavaScript inspection needs neither Hopper nor Ghidra, and Android inspection has separate bring-your-own JADX/Java prerequisites.

1. Distinguish the reason. Missing, malformed, or stale registration needs a

npx -y rea-agents@latest setup --client codex --dry-run --json. Use the current client's ID, show its exact proposed paths, backups, and changes, and obtain approval before setup writes configuration or installs Hopper. Setup normally installs the matching bundled skill too; include that replacement in the reviewed plan. After approval, apply the same scope with npx -y rea-agents@latest setup --client codex --yes. Add --install-hopper only if that separate installation was needed and explicitly approved.

1. For a configuration repair, prepare the read-only plan:

in the session, then resume the original investigation. If they remain absent, inspect the client's MCP launch error rather than repeating setup.

1. Restart/reconnect the affected agent. Verify that REA tools actually appear

REA setup never installs or upgrades Node.js, npm, Homebrew, Java, Ghidra, IDA, JADX, Binwalk, or Unblob. Use existing prerequisites; do not install unrelated software to repair MCP registration. For an unsupported client, use manual stdio registration with a version-pinned rea-agents package or continue through the CLI.

A concrete CLI fallback for an operator-supplied JavaScript tree or ASAR is:

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

No MCP registration or native engine is required. Read the returned Evidence, graph, limitations, and unknowns with the same care as an MCP result; the CLI returns the Evidence record directly. This fallback does not establish that MCP is configured. Native CLI tasks still require their selected engine.

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.

analyzejavascriptapplication.

• ASAR or extracted JavaScript/Electron tree:

openbinary with the supplied local path; use inspectartifact when its graph and findings help answer the question.

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

inspectandroidpackage, then focused Android tools when advertised. Archive member inventory still uses the archive route above.

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

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.

• Managed PE/CLI assembly: inspectmanagedartifact.
• Firmware image: inspectfirmwareregions when advertised. Use

consult the NativeAOT workflow in references/native-and-artifacts.md for optional metadata recovery and its supported host/layout boundary.

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

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 browser page already open: listbrowsertargets.
• Retained HAR/native mitmproxy capture: inspectwebnetwork_capture. Select

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.

• User-owned Electron runtime already open: listelectrontargets.
• Explicit local EVM bytecode carrier: inspectevminterface with caller-selected

mitigation evidence: inspectbinarylayout. 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.

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

thread, raw note and source-bound register without opening a live target. Historical PIDs do not select live processes. Request includedebuggercontext only when core-only mapping candidates help; see the recorded crash guide.

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

use focused analysis tools directly; call binary_overview when metadata or inventory context is useful and available from the selected provider.

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

For an existing IDA MCP configuration, use openbinary with the original input binary and providerid: "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 analyzefunction, pseudocode, or function/string searches after opening; IDA does not supply binaryoverview. 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 app is missing, ask which app to inspect. Resolve a human-readable app name to one clear installed artifact when possible; ask only when matches are ambiguous. Never choose an example app on the user's behalf.

In a target-free session, use openbinary to bind any archive/package or native target whose analysis tool operates on the active target. Do not call an unadvertised tool; inspect binarysession with {} and its result.tool_availability for availability reasons and remediation. The tool list stays complete; availability depends on the operation, target, and host.

Work summary-first

Start with the default result and use its inline Evidence and graph context. Do not repeat an identical tool call. Make a focused follow-up only when the returned result leaves a specific question unanswered.

If MCP reports resourceconstraint with details.resource: "transport", call inspectanalysisview with its reported same-session Evidence reference for a summary, one section/module, or a stable page. Use traceapplicationfeature once a seed is known, or call exportevidence_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.

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. Follow the declared request scope and the host's actual access requirements.

Plan broader investigations

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

needs. Resolve target identity and constraints from the conversation and workspace before asking for information again.

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

bookmarks, and prior evidence. Reuse matching state; do not open duplicate sessions or repeat identical analysis.

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

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. Start with the smallest useful overview or inventory. Follow each question

they affect the question. Use format-aware inventory and parsers; do not infer behavior from filenames, strings, or layout alone.

1. Inspect relevant packaged resources and configuration alongside code when

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. Corroborate a conclusion with the evidence type it requires. Use runtime