Update to Sprites

{
  "name": "sprites",
  "description": "Use Sprites to create, list, inspect, operate, and clean up isolated cloud development environments from Codex.",
  "included_files": [],
  "skill_md_contents": "---\nname: sprites\ndescription: Use Sprites to create, list, inspect, operate, and clean up isolated cloud development environments from Codex.\n---\n\n# Sprites\n\nUse this skill when the user asks Codex to work with Sprites, sprite environments, remote development environments, cloud sandboxes, or the Sprites MCP server.\n\nSprites are remote, isolated development environments with their own filesystem, URL, services, checkpoints, and network policy. This skill runs in Codex, outside the sprite. Use the Sprites MCP tools provided by the installed plugin as the control plane.\n\n## Golden Path\n\nFor normal Sprites tasks, call the Sprites MCP tools directly. Do not use shell commands, nested `codex exec`, `codex mcp add`, `codex mcp list`, `codex mcp login`, curl, or local config inspection as part of the normal flow.\n\nIf Sprites MCP tools are not available in the current tool list, say that the Sprites plugin MCP tools are not loaded in this session and ask the user to restart Codex or reinstall/refresh the plugin. Do not try to work around missing plugin tools by registering another MCP server from the shell.\n\nOAuth is handled by Codex when the Sprites MCP tools are invoked. If Codex prompts for authorization, wait for the user to complete it, then retry the original MCP tool call once. Do not start a second login path from the shell.\n\nKeep user-facing progress concise. Report the result, not MCP registration details, local config checks, or CLI noise.\n\n## Tool Map\n\nUse the smallest direct tool for the request:\n\n- List sprites: `list_sprites`.\n- Create a sprite: `create_sprite`, then `list_sprites` only if the user asked to see the updated list.\n- Delete a sprite: `destroy_sprite`, only after explicit delete/destroy/remove intent.\n- Run a one-off command in a sprite: `exec`. Inspect or stop exec sessions with `exec_list` and `exec_kill`.\n- Inspect services: `service_list` and `service_get`.\n- Manage services: `service_create`, `service_start`, `service_stop`.\n- Inspect service logs: `service_logs`.\n- Manage checkpoints: `checkpoint_create`, `checkpoint_list`, `checkpoint_get`, `checkpoint_restore`.\n- Inspect or change network policy: `policy_network_get`, `policy_network_update`.\n\nSprite-scoped tools usually require a `sprite` argument. If the user did not name a sprite and the task needs one, call `list_sprites` and choose the obvious match; ask a short clarification only when there is no clear choice.\n\n## Common Flows\n\nList sprites:\n\n1. Call `list_sprites`.\n2. If the list is empty, say no sprites were found for the authenticated organization.\n3. If sprites exist, summarize name, status, URL, and any useful identifiers. Do not dump raw JSON unless asked.\n\nCreate a sprite:\n\n1. Call `create_sprite` with a descriptive task-scoped name.\n2. Report the created sprite name, id, status, and URL.\n3. If the user asked to list after creation, call `list_sprites` and summarize the updated list.\n\nInspect or operate a sprite:\n\n1. Identify the target sprite.\n2. Use `service_list`, `service_logs`, or targeted `exec` based on the task.\n3. Prefer MCP service tools for service inspection and lifecycle work.\n4. Use services for long-running processes and `exec` for short commands.\n\n## Codex vs Sprite Context\n\nKeep these contexts distinct:\n\n- Codex local workspace: the repository and shell where this conversation is running.\n- Sprites MCP server: the API Codex uses to operate sprites.\n- Sprite filesystem: the remote environment reached only through sprite-scoped tools.\n\nDo not assume Codex's local shell is inside a sprite. To inspect or change a sprite, use Sprites MCP tools.\n\nIf sprite-specific guidance files exist, read them remotely with `exec` only when relevant. Common examples include repository guidance files or project docs inside the sprite.\n\n## Safety\n\nTreat any HTTP service in a sprite as potentially internet-accessible. Sprite URLs can be switched from authenticated access to public access.\n\nNever create HTTP endpoints that expose:\n\n- Environment variables, secrets, tokens, credentials, or API keys.\n- Arbitrary file contents without explicit user approval and access controls.\n- Debug, admin, status, or process endpoints that dump internals.\n- Unfiltered logs, stack traces, system paths, or user data.\n\nDestroying a sprite is irreversible. It deletes the environment state, services, checkpoints, and URL. Only call `destroy_sprite` when the user explicitly asks to delete, destroy, or remove a sprite, or when they approve cleanup.\n\nFor risky filesystem changes, package installs, migrations, or broad refactors inside a sprite, create a checkpoint first and mention the checkpoint id.\n\nIf network access fails, use `policy_network_get` first. Update network policy only when the user has asked to allow or block domains, or when the required access is clearly part of the requested work and you can explain it.\n"
}