One session doing everything is the slow way.

The main session makes the decisions that are expensive to get wrong: the capabilities, the data model, the auth flows, which clients. That is where a strong model earns its cost.

The server agent builds the Worker: pithy.config.ts, the capabilities, your routes and migrations. client-web builds a React app in the same Worker. client-mobile builds the Expo app pithy ui add react-native scaffolds, signing in with the kit's bearer session and keeping its token in the Keychain or the Keystore. The runner runs pithy dev, the tests, typecheck and builds, and hands back a summary instead of a log.

Web and mobile are two agents because they sign in two ways. One agent holding both would mix them.

Every agent's model and effort is a plugin setting. Change them with /plugin, or from a shell. An option you leave out keeps its value.

/new-app and /deploy pass your choice on every agent they bring in, and it outranks the agent's own default. The main session's model is yours to set with /model and /effort, because a plugin cannot set it.

The runner holds Bash and Read and nothing else. The cheapest model on the team is never the one changing your code.

/new-app asks which clients call the backend — web, mobile or both — then the project name and the first Worker's name. It runs /app-design before any code, scaffolds with pithy init, and dispatches the agents in order: the server, the runner to migrate and test, then the clients once the contract exists.

A mobile project gets no web agent, and a web project gets no mobile one.

Ask for a deploy on the first day or the fortieth. The team checks your Cloudflare credentials with pithy doctor, shows what pithy provision --dry-run would create on your account, and asks. On your yes the runner provisions, migrates and deploys that one environment.

A yes to staging is not a yes to production. Production takes a phrase you type yourself, and the team passes it on exactly as typed. Afterward it offers to connect the dashboard, which you approve in your browser.

An environment holds one connection, the dashboard's or an agent's, never both. So before it offers the dashboard, the team says that connecting it means /operate cannot connect there.

An agent that hits a gap does not patch node_modules. It runs /report-kit-gap, works around the gap in your app, and marks the workaround with the issue's number, so you find it and remove it when the fix ships.

The report searches the open issues first and comments on a match rather than filing a duplicate. Its repro is written from scratch. It never includes your code or a secret, and it files only on your yes. Without gh signed in, it hands you a prefilled link to open yourself.

The plugin organizes the work. The CLI is still how each agent learns the kit. Every command takes --json, and the runner reads the result rather than the prose. pithy schema --json describes every command the installed version takes, so an agent builds its call from your binary rather than from memory.

The AGENTS.md block pithy init writes says how this project wants the CLI driven. pithy docs connect points your session at the documentation server, so an agent reads the current docs instead of guessing. And every client is built against the Worker's OpenAPI document, which pithy contract writes and the server agent keeps current.

The team builds the app. Once it is deployed, an agent can also help run it, and your users can bring their own. Both use the Model Context Protocol, MCP, the standard way an AI client calls tools, and they are not the same thing.

pithy mcp connect points an agent at your Worker's admin routes, through the control plane the dashboard uses. It holds its own scoped credential, a key on your machine or a CI job's own identity with no key at all, and every call lands in your audit trail marked as an agent. /operate sets it up for this session: it grants manifest:read and only the reads you need first, hands you the connect command to run yourself, and asks before every call that changes anything.

Compose mcp() and your app serves its own endpoint at /mcp. Your users connect their agents there, approve them on your origin, and each one acts as the person who approved it: your routes, their role, nothing more. /app-design asks whether you want one, recommends no unless you name a use, and settles which routes become tools, reads first.

And pithy.sh/mcp is neither. It is the documentation server, and it answers questions about the kit.

pithy-games is an add-on, and installing it installs pithy with it. It reuses the whole team and adds one agent, client-unity, which generates the Unity client's HTTP layer from openapi.json at a pinned generator version and writes the socket layer against asyncapi.json. Compiling stays in your own Unity project.

/game-design settles what the server is the authority for, what the room holds and the game's action and view schemas before any code. /new-game is /new-app with the game capabilities added. /playtest plays simulated players through one room against pithy dev and reports every move. Pithy for games has the capabilities it builds on.

#release is deliberate. The kit's default branch runs ahead of npm between releases, so a plugin read from it would name commands your installed CLI does not have. The release branch moves only when the kit is published, and the plugin's version is the CLI's version, so an update arrives once per release and never between.

Claude Code does not auto-update a third-party marketplace by default. Turn it on under /plugin, Marketplaces, pithy, Enable auto-update, or update by hand. Upgrade the CLI at the same time.

Install from one source: pithy@pithy from this marketplace, or pithy@synced from Anthropic's plugin directory. Not both, or every agent and skill appears twice.