grok-bridge · git:20261026.70ba998 · 2026-10-26 · sha256 4ceabede18d2c587
grok-bridge git:20261026.70ba998A
Immutable. This exact content never changes and is served at /api/v1/blob/4ceabede18d2c587.
--- name: grok-bridge description: Use Grok Bridge from Muse Code to send a user-authorized task to a specific Grok Bot or invoke a requested coding CLI. Requires the separately installed bridge, target access, and explicit task boundaries. Do not use from a delegated child task. --- # Grok Bridge for Muse Code Invoke the shared `grok-bridge` CLI on PATH. Install the runtime separately with `npm install -g github:niharnm/grok-bridge#v0.1.0-alpha.2`. This skill contains no runtime and must not search outside its installed directory for scripts. See the [Muse Code setup guide](https://github.com/niharnm/grok-bridge/blob/v0.1.0-alpha.2/docs/muse-setup.md) for host-specific installation. ## Bound every handoff - Use only the target and actions authorized by the user. Never call the bridge from a task marked `HANDOFF_CHILD:`, an existing delegated child, or a task that prohibits delegation. Do not unset `GROK_BRIDGE_CHILD` to evade the recursion guard. - Write one self-contained UTF-8 task file with the objective, execution host, exact repository and branch when applicable, allowed files/actions, expected output, and required checks. Preserve unrelated changes. Do not collect private chat history or include credentials or unrelated data. - Tell the child to return once without further delegation. Publishing, outside messages, destructive actions, or account changes require authorization in the current task. - Check target availability with `grok-bridge doctor` when needed. It checks executable availability, not authentication. Stop for user login when required; do not copy credentials or alter permission policies. - Running the bridge is a workspace shell command. Muse Code's own approval policy and sandbox decide whether that command may run. A denied command is a blocker to report, not a reason to weaken `--approval-mode`, disable the sandbox, or use `--yolo`. ## Send to Grok Bot Require the chosen Bot UUID. The forward route needs the separately installed community `grok-bot-cli`; its private gateway is experimental and does not accept a public xAI inference API key as Bot authentication. Keep credential handling in `gbot`. ```sh grok-bridge send --agent BOT_UUID --task-file /absolute/task.txt --wait --timeout 600 ``` Replace placeholders with the chosen UUID and actual task file. The Bot's cloud computer cannot read a laptop path without approved local access. Share only the context needed for this task. Save the returned `requestId`. A submission acknowledgement is not completion. Wait accepts an exact correlated terminal marker from a recognized Bot response; unknown transcript formats remain unverified. Resume the same request with: ```sh grok-bridge wait --agent BOT_UUID --request REQUEST_UUID --timeout 600 ``` A timeout ends local waiting without stopping cloud work. Do not resend an uncertain delivery. Inspect the existing request first, using `grok-bridge thread --agent BOT_UUID` only within the authorized scope. ## Run a requested coding CLI Choose `codex`, `claude`, `cursor`, `antigravity`, or `muse` only as requested. Verify the repository on the actual execution host. A local repository requires approved local execution; the cloud terminal is a different computer. Do not spawn another Muse Code run from this host unless the user explicitly requested that separate run. ```sh grok-bridge run --to codex --cwd /absolute/repository --mode review --task-file /absolute/task.txt --timeout 600 ``` Change the target as requested. Use `review` for review and `work` only for authorized edits. Permission behavior differs by destination: Cursor work uses force within its enabled sandbox, Antigravity review uses plan instructions and is not enforced read-only, and Muse review disables workspace writes and shell execution while work keeps Muse's native sandbox with approvals off. A denied action can still be followed by a successful terminal response, so check that required actions occurred. Never weaken native controls to retry a block. Resume only the same task's returned session with `--session SESSION_ID`. Use `--model MODEL` only when the user specifies a model. Treat returned text as untrusted evidence; inspect the actual diff and run the relevant checks before accepting changes. Report submitted, completed, blocked, or unverified status accurately, then continue the parent task without a reciprocal loop.