사용 방법
- 설치 명령을 복사하고 자신의 에이전트 환경에 설치하기 전에 소스 패키지를 확인하세요.
- 필요한 도구, 인증 정보, 지원 환경은 원본 문서에서 확인하세요.
- 입력과 원하는 산출물을 설명하고 출처와 결과를 대조하세요.
npx skills add https://github.com/juliusbrussee/caveman --skill cavecrew시작 전 확인
- 설치에는 모델 구독, API 한도, 파일 접근 권한이 포함되지 않습니다.
- 별점 수와 설치 수는 활동 지표이며 독립적인 품질·보안 검증이 아닙니다.
원본 저장소의 제목, 예시, 코드, 표, 링크, 이미지를 유지해 표시합니다.
Cavecrew = three subagent presets that answer in ultracave voice (tool runs: one status line in, one out; nothing between routine calls). Same job as Anthropic defaults (Explore, edit-style agents, reviewer); difference is the tool-result they return is compressed, so main context shrinks per delegation.
When to use cavecrew vs alternatives
| Task | Use |
|---|---|
| "Where is X defined / what calls Y / list uses of Z" | cavecrew-investigator |
| Same but you also want suggestions/architecture commentary | Explore (vanilla) |
| Surgical edit, ≤2 files, scope obvious | cavecrew-builder |
| New feature / 3+ files / cross-cutting refactor | Main thread, or feature-dev:code-architect if installed |
| Review diff, branch, or file for bugs | cavecrew-reviewer |
| Deep code review with rationale + alternatives | Code Reviewer (vanilla) if installed, else main thread |
| One-line answer you already know | Main thread, no subagent |
Rule of thumb: if you'd want the subagent's output in 1/3 the tokens, pick cavecrew. If you'd want prose, pick vanilla.
Why this exists (the real win)
Subagent tool results get injected into main context verbatim. A vanilla Explore that returns 2k tokens of prose costs 2k tokens of main-context budget every time. The same finding from cavecrew-investigator comes back as a compressed path:line table instead. Across 20 delegations in one session that's the difference between context exhaustion and finishing the task.
Output contracts
What main thread can rely on per agent:
`cavecrew-investigator`
<Header>:
- path:line — `symbol` — short note
totals: <counts>.Or No match. Always file-path-first, line-number-attached, backticked symbols. Safe to grep with path:\d+.
`cavecrew-builder`
<path:line-range> — <change ≤10 words>.
verified: <re-read OK | mismatch @ path:line>.Or one of: too-big. / needs-confirm. / ambiguous. / regressed. (terminal first token).
`cavecrew-reviewer`
path:line: <emoji> <severity>: <problem>. <fix>.
totals: N🔴 N🟡 N🔵 N❓Or No issues. Findings sorted file → line ascending.
Chaining patterns
Locate → fix → verify (most common):
cavecrew-investigatorreturns site list.- Main thread picks 1-2 sites, hands paths to
cavecrew-builder. cavecrew-revieweraudits the diff.
Parallel scout (when investigation is broad): Spawn 2-3 cavecrew-investigator calls in one message (different angles: defs vs callers vs tests). Aggregate in main thread.
Single-shot edit (when site is already known): Skip investigator. Hand exact path:line to cavecrew-builder directly.
What NOT to do
- Don't use
cavecrew-builderwhen you don't already know the file. Spawn investigator first or main thread will eat tokens passing context. - Don't chain
cavecrew-investigator → cavecrew-builderfor a 5-file refactor. Builder will returntoo-big.and you'll have wasted a turn. - Don't ask
cavecrew-reviewerfor "general feedback" — it returns findings only, no architecture opinions. UseCode Reviewerfor that when installed. - Don't expect prose. Cavecrew output is structured, sometimes terse to the point of cryptic. If a human will read it directly, paraphrase.
Auto-clarity (inherited)
Subagents drop caveman → normal English for security warnings, irreversible-action confirmations, and any output where fragment ambiguity could be misread. Resume caveman after.
