session-bash-audit

Session Bash 审计

衡量 Claude Code 会话实际如何使用 Bash 工具，并与始终加载的指令文件中规定的 Bash 规则进行对照，再将数据转化为关于应在_何处_修复的判断。首次运行（2026-08-24，四天内共 3,956 次调用）的分析记录在 references/research.md 中——解读新一轮运行前，请先阅读其中的“根本原因”和“模式对比”部分；大部分分析都适用，无需重新推导。

读取 ~/.claude/——转录记录存储目录 ~/.claude/projects/*.jsonl，以及用于权限重放的 ~/.claude/settings.json。两者都是 Claude Code 自有的只读数据，绝不会被写入，因此任何运行 Claude Code 的机器都可以使用，无需安装任何东西。其他运行环境没有可供读取的数据，脚本会对此作出说明，而不是报告零值。此处附带的测量数据和基准来自一位作者的机器，且使用了一套规则——请将它们视为比较参照，而非你自己的基准；首次运行时请保存自己的数据。

此处的每种模式都是 POSIX shell 习惯用法——&&、;、|、cd、sed -n、here-doc——因此审计描述的是 Bash 工具运行 POSIX shell 的会话。在 Windows 上，这类会话使用 Git Bash 或 WSL，规则同样适用；PowerShell 会话生成的命令与这些模式都不匹配，因此报告会显示“未发现问题”，但实际含义是“此转录记录不适用该工具”。在有人用真实的 PowerShell 转录记录运行此脚本之前，如果 Windows 上的运行结果干净得可疑，请优先将其视为第二种情况，而非第一种。

cd-own-repo 和 git-C-own-repo 根据 Claude Code 为项目目录生成 slug 的方式，判断“自有仓库”。直到 2026-09-05，这两项在所有平台上都判断错误：它们会替换 / 和 .，而运行环境会替换_所有_非 ASCII 字母或数字的字符（根据当天 CLI 二进制文件读取的规则；超过 200 个字符时会附加哈希后缀）。因此，路径中带下划线的仓库始终无法匹配，这两行会报告零值，看起来像是完全遵守了规则。现在脚本采用运行环境自身的规则，因此 Windows 路径（\、:）和 Linux 路径会生成相同的 slug；不过，如上段所述，这两行的零值仍取决于转录记录是否来自 POSIX shell 会话。

如果会话从 git worktree 中运行，同样两行仍会悄无声息地出错，且这种情况更难发现，因为转录记录看起来完全正常。两个标签都会将命令目标与项目 slug 进行完全相等比较，而 worktree 会话的 slug 是 worktree 的路径，不是仓库的路径。因此，git -C <the main checkout> 调用——这是从 worktree 操作时最可能出现的自有仓库形式，因为分支会在主检出目录中合并，且同级 worktree 的工具仍会指向该目录——会生成不同的 slug，完全不会被标记；对应的 cd 形式则会被标记为 cd-other，而这是推荐的_跨仓库_形式的标签。规则恰好没有在最可能违反它的会话中得到衡量，因此报告为零。

这是一个已声明的限制，而非修复方案，因为现有数据不足以支持修复：脚本离线读取转录记录，读取时相关目录可能早已不存在，因此无法向 git 查询 slug 对应的是哪个检出目录。唯一的信号来自 slug 本身的形态，而且它只适用于多种布局中的一种——Claude Code 的 <repo>/.claude/worktrees/<name> 会留下 --claude-worktrees- 片段（这是根据运行环境的 slug 规则推导得出的，并非实际观察到的：作者机器上的 211 个项目目录中没有一个是 worktree）；而 VS Code 的默认布局 <repo>.worktrees/<name> 和检出目录旁的扁平形式 <repo>-<branch> 都无法与普通仓库名称区分。只针对一种布局进行部分修复，会让其他布局看起来像是已验证。只要会话可能从 worktree 中运行，就应将这两行的零值视为未验证，Windows 上也同样如此。 exit-masked 会统计某种形式，而这种形式是否造成了影响，取决于每台机器；本脚本无法判断。 默认情况下，管道会报告最后一个阶段的状态，这也是该行名称的由来——但如果 shell 设置了 pipefail，它会报告最右侧的非零状态，因此 inv quality.precommit 2>&1 | tail -3 在门禁未通过时会以非零状态退出，根本没有隐藏任何内容。记录文件会记录命令，但不会记录 shell，因此应在正在审计的会话中，通过 Bash 调用询问会话自己的 shell——在 zsh 下运行 setopt | rg pipefail，在 bash 下运行 set -o | rg pipefail；在根据高比例得出任何结论之前，先确认这一点。配置文件并不能说明问题：该选项通常受某个 harness 变量控制（在作者的机器上，~/.zshenv 只会在存在 CLAUDECODE 时设置它），因此它可能在 Agent shell 中生效，而在同一台机器的其他地方都未生效。

session-harvest 的 claims 对同名行的统计方式不同，而且这两个数字都朝相反方向算错了。 harvest.py 的 EXIT_MASKED_RE 会匹配原始命令，因此会把引号字符串或 heredoc 正文中写出的管道也算作真实情况；audit.py 会剔除这两者，因此不会漏掉任何带引号的内容，但直到 2026-09-06 之前，它会丢弃 heredoc 之后的所有命令。在截至该日的一周内，claims 标记了但 audit.py 未标记的 390 次调用中，388 次是 heredoc 漏算错误，另外 2 次是真正的带引号提及。该错误已修复，带引号内容的高估问题仍未修复，因此如今读者比较这两者时，应该预期 claims 的数字略高——同一天的一个会话中，claims 为 7，而另一项为 4；多出的三项全都是 python3 - <<'PY' 探测正文中的 2>&1。两个技能各自独立安装，无法相互导入，因此共用剥离器是 plans/2026-09-03-skill-dependencies-and-bundling.md 提出的问题；在此之前，差异是预期现象，任何一个数字都不是对另一个数字的校验。

该行会保留，并且因两个理由都与此结论一致，不由 EXPECTATIONS 进行评判。保护条件意味着，同一条命令在 cron、CI、容器以及任何没有该片段的机器上仍会丢失状态——在这里学会这种形式无害的会话，可能会把它写进在别处运行的脚本中。而且，根据记录文件计算出的判定无法知道运行命令的是哪个 shell，因此这样的数字看似笃定，实则建立在假设之上。head/tail 则根据输出丢失情况为这一习惯打分，因此在任何环境下都成立。

此技能读取、运行和写入的内容

• 读取：~/.claude/projects/*.jsonl 和 ~/.claude/settings.json，均为 Claude Code 自身的文件，仅作只读访问；以及（如果存在）你自己的预期文件，位于 $XDG_CONFIG_HOME/session-bash-audit/expectations.json（Windows 上为 %APPDATA%\…），或 --expectations <path> 指定的位置。
• 运行：仅在写入基线时，对其自身目录执行三个只读 git 命令——针对 audit.py 本身运行 ls-files、rev-parse HEAD 和 status --porcelain，以记录生成该测量结果的工具版本。除此之外不运行任何命令：prompts.py 会在进程内重放权限规则，而 Probe 流程会打印供你运行和查看的命令。
• 写入：仅在通过 --save-baseline 请求时，写入基线至 $XDG_STATE_HOME/session-bash-audit/（Windows 上为 %LOCALAPPDATA%\session-bash-audit\），并且如果该位置已有基线，它会拒绝覆盖——--force 用于按需销毁该基线；转储文件则写入 --json <path> 指定的位置。绝不写入记录文件、设置或自身的安装目录。
• 网络：无。

四种流程——技能负责运行，用户只需查看结果

适用哪一种：

问法	操作
“使用 Bash 的会话情况如何”，一种新的测量模式	测量（见下文）
“改动生效了吗”“重新检查”，改动后一周	与基线比较
“权限设置表现如何”，模式／规则编辑后	探测当前权限
“为什么有这么多提示词”“还有什么会触发提示词”	提示词——重放规则
“_这个_会话的情况如何”，来自一次采集	对照基线运行 --session

前三项使用 scripts/audit.py，第四项使用 scripts/prompts.py； 下文中的 S=~/.agents/skills/session-bash-audit。

测量

python3 $S/scripts/audit.py --days 4 --samples 5
python3 $S/scripts/audit.py --days 7 --project <repo> --json <scratch-dir>/calls.json

只读，仅使用标准库；统计一周的转录记录约需 10 秒。使用 --samples 0 仅输出表格。 --json 转储内容可用作任何临时后续问题的输入（这里用 python3 -c 处理即可—— 这些数据只是一次性快照，不是仓库代码）。将转储文件放在任务／会话临时目录中，不要直接放在 /tmp。

单个会话，对照基线——这是唯一一种能在会话仍可据此采取行动时就得到结果的模式。 session-harvest 的第 5 步会调用此模式；当会话想了解自身情况，而非一般会话的情况时，可直接运行：

python3 $S/scripts/audit.py --session <session-id> --compare ~/.local/state/session-bash-audit/<file>.json

ID 是转录文件名去掉扩展名后的部分，使用唯一前缀即可。此脚本中的其他模式都是事后测量趋势；这个模式测量的是当前运行中的会话。

看计数，不看比率。 会话视图每行打印一条记录，先显示计数：

== this session, 247 calls ==
  head/tail                   38   15%
  exit-masked                 22    9%   14 wrapped a gate, 8 a listing
  rg-replace                   1    0%   -rn x 1

每行都会打印，包括计数为 0 的行；显示计数是因为在会话规模下，比率会把真实发现四舍五入抹去：中位数会话有 247 次调用，一次占 0.40%，显示为 0%。 在 2026-09-06 对 67 个会话进行测量——在 30 个命中 rg-replace 的会话中，有 13 个显示结果会是 0%。0 表示已检查且没有问题；完全没有打印的行，则是该视图此前对 rg-replace、find-not-fd、grep-r-not-rg 和 find-exempt 的处理方式，因为它继承了语料库表格的列，而语料库表格没有足够的宽度容纳这些列。

有两行带有细分数据，因为一个数字涵盖两种不同故障时无法采取相应行动。 exit-masked 将被屏蔽的调用分为包裹门禁检查和包裹列表输出的调用——屏蔽四十次列表输出没人会看见；屏蔽一次门禁检查后却声称“全绿”则不然。 rg-replace 会标出标志的写法：-rn 会丢失行号并重写匹配文本，-ril 会把不区分大小写的文件列表搜索变成区分大小写的行搜索，而单独使用 -r 通常是有意使用 rg -o -r '' 提取内容，并非错误。

压缩后的会话相当于两个会话，整场会话的行描述的却不是其中任何一个。 如果转录记录包含续接轮次，报告会在整场会话记录下方分别打印两侧的行。2026-09-13 在一个运行七天的后台任务中确认了这一点：67% 的链式调用、48% 的 head/tail 和 32% 的 heredoc 出现在压缩前；压缩后则分别为 1%、0% 和 0%。若将其视为一个会话，结果会是 47%、33% 和 22%，这并不代表任何人的实际行为。之所以发现这一点，只是因为会话最近的调用与总计数据看起来完全不同，而这并不是一种检查方式。拆分依据是运行框架自身的 isCompactSummary 标志，而不是续接轮次开头的句子：在一份真实的 10 MB 转录记录中匹配该句，返回了三条结果，其中两条是会话在讨论这句话时引用了它。

--since 是 --until 的另一端，因此窗口只需两个标志，而不是运行两次再相减。 计数可以相减；样本、门禁检查与列表输出的细分数据以及截断行则不能，而且所有尝试过的运行中，这些数据描述的都是整个前缀。

python3 $S/scripts/audit.py --session <session-id> --since <the continuation turn's instant> --samples 4

--json <path> 在此模式下同样有效，并会转储与打印报告所对应的同一组经过时间窗口筛选的数据。直到 2026-09-06，--session 路径都会在读取该标志前返回，因此恰好在 session-harvest 始终使用的模式下无法生成转储；既没有错误，也不会生成文件。 此处会拒绝 --save-baseline，而不是跳过它——单个会话的比率并非语料库基线，而一个静默无效的标志比一个会明确说明原因的标志更糟。

应与自己保存的基线比较，而不是与此处附带的基线比较。$S/references/baselines/ 中有一个在作者机器上按该机器规则测得的文件；它只是一个参考点，用 --compare 将会话与它比较，报告的是你的会话与别人的设置有何不同。首次运行时保存自己的基线（--save-baseline），并使用它——即使运行结果很差也要保存，而人们往往会犹豫要不要这样做。基线绝不会被当作目标来读取：EXPECTATIONS 是有方向的（down 或 zero），因此判定是根据差值计算的；即使首次基线很差，也只是为下一次运行设定了一个必须超越的门槛。只在自己满意的运行中保存基线，才会让这一系列数据失真，因为参考点会变成筛选结果，而不是测量结果。

[PITFALL：**每种模式、每次运行都不要通过管道传输输出。**输出只有几十行，测试框架会完整保留；对于主题本身就是 head/tail 截断的报告，使用 | head -N 是唯一会让这种习惯导致错误结论、而非需要重跑的情况。已于 2026-09-02 确认：一次采集运行了此命令 … --compare … | head -12，看到了比率行和前几个样例块，便认定 --compare 根本没有生成比较结果——没有错误、没有 OK/MISS 列，也没有 n/m expectations met 行。随后，它手动读取基线 JSON，重新计算差值，并提交了一份方案，将脚本和基线列为两个可能的原因。两个都不是原因：比较结果早已打印出来，只是位于截断位置下方 40 行处。同一次会话测得 45% head/tail，这也是发现问题及其原因在同一次运行中出现的原因。

现在，两种模式下都会将比较结果打印在样例块上方，这样输出被截断时，丢失的是大部分内容，而不是判定结果——但这只是第二道防线，并不代表可以通过管道传输输出。]

[PITFALL：刚编写规则的 Agent 并不会因此更有可能遵守规则，所以绝不能通过询问会话表现如何来替代这个数字。已两次确认。2026-08-30：一个花了一整天编写禁止通过 head/tail 管道截断检查命令规则的会话，在自己 33% 的调用中都采用了这种写法——比它当时正在测量的会话还差——却自我报告说“表现不错”。2026-09-01：实现此模式的会话测得 47% head/tail，比重写前的基线上升 17 个百分点，此外还有三项未达标；它甚至在自己的提交说明中引用过这条规则。两次都如此，而且两种情况下，会话自己的印象都是运行过程很顺利。]

[PITFALL：**heredoc 过去会让提交较多的会话数据偏高，该问题已于 2026-09-01 修正。**此处曾建议使用带 heredoc 正文的 git commit -F - 来编写多行提交消息，因此它会在每次提交时都被标记，该列必须结合会话的提交次数来解读。 ~/.agents/AGENTS.md 颠倒了这条规则：现在消息改为直接写在 -m 中，且不使用反引号或 $，因为 -m 会将消息显示在审批提示中，而 -F <file> 会将其隐藏在路径之后。因此，在提交较多的会话中出现 heredoc 现象，再次成了一个发现，而非统计假象；跨越规则变更时采集的样本，测量的是该会话所遵循版本的规则。请在样本上标注其所依据的 ~/.agents/AGENTS.md 提交版本，否则看似偏离的比率，可能是会话正确遵循了较早版本的规则。]

比较——检查“是否生效”的方法，无需手动阅读表格：

python3 $S/scripts/audit.py --days 7 --samples 0 --compare $S/references/baselines/2026-08-24-auto-mode.json

在基线旁显示每个模型当前的比率，并以百分点差值呈现；每项预期标记为 OK/MISS （脚本中的 EXPECTATIONS：chaining、head/tail、sed -n、cat、heredoc 和 git-in-chain 应该是 down； 自有仓库的 cd 和 git -C 修改，以及捆绑的 rg -r，应为零）。任一轮调用次数少于 50 次的模型会显示为 ?，不作判定。

这些预期是一位作者的规则集，并非关于 Bash 的事实——请用你自己的规则集评分。 每一项都是对一台机器的 ~/.agents/AGENTS.md 的解读：find-not-fd 为 down，因为该文件偏好 fd；cd-own-repo 为 zero，因为它明确禁止这种形式。无论你的指令写了什么，你的各行都依然成立；只有判定是借用的。将你自己的规则写成 {"<row>": "down"|"zero"} 格式的 JSON，并传入 --expectations <path>；或者将其放到 $XDG_CONFIG_HOME/session-bash-audit/expectations.json（默认位于 ~/.config/…，Windows 上位于 %APPDATA%\…），不传任何参数时也会自动找到：

{ "chain": "down", "head/tail": "down", "cd-own-repo": "zero" }

该文件会替换随附的规则集，而不是在其上打补丁——同一判定若同时归因于两份文档，就无法回溯。因而，请重新列出所有要评分的行。未知的行名或不是 down/zero 的判定都会报错，并列出有效选项；绝不会让某行悄无声息地不参与评分。比较标题会显示所用的文档。

zero 预期根据计数进行判定，其单元格只显示该计数，不显示差值。 在 2026-09-06 之前，它采用比率区间（<= 2%），但这并非适用于任何规模的零值定义，而且会掩盖两端的发现：截至该日期的 7 天内，最繁忙模型的每个零值行都通过了判定，但实际有数百个实例——git-C-mutating 为 288，git-C-own-repo 为 231，echo-exit 为 146，cd-own-repo 为 94，却全部报告为 OK；而在一次 157 调用的会话中，单个真实的 rg -rn 显示为 1%(OK)，但会话视图显示的是计数。无法证伪的判定会掩盖发现，这比夸大问题更糟。预计语料库判定行中的未通过项会比以前多；它们一直都存在。不显示差值，是因为测试采用绝对值：接近零的行，其百分点差值会四舍五入为 -0pp；而不同分母之间的计数差值，会把一次 160 调用的会话与 15,000 次调用的基线比较成有所改善。

zero 预期针对的是 rg-replace-bundle，而不是 rg-replace 本身。 父级行既统计有意使用 rg -o -r '' <pattern> <path> 提取的惯用写法，也统计误用——截至 2026-09-06 的 30 天内，86 次命中中有 13 次是这种用法。因此将该行设为 zero，就等于要求停止正确使用一个真实存在的标志。捆绑行统计的那一半始终是错误：两个或更多标志字母中包含 r，意味着 -r 吞掉了标志组剩余部分，并将其作为替换字符串。向用户报告判定行和未通过项；然后使用“Decide where the fix goes”中的表格逐项处理每个未通过项。规则或模式更改后，为下一次比较保存新的基线——--save-baseline --note "<mode in force>"——并保留旧文件；差值才是重点。

你保存的基线会写入 $XDG_STATE_HOME/session-bash-audit/（默认位于 ~/.local/state/…，Windows 上位于 %LOCALAPPDATA%\session-bash-audit\），现在不带参数的 --save-baseline 会写入此处。直到 2026-09-03，这一行写的还是 $S/references/baselines/…——也就是已安装的技能内部；重新安装时会替换该位置的内容，而本文其他地方称之为需要编辑的漂移内容。技能要求保留的唯一真正按机器区分的状态，之前一直存放在专门用于覆盖的地方。如果想保存到其他位置，请传入明确的路径；只要不在安装目录内，任何位置都可以。

探测——实时权限行为，任何转录记录都无法展示：

python3 $S/scripts/audit.py --probe

在 acceptEdits 模式下，根据这台机器的规则，打印六条命令及其各自应有的结果（提示／不提示）。每条命令都要作为单独的一次 Bash 工具调用运行——在脚本中运行会绕过测试所针对的 harness 权限检查——其中 <scratch> = $CLAUDE_JOB_DIR/tmp（如果你的 harness 设置了该变量），或仓库外的任意临时目录。Agent 无法观察提示：运行后，列出哪些步骤预计会触发提示，并询问用户实际看到的情况是否与预期相符。不匹配就是实际发现的问题（规则遮蔽了模式授权、前缀规则未匹配）——记录在 references/research.md 的“Harness facts”中并注明日期，然后安排修复。

提示——用户报告“确认次数太多”时，哪些调用触发了提示，以及原因：

python3 $S/scripts/prompts.py --days 2
python3 $S/scripts/prompts.py --since 2026-08-24T19:13:00Z --project <repo>

已批准的提示不会在 transcript 中留下痕迹，因此这会根据当前的 ~/.claude/settings.json 重放 harness 的匹配逻辑（按分隔符拆分、ask 优先于 allow、内置只读集合、acceptEdits 的范围内授权），并打印每个会话的估算提示占比，以及每次调用触发提示的首要原因，并按样本排序。规则变更前后都要运行：“变更后”的运行用于检查变更是否确实消除了该模式，而不只是消除了某一种形式。根据下表安排每个原因的处理方式——大多数问题出在生成权限规则的环节，而非文案。引入此项的 2026-08-25 运行记录在 references/research.md（“Prompt audit”）中。

按顺序阅读 Measure 输出：

1. 按模型统计——基线。与 references/research.md 中的表格（“Baseline 2024-08-24”）比较。命令链式执行率和 head/tail 使用率是关键指标；2026-08-24 的变更后，cd-own-repo、git-mutating-in-chain 和 git-C-mutating 应接近于零。
2. 按会话统计——关注异常值，而非平均值。若一条会话的链式执行率为 90%，而另一条使用相同规则的会话只有 15%，问题出在处置方式或任务形式，而非措辞；修改规则前，先阅读其中几条样本。
3. 模式总计——每行都列出了成本（“原因”）。某个模式即使计数很高，如果其成本只是“提示造成的阻碍”，也只有在会触发提示的模式下才重要；检查统计时间段内生效的模式（~/.claude/settings.json 中的 permissions.defaultMode，以及会话是否覆盖了该设置）。
4. 截断后的重跑——| head／| tail 的直接成本：同一命令再次执行，只是使用了更大的限制值。每次重跑都浪费一次调用，而且在两次调用之间，还可能有人根据被截断的视图作出决定。
5. 拒绝——分类器拒绝（Blocked by classifier）表示该会话启用了自动模式；“用户不想继续”则表示用户主动拒绝。值得检查一下，是哪种命令形式导致了这两种情况。

确定修复应放在哪里

这项审计旨在避免条件反射式地“往说明文件里加一句话”。应根据机制选择修复位置。右侧列出了修复所属的_位置类型_；括号中则以作者机器上的具体位置为例，每种情况各举一例：

发现	修复位置
某条规则所述的_理由_已不成立（例如，在不会触发提示的模式下提到“提示摩擦”）	重写规则本身的来源，而不是用更强硬的措辞重申。若问题出在理由上，单靠措辞无法改变触发率。（agents-md 片段，旁边附上证据页面。）
某种命令格式会触发提示，但属于只读操作且很常见	权限允许列表中的前缀规则（生成的 tools.toml 条目）。不适用于 Claude Code 中类似 git -C 的格式：那里没有前缀规则能匹配，因此应由沙箱处理
某个动词确实是 write，但不会丢失代码，而且说明让它变得频繁	为该工具添加允许覆盖项，并为确实会导致代码丢失的标志格式添加询问覆盖项（git add 与 git reset --hard，2026-08-25）
只读的任务运行器调用会触发提示	明确的按任务设置允许规则。不能笼统允许任务运行器的全部操作——它会运行任意仓库代码——因此只列出指定任务
某种命令格式受权限模式限制，比前缀规则更精确	让允许列表自身支持模式识别，绝不要手动编辑运行框架的 settings.json
向运行框架的临时目录写入内容会触发提示	在运行框架的附加目录设置中声明，并放在其他运行框架配置所在的位置
运行框架本身指示了相反的做法（自动模式中的“优先使用 Bash”提醒）	应调整模式，而不是措辞。不要编写与当前系统提醒相冲突的规则
只有 Plan/Explore 风格的子 Agent 行为不当	它们的生成提示词——内置子 Agent 不会在任何层级加载 AGENTS.md/CLAUDE.md，因此每条规则都必须在提示词中内联重述
某个模型的倾向（相同规则下，不同模型的触发率不同）	无需编写任何内容；在 references/research.md 中记录，并为任务选择合适的模型

优先通过指导来解决，而非强制执行：不要使用 PreToolUse 提醒钩子。对 Agent 的要求应与对开发者相同——它们应该知道该运行什么，而不是在背后被悄悄纠正。已否决的钩子设计见 references/research.md。

记录学到的内容

• 发现值得衡量的新模式 → 在 scripts/audit.py 中添加一行 PATTERNS，并如实说明“原因”，运行一次，然后在 references/research.md 中添加一段带日期的说明，记录计数及其含义。 没有说明成本的行毫无意义；不要添加。
  • 每个问题一行，绝不能用一行同时覆盖同一命令的合规形式和不合规形式。 这种行给出的比率既回答不了任何一个问题，又看起来像是在衡量覆盖率，因此恰恰因为有人在衡量，问题反而无从发现。2026-09-02 确认：一条 grep/find 规则同时匹配了 grep、rg、find 和 fd，因此优先使用 rg 而非 grep -r、优先使用 fd 而非 find 的规则从未真正被衡量过；实际分别衡量后，两部分的遵守率为 90% 和 47%，一个数字根本无法体现这种差异。如果一条规则区分同一命令的两种写法，就应该分成两行。
  • 信任正则表达式的计数前，先用手写案例测试，包括多行命令。2026-09-02 发现的两个错误都让数字显得更好看：前瞻中的 .* 会在换行符处停止；分隔符锚点漏掉了 \n，但 split_chain 一直会按它拆分，导致调用第二行上的所有命令都被隐藏。
• 规则或模式更改后有了新的基线 → 在 references/research.md 的基线表中追加一行带日期的记录；不要覆盖旧记录——重点在于比较变化。
• 处理框架事实（自动模式的行为、某模式会自动批准什么、规则优先级）→ 写入 references/research.md 的“Harness facts”部分，并附上文档 URL 和核查日期。这些内容会随着 Claude Code 版本变化；带日期的记录才是证据，而非传闻。
• 其实是仓库缺陷或设计决策的一次性发现 → 记录在对应仓库的 plans/ 中（参见 plan-conveyor 技能），并从这里链接过去。

上述所有内容都应写入此技能自身的源文件，而非安装在 ~/.agents/skills/ 下的副本——下一次安装会覆盖该副本，而且它不会影响其他任何地方。skill-authoring-taudelta 技能介绍了编辑 → 检查 → 提交 → 推送 → 重新安装 → 验证的流程。