pome

name	pome
description	Entry point for testing an agent with Pome — routes to the right coach skill by context (managed-agent YAML → pome-intake, local repo / self-hosted REST agent → the local-examinee run path, plain task authoring → pome-author-task) and maps CLI-era commands to the hosted MCP tools. Use when the user says "test my agent with pome", "run pome", or "use pome". Supersedes the Gen-1 /pome-test skill.

Pome (entry router)

You are the coach: you talk to the builder and to the Pome control MCP (mcp.pome.sh). The examinee is a sandbox clone of their agent, run against Pome's digital twins and graded from the live twin tape. This skill does one thing: read the builder's context and hand off to the right coach skill. Do not improvise a pipeline here.

If the mcp__pome__* tools are missing, the MCP isn't connected: ask the user to connect and authenticate it (interactive OAuth — needs a human in a browser): claude mcp add --transport http pome https://mcp.pome.sh/mcp.

Route by context

The builder arrives with…	Route
A Claude managed-agent YAML (pasted, or "test my managed agent")	pome-intake — collect the clone scope, register via intake_clone_scope, report twin coverage
A registered own agent — a repo with a pome.json but no task yet ("test my agent" / "what should I test?", tasks/ empty and list_tasks empty)	pome-suggest-tasks — read the manifest (twins) + the agent's prompt/code, propose grounded candidates, interview to pick one, then the authoring chain
A local repo agent / self-hosted process (talks REST, no managed-agent YAML)	The local-examinee path: register with the CLI — pome register agent <name> [--twins …], which writes pome.json + .pome/link.json and sets local transport (the MCP register_agent does not — see One register verb below). Then pome-run-task — run_task mints the session and the launch spec; launch the process yourself via the REST launcher (pome-run-task/references/launch-rest.md), which preflights the wiring (config → twin reachable → routing → egress floor, the pome doctor checks) before it launches
"What should I test?" / a worry to turn into a graded check	pome-author-task — library-first authoring, [code]/[model] criteria, validate → dry-run → save_task
A drafted task, first run coming up ("is my seed right?")	pome-verify-seed — fair-exam triage before anything runs
A verified task to execute ("run my tasks", "how did my agent do?")	pome-run-task — mint, launch, finalize_run on idle, narrate get_report

Registered but untested (the F-891 cold start). Detect it locally first, so the route resolves even before the MCP is connected: a pome.json at the repo root whose tasks dir holds no .md, and — when the MCP is up — an empty list_tasks. Both empty → the builder has an agent but no first task → pome-suggest-tasks. If local task files exist but the catalog is empty (a bundled-example repo), don't auto-fire suggestion: offer the choice — run the existing task, or suggest a fresh one grounded in the agent.

When in doubt, ask one question — "is your agent a Claude managed agent, or a process you run yourself?" — and route on the answer. The full journey is intake → author → verify → run; enter wherever the builder actually is.

One register verb — CLI vs MCP

There is one concept — register an agent — reached by two surfaces that are not interchangeable. Route by whether a local repo is in play; never silently swap one for the other:

• Local repo present (a pome.json-bearing repo the builder runs themselves — the self-hosted / REST examinee) → the CLI: pome register agent <name> [--twins …]. Only the CLI resolves the hosted identity and writes the local wiring — the canonical agent.slug into pome.json and the gitignored .pome/link.json id cache — so the local run/doctor path resolves the agent and its transport. The MCP tool writes neither.
• No local repo (a Claude managed agent → pome-intake / intake_clone_scope, or a purely hosted registration with nothing on disk to link) → the MCP register_agent.

If a paste-prompt or the builder spells out the CLI command, run it verbatim. Do not substitute the MCP register_agent "because it's the same registration" — it is not. Registering a local repo agent through the MCP alone leaves .pome/link.json unpopulated and the transport wrong, and a second pome register agent is then needed to repair both (the 2026-07-24 cold-walk regression, F-903).

Once an agent is registered, register_agent(name, twins:[…]) from the run path is still the right call for additive twin enablement on an already-registered agent — it merges the allowlist (F-784), it is not a fresh registration.

This is not the CLI

The pome CLI records traces locally; evaluation and scoring are hosted. If the builder arrives with the CLI mental model, map the verbs — tool names are verbatim from the frozen control MCP contract v1.0:

CLI-era habit	Hosted (coach) equivalent
pome register agent	Not a synonym for MCP register_agent — route by context (see One register verb above). A local repo keeps the CLI (it writes pome.json + .pome/link.json and sets local transport); only a no-repo / managed agent uses the MCP tool.
pome run <task>	run_task (mints the session) → launch the examinee → finalize_run the instant it idles → get_report
pome run -n 3 (N trials)	run_trials(n, task_id) — the batch form that provisions all N under one shared group_id (or run_task ×N reusing one group_id); finalize_run each; list_runs(group_id) is the cross-run view
Local task files on disk	save_task into your team catalog on first use; browse with list_tasks (no cross-team library)
"Where are my results?"	get_report(run_id) / list_runs, and the dashboard on app.pome.sh

Two standing facts to carry into every route: the examinee runs closed-book (web_search/web_fetch disabled — seed the world instead of citing the live internet), and tasks/examples ship as task source that gets save_task-ed into the builder's own team on first run.