mcpField
C
cavecrew

cavecrew

github.com/rheinmirAgent 工作流10262 次安装2 周前更新
代码仓库

关于 cavecrew

cavecrew 提供代码调查、有限修改和审查三种子 Agent 预设，并以压缩的结构化格式返回结果，适合希望减少主 Agent 上下文占用的委派任务。

主要功能

  1. 01调查、构建与审查预设
  2. 02压缩的结构化子 Agent 结果
  3. 03含文件路径和行号的调查发现
  4. 04带验证状态的有限修改
  5. 05按文件和行号排序的审查发现

适用场景

  1. 01定位定义与调用处
  2. 02委派范围明确的小型修改
  3. 03检查代码差异中的错误
  4. 04并行调查代码库

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/rheinmir/setup --skill cavecrew

安装后在 Claude Code 中输入/cavecrew确认已加载。

详细介绍

Cavecrew = 3 个输出穴居人风格内容的子 Agent 预设。它们与 Anthropic 默认配置（Explore、编辑类 Agent、审查者）执行相同的任务；区别在于它们返回的工具结果经过压缩，因此每次委派都会减少主上下文的占用。

何时使用 cavecrew，何时使用其他方案

任务使用
“X 定义在哪里／什么调用了 Y／列出 Z 的所有用法”cavecrew-investigator
同上，但还想要建议／架构方面的评论Explore（原版）
精准编辑，不超过 2 个文件，范围明确cavecrew-builder
新功能／3 个以上文件／跨领域重构主线程或 feature-dev:code-architect
审查差异、分支或文件中的错误cavecrew-reviewer
深入代码审查，并提供理由和替代方案Code Reviewer（原版）
已经知道答案的单行问题主线程，不用子 Agent

经验法则：如果你希望子 Agent 的输出缩短到三分之一的 Token，就选 cavecrew。如果你想要的是散文式输出，就选原版。

为什么要这样做（真正的优势）

子 Agent 的工具结果会原封不动地注入主上下文。原版 Explore 返回 2k Token 的散文，每次都会占用主上下文预算中的 2k Token。cavecrew-investigator 返回相同发现时只需约 700 Token。在一次会话中委派 20 次，这就决定了你会耗尽上下文，还是能完成任务。

输出约定

主线程可以依赖各 Agent 提供以下输出：

cavecrew-investigator

<Header>:
- path:line — `symbol` — short note
totals: <counts>.

或 No match. 始终优先给出文件路径，并附上行号；符号用反引号括起。可安全地用 path:\d+ 进行 grep。

cavecrew-builder

<path:line-range> — <change ≤10 words>.
verified: <re-read OK | mismatch @ path:line>.

或以下之一：too-big.／needs-confirm.／ambiguous.／regressed.（首个 Token 表示终止状态）。

cavecrew-reviewer

path:line: <emoji> <severity>: <problem>. <fix>.
totals: N🔴 N🟡 N🔵 N❓

或 No issues. 发现按文件、再按行号升序排列。

串联模式

定位 → 修复 → 验证（最常见）：

  1. cavecrew-investigator 返回位置列表。
  2. 主线程选出 1–2 个位置，将路径交给 cavecrew-builder。
  3. cavecrew-reviewer 审查差异。

并行侦察（调查范围较广时）： 在一条消息中启动 2–3 次 cavecrew-investigator 调用（从不同角度调查：定义、调用方、测试）。由主线程汇总结果。

单次编辑（已知位置时）： 跳过 investigator。直接将精确的路径:行号交给 cavecrew-builder。

不要这样做

  • 不要在尚不知道文件位置时使用 cavecrew-builder。先启动 investigator，否则主线程会浪费 Token 来传递上下文。
  • 不要为包含 5 个文件的重构串联 cavecrew-investigator → cavecrew-builder。Builder 会返回 too-big.，你就白白浪费了一轮。
  • 不要向 cavecrew-reviewer 索要“总体反馈”——它只返回发现，不提供架构方面的意见。需要架构意见时使用 Code Reviewer。
  • 不要期待散文式输出。Cavecrew 的输出是结构化的，有时简短到难以理解。如果人类要直接阅读，请改写。

自动清晰化（继承）

对于安全警告、不可逆操作确认，以及片段歧义可能导致误读的任何输出，子 Agent 会将穴居人风格转换为正常英语。之后恢复穴居人风格。

输出报告

所有主要技能任务完成后，将提案草稿写入 wiki。

步骤

1. 构建文件名：

  • 格式：DDMMYY-<ten>.md
  • DDMMYY = 今天的日期（例如，2026 年 6 月 2 日对应 020626）
  • <ten> = 用 2–4 个 kebab-case 单词概括完成的工作（例如，landing-page-coteccons、brand-kit-fintech、ingest-auth-spec）

2. 写入 llmwiki/wiki/draft/cave/DDMMYY-<ten>.md：

# DDMMYY-<ten>
**Type:** draft
**Status:** proposed
**Tags:** <skill-name>, output-report
**Proposed:** YYYY-MM-DD

## What
<One sentence — what this skill invocation produced or decided>

## Output
<Key artefacts, files created/modified, or decisions made>

## Files
| File | Action |
|------|--------|
| `path/to/file` | created / modified |

## Notes
- Invoked via: `/<skill-name>` skill

## Origin
- **Draft:** `wiki/draft/cave/DDMMYY-<ten>.md`
- **Commit:** _(filled by verify-before-commit)_
- **Date promoted:** _(filled by verify-before-commit)_

3. 更新 wiki 索引和日志：

  • llmwiki/wiki/index.md — 追加一行：| [DDMMYY-<ten>](draft/cave/DDMMYY-<ten>.md) | draft | YYYY-MM-DD |
  • llmwiki/wiki/log.md — 追加：## YYYY-MM-DD — <skill-name> — <ten>

仅当该技能未产出任何成果且未作出任何决策时才跳过（例如，像 /caveman-stats 这样的纯显示模式）。

评论

支持 Markdown