Decepticon operator

Use Decepticon as the user's security platform. The host decepticon command manages the installation and opens an interactive CLI. The registered MCP server exposes engagement control and observation to coding agents. These interfaces cover different operations; choose the one that actually exists.

Connect

1. Check decepticon status. If the installation is missing, the user can run decepticon onboard. decepticon start starts services and opens the interactive terminal; it is not a headless scan command.
2. For MCP, confirm decepticon_list_graphs works. A connection error means the stack or MCP registration needs attention. See the integration guide for Claude Code and Codex registration.
3. The user can install this skill for both clients with decepticon skill install after a release containing that command.

Choose the operation

Do not invent MCP tools for Blue Cell setup or service management. The slash commands above work inside Decepticon's interactive terminal, not in the shell or the MCP bridge.

• Poll decepticon_blue_events with its next_after cursor and decepticon_blue_notifications with its separate next_after cursor.
• Check decepticon_blue_status for collector and monitor health before interpreting missing events. Cite exact incident IDs and event sequences.

Engagement workflow

• Obtain the user's explicit target scope and rules of engagement before any active testing. State both included and excluded assets. Do not infer authorization from a URL or repository path.
• For an existing CLI engagement, call decepticon_list_engagements, identify its thread_id, then read decepticon_engagement_state and decepticon_transcript. Keep the returned next_index for later reads.
• decepticon_start_engagement binds the run to a workspace via workspace_path (default /workspace). To share the workspace binding the interactive CLI selected, pass the same binding explicitly — the binding is returned in the result's workspace_path field. A non-default binding must be the engagement's own directory (final segment = engagement_name, e.g. /workspace/<engagement_name>); anything else is rejected so one engagement's run cannot write into another engagement's workspace. The run still requires the workspace mapping on the server to exist and be authorized for that engagement; when in doubt, start the engagement in the interactive CLI and observe its thread through MCP.
• Engagement targets are network assets (URLs, hosts, CIDRs, globs, git remotes). A local repository path is not a valid target — the standalone SAST/CI entry was removed (issue #1059); code analysis happens inside an engagement once the operation itself obtains the source, with the code mounted or fetched as part of that engagement's workflow.
• decepticon_send_message queues a new turn behind an active run. Do not tell the user it changed the current execution until a subsequent transcript or state confirms the effect.
• decepticon_engagement_findings reads a persisted graph.json only. An available=false result does not prove the absence of findings. For an installed CLI engagement, inspect the selected host workspace's findings/FIND-*.md and report/ artifacts when available. Cite the actual artifact and verification status; do not invent a SARIF result.
• If a run is interrupted or fails, read the latest transcript and status before retrying. Stop polling when the user has the requested update or the run reaches a terminal state.

Read reference.md for exact MCP arguments and examples.md for CLI and MCP handoffs.