gentle-ai-bench 是 gentle-ai 仓库中的基准测试技能，用于编写与验证 gentle-ai 的 bench journey。它定义了何时加载、必须遵守的硬性规则，以及执行步骤和输出要求。
用途与加载条件 当你要触碰 gentle-ai 的 bench/ 目录、新增或修改一个 journey、变更某个 journey 可能固化的产品语义，或在 CI 的 Unit Tests 任务中诊断 bench 失败时，应加载本技能。
硬性规则
- go test ./bench 只校验语料声明，并不执行 journey。唯一的驱动证明是构建 harness 和产品二进制，并用其运行 harness；绿色的 go test ./bench 对执行结果不做任何保证。
- 复现 CI，不要猜测调用方式：阅读 .github/workflows/ci.yml 中的 Unit Tests 步骤，复制其确切的构建与 gentle-ai-bench run --binary ... 命令。使用 --only <journey-id> 驱动单个 journey。
- journey ID 在所有 journeys_*.go 文件中必须唯一。冲突守卫会失败并同时报出两个文件名；通过阅读语料挑选未使用的 ID，绝不复用已退役的 ID。
- 每个 journey 必须声明 Review：reviewOptedIn（运行器在第一步之前全局启用 receipt-driven development，不计数，若开关未开启则使该 journey 失败）或 reviewUntouched（其主体就是该开关，或与 review 无关）。该声明是强制的；缺少它 validateCorpus 会使运行失败。生命周期 journey 不得依赖产品默认值。Review 默认为 ON；reviewUntouched 并不意味着 OFF。需要 OFF 的 journey 必须显式禁用，而默认模式 journey 必须在未设置来源的情况下断言 ON/default。
- 每条 execute 转换必须携带可运行命令；否则 dead-execute 守卫会使运行失败。
- 当已批准的产品语义发生变化时，在发布前用 grep 检索语料中固化了旧行为的 journey。语料是单元测试之外的第二测试面；一个断言缺陷的 journey 会让缺陷保持绿色。
- 除非运行实际测量到了 dead_end，否则打印 n/a。绝不要为移动列而编造数值。
- by_design 豁免需要一个来自封闭词表的 shape 加上对产品自身 next-action 文本的已验证引用。如果该引用不再告诉操作者该做什么，那就是披着豁免外衣的缺陷。
- 当共享的 journeys_.go 文件被未合并的 PR 占用时，优先新建一个 journeys_.go 文件；并在同一变更中更新核心 journey 计数钉。
执行步骤
- 在编写之前，阅读你要触碰的语料区域以及 CI 调用方式。
- 编写或改编 journey；更新其标题、步骤名称和注释，说明期望为何成立（引用 issue 或已批准的决定）。
- 在 bench/ 中运行 go test ./... 做声明校验，然后运行驱动 harness 做执行验证；两项结果都写入 PR 正文。
- 对于语义变更，列出你检查过是否存在陈旧钉的 journey。
输出约定 PR 证据要包含来自本地构建二进制的驱动模式摘要行（completed / unsupported / failed 计数），而不仅仅是 go test 输出。
适用场景 本技能适用于维护 gentle-ai 基准测试语料、排查 CI 中 bench 失败、变更可能影响 journey 断言的 product semantic 等开发与测试工作流。
限制 资料未说明本技能是否有额外平台要求、收费模式或价格；也未提供除上述规则外的更多实现细节。