omnius 1.0.891 → 1.0.893

package/assets/rea/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 morluto
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/assets/rea/UPSTREAM.json

@@ -0,0 +1,43 @@
+{
+  "package": "rea-agents",
+  "version": "6.7.0",
+  "repository": "https://github.com/morluto/rea",
+  "documentation": "https://rea.tools/",
+  "license": "MIT",
+  "tarball": "https://registry.npmjs.org/rea-agents/-/rea-agents-6.7.0.tgz",
+  "integrity": "sha512-yhIx2ioJYYT1C/tONfYeitC6LhnKmCh+ZwRUOgYuhSc733lGhkkt73zhug9WmLgxoMdKuqIYGCoBfD4fXkOhFw==",
+  "files": {
+    "LICENSE": {
+      "bytes": 1064,
+      "sha256": "798f9e4d18e49b30bf2f12696c8ced73dc4e1413da375a333d01281543a1ea8b"
+    },
+    "skills/reverse-engineer-anything/references/android-applications.md": {
+      "bytes": 2125,
+      "sha256": "67a9237d76a5b736640c6404f5e1fe01d83369848142feb7e11d78f4a5e62732"
+    },
+    "skills/reverse-engineer-anything/references/connection-and-recovery.md": {
+      "bytes": 8823,
+      "sha256": "a33760c84ae100f6ffd27d666e515956c5014ac33a6ee2414807833ae666a2b1"
+    },
+    "skills/reverse-engineer-anything/references/evidence-workflows.md": {
+      "bytes": 4363,
+      "sha256": "2bdee98a843d018cf850c706111bb74c459ba8640da00799e9208122e4d5ab80"
+    },
+    "skills/reverse-engineer-anything/references/javascript-applications.md": {
+      "bytes": 11962,
+      "sha256": "aaa78502a3e95268f6269e75f373908045291fedf6ddd106001555ed06bb2bf6"
+    },
+    "skills/reverse-engineer-anything/references/native-and-artifacts.md": {
+      "bytes": 18911,
+      "sha256": "18b8828aec6476be03ca92bdb9506c47cc9ef8c1415c37d33e4af2f8c55cf8f9"
+    },
+    "skills/reverse-engineer-anything/references/runtime-observation.md": {
+      "bytes": 4798,
+      "sha256": "fea85e2005a8fd1c86a946eeede24c20e57592a1deb36576b45216e9854803c8"
+    },
+    "skills/reverse-engineer-anything/SKILL.md": {
+      "bytes": 23523,
+      "sha256": "fbcd39d6abe803cf7aa49c1880815bc8e22ba2af87a23681944f687bb7629eb1"
+    }
+  }
+}

package/assets/rea/skills/manifest.json

@@ -0,0 +1,14 @@
+{
+  "skills": [
+    {
+      "name": "omnius-rea",
+      "description": "Use Omnius's installed REA CLI and optional MCP binding for scoped reverse engineering without an additional setup or npm download.",
+      "triggers": ["REA", "reverse engineer", "decompile", "disassemble", "Electron ASAR", "inspect packaged application"]
+    },
+    {
+      "name": "reverse-engineer-anything",
+      "description": "REA's version-matched investigation guide for native, managed, Electron/JavaScript, packaged, firmware, and browser targets; load omnius-rea for the installed CLI route.",
+      "triggers": ["reverse engineering", "binary analysis", "decompile", "firmware", "ASAR", "recorded runtime evidence"]
+    }
+  ]
+}

package/assets/rea/skills/omnius-rea/SKILL.md

