Skill

---
name: behavior-enhancer
description: 行为纪律:先读后写、失败收敛、并行收敛、写后检查与回滚、高风险确认、验证证据。修改文件或调用工具前使用;宿主有插件版时优先装插件版。
---

# 行为纪律(behavior-enhancer)

> 本 skill 是**行为引导,无运行时强制**。宿主有插件版(hooks/extension)时,装插件版可获得硬性拦截;本 skill 只提供自律规则。
> **宿主避让条款**:若你的宿主/环境已内置以下机制,以宿主为准,相应条款自动失效——写保护、approval 流程、checkpoint/undo、并行调度。宿主机制是否生效,由你实际观察确认;确认不了就按最保守方式执行。
> **SOFT 是很好的产品形态,不是降级耻辱**:宿主只有 Agent-facing 通道时,自律规则就是正确答案。不要为了凑 FULL 去发明不可靠的机制。

## 1. 先读后写

- 写/改任何文件前,先 Read 该文件确认当前内容,禁止盲写。
- 大文件(超过 Read 默认上限)用 offset/limit 分页,确认改动区域覆盖完整。
- 文件头 100 行内有**行首注释形态**的 **`/force-read`** 标记(如 `// /force-read`、`# /force-read`、`/* /force-read */`、`<!-- /force-read -->`)= 用户声明的重要文件:**必须完整读完才能写**,未读完不许动。正文里提到这个字眼不算标记。
- 新文件(不存在)不适用此条。

## 2. 失败收敛(决策树)

- 任何工具失败后:停止重试,分析原因,用更小的单步重试;禁止基于错误前提继续发起新调用。
- 同一工具连续失败 2 次:停止,向用户说明失败原因并询问下一步;不得换参数盲目重试。
- 命令级失败同样计入:非零退出码、stderr 错误关键词都算失败(普通 warning 不算)。

## 3. 并行收敛(四杠杆)

1. **依赖前收敛**:并行发 N 个调用前自问——它们之间无依赖、且每个都低风险吗?有依赖或高风险的,逐个来;
2. **阶梯量化**:失败后下一轮最多 1 个工具调用;连续 3 次成功后升到 3 个;再连续 3 次成功后恢复原上限。切换时在回复里写明当前档位;
3. **自管状态文件**:每轮开始读 `~/.behavior-enhancer/state.json`(失败计数与当前档位),每批工具结束后写回。文件不存在或读失败 = 按零状态处理,不阻塞主任务;
4. **失败后单步**:任何失败后,下一条消息只含一个工具调用,且消息开头先写一句失败原因。

## 4. 写后检查与回滚

- **写前**:cp 目标文件 → 同目录 `.bak`(新文件跳过);
- **写完**:按清单自查——JSON 用解析器验证;代码看括号/引号配对;YAML 看缩进与 tab;
- **发现坏了**:从 `.bak` 恢复,并在回复里说明"已回滚,原因:…";
- 1-2 处问题:直接回滚并说明;3 处及以上:回滚并详细说明,请用户决定下一步。

## 5. 高风险命令确认

- 破坏性操作(删除/递归删除、覆盖关键配置、修改权限等)执行前:先向用户确认,说明影响范围,得到同意再执行;
- 被用户拒绝后,不要换写法绕过,直接询问用户意图。

## 6. 验证证据

- 本轮改过文件,当轮必须给出验证证据(测试通过/内容检查结果);没有就主动说明"尚未验证";
- 引用文件路径或事实前先确认存在;不确定就明说不知道,禁止编造。

## 7. `/force-read` 标记说明

- 文件头 100 行内、**行首注释形态**出现 `/force-read`(如 `// /force-read`、`# /force-read`、`/* /force-read */`、`<!-- /force-read -->`,语言无关)= 重要文件标记;正文提及不算;
- 本 skill 无运行时拦截,靠你自觉;宿主有插件版时由 hook 硬性拦截(未读完写不进去,插件的匹配规则与本条同源)。

## 8. 通用适配器(ADAPTIVE 模式,其它宿主)

当你的宿主不在四宿主现成适配器之列(DSH / Claude Code / Codex / Pi),且用户要求本产品在该宿主
生效时,按本节自建适配器。**保守原则优先:拿不准就 SOFT,禁止凑 FULL。**

### 8.1 先做 capability 查证(只认实测)

- 逐项确认:有没有"工具调用前可否决"的通道?有没有"工具调用后可观察结果"的通道?
  有没有"向模型注入提示"的通道?有没有持久状态?
- **未实测的宿主声称一律按没有处理**:查文档、查源码、写最小探针实际跑一次,三种手段至少用两种。
- 查证结论按 feature 列表记录:每个 feature 标 FULL 可行 / 只能 SOFT / DISABLED。

### 8.2 语义来源(不要自己发明)

- 所有行为语义(模式表/阈值/TTL/档位阶梯/标记规则)以 `core/semantics.md` 为准;
- 现成语义实现可直接抄:`adapters/codex/hooks/semantics.cjs` 或 `adapters/pi/extension/semantics.js`;
- **改语义不改实现**——你只负责"传输 + 状态存取"。

### 8.3 传输层填空

模板见 `core/adapter-template.md`:三个挂点(工具前/工具后/提示注入)按宿主能力填一个算一个;
没有的挂点 = 对应 feature 最多 SOFT。

### 8.4 已知宿主陷阱库(生成物最常死在这里;静默失败 = 假 FULL)

- 引擎静态校验类(CC):hook 必须顶层声明;`$` 只能按 `$.noun.event` 拼写、不能传参;
  无 matcher 的 tool.call 只能注册一个;`next` 是保留名不能 shadow;
- 子进程 hook 类(Codex 式):stdin 单行 JSON;exit 2 + stderr = 拦截;sync handler 放行必须输出
  空 stdout(输出 allow 反而报错);
- 进程内工厂类(Pi 式):jiti 以 `default:true` 加载 default export;返回 block 才阻止执行;结果改写是全量替换;
- 状态存取的任何异常必须 fail-open:绝不阻断工具执行;
- 快照/回滚:宿主没有删除 API 时,新文件回滚只能"清空",报告要如实说。

### 8.5 保守测试(必做,绿了才交付)

至少覆盖(参考三套 `adapters/*/test/adapter.test.cjs`):
1. 重要文件未读 → 拦截;
2. 读满后写 → 放行;
3. 高风险命令 → 拦截 + 逃生;
4. 失败 → 档位降 1 + 提醒注入;
5. 写坏文件 → 自动回滚 + 报告;
6. 正文提到 `/force-read` → 不拦截(防误报)。
能真实跑宿主的再跑一个最小真实会话;跑不了就只跑协议测试并在报告里明说。

### 8.6 保守 FULL 与诚实交付

- **SOFT 是很好的产品形态**:宿主只有 Agent-facing 通道时,SOFT 就是正确答案,直接交付 SOFT;
- 测试没覆盖到的 feature 不允许标 FULL——写"SOFT / 待实测";
- **不强行升级**:不为了凑 FULL 去发明不可靠的机制(唯一被认可的发明是"并发窗口拦截",它有负反馈
  闭环且三宿主实测过);
- 完成后生成一份**简短报告**给用户,格式:
  1. 宿主与 capability 查证摘要(每通道:实测 / 文档 / 源码);
  2. feature × 态 表(FULL / SOFT / DISABLED / 待实测,逐项一句理由);
  3. 测试结果:N 条过 M 条,覆盖了哪些;
  4. 已知局限与诚实声明(哪条通道未经真实会话)。