귀하는 이 저장소의 LLM 워크플로우를 Caveman Cloud에 라벨링하고 있습니다. 워크플로우는 기술이 아닌, 코드가 수행하는 작업입니다 — "지원 티켓에 답변", "야간 다이제스트 생성", "평가 제품군 실행" 등. 모든 게이트웨이 요청은 워크플로우 라벨을 전달할 수 있습니다. 라벨이 없는 트래픽은 모두 하나의 unlabeled-workflow 버킷으로 모입니다. 귀하의 임무: 워크플로우를 찾고, 잘 이름을 지정하고, 라벨을 연결하고, 아무것도 손상되지 않았는지 확인하는 것입니다.
이 작업은 코드를 변경하므로, 사용자의 일반적인 리뷰 과정을 거칩니다: 먼저 테이블을 제안하고, 사용자가 동의한 후에 적용하십시오. 이미 라벨링된 저장소에서 다시 실행하면 아무것도 변경되지 않아야 합니다(멱등성).
이 스킬은 운영자가 호출합니다. unlabeled-traffic Cave Plan 관찰은 검토 전용이며, 조언 파일, 제안서 또는 Draft PR을 생성하지 않습니다. 텔레메트리가 호출 사이트를 선택했거나 편집을 승인했다고 추론하지 마십시오. 독립적으로 저장소를 목록화하고, 라벨링 테이블을 제시한 후, 코드를 변경하기 전에 사용자의 승인을 기다리십시오.
1단계 — 워크플로우 목록 작성
저장소를 진입점부터 탐색하되, 임포트부터는 탐색하지 마십시오:
- LLM을 호출하는 HTTP/RPC 핸들러(직접 또는 계층을 통해)
- 예약된 작업: 크론 정의, 큐 소비자, 워커, LLM 코드를 호출하는 GitHub Actions
- CLI 명령 및 스크립트(
scripts/,bin/, package.json 스크립트) - 실제 토큰을 소모하는 평가/테스트 하네스
- 프레임워크 내의 개별 에이전트 또는 체인(각 LangGraph 그래프, 각 crew, 각 에이전트 정의는 일반적으로 자체 워크플로우)
하나의 워크플로우 = 사람이 이름을 지을 하나의 작업입니다. 동일한 요청 핸들러 내의 10개 호출 사이트는 하나의 워크플로우입니다. 세 가지 작업에서 사용하는 공유 llm.ts 헬퍼는 세 개의 워크플로우입니다(호출자에서 라벨링하고, 공유 헬퍼에서는 절대 라벨링하지 마십시오).
2단계 — 이름 지정
Slug 문법(게이트웨이에서 강제): 소문자 [a-z0-9_-], 1–96자. 작업의 이름을 지정하고, 기술의 이름을 지정하지 마십시오:
- 좋은 예:
support-reply,nightly-digest,pr-review,eval-suite,onboarding-email - 나쁜 예:
openai-calls(기술),main(의미 없음),SupportReply(유효하지 않음),johns-test-3(지속 불가)
이름은 거의 영구적입니다 — 나중에 이름을 바꾸면 지출 내역이 분할됩니다. 작업의 목적이 코드에서 명확하지 않은 경우, 파일 이름에서 slug를 파생시키고 테이블에 review로 표시하십시오. 목적을 임의로 만들지 마십시오.
3단계 — 제안 후 적용
다음 테이블을 제시하고 진행을 요청하십시오:
| 워크플로우 | 작업 | 위치 | 라벨링 방법 |
|---|---|---|---|
| support-reply | 인바운드 티켓에 답변 | src/bot/reply.ts:41 | reply 클라이언트의 defaultHeaders |
| nightly-digest | 02:00 요약 작업 | jobs/digest.ts:12 | digest 클라이언트의 헤더 |
| eval-suite (review) | scripts/eval.ts:8 — 목적은 파일 이름에서 추론 | scripts/eval.ts:8 | 호출 시 env 재정의 |
그런 다음 해당 호출 사이트에서 사용 가능한 가장 가벼운 메커니즘으로 각 라벨을 연결하십시오:
- @caveman-ai/sdk / caveman_cloud SDK: 추적별
workflow옵션, 또는 단일 작업 서비스가 생성하는 클라이언트의defaultWorkflow. - 원시 제공자 SDK (OpenAI/Anthropic/LangChain/LiteLLM/Vercel): 이미
x-cave-api-key를 전달하는 동일한defaultHeaders/default_headers/extra_headers블록에"x-cave-workflow": "<slug>"를 추가하십시오. 여러 작업에서 사용하는 공유 클라이언트 → 호출별로 헤더를 전달(위의 모든 SDK는 요청별 헤더 재정의를 허용함)하거나, 각 작업에 자체 클라이언트를 제공하십시오. - 래핑된 코딩 에이전트 (
caveman wrap): 호출 사이트(크론 라인, CI 단계)에서--workflow <slug>플래그 또는CAVE_WORKFLOW=<slug>환경 변수. - 원시 HTTP: 요청에
x-cave-workflow헤더를 추가하십시오.
호출자에 라벨을 지정하고, diff를 최소화하며, 저장소 스타일을 따르십시오. 호출 사이트가 전혀 Caveman 게이트웨이를 통해 라우팅되지 않는 경우, 라벨을 지정하지 말고 보고서에 "연결되지 않음" 아래에 나열하십시오(라벨은 게이트웨이 트래픽에서만 전달됩니다. 연결은 caveman-setup 스킬의 작업입니다).
4단계 — 검증
저장소에서 이미 사용 중인 것을 실행하여 라벨이 지정된 경로 하나를 테스트하십시오(테스트, 개발 스크립트, curl 하나). 그런 다음 확인하십시오: 요청이 여전히 성공하는지(게이트웨이가 잘못된 라벨을 400 cave_invalid_request_header로 거부합니다 — slug를 수정하십시오). 라벨이 지정된 지출은 각 워크플로우가 다음에 실행될 때 /activity?tab=workflows에서 대시보드에 나타납니다. 예약된 작업은 스케줄이 실행될 때 나타나며, 이는 보고서에서 언급할 가치가 있습니다. 마치 지금 실행 중인 것처럼 가장하지 마십시오.
5단계 — 보고
## 라벨링된 워크플로우
| 워크플로우 | 작업 | 위치 |
|---|---|---|
| support-reply | 인바운드 티켓에 답변 | src/bot/reply.ts:41 |
| nightly-digest | 02:00 요약 작업 | jobs/digest.ts:12 |
검증됨: <실제로 테스트한 라벨링된 경로와 관찰 결과>
위치: <DASHBOARD>/activity?tab=workflows — 각 행은 해당 워크플로우가 다음에 실행될 때 나타납니다.
여전히 라벨링되지 않은 모든 것은 `unlabeled-workflow`로 표시됩니다.
연결되지 않음(게이트웨이 라우팅이 없으므로 라벨 없음): <목록 또는 "없음">
리뷰 표시됨: <파일 이름에서 목적이 추론된 slug, 또는 "없음">
LLM 진입점을 전혀 찾지 못한 경우: 정확히 그렇게 말하고, 테이블을 조작하는 대신 설정 스킬(<문서 원본>/docs/agent-setup.md)을 가리키십시오.