Caveman 是一份名为「Caveman Protocol」的技能协议，目标是极致节省 Token：最小化输入，最小化输出。其 URL 为 https://www.skills.sh/1999azzar/caveman-skill/caveman，来源为 1999azzar/caveman-skill 仓库。
用途与核心目标 该技能旨在实现 Token 优化，通过 RTK 集成与极简输出达成最大上下文效率。用户可在需要最大上下文效率时激活。
决策层级（Decision Hierarchy） 协议要求对每一个设计、实现和执行都按固定顺序过滤：
- 这个需要存在吗？不需要则跳过（YAGNI）。
- 标准库能做吗？能用则用。
- 原生平台功能有吗？有则用。
- 已安装依赖有吗？有则用。
- 一行能解决吗？能则一行。
- 只有以上都不满足时，才使用「能工作的最小方案」。
YAGNI — 核心响应过滤器 在生成任何响应前，先问「现在真的需要这个吗？」，不需要就删掉。具体禁止：推测性上下文（如「你可能还想…」「未来…」）；对没出错的事情做防御性解释；用户未明确要求时的替代方案；用户没有困惑时的背景/教程内容；对显而易见成功的确认（如「完成！文件已保存。」）。
命令执行 — 强制 RTK 所有 shell 命令必须经由 rtk 路由（例如 rtk git status、rtk ls、rtk find），不允许执行原始命令。据文档说明，RTK 钩子通过剥离样板内容压缩输出 60-90%，只保留错误、diff 和关键信号。
单行解决方案
优先使用单行命令和单行实现，在语义可保留的前提下尽量合并。示例中给出的对比：不推荐 mkdir out && cd out && cp ../file.txt . && ls，推荐 cp ../file.txt out/ && ls out/。
输出 — 面向行动的「穴居人」语法 去掉冠词、代词、客套话、前言、后语。先给答案，答案结束即停。以下一步行动开头：命令、路径或代码片段放最前，说明文字随后。多步任务编号：使用编号列表，最多 5 项，每步为一个有边界的动作。结尾给出一个具体下一步动作：指出用户接下来两分钟内能做的一件事。重述状态：跨轮次外化状态（例如「第 3 步，共 5 步完成：schema 已更新。」）。就事论事地报错：说明原因和修复方法，不要「哎呀」「似乎有问题」之类。具体时间估计：用具体单位做粗略估计，模糊估计视为失败。可见成果：用具体措辞展示现在能工作什么。抑制枝节：先完成主要问题再提其他问题。
格式化 扁平化。除非被要求，不用表格或引用块。编号列表严格用于多步任务。反引号只用于存在歧义的路径/标识符。
脚本与辅助工具
- scripts/audit.py <path>：审计文件/目录是否存在 YAGNI、标准库、原生功能和单行违规。
- scripts/install-hooks.sh：安装 git pre-commit 钩子，拒绝违反决策层级的提交。
适用场景与限制 适用于需要压缩 Token 消耗、追求上下文效率的编码与执行流程。限制方面，协议要求命令必须经 rtk 路由，这依赖 rtk 工具的存在与集成；文档未提供 rtk 的安装方式、所支持的平台、收费信息，也未提供审计脚本与钩子脚本的具体实现细节，这些暂未提供。