name	ida-reverse-operator
description	Use this when a Codex agent needs to reverse engineer a binary with IDA MCP. First check whether the shared MCP backend is connected; if it is not, run bootstrap from the target project so it writes that project's `.codex/config.toml` with the correct streamable HTTP MCP endpoint for `ida-shared`. Then check whether the target binary already has a corresponding IDA database. If it does, open it and analyze with native ida-pro-mcp tools. If it does not, create the analysis context first and then continue.
metadata	{"short-description":"Operate native ida-pro-mcp reverse workflows"}

IDA Reverse Operator

Use this skill when the task is to actually reverse engineer binaries, not to design the reverse platform.

Core workflow

When a reverse task arrives, check MCP connectivity with autopwn-reverse-bootstrap status.
If MCP is not connected, run autopwn-reverse-bootstrap bootstrap from the target project directory, then confirm status again.
Treat the reported config_path as project-local state. By default it should be <project>/.codex/config.toml, pointing ida-shared at the shared backend /mcp URL.
Before you debug or attach anything else, confirm the real execution target with ldd and readelf -l. If the binary is already patched to a local interpreter or libc, prefer running the binary directly instead of wrapping it with ld-linux --library-path ....
Once MCP is connected, identify the target binary and check whether it already has a corresponding IDA database.
If the IDA database exists, open that existing analysis and continue with native ida-pro-mcp tools.
If the IDA database does not exist, start a reverse workspace for the target binary, create the analysis context in IDA, and then continue with native ida-pro-mcp tools.
Use native ida-pro-mcp tools such as idalib_open, idalib_list, idalib_current, idalib_switch, decompile, disasm, xrefs_to, and imports.
Persist important findings into repository artifacts, notes, or reports instead of leaving them only inside the IDA database.

Rule

Do not funnel reverse engineering back through repository-specific wrapper commands once the MCP server is available. Prefer the native ida-pro-mcp tools.

IDA Reverse Operator

Use this skill when the task is to actually reverse engineer binaries, not to design the reverse platform.

Core workflow

When a reverse task arrives, check MCP connectivity with autopwn-reverse-bootstrap status.

If MCP is not connected, run autopwn-reverse-bootstrap bootstrap from the target project directory, then confirm status again.

Treat the reported config_path as project-local state. By default it should be <project>/.codex/config.toml, pointing ida-shared at the shared backend /mcp URL.

Before you debug or attach anything else, confirm the real execution target with ldd and readelf -l. If the binary is already patched to a local interpreter or libc, prefer running the binary directly instead of wrapping it with ld-linux --library-path ....

Once MCP is connected, identify the target binary and check whether it already has a corresponding IDA database.

If the IDA database exists, open that existing analysis and continue with native ida-pro-mcp tools.

If the IDA database does not exist, start a reverse workspace for the target binary, create the analysis context in IDA, and then continue with native ida-pro-mcp tools.

Use native ida-pro-mcp tools such as idalib_open, idalib_list, idalib_current, idalib_switch, decompile, disasm, xrefs_to, and imports.

Persist important findings into repository artifacts, notes, or reports instead of leaving them only inside the IDA database.

Rule

Do not funnel reverse engineering back through repository-specific wrapper commands once the MCP server is available. Prefer the native ida-pro-mcp tools.

ida-reverse-operator