pome-sh/digital-twins

Pome (Einstiegsrouter)

Du bist der Coach: Du sprichst mit dem Builder und mit der Pome-Steuerungs-MCP (mcp.pome.sh). Der Prüfling ist ein Sandbox-Klon seines Agenten, der gegen Pomes digitale Zwillinge läuft und anhand des Live-Zwillingsbands bewertet wird. Dieser Skill macht genau eine Sache: Er liest den Kontext des Builders und übergibt an den richtigen Coach-Skill. Improvisiere hier keine Pipeline.

Wenn die mcp__pome__*-Werkzeuge fehlen, ist die MCP nicht verbunden: Bitte den Benutzer, sie zu verbinden und zu authentifizieren (interaktiver OAuth – benötigt einen Menschen im Browser): claude mcp add --transport http pome https://mcp.pome.sh/mcp.

Nach Kontext routen

Der Builder kommt mit…	Route
Einem Claude Managed-Agent-YAML (eingefügt oder „Teste meinen Managed Agent“)	pome-intake – den Clone-Scope erfassen, über intake_clone_scope registrieren, Twin-Abdeckung melden
Einem registrierten eigenen Agenten – einem Repository mit pome.json aber noch keiner Aufgabe („Teste meinen Agenten“ / „Was soll ich testen?“, tasks/ leer und list_tasks leer)	pome-suggest-tasks – das Manifest (twins) + das Prompt/den Code des Agenten lesen, fundierte Kandidaten vorschlagen, durch Befragung einen auswählen, dann die Authoring-Kette
Einem lokalen Repo-Agenten / selbst gehosteten Prozess (spricht REST, kein Managed-Agent-YAML)	Den lokalen Prüflingspfad: mit der CLI registrieren – pome register agent <name> [--twins …], dies schreibt pome.json + .pome/link.json und setzt den lokalen Transport (die MCP register_agent tut das nicht – siehe Ein Register-Verb unten). Dann pome-run-task – run_task erzeugt die Sitzung und den Launch-Spez; starte den Prozess selbst über den REST-Launcher (pome-run-task/references/launch-rest.md), der die Verkabelung vorprüft (Config → Twin erreichbar → Routing → Egress-Stufe, die pome doctor-Prüfungen) bevor er startet
„Was soll ich testen?“ / eine Sorge, die in eine benotete Prüfung umgewandelt werden soll	pome-author-task – Library-first Authoring, [code]/[model]-Kriterien, validieren → Trockentest → save_task
Einer entworfenen Aufgabe, erster Lauf steht an („Ist mein Seed richtig?“)	pome-verify-seed – Fair-Exam-Triage, bevor etwas läuft
Einer verifizierten Aufgabe zur Ausführung („Führe meine Aufgaben aus“, „Wie hat mein Agent abgeschnitten?“)	pome-run-task – erzeugen, starten, finalize_run bei Leerlauf, get_report erzählen

Registriert, aber ungetestet (der F-891-Kaltstart). Erkenne dies zuerst lokal, sodass die Route sogar aufgelöst wird, bevor die MCP verbunden ist: eine pome.json im Repository-Stammverzeichnis, dessen tasks-Verzeichnis keine .md-Dateien enthält, und – wenn die MCP läuft – eine leere list_tasks. Beide leer → der Builder hat einen Agenten, aber keine erste Aufgabe → pome-suggest-tasks. Wenn lokale Aufgaben-Dateien vorhanden sind, der Katalog aber leer ist (ein Repository mit gebündelten Beispielen), löse keinen automatischen Vorschlag aus: Biete die Wahl an – die vorhandene Aufgabe ausführen oder eine neue, auf den Agenten abgestimmte, vorschlagen.

Bei Unsicherheit stelle eine Frage – „Ist dein Agent ein Claude Managed Agent oder ein Prozess, den du selbst ausführst?“ – und route basierend auf der Antwort. Die gesamte Reise ist Aufnahme → Author → Verifizieren → Ausführen; steige dort ein, wo der Builder tatsächlich ist.

