Investigate with REA

Skill re-rea. When and how to use REA (Reverse Engineer Anything, the rea-agents MCP server) alongside GameFrame - quick evidence-backed inspection of binaries, archives, Android/iOS/.NET/Electron/browser targets, focused decompilation and call graphs through Ghidra, and runtime observation. Use for targets the text export does not cover, for a fast first answer about one function, or when a claim needs a citable Evidence record.

Copy this prompt into your coding agent. Replace the part in angle brackets.

In my GameFrame project, use the re-rea skill for <the task>.
Read the skill first and follow its steps in order.
Report the evidence it asks for, with its label: observed, measured, inferred or unknown.

REA (https://github.com/morluto/rea) is an MCP server that gives the agent reverse-engineering tools and records every result as Evidence with an ID, coverage and limits. Its own skill, reverse-engineer-anything, documents each tool in detail: install it with REA's setup (re-setup) and read it before a large REA investigation. This skill says how REA fits into the playbook's loop.

REA or the text export?

Use REA (mcp__rea__*) when	Use GameFrame's Ghidra export (re-ghidra) when
The target is not a plain native binary: an APK/IPA, a .NET assembly, an Electron app or ASAR, a browser page, firmware, an archive	You need to search the whole program as text, many times (grep is instant)
You want a quick, cited answer about one function: open_binary then analyze_function, procedure_callers, xrefs	You trace a system across hundreds of functions over several sessions
You need a call path between two functions (build_call_path, trace_call_path)	You need decomp_query.py with your labels applied
You need runtime evidence from a running browser or Electron app (observe_web_session, capture_browser_scenario)	You emulate functions (re-emulate): REA does not replace the Unicorn harness
You compare two versions of an application (compare_application_versions, find_changed_behavior)
A finding must carry a citable Evidence ID in a report

They agree because both read the same binary through Ghidra; addresses match. Use both: REA for targeted questions and evidence, the export for broad search.

The workflow

1. Route by target (from REA's skill): a native EXE/DLL → open_binary with the path; an archive or package → open_binary then inspect_artifact; .NET → inspect_managed_artifact; Android → inspect_android_package; extracted JavaScript or ASAR → analyze_javascript_application; Windows resources and icons → inspect_pe_resources.
2. Start with a summary (binary_overview when available), then ask focused questions: search_strings, search_procedures, analyze_function, procedure_callers, procedure_callees, xrefs, procedure_pseudo_code.
3. Name what you learn in the session: set_address_name and set_comment keep labels in REA's database; also copy each label into labels/names.tsv so GameFrame's tools see it.
4. Keep the Evidence IDs in your notes; cite them in the finding's document next to the address ("observed: FUN_1400be770 writes +0x44 (REA evidence ev_...)").
5. Close native sessions with close_binary when done.

Rules that carry over

• REA's evidence labels match ours: observations, inferences and unknowns stay separate; static analysis never proves run-time behaviour.
• Do not repeat an identical REA call; page large results with inspect_analysis_view instead.
• REA's runtime tools run the target: run them on the target the user chose, with their agreement. A game's online service belongs to someone else; if the user points REA at one, mention its terms once, then follow the user's decision.
• Decompiled output from REA is still decompiled code: it stays out of tracked files.

When REA is not connected

No mcp__rea__* tools in the session means the MCP server is not registered or did not start. Follow re-setup section 3. Meanwhile, continue with GameFrame's own tools: Ghidra export, decomp_query.py, ghidra-run.sh and the emulator cover native binaries completely.