opencode-skills-collection 4.1.10 → 4.1.12

package/bundled-skills/jet-browser/SKILL.md

@@ -0,0 +1,155 @@
+---
+name: jet-browser
+description: "Verify or integrate Jet Browser when a project needs isolated WPE WebKit sessions, native input, screenshots, ordered JSONL automation, or reproducible runtime checks."
+category: browser-automation
+risk: critical
+source: "https://github.com/masakaai/jet-browser"
+source_repo: masakaai/jet-browser
+source_type: official
+date_added: "2026-10-09"
+author: masakaai
+tags: [browser, wpe-webkit, automation, docker, jsonl, testing]
+tools: [claude, codex]
+license: Apache-2.0
+license_source: "https://github.com/masakaai/jet-browser/blob/v0.6.7/LICENSE"
+---
+
+# Jet Browser
+
+## Overview
+
+Use Jet Browser as a replaceable browser-runtime boundary for an agent or deterministic test runner. It runs one isolated WPE WebKit session per container and exposes ordered JSONL commands for navigation, native input, semantic inspection, screenshots, and cleanup.
+
+Keep model selection, reasoning, credentials, and orchestration in the calling project. Jet Browser is a browser runtime, not an agent framework, hosted proxy network, anti-bot service, or bridge to a user's personal Chrome profile.
+
+## When to Use This Skill
+
+- Use when a project needs a self-hosted browser process with an explicit container lifecycle.
+- Use when a harness needs framework-neutral, ordered JSONL instead of a bundled agent loop.
+- Use when native pointer, keyboard, touch, DOM, and screenshot evidence should share one runtime.
+- Use when a repository needs a reproducible offline smoke test or GitHub Actions browser-runtime check.
+- Do not use this skill to control an already-running personal Chrome or reuse its logged-in state; use the environment's permission-approved CDP workflow for that.
+
+## Safe Setup and Verification
+
+### 1. Establish the boundary before downloading
+
+Confirm that the user wants a separate Jet Browser container rather than their daily browser. Check for Docker and Node.js 24+, and report a missing requirement instead of claiming the runtime was verified.
+
+For a new checkout or upgrade, identify an immutable release or full commit, inspect the repository's `package.json`, lifecycle scripts, lockfile, Dockerfiles, executable files, symlinks, network access, and credential handling, and summarize what will run. Obtain explicit approval before downloading and again before installing dependencies, building images, or starting containers. A Git commit pin provides reproducibility, not proof of trust.
+
+The v0.6.7 source commit reviewed for this catalog entry is:
+
+```text
+882b17ab1b865560f17dbfeeeea0a7b40b95a146
+```
+
+Review a newer source tree independently before changing that pin.
+
+### 2. Run the standalone acceptance flow
+
+After the approvals above, install the pinned source's exact lockfile dependencies and run its standalone check:
+
+```bash
+npm ci
+npm run standalone
+```
+
+Treat the command's observed JSON result as the acceptance check. A passing run must start the local page, verify the JavaScript marker, type through the native input path, capture a PNG, keep the smoke browser's outbound network disabled, and shut the container down cleanly.
+
+For source changes, also run:
+
+```bash
+npm test
+cargo test --all-targets
+```
+
+Never report a pass when Docker, Node.js, the image build, browser startup, native input, DOM verification, screenshot capture, or cleanup did not actually complete.
+
+### 3. Integrate the documented contract
+
+Read `docs/demo.md` for the container lifecycle and `docs/agent-tools.md` for model-facing declarations. Prefer the versioned declarations exported by `sdk/tools.mjs`; do not invent tool names, input fields, or response shapes.
+
+Send one JSON command per line and consume one JSON response per line. Preserve ordering, bound inputs and outputs in the calling harness, and close the session in guaranteed cleanup. Keep one container per mutually untrusted session, mount profile or download paths explicitly, and never pass unrelated host credentials into the container.
+
+Use semantic evidence for target selection and screenshots for visual verification when both are available. Treat evaluation, imported profiles, downloads, and outbound network access as privileged capabilities that require the calling application to define its own authorization and policy gates.
+
+## Examples
+
+### Example 1: Verify a pinned source checkout
+
+After inspecting the pinned source and receiving the required approvals:
+
+```bash
+git clone --filter=blob:none --no-checkout https://github.com/masakaai/jet-browser.git
+git -C jet-browser checkout --detach 882b17ab1b865560f17dbfeeeea0a7b40b95a146
+cd jet-browser
+npm ci
+npm run standalone
+```
+
+Report the exact command result and which acceptance assertions ran. Do not translate a partial build or startup log into a successful verification.
+
+### Example 2: Verify Jet Browser in GitHub Actions
+
+Pin the Action to the reviewed full commit rather than a moving branch or tag:
+
+```yaml
+permissions:
+  contents: read
+
+jobs:
+  verify-browser-runtime:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Verify Jet Browser
+        uses: masakaai/jet-browser@882b17ab1b865560f17dbfeeeea0a7b40b95a146 # v0.6.7
+```
+
+This checks the public `linux/amd64` release image on a GitHub-hosted Linux runner. Review the Action source and repository workflow permissions before use.
+
+## Best Practices
+
+- ✅ Pin source and Action use to a reviewed full commit.
+- ✅ Keep one isolated browser session per container and always close it.
+- ✅ Preserve ordered JSONL and use the published schemas instead of inferring fields.
+- ✅ Keep credentials and network policy in the embedding harness.
+- ✅ Report observed checks, failures, and platform limitations exactly.
+- ❌ Do not attach Jet Browser to a personal Chrome profile or copy daily-browser credentials into it.
+- ❌ Do not promise CDP, Chrome extensions, Chromium-only behavior, stealth, CAPTCHA solving, or public-site success.
+- ❌ Do not generalize the published offline benchmark to model accuracy or long-running production reliability.
+
+## Limitations
+
+- Jet Browser uses WPE WebKit, not Chromium. It does not implement Chrome-only extension, enterprise-policy, or CDP contracts.
+- The published v0.6.7 image targets `linux/amd64`; ARM hosts need compatible emulation or a source build for the host architecture.
+- Docker and Node.js 24+ are required for the documented standalone flow; source development also requires the repository's Rust toolchain.
+- The standalone runtime does not include a hosted control plane, proxy network, account system, persistent daily-browser takeover, or model loop.
+- The published ready-time and memory figures are medians from a pinned offline fixture. They do not measure public-site success, stealth, CAPTCHA handling, model accuracy, or long-running stability.
+- This skill cannot validate a local run when the required runtime is unavailable; report the missing dependency or failed assertion instead.
+
+## Security & Safety Notes
+
+- `npm ci`, Docker builds, and container startup modify local state and may execute repository-controlled code. Inspect the pinned source and obtain approval before each installation or execution boundary.
+- The standalone smoke test disables browser outbound networking, but image and dependency acquisition can use the network. State that distinction before running it.
+- Use a dedicated container per mutually untrusted session. Mount only required paths, avoid unrelated host credentials, and set explicit resource and network limits.
+- Do not import a user's daily browser profile merely to reuse authentication. When a task genuinely requires an existing logged-in Chrome session, route to a permission-approved CDP workflow instead.
+
+## Common Pitfalls
+
+- **Problem:** The task needs an already logged-in personal browser.
+  **Solution:** Do not use Jet Browser for that path; use the environment's authorized CDP integration.
+- **Problem:** The image fails on an ARM host.
+  **Solution:** Use Docker's `linux/amd64` emulation when appropriate or build the pinned source for the host architecture.
+- **Problem:** A harness assumes Chromium/CDP fields.
+  **Solution:** Use the JSONL protocol and `sdk/tools.mjs` declarations shipped by the pinned Jet source.
+- **Problem:** A partial startup is reported as a pass.
+  **Solution:** Require the complete native-input, DOM, PNG, offline-network, and cleanup assertions before reporting success.
+
+## Additional Resources
+
+- [Jet Browser source](https://github.com/masakaai/jet-browser)
+- [v0.6.7 release](https://github.com/masakaai/jet-browser/releases/tag/v0.6.7)
+- [Standalone demo](https://github.com/masakaai/jet-browser/blob/v0.6.7/docs/demo.md)
+- [Agent tool catalog](https://github.com/masakaai/jet-browser/blob/v0.6.7/docs/agent-tools.md)
+- [Benchmark method](https://github.com/masakaai/jet-browser/blob/v0.6.7/docs/benchmarks.md)

package/bundled-skills/qrx/SKILL.md

@@ -0,0 +1,131 @@
+---
+name: qrx
+description: "Make branded, print-ready art QR codes that always scan with QRX (qrx.codes). Use when a link needs a QR code that looks like artwork or matches a brand for print, packaging, signs, slides or event badges, and to list or re-point QRX codes. Not for plain QR codes the agent makes locally."
+category: design
+risk: critical
+source: https://github.com/qrxcodes/qrx-mcp/tree/main/skills/qrx
+source_repo: qrxcodes/qrx-mcp
+source_type: official
+date_added: "2026-10-10"
+author: QRX
+tags: [qr-code, design, branding, mcp, rest-api, print]
+tools: [claude, codex, cursor, copilot, gemini]
+license: MIT
+license_source: https://github.com/qrxcodes/qrx-mcp/blob/main/LICENSE
+---
+
+# QRX: art QR codes that always scan
+
+QRX turns a short picture description (the prompt) and a destination link into an artistic QR code. Every code is checked to decode before it is returned, and it encodes a hosted short link, `https://qrx.to/<id>` on qrx.codes, which forwards scans to the destination. Treat the result as a design asset: a PNG the user can drop into print or digital layouts.
+
+## When to Use
+
+Use it when the user wants a QR code that is also a picture: on-brand, decorative, or eye-catching enough to earn a scan. Typical asks: a café menu code in a watercolour style, a conference badge code in the event's colours, a poster code that blends into the artwork, a product-packaging code, a wedding-invitation code.
+
+Do not use it when:
+- a plain, unstyled QR code will do and can be made locally (offer QRX only if the user wants something designed);
+- the user wants to change the art of an existing code (make a new code instead);
+- the request is for a logo, trademark or character the user does not own (see "What not to do").
+
+## Tools (QRX MCP server)
+
+| Tool | Use |
+| - | - |
+| `list_styles` | List style ids and names. |
+| `generate_qr_code` | Start a code. Args: `prompt` (required, up to 1,000 characters), `destination` (required, an absolute `http` or `https` URL, up to 2,048 characters), optional `style`. Answers at once with the code's `id` and `status: processing`. |
+| `get_qr_code` | Get a code by `id`. Waits up to `wait` seconds (0 to 25, default 25) for a processing code to finish. Call again while it is still `processing`. |
+| `list_qr_codes` | The user's codes, newest first. `limit` 1 to 100 (default 20); pass `nextCursor` as `cursor` for the next page. |
+| `change_qr_code_destination` | Re-point a link code's short link to a new destination (`id`, `destination`: an absolute `http` or `https` URL). Printed codes follow at once. Only if the account's plan allows changing destinations; it replaces the old destination, so confirm with the user first. |
+| `get_account` | The plan, today's allowance, what is left, when it resets, and which features the account has (Wi-Fi codes, changing destinations). |
+| `get_profile` | The connected QRX account. |
+
+The server needs the user to sign in to QRX (or an API key) before it connects. If the tools are missing, it is not connected: ask the user to sign in from their client's MCP or connector settings, or use the REST API instead (see [references/rest-api.md](references/rest-api.md)).
+
+## How to make a code
+
+1. **Get the destination.** It must be an absolute URL starting with `https://` or `http://` (add `https://` if the user gave a bare domain, and confirm the exact link if it is ambiguous). The MCP tools make link codes only; for a Wi-Fi code, send the user to https://qrx.codes, and never ask them for a Wi-Fi password.
+2. **Write the prompt** (see "Writing a good prompt"). If the user named a look, call `list_styles` and pick the closest style id; otherwise leave `style` out.
+3. **Call `generate_qr_code` once.** Keep the returned `id`; it never changes. Painting usually takes under a minute.
+4. **Poll with `get_qr_code`** using that `id` until `status` is `succeeded` or `failed`. Each call waits up to 25 seconds, so two or three calls are normal.
+   - Never call `generate_qr_code` again while a code is still processing: every generate counts against the user's allowance.
+5. **Show the result:** the image (`imageUrl`, a PNG), the short link the code encodes (`shortUrl`, `https://qrx.to/<id>` on qrx.codes), the destination, and the code's page (`pageUrl`). Tell the user to test-scan it with a phone before printing.
+6. **On `failed`:** read `error.message`, simplify the prompt (fewer elements, more contrast), and offer one retry. Ask before making more than one extra attempt.
+
+For several variations, say how many will be made and that each counts against the allowance, then start them and poll each `id`.
+
+## Writing a good prompt
+
+The prompt describes the picture only. QRX handles the QR pattern itself.
+
+- **Lead with one clear subject and setting:** "a lighthouse on a cliff at sunset", "a bowl of ramen with steam rising", "a eucalyptus branch with gumnuts".
+- **Add a style or medium:** watercolour, linocut print, isometric 3D, art deco poster, Japanese woodblock, papercraft, neon line art.
+- **Name the palette, especially brand colours:** "in deep navy, coral and cream"; describe colours in words, since hex codes are not reliably followed.
+- **Keep it simple:** one subject, a few adjectives, 10 to 30 words. Busy scenes with many small objects scan and read worse.
+- **Prefer strong light-dark contrast** in the description ("bold shapes, high contrast") for codes that will be printed small or viewed from a distance.
+- **Leave out words and lettering:** do not ask for text, slogans, numbers or logos inside the art. Put copy next to the code in the layout instead.
+- Use Australian or the user's own spelling; it does not matter to the model.
+
+More examples and fixes: [references/prompt-guide.md](references/prompt-guide.md).
+
+## Limits
+
+- Accounts have a daily allowance of codes (some have no daily limit), and changing where a code points depends on the account's plan. Call `get_account` to see what is left today, when the count resets and which features the account has; act on the features it reports, not on the plan name.
+- If a call fails with a limit error, or says a feature is not included in the account's plan, call `get_account`, tell the user plainly what is left and when it resets (or that the feature is not included in their plan), and point them to their account at https://qrx.codes. Do not retry in a loop.
+- An authentication error means no QRX account is connected. Ask the user to sign in to QRX when their client prompts (or from its MCP or connector settings); a client that cannot sign in can use an API key from https://qrx.codes/developers/keys instead.
+
+## Links and re-pointing
+
+The code encodes its short link (`https://qrx.to/<id>` on qrx.codes), not the destination itself. A code's `id` and short link never change. That keeps the pattern simple and, where the account's plan allows it, lets the user change the destination later with `change_qr_code_destination` without reprinting. Mention this when the user is printing in volume or the destination may change (seasonal menus, event pages).
+
+## Print and placement checklist
+
+Share the relevant points when the code is for print:
+- **Test-scan** the downloaded PNG on at least two phones (iPhone camera and an Android camera) before sending to print, and again on a printed proof.
+- **Minimum size:** about 2.5 cm (1 inch) square for handheld items such as cards and menus; scale up roughly 1 cm of code width per 10 cm of scanning distance for posters and signs.
+- **Quiet zone:** keep a clear margin around the code, and do not crop, overlap or place text over the artwork's edges.
+- **Do not recolour, stretch, add filters or vectorise** the image; resize proportionally only.
+- **Contrast with the background:** place it on a calm area, not on a busy photo.
+- **Finish:** matte stock scans more reliably than gloss under lights.
+- Put a short call to action beside the code ("Scan for the menu").
+
+## What not to do
+
+- Do not put logos, trademarks, celebrities or characters the user does not own in the prompt, and do not imitate another company's branding.
+- Do not ask for text inside the art.
+- Do not generate codes that point to phishing, malware or deceptive pages, or that hide where a link goes.
+- Do not start many codes "just to see"; each one uses the user's allowance.
+- Do not paste the user's API key into chat output, files or commits.
+
+## REST API fallback
+
+If the MCP tools are not available but the user has an API key, follow [references/rest-api.md](references/rest-api.md) (create with `POST https://qrx.codes/v1/codes`, then `GET https://qrx.codes/v1/codes/{id}?wait=45`).
+
+## Examples
+
+A café wants a menu QR code in watercolours:
+
+```text
+1. Destination: https://example.com/menu (confirm the exact link).
+2. find_ui style: list_styles, then pick the closest watercolour-style id.
+3. generate_qr_code({"prompt": "a steaming flat white on a timber bench, watercolour, warm cream and espresso brown", "destination": "https://example.com/menu", "style": "<id>"})
+4. Poll get_qr_code with the returned id until status is succeeded.
+5. Show imageUrl, shortUrl, destination and pageUrl, and ask the owner to test-scan before printing.
+```
+
+REST fallback when the MCP server is not connected:
+
+```bash
+curl -sS -X POST "https://qrx.codes/v1/codes?wait=45" \
+  -H "Authorization: Bearer $QRX_API_KEY" \
+  -H "Content-Type: application/json" \
+  -H "Idempotency-Key: $(uuidgen 2>/dev/null || date +%s)" \
+  -d '{"prompt":"a lighthouse on a cliff at sunset, watercolour, navy and coral","destination":"https://example.com/menu"}'
+```
+
+## Limitations
+
+- Needs a QRX account and either the QRX MCP server or an API key; without them the skill cannot generate codes and says so.
+- Codes consume the account's allowance, and changing a code's destination depends on the account's plan; call `get_account` before promising either.
+- Looks codes up by the QRX account only: it cannot manage codes owned by another account.
+- Generated art is returned as a hosted PNG and a hosted short link; QRX does not return the code as a local editable vector.
+- The model provider's data-handling policy still applies to any prompt text that passes through the connected tools.

package/bundled-skills/qrx/references/prompt-guide.md

@@ -0,0 +1,30 @@
+# QRX prompt guide
+
+A QRX prompt describes only the picture. Formula: **subject + setting + style or medium + palette + mood**, in 10 to 30 words.
+
+## Examples by use
+
+| Use | Prompt |
+| - | - |
+| Café menu | a steaming flat white on a timber bench, morning light, watercolour, warm cream and espresso brown |
+| Surf club poster | a curling turquoise wave at dawn, Japanese woodblock print, navy, teal and sand |
+| Florist packaging | a bunch of native waratahs and banksias, botanical illustration, crimson and sage green |
+| Tech conference badge | a glowing circuit-board city at night, isometric 3D, electric blue and magenta |
+| Wedding invitation | climbing white roses on a stone arch, soft pastel gouache, ivory and blush pink |
+| Winery label | rolling vineyard hills at golden hour, linocut print, burgundy and gold |
+| Kids' event flyer | a friendly cartoon koala in a hot-air balloon, bright flat illustration, primary colours |
+| Real-estate sign | a modern house with a pool at dusk, architectural rendering, charcoal and warm amber |
+
+## Fixes
+
+| Problem | Change |
+| - | - |
+| Art looks busy or muddy | One subject, drop secondary objects, add "bold shapes, clean composition" |
+| Code hard to scan when printed small | Ask for "high contrast, strong light and dark areas"; print larger |
+| Colours off-brand | Name colours in plain words ("forest green, cream"), two or three at most |
+| Unwanted text or letters appear | Remove any mention of words, signs, labels or typography |
+| Looks generic | Add a specific medium and era: "1930s travel poster", "risograph print" |
+
+## Brand fit
+
+Ask the user for their brand colours, two or three adjectives for the brand voice, and where the code will appear. Translate these into palette and style words. Never include logos, wordmarks or mascots in the prompt; place the brand logo beside the code in the final layout instead.

package/bundled-skills/qrx/references/rest-api.md

@@ -0,0 +1,40 @@
+# QRX REST API fallback
+
+Use this only when the QRX MCP tools are not connected (connecting the MCP server needs sign-in or an API key; prefer signing in). Requires an API key from https://qrx.codes/developers/keys, read from the environment variable `QRX_API_KEY`. Never print the key.
+
+Base URL: `https://qrx.codes/v1`. The OpenAPI 3.1 spec is at `https://qrx.codes/v1/openapi.json`, and the reference is at https://qrx.codes/developers/docs/reference (append `.md` to any docs page for Markdown). None of these need a key.
+
+Send the key as `Authorization: Bearer $QRX_API_KEY` (preferred) or `X-API-Key: $QRX_API_KEY`. If both are sent, `Authorization` wins.
+
+## Create a code
+
+```bash
+curl -sS -X POST "https://qrx.codes/v1/codes?wait=45" \
+  -H "Authorization: Bearer $QRX_API_KEY" \
+  -H "Content-Type: application/json" \
+  -H "Idempotency-Key: $(uuidgen 2>/dev/null || date +%s)" \
+  -d '{"prompt":"a lighthouse on a cliff at sunset, watercolour, navy and coral","destination":"https://example.com/menu"}'
+```
+
+- `prompt` (required, up to 1,000 characters), `destination` (an absolute `http` or `https` URL, up to 2,048; anything else is a `400`) **or** `wifi` `{ "ssid", "password", "security": "wpa"|"wep" }` (only if the account's plan includes Wi-Fi codes), optional `style` (an id from `GET /v1/styles`).
+- `?wait=` (0 to 50; use 45) holds the request open: `201` means it finished within the wait, `202` means it is still `processing`. The `Location` header is the code's absolute URL.
+- Always send an `Idempotency-Key` so a retried request cannot make a second code. A retry with the same key and body within a day answers with the code as it is now; one that arrives before the first request has made its code answers `409` with `Retry-After`.
+
+## Wait for it
+
+```bash
+curl -sS "https://qrx.codes/v1/codes/<id>?wait=45" -H "Authorization: Bearer $QRX_API_KEY"
+```
+
+Repeat until `status` is `succeeded` or `failed`. A finished code has `imageUrl` (PNG), `shortUrl` (the short link, `https://qrx.to/<id>` on qrx.codes), `destination` and `pageUrl`. A code's `id` and `shortUrl` never change. A link code's `id` is currently 6 lowercase letters and digits, such as `k7m2qz`; a Wi-Fi code's `id` is a UUID and its `shortUrl` is null. Treat ids as opaque strings.
+
+## Other endpoints
+
+| Method and path | Purpose |
+| - | - |
+| `GET /v1/codes?limit=10&cursor=...` | List codes, newest first (`nextCursor` for the next page) |
+| `PATCH /v1/codes/{id}` with `{"destination":"https://..."}` | Re-point a link code (only if the account's plan allows changing destinations) |
+| `GET /v1/account` | Plan, allowance, features and limits |
+| `GET /v1/styles` | Style ids, names and preview images |
+
+Errors are RFC 9457 `application/problem+json` with a `type` (`https://qrx.codes/developers/docs/errors#<code>`), `title` and `detail`; `403 plan-required` means the feature is not included in the account's plan, and `429` means a rate or daily limit was hit (check `GET /v1/account`). Rate limits are reported in the `RateLimit-Policy` and `RateLimit` headers (for example `RateLimit-Policy: "requests";q=30;w=60` and `RateLimit: "requests";r=29;t=2`); creates on accounts with a daily allowance also carry a `"codes"` policy for the day's codes.

package/bundled-skills/reverse-engineer-anything/SKILL.md

@@ -0,0 +1,239 @@
+---
+name: reverse-engineer-anything
+description: Use REA to investigate shipped apps, binaries, packages, and runtimes; trace features with evidence, compare versions, or guide reconstruction. Skip ordinary source-code analysis.
+risk: safe
+source: "https://github.com/morluto/rea/tree/main/skill-src/reverse-engineer-anything"
+source_repo: "morluto/rea"
+source_type: community
+date_added: "2026-10-10"
+license: "MIT"
+license_source: "https://github.com/morluto/rea/blob/main/LICENSE"
+metadata:
+  version: "34"
+---
+
+# REA
+
+## When to Use
+
+- Use when a claim depends on a shipped application, binary, package, or requested runtime evidence.
+- Use for decompilation, evidence-backed feature traces, version comparisons, or investigation-guided reconstruction.
+- Skip REA for ordinary source-code analysis of a complete repository.
+
+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.
+
+## Limitations
+
+- The skill supplies investigation guidance; it does not register the REA MCP server or install analysis engines.
+- Native-analysis availability depends on the selected provider, host, and target format. Hopper is separate licensed software; Ghidra and IDA are bring-your-own.
+- Static analysis does not establish runtime behavior or recover original source code. Report provider-specific coverage, partial results, and unknowns.
+- REA runs analysis locally, but the connected model provider may have separate data-handling policies.
+
+## 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:
+
+1. Diagnose without changing files. For Codex, run
+   `npx -y rea-agents@latest 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@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.
+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, 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@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.
+
+- 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`.
+- 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](https://github.com/morluto/rea/blob/main/docs/web-network-captures.md) for the exact upstream
+  profile and credential exclusions.
+- User-owned Electron runtime already open: `list_electron_targets`.
+- 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](https://github.com/morluto/rea/blob/main/docs/evm-bytecode.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).
+- 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.
+
+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 `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. 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 `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.
+
+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:
+
+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)
+- 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.

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

@@ -0,0 +1,34 @@
+# 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. 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`.