JuliusBrussee/caveman-discover

Sie kennzeichnen die LLM-Workflows dieses Repositorys für Caveman Cloud. Ein Workflow ist eine Aufgabe, die der Code ausführt – „Support-Ticket beantworten“, „Den Nacht-Digest erstellen“, „Die Evaluierungssuite ausführen“ – keine Technologie. Jeder Gateway-Request kann ein Workflow-Label tragen; unmarkierter Traffic landet in einem unlabeled-workflow Bucket. Ihre Aufgabe: die Workflows finden, gut benennen, die Labels verknüpfen und sicherstellen, dass nichts kaputtgeht.

Dies ändert Code und durchläuft daher den normalen Review-Prozess des Benutzers: Schlagen Sie zuerst die Tabelle vor, wenden Sie sie erst an, nachdem der Benutzer zugestimmt hat. Eine erneute Ausführung auf einem bereits gekennzeichneten Repository darf nichts ändern (idempotent).

Dieser Skill wird vom Benutzer aufgerufen. Eine unlabeled-traffic Cave Plan Beobachtung ist nur zur Überprüfung gedacht und erstellt keine Advisory-Datei, keinen Vorschlag und kein Draft-PR. Leiten Sie nicht ab, dass Telemetrie eine Aufrufstelle ausgewählt oder eine Bearbeitung autorisiert hat. Inventarisieren Sie das Repository eigenständig, präsentieren Sie die Kennzeichnungstabelle und warten Sie auf die Zustimmung des Benutzers, bevor Sie Code ändern.

Schritt 1 — Workflows inventarisieren

Durchsuchen Sie das Repository von seinen Einstiegspunkten aus, nicht von seinen Importen:

• HTTP/RPC-Handler, die ein LLM aufrufen (direkt oder durch Schichten)
• Geplante Jobs: Cron-Definitionen, Queue-Consumer, Worker, GitHub Actions, die LLM-Code aufrufen
• CLI-Befehle und Skripte (scripts/, bin/, package.json-Skripte)
• Evaluierungs- / Test-Harnesses, die echte Tokens verbrauchen
• Verschiedene Agenten oder Chains innerhalb eines Frameworks (jeder LangGraph-Graph, jedes Crew-Team, jede Agentendefinition ist normalerweise ein eigener Workflow)

Ein Workflow = eine Aufgabe, die ein Mensch benennen würde. Zehn Aufrufstellen innerhalb desselben Request-Handlers sind ein Workflow; ein gemeinsam genutzter llm.ts-Helper, der von drei Jobs verwendet wird, sind drei Workflows (kennzeichnen Sie die Aufrufer, niemals den gemeinsam genutzten Helper).

Schritt 2 — Workflows benennen

Slug-Grammatik (vom Gateway durchgesetzt): nur Kleinbuchstaben [a-z0-9_-], 1–96 Zeichen. Benennen Sie die Aufgabe, nicht die Technologie:

• Gut: support-reply, nightly-digest, pr-review, eval-suite, onboarding-email
• Schlecht: openai-calls (Technologie), main (sagt nichts), SupportReply (ungültig), johns-test-3 (nicht zukunftssicher)

Namen sind quasi für immer – eine spätere Umbenennung teilt die Ausgabenhistorie. Wenn der Zweck einer Aufgabe aus dem Code nicht klar hervorgeht, leiten Sie den Slug aus dem Dateinamen ab und markieren Sie ihn in der Tabelle als review, anstatt einen Zweck zu erfinden.

Schritt 3 — Vorschlagen, dann anwenden

Präsentieren Sie diese Tabelle und fragen Sie nach Fortfahren:

| workflow | job | wo | wie es gekennzeichnet wird |
|---|---|---|---|
| support-reply | beantwortet eingehende Tickets | src/bot/reply.ts:41 | defaultHeaders auf dem reply-Client |
| nightly-digest | 02:00 Zusammenfassungs-Job | jobs/digest.ts:12 | Header auf dem digest-Client |
| eval-suite (review) | scripts/eval.ts:8 — Zweck aus Dateiname abgeleitet | scripts/eval.ts:8 | env-Override beim Aufruf |

Verknüpfen Sie dann jedes Label mit dem leichtesten Mechanismus, der an dieser Aufrufstelle verfügbar ist:

• @caveman-ai/sdk / caveman_cloud SDK: Per-Trace workflow-Option oder defaultWorkflow auf dem Client, den ein Single-Job-Service erstellt.
• Rohe Provider SDKs (OpenAI/Anthropic/LangChain/LiteLLM/Vercel): Fügen Sie "x-cave-workflow": "<slug>" zum selben defaultHeaders / default_headers / extra_headers-Block hinzu, der bereits x-cave-api-key trägt. Gemeinsam genutzter Client für mehrere Jobs → übergeben Sie den Header pro Aufruf (jedes SDK oben akzeptiert per-Request-Header-Überschreibungen) oder geben Sie jedem Job seinen eigenen schlanken Client.
• Gewrappte Coding-Agenten (caveman wrap): --workflow <slug>-Flag oder CAVE_WORKFLOW=<slug>-Env an der Aufrufstelle (Cron-Zeile, CI-Schritt).
• Rohes HTTP: Fügen Sie den x-cave-workflow-Header zum Request hinzu.

Kennzeichnen Sie die Aufrufer, halten Sie das Diff minimal, passen Sie sich dem Stil des Repositorys an. Wenn eine Aufrufstelle überhaupt nicht über das Caveman-Gateway geroutet wird, kennzeichnen Sie sie nicht – listen Sie sie unter „nicht verkabelt“ im Bericht auf (Labels reisen nur auf Gateway-Traffic; die Verkabelung ist Aufgabe des caveman-setup Skills).

Schritt 4 — Verifizieren

Führen Sie aus, was das Repository bereits verwendet, um einen gekennzeichneten Pfad zu testen (einen Test, ein Dev-Skript, einen einzelnen Curl-Befehl). Bestätigen Sie dann: Der Request ist weiterhin erfolgreich (das Gateway lehnt ein ungültiges Label mit 400 cave_invalid_request_header ab – korrigieren Sie den Slug in diesem Fall). Gekennzeichnete Ausgaben erscheinen im Dashboard unter /activity?tab=workflows, sobald jeder Workflow das nächste Mal läuft; Jobs mit Zeitplan erscheinen, wenn der Zeitplan ausgelöst wird, und das ist es wert, im Bericht erwähnt zu werden, anstatt so zu tun, als wären sie live.

Schritt 5 — Bericht

## Gekennzeichnete Workflows

| workflow | job | wo |
|---|---|---|
| support-reply | beantwortet eingehende Tickets | src/bot/reply.ts:41 |
| nightly-digest | 02:00 Zusammenfassungs-Job | jobs/digest.ts:12 |

Verifiziert: <der tatsächlich getestete gekennzeichnete Pfad und was Sie beobachtet haben>
Landet in: <DASHBOARD>/activity?tab=workflows — jede Zeile erscheint, sobald dieser Workflow das nächste Mal läuft. Alles noch Unmarkierte wird als `unlabeled-workflow` angezeigt.
Nicht verkabelt (kein Gateway-Routing, daher kein Label): <Liste oder "keine">
Markiert review: <Slugs, deren Zweck aus Dateinamen abgeleitet wurde, oder "keine">

Wenn Sie überhaupt keine LLM-Einstiegspunkte gefunden haben: Sagen Sie genau das und verweisen Sie auf den Setup-Skill (<docs origin>/docs/agent-setup.md), anstatt eine Tabelle zu erfinden.