Your own agent, from repo to scored run

Connect this repo to Pome as my own agent — take it up to a registered agent
with a written pome.json, and stop there. Do not run it yet.

1. Confirm I've already seen a scored run on the bundled support-triage
   example (the capstone). If I haven't, tell me to do that first — the
   example is how the loop is taught.
2. Scaffold the manifest so I never hand-write it: run `pome init` in this
   repo (use `pome init --sdk claude` if this is a Claude Agent SDK project).
   That writes a starter pome.json.
3. Set `command` in pome.json to how THIS agent actually starts (e.g. `npm
   start`, detected from package.json / the repo), and set `twins` to the
   services it uses. Confirm both with me before writing them.
4. Register the agent so runs scope to this project:
   `pome register agent "<a short name>" --twins <services it uses, e.g. github,slack>`.
   This POSTs the identity and writes the server-canonical agent.slug back
   into pome.json.
5. Show me the final pome.json (agent.slug + command + twins) and the
   dashboard line register printed. Stop here — the first run is the next step.

Guardrails: keep every command plain text and show it to me before running;
never write secrets or URLs into source. pome.json is safe to commit; the
agt_ id register caches under .pome/ is not — leave it gitignored.

pome doctor

pome run

Test my own agent with pome, end to end, and take it to a scored report.

First present this plan as a short checklist and ask "Shall I proceed?" —
wait for my yes before running anything.

1. Read pome.json for agent.slug, agent.version, command and twins. If there
   is no pome.json, stop and tell me: registration is the step above this one.
2. Preflight with `pome doctor` and stop at the first red. Do not launch a run
   on a red preflight — there is no override, and a mis-wired agent scores
   nothing.
3. Propose the task (pome-suggest-tasks): read my agent's prompt and its tool
   set, then give me 2-3 candidates, one line each — the fear, the twin, the
   bad end-state vs the good one. Ground every candidate in something you
   actually read in this repo, never a generic template, and drop any that
   touches a twin outside pome.json's twins list. Adapt the nearest task in the
   bundled library or my team catalog (list_tasks) before writing a fresh one.
   I pick one.
4. Draft it (pome-author-task), then validate_task and save_task. Keep the
   task id.
5. Check the exam is fair before spending a run on it (pome-verify-seed):
   verify_seed plus an evaluate_criteria dry-run. A criterion that already
   passes on the seed measures nothing — tell me and fix it rather than
   running it.
6. Run it (pome-run-task): mint a fresh grp_ group id, call run_task with the
   task id, my agent and the agent_version from pome.json, then launch my
   agent from the manifest's `command` with every key in examinee_launch.env
   exported verbatim — the whole block, without picking out the ones you
   recognise; it carries the twin bearer and the telemetry wiring, and a
   cherry-picked subset is how that goes missing. Call finalize_run the instant
   my agent idles, while the sandbox is still live.
7. get_report(run_id). Show me the score, the criteria table, the criterion
   that failed with its evidence pointer, and the dashboard link.

Guardrails: pause after the checklist for my go-ahead; keep every command plain
text and show it to me before running; never pipe remote scripts into a shell;
the run's bearer stays in env and is never written to a file, logged, or
repeated back to me.