git:20260827.af0a875 to git:20260902.0cc9708

- 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). Use when the user says "test my agent with pome", "run pome", or "use pome".

- (`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`.

- | 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 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).

- 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, it is not a fresh

- registration.

- 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:

- | `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) |

- 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.