@@ -0,0 +1,61 @@
+---
+name: omnius-rea
+description: Use the REA runtime shipped with Omnius to reverse engineer explicit binaries, packages, Electron/JavaScript apps, firmware, and recorded runtime evidence.
+---
+
+# REA in Omnius
+
+Omnius includes the reviewed `rea-agents` 6.7.0 runtime and its matching
+`reverse-engineer-anything` skill with reference guides. Load that skill for
+target routing, provider requirements, and evidence handling. Use normal
+repository tools for ordinary analysis of available source code.
+
+## Triggers
+
+- reverse engineer an application
+- inspect an executable or packaged application
+- decompile a binary
+- analyze an Electron ASAR
+- REA
+
+## Use the installed runtime
+
+Run `omnius rea status --json` when installation readiness is unknown.
+Commands after `omnius rea` go directly to the installed CLI, preserving every
+argument. No `npx` download, REA setup, global registration, engine installation,
+or inference startup is needed for a supported CLI investigation.
+
+For an explicitly supplied JavaScript tree or ASAR:
+
+```sh
+omnius rea analyze-javascript-application "/absolute/path/to/app" --json
+```
+
+Native analysis uses the operator's existing provider configuration. Missing
+Ghidra, Hopper, Java, IDA, or other engines affects only the routes requiring
+them. Continue supported inspection; never install a provider implicitly.
+
+## MCP only when needed
+
+Use `omnius rea mcp-config` to print the exact installed Node/REA stdio binding.
+This command only prints configuration. It does not alter this client or other
+agents. The same server is available as `omnius rea --mcp`; its stdout belongs to
+the MCP protocol. Omnius does not start the server or inject its entire tool
+catalog into ordinary tasks.
+
+`omnius rea mcp add` and `omnius rea mcp doctor` remain the upstream registration
+and connection-diagnostic commands; their arguments pass through unchanged.
+
+When connecting is useful for the requested task, use Omnius's existing MCP
+configuration/onboarding tools with that exact binding, preserving existing
+servers and credentials. Discover the connected server's actual tools and
+schemas; do not infer connection readiness from an installed skill. CLI
+inspection remains available immediately without registering an MCP server.
+
+## Evidence and scope
+
+Use the user's exact artifact, endpoint, or recorded capture. Static inspection
+does not establish runtime behavior. Preserve evidence identities, file hashes,
+coverage limits, and unknowns. Prefer summaries and retained evidence pages to
+repeating large analyses. Execute an application or browser scenario only when
+that action and target are within the requested investigation.

package/assets/rea/skills/reverse-engineer-anything/SKILL.md