Ein Register-Verb – CLI vs. MCP

Es gibt ein Konzept – einen Agenten registrieren – das über zwei Oberflächen erreicht wird, die nicht austauschbar sind. Route danach, ob ein lokales Repository im Spiel ist; ersetze niemals stillschweigend eine durch die andere:

• Lokales Repository vorhanden (ein pome.json-tragendes Repository, das der Builder selbst ausführt – der selbst gehostete / REST-Prüfling) → die CLI: pome register agent <name> [--twins …]. Nur die CLI löst die gehostete Identität und schreibt die lokale Verdrahtung – den kanonischen agent.slug in pome.json und den gitignorierten .pome/link.json-ID-Cache – damit der lokale Run/Doctor-Pfad den Agenten und seinen Transport auflöst. Das MCP-Werkzeug schreibt keines von beiden.
• Kein lokales Repository (ein Claude Managed Agent → pome-intake / intake_clone_scope, oder eine rein gehostete Registrierung ohne etwas auf der Festplatte zum Verknüpfen) → die MCP register_agent.

Wenn ein Einfüge-Prompt oder der Builder den CLI-Befehl buchstabiert, führe ihn wortwörtlich aus. Ersetze ihn nicht durch die MCP register_agent, „weil es dieselbe Registrierung ist“ – das ist sie nicht. Das Registrieren eines lokalen Repo-Agenten allein durch die MCP lässt .pome/link.json unpopuliert und den Transport falsch, und ein zweites pome register agent ist dann nötig, um beides zu reparieren (die Kaltstart-Regression vom 24.07.2026, F-903).

Sobald ein Agent registriert ist, ist register_agent(name, twins:[…]) aus dem Run-Pfad dennoch der richtige Aufruf für additive Twin-Aktivierung bei einem bereits registrierten Agenten – es führt die Whitelist zusammen (F-784), es ist keine Neuregistrierung.

Dies ist nicht die CLI

Die pome CLI zeichnet Traces lokal auf; Evaluierung und Benotung sind gehostet. Wenn der Builder mit dem CLI-Mentalmodell kommt, ordne die Verben zu – Werkzeugnamen sind wörtlich aus dem eingefrorenen MCP-Steuerungsvertrag v1.0:

CLI-Ära-Gewohnheit	Gehostetes (Coach)-Äquivalent
pome register agent	Kein Synonym für MCP register_agent – nach Kontext routen (siehe Ein Register-Verb oben). Ein lokales Repository behält die CLI (sie schreibt pome.json + .pome/link.json und setzt den lokalen Transport); nur ein repo-loser / Managed Agent verwendet das MCP-Werkzeug.
pome run <task>	run_task (erzeugt die Sitzung) → Prüfling starten → finalize_run sobald er in den Leerlauf geht → get_report
pome run -n 3 (N Durchläufe)	run_trials(n, task_id) – die Batch-Form, die alle N unter einer gemeinsamen group_id bereitstellt (oder run_task ×N unter Wiederverwendung einer group_id); jedes finalize_run; list_runs(group_id) ist die durchlaufübergreifende Ansicht
Lokale Aufgaben-Dateien auf der Festplatte	save_task in deinen Team-Katalog bei der ersten Nutzung; durchstöbern mit list_tasks (kein teamübergreifender Library-Zugriff)
„Wo sind meine Ergebnisse?“	get_report(run_id) / list_runs, und das Dashboard auf app.pome.sh

Zwei ständige Fakten, die in jede Route einfließen: Der Prüfling läuft Closed-Book (web_search/web_fetch deaktiviert – stattdessen die Welt seeden, anstatt das Live-Internet zu zitieren), und Aufgaben/Beispiele werden als Aufgaben-Quelle ausgeliefert, die beim ersten Durchlauf per save_task in den eigenen Team-Katalog des Builders gespeichert wird.