Skip to main content
You do not have to memorize commands to use Pome. One install puts six coach skills into your coding agent, and from then on it knows the loop: register what is under test, author a task, check the task is a fair exam, run it against the digital twins, read the score back. The skills are instructions, not a runtime. They call the Pome control MCP and the Pome CLI on your behalf, show you every command in plain text before running it, and stop where a step needs your judgement.

​
Install

The skills CLI discovers every skill in the repo and installs the set into your agent’s skills directory. --skill '*' takes all six in one pass; drop it and the installer opens an interactive picker instead. Take all six either way — pome routes into the other five, so a partial install routes into nothing. Then connect the control MCP, so the tool calls the skills make resolve: add https://mcp.pome.sh/mcp to your coding agent as a remote HTTP MCP server. There is no API key to paste — auth is OAuth, and the consent screen opens on the first tool call. Connect to the MCP has the wiring for each client: the one-line CLI form, the mcpServers JSON block, and what to do for a headless or managed agent. That page is where per-client configuration lives.
If you have done the graded capstone, both of these are already done — that page’s first two steps are this install and this connection.

​
The six skills

The journey is register → author → verify → run, and you enter wherever you already are; pome works that out rather than making you pick. Each skill’s full instructions live beside it in pome-sh/digital-twins/skills, which is the canonical copy — it versions with the CLI and the twins, so the skill you installed and the product it drives move together.

​
Which door registers your agent

There is one concept — register an agent — reached through two doors that are not interchangeable. Which one is right is decided by whether a local repo is in play, and picking the wrong one leaves a run that cannot start.
  • Your agent lives in a repo you run yourself → the CLI:
    Only the CLI does both halves. It resolves the hosted identity and writes the local wiring: the canonical agent.slug into pome.json, and the agt_… id into gitignored .pome/link.json. That local wiring is what pome run and pome doctor read to find the agent and its transport. See Your own agent for the whole path.
  • No local repo — a Claude managed agent, or a hosted registration with nothing on disk to link → the MCP tool register_agent. pome-intake takes this door for a managed agent, through intake_clone_scope.
Registering a repo-backed agent through the MCP alone writes no .pome/link.json and leaves the transport wrong, and a second pome register agent is then needed to repair both — so do not substitute one for the other on the grounds that it is the same registration. If a paste-prompt spells out the CLI command, let the coach run it verbatim. Adding twins later is the exception: on an agent that is already registered, register_agent with a twins list merges the allowlist rather than re-registering, and is the right call from either door.

​
Where the skills sit

The skills are one way in, not the only one, and nothing is exclusive to them. Same loop, same run row, wherever you drive it from: the CLI for local loops and CI, the MCP for any client that speaks tool calls, and the dashboard for reading what happened afterwards. A skill-driven run and a pome run produce the same evidence.

​
Next

Your own agent

Point Pome at your repo — register it and write the pome.json every run reads.

Write a task

The file’s shape, [code] vs [model], and the checks each twin declares.

Evaluate an agent over MCP

The same coach loop the skills drive, call by call.

Dashboard

Where agents, sandboxes, runs, and handoffs land: app.pome.sh.