Build Scalable, Collaborative Coding Agents

This skill covers building background coding agents that run in remote sandboxed environments rather than on local machines, aiming for unlimited concurrency, consistent execution environments, and multiplayer collaboration - with session speed limited only by model provider time-to-first-token. Its architecture has three layers: sandbox infrastructure (isolated execution), an API layer (state management and client coordination), and client interfaces (user interaction across platforms). For sandbox infrastructure, it recommends an image-registry pattern - pre-building environment images every ~30 minutes with the repo cloned, dependencies installed, and caches warmed from a prior app/test run - plus filesystem snapshots at key points (base, post-session, pre-exit) for instant restoration, GitHub app tokens for image-build git operations with the prompting user's identity used for actual commits, and a warm pool of pre-warmed sandboxes for high-volume repos, started as soon as a user begins typing.

Use it when building background coding agents that run independently of user devices, designing sandboxed execution environments for agent workloads, implementing multiplayer agent sessions with shared state, building multi-client agent interfaces (Slack, web, Chrome extension), scaling agent infrastructure past local-machine constraints, or building systems where agents spawn sub-agents for parallel work.

Guidance covers agent framework selection (a server-first architecture with TUI/desktop apps as thin clients, a framework where the agent can read its own source code to avoid hallucinating about its own capabilities, and a plugin system that can listen to and block/modify tool-execution events), speed optimizations (predictive warm-up on first keystroke, allowing file reads to start before git sync completes while blocking only writes, and maximizing build-time work so dependency installs and cache-warming runs are invisible to users), self-spawning agents (tools letting an agent start a new session with parameters, check another session's status, and continue main work while sub-sessions run in parallel - for cross-repo research, splitting a monolithic change into smaller PRs, or parallel approach exploration), an API layer (per-session isolated state such as one SQLite database per session, WebSocket streaming with hibernation APIs to cut idle compute cost, and a single state system synchronized across chat, Slack, Chrome extension, web, and VS Code clients), multiplayer support (valuable for teaching non-engineers to use AI effectively, live QA with multiple team members, real-time PR review, and collaborative debugging, requiring only a data model not tied to a single author, per-prompt authorship attribution, and shareable session links - nearly free to add given proper sync), and GitHub-based authentication (user tokens for PR creation so users can't approve their own changes, with the sandbox pushing changes, notifying the API by session ID, and the API creating the PR under the user's token).

Client implementations named specifically: a Slack integration (classifies target repository from message/thread/channel context, drives adoption virality), a web interface (real-time streaming, a hosted VS Code instance in-sandbox, before/after PR screenshots, and a stats page tracking merged-PR sessions and live "humans prompting" count), and a Chrome extension for non-engineers (DOM/React-internals extraction instead of screenshots to cut token usage, distributed via managed device policy). It builds on sibling skills multi-agent-patterns (self-spawning supervisor patterns), tool-design (spawn/status tools), context-optimization, and filesystem-context, and references Ramp's background-agent writeup, Modal Sandboxes, Cloudflare Durable Objects, and OpenCode as external examples.

Practical guidance covers follow-up message handling during an active session - a queue approach (simpler, lets users send next-step thoughts while the agent works) versus an insert approach (processed immediately), plus a mechanism to stop the agent mid-execution - the metrics that actually matter (sessions resulting in merged PRs as the primary success metric, time from session start to first model response, PR approval rate and revision count, agent-written code percentage), and an adoption strategy of working in public Slack channels for visibility, letting the product create its own virality loop, not forcing usage over existing tools, and building to people's actual needs rather than hypothetical ones.

Teams building or scaling hosted/background coding-agent infrastructure who need concrete patterns for sandbox spin-up speed, per-session state isolation, multiplayer collaboration, and multi-client delivery, rather than reinventing these from a local-agent starting point.