Caveman Discover

You are labeling this repository's LLM workflows for Caveman Cloud. A workflow is a job the code performs — "answer a support ticket", "build the nightly digest", "run the eval suite" — not a technology. Every gateway request can carry a workflow label; unlabeled traffic all lands in one unlabeled-workflow bucket. Your job: find the workflows, name them well, wire the labels, and verify nothing broke.

This changes code, so it goes through the user's normal review: propose the table first, apply after the user agrees. Re-running on an already-labeled repo must change nothing (idempotent).

This skill is operator-invoked. An unlabeled-traffic Cave Plan observation is review-only and does not create an advisory file, proposal, or Draft PR. Do not infer that telemetry selected a callsite or authorized an edit. Independently inventory the repository, present the labeling table, and wait for the user's approval before changing code.

Step 1 — Inventory the workflows

Walk the repo from its entry points, not from its imports:

• HTTP/RPC handlers that call an LLM (directly or through layers)
• Scheduled jobs: cron definitions, queue consumers, workers, GitHub Actions that invoke LLM code
• CLI commands and scripts (scripts/, bin/, package.json scripts)
• Eval / test harnesses that burn real tokens
• Distinct agents or chains inside a framework (each LangGraph graph, each crew, each agent definition is usually its own workflow)

One workflow = one job a human would name. Ten callsites inside the same request handler are one workflow; one shared llm.ts helper used by three jobs is three workflows (label at the callers, never the shared helper).

Step 2 — Name them

Slug grammar (the gateway enforces this): lowercase [a-z0-9_-], 1–96 chars. Name the job, not the tech:

• Good: support-reply, nightly-digest, pr-review, eval-suite, onboarding-email