@@ -0,0 +1,356 @@
+---
+name: reverse-engineer-anything
+description: Reverse engineer native, managed, Electron/JavaScript, packaged, firmware, and browser targets with REA. Use shipped-artifact or requested runtime evidence to explain features, compare versions, decompile code, or guide a reconstruction. Skip REA for ordinary source-repository architecture analysis.
+metadata:
+  version: "42"
+  tool_count: 207
+---
+
+# 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.
+
+1. Diagnose without changing REA or client configuration. `npx` may download
+   the package and write to npm's cache. For Codex, run
+   `npx -y rea-agents@6.7.0 doctor --client codex --json`. Substitute the current
+   supported client: `claude_code`, `claude_desktop`, `codex`, `cursor`,
+   `gemini_cli`, `windsurf`, `devin`, `opencode`, `antigravity`, `copilot_cli`,
+   `commandcode`, `vscode`, `grok_build`, `omp`, or `grok_bot`. `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.
+2. Distinguish the reason. Missing, malformed, or stale registration needs a
+   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.
+3. For a configuration repair, prepare the read-only plan:
+   `npx -y rea-agents@6.7.0 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@6.7.0 setup --client codex --yes`. Add `--install-hopper`
+   only if that separate installation was needed and explicitly approved.
+4. Restart/reconnect the affected agent. Verify that REA tools actually appear
+   in the session, then resume the original investigation. If they remain
+   absent, inspect the client's MCP launch error rather than repeating setup.
+
+REA setup never installs or upgrades Node.js, npm, Homebrew, Java, Ghidra, IDA,
+JADX, Kuna, 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:
+
+```bash
+npx -y rea-agents@6.7.0 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.
+Prefer an existing `rea` CLI. When none is installed and REA package acquisition
+is within the authorized scope, use `npx -y rea-agents@6.7.0` 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, Kuna, 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](https://github.com/morluto/rea/blob/main/docs/firmware-analysis.md).
+- .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`.
+- Browser action the agent must perform (click, type, navigate):
+  `capture_browser_scenario` with declared actions. See
+  [runtime observation](references/runtime-observation.md) for connect/launch
+  and the focused follow-up browser tools.
+- Fiddler Everywhere traffic or a native `.saz` capture: read the
+  [Fiddler workflow](references/runtime-observation.md#fiddler-everywhere-traffic-debugging).
+  Inspect saved SAZ with `inspect_web_network_capture` and `format: "saz"`;
+  connect Everywhere's separate MCP server for live traffic.
+- Retained HAR/SAZ/native mitmproxy/aioquic qlog 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](https://github.com/morluto/rea/blob/main/docs/web-network-captures.md) for the exact upstream
+  profile and credential exclusions. Qlog support starts with aioquic 1.5.0
+  JSON 0.3; stream coverage and endpoint loss declarations do not recover bodies
+  or establish network loss. Prefer detail summary, then kind qlog trace/stream
+  pages; select one trace, stream ID and direction for contribution/range pages.
+  Facts retain all-recorded-events-before-selection scope. Other qlog layouts
+  and PCAP correlation are unsupported.
+- User-owned Electron runtime already open: `list_electron_targets`. Before an electron-main Inspector attempt, check packaged fuses with `inspect_electron_fuses`; disabled `EnableNodeCliInspectArguments` means the app ignores `--inspect`.
+- Packet-field discovery: `inspect_packet_fields` searches installed protocols
+  and field names/types before choosing fields for `inspect_packet_capture`.
+  Query/page the relevant records; registrations do not establish observed traffic.
+- Recorded packet captures: `inspect_packet_capture` with selected TShark fields,
+  display filters and decode-as rules. Requires Linux, util-linux prlimit and `REA_TSHARK_COMMAND`; see
+  [capture guide](https://github.com/morluto/rea/blob/main/docs/packet-captures.md).
+  Packet limits count input packets before filtering. Output defaults to 50 matching
+  frames; use `match_offset` / `match_limit` for later pages, or explicit null
+  limit for complete matching output. Preserve the source digest across pages.
+  This does not perform live capture.
+  For address/DNS/SNI/protocol summaries use `inspect_pcap_capture` with MCP
+  detail summary, then retained kind pcap pages. Requires Wireshark 4.x tshark
+  and capinfos, with Linux prlimit or Windows Job Objects; see
+  [packet summaries](https://github.com/morluto/rea/blob/main/docs/pcap-analysis.md).
+  Select an exact DNS question for address pages; page exhaustion does not prove
+  network completeness. This reads recordings and does not acquire traffic.
+- Decoder discovery: `inspect_signal_decoders` searches installed decoder IDs
+  or selected decoder help, including channels and options. Query and page the
+  relevant details before choosing settings; this does not scan hardware.
+- Recorded logic/signal traces: `decode_signal_recording` with explicit decoder,
+  channel and protocol settings. On Linux with util-linux prlimit, supply sigrok-cli 0.7.2 through
+  `REA_SIGROK_COMMAND`; see [recording guide](https://github.com/morluto/rea/blob/main/docs/signal-recordings.md).
+  Output defaults to 50 literal lines; select annotation classes and page with
+  `line_offset` / `line_limit`, or explicit null for all remaining output.
+  Window counts are display lines, not annotations or samples. Preserve source digests across pages.
+  This reads existing files; it does not acquire hardware signals.
+- 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](https://github.com/morluto/rea/blob/main/docs/wasm-artifacts.md).
+- 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. For the complete inferred interface without hex or
+  duplicate stdout, discover support and select `detail: "summary"`; complete
+  Evidence stays retained under its original identity. Use the returned
+  `parent_evidence_id` for exact function or `bytecode_hex`/stdout/stderr pages.
+  Candidate coverage does not establish interface completeness. See the
+  [EVM bytecode guide](https://github.com/morluto/rea/blob/main/docs/evm-bytecode.md).
+- 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](https://github.com/morluto/rea/blob/main/docs/go-binaries.md).
+- Embedded cargo-auditable Rust dependency metadata: `inspect_rust_binary`
+  with the explicit local ELF, PE, or thin Mach-O file. This built-in
+  target-free inspection requires no Rust installation or disassembler. Preserve
+  package order, dependency indices, and the section file range. A missing
+  `.dep-v0` section is null metadata, not proof the binary has no dependencies.
+  A rustc commit hash is an inference from a read-only `/rustc/<40-hex>/` path.
+  See the
+  [Rust binary guide](https://github.com/morluto/rea/blob/main/docs/rust-binaries.md).
+
+- Explicit local SQLite database snapshot: `inspect_sqlite_database`. Inspect
+  with Node.js 24.x >=24.15 or 26+ providing native SQLite limits. Read schema
+  first (compact inventory by default), or select an exact ordinary table
+  and `columns` when rows are needed. Defaults are selected-table schema and
+  20 rows; request `schema_scope: "database"` for the complete stored schema. Preserve both database and existing sibling WAL identity; row samples
+  report truncation and have unspecified order. Use a quiescent snapshot rather
+  than assuming a live database/WAL pair was copied atomically. See the
+  [SQLite guide](https://github.com/morluto/rea/blob/main/docs/sqlite-databases.md).
+- 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](https://github.com/morluto/rea/blob/main/docs/binary-diagnostics.md).
+- 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](https://github.com/morluto/rea/blob/main/docs/recorded-crashes.md).
+- 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](https://github.com/mrexodia/ida-pro-mcp); see the
+[IDA provider guide](https://github.com/morluto/rea/blob/main/docs/ida-provider.md).
+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.
+
+With `REA_KUNA_COMMAND` configured, `provider_id: "kuna"` answers procedure
+lists, lookups, pseudocode, assembly and `analyze_function` from Kuna's cached
+whole-program export. Callers/callees use a separate body-free graph shared by
+the session; `xrefs` returns exact-address incoming sites and filters forwarding
+aliases. These queries and inventory lookups do not trigger a C export. Indirect
+targets remain unknown and can make relationship coverage partial. Reference
+caches expire on close; a fresh CLI process repeats the native reference walk.
+Typed references, CFG, raw-memory tools and annotations remain unsupported. A cold first
+answer can come from a single-function run (its limitations say so); assembly
+waits for the export. For pseudocode and assembly, `raw_result.source` names the
+cached `.c`/`.asm` file and byte span, which you may search directly instead of
+calling per function. See the
+[Kuna provider guide](https://github.com/morluto/rea/blob/main/docs/kuna-provider.md).
+
+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.
+2. 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.
+3. 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.
+4. 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.
+5. 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.
+6. 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.
+7. 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)
+- Browser/Electron observation (passive and scenario) 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.

package/assets/rea/skills/reverse-engineer-anything/references/android-applications.md

@@ -0,0 +1,36 @@
+# Android application artifacts
+
+Use the connected server's advertised Android tools. Repository main and npm
+4.1.0 include this family. A skill installation alone cannot add it to an
+older server.
+
+Start with `inspect_android_package` on the caller's APK path for package
+identity, manifest declarations, coverage, and inline Evidence. Use
+`search_android_classes` to find candidates, `inspect_android_class` for one
+class's members, `inspect_android_method` for decompilation, and
+`trace_android_references` for incoming static references. Each call takes its
+own APK path and explicit selectors; do not open a native session first.
+Choose an `overload_index` from the class inventory when methods are ambiguous
+instead of guessing.
+
+The provider requires a separately supplied headless JADX MCP JAR 0.7.1 and
+Java 17 or newer. `REA_JADX_MCP_JAR` selects the absolute JAR path; `JAVA_HOME`
+can select Java. REA setup does not install or configure that JAR, and doctor
+provider scopes cover Hopper/Ghidra rather than JADX. Use existing tools and
+report missing prerequisites for the Android task specifically.
+
+Linux and macOS use the POSIX owned-process boundary. Windows x64 requires the
+matching bundled native controls and uses an owned Job Object with bidirectional
+stdio. A full JDK, including `jdk.compiler`, is required on every host; Windows
+`JAVA_HOME` selects `bin\java.exe`. Consult the Android guide for actual host
+verification coverage. Calls use one worker and provider deadlines; optional
+`REA_JADX_HEAP_MIB` selects the JVM heap and `REA_JADX_OPERATION_TIMEOUT_MS`
+the per-operation deadline (default 120000 ms; the MCP client's tool timeout
+must also allow it). The APK is never launched,
+and no emulator is required.
+
+Manifest entries and decompiled text are static observations, not execution or
+policy enforcement. Incoming references are recovered static relationships;
+reflection, dynamic loading, and unresolved calls remain unknown. Preserve
+artifact digests, locations, diagnostics, and incomplete coverage. For archive
+members rather than code analysis, use `open_binary` and `inspect_artifact`.