mcpField
R
record-verdict

record-verdict

github.com/jayden-dang开发151 次安装5 天前更新
代码仓库

关于 record-verdict

record-verdict 是一项技能,用于在符合条件的技能流程产生最终判定时发布不可变的决策记录。它会检查调用方与证据要求,逐字记录人工判断及持久引用,并在必要操作执行前验证记录。

主要功能

  1. 01限定符合条件的调用方和判定
  2. 02要求内联的持久证据
  3. 03逐字记录人工判断
  4. 04按固定规则划分记录深度
  5. 05发布前扫描并验证记录
  6. 06相关操作前要求先发布记录

适用场景

  1. 01记录 land-branch 的合并判定
  2. 02记录 cut-release 的批准或拒绝
  3. 03在重要操作前保留可审计记录

安装

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

$npx skills add https://github.com/jayden-dang/skills --skill record-verdict

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

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

eval.json
RECORD.md
validate-records.sh

详细介绍

记录边界决策

在 .skills/decisions/ 下发布一条决策记录(不可变的载荷 + 仅追加的封套),用于技能介导的终局裁决——遵循先记录后越界顺序。

**语法 SSOT:**同级的 RECORD.md。编写或解析字段时都要加载它。 不要在此重述字段列表。

硬门槛——调用方门槛

仅当以下条件全部满足时才继续;否则返回且不生成任何产物:

  1. 调用方是 land-branch 或 cut-release(封闭集合)
  2. Write Handoff 包含终局人工裁决
  3. 持久化证据为内联文本(或明确为空)——绝不能是 .skills/、临时文件或会话历史中的定位符

证据生产者不能自行晋升为发布者。仅为技能介导的裁决发布记录(ARCH-6)。

想法实际情况
“这项批准重要到值得记录”只有 land-branch / cut-release 且存在终局裁决时才行
“我在 .skills/ 下有一份日志”先将实质内容内联;不要发布路径
“记录存放在 .skills/ 下,所以现在可以引用 .skills/ 路径了”存储位置 ≠ 可引用定位符;禁令未变
“跳过记录;合并很紧急”先记录后越界——未有效发布,就不能越界
“资深人员/CTO 说可以跳过文书工作”职级不会改写门槛;只有用户明确更改规则才行
“文件已写好;验证器可以稍后再跑”已写入 ≠ 已发布;越界需要验证器退出码为 0

**完成条件:**门槛开启(调用方 + 裁决 + 内联引用)或已返回且未创建文件。

Write Handoff(来自发布者)

仅接受内联内容:

  • 裁决:merge | pr | discard | block | release-approve | release-reject
  • 发布者已掌握的边界类型、仪式层级、谓词事实
  • 持久化引用(commit、tag name@object-id、PR/CI/cut-release 引用)
  • 晋升实质内容(将临时内容改写为文本)

深度(固定查表——无需每次越界都访谈)

depth = max(ceremony floor, boundary floor, predicate escalation)
来源下限
Tier 1 / mini-specGuarded
Tier 2 / full triadAccountable
cut-releaseAccountable
边界 disposalAccountable
任一谓词为 true 或 unknown升级至 Accountable

规则(始终适用):

  • 实际越界的深度至少为 Guarded。绝不发布 Minimal。
  • 即使下限已确定深度,也要评估全部三个谓词:外部受众 · 无法机械撤销 · 持续性风险。
  • 外部受众:只有在机械方式确立输出会到达创建和批准该输出的群体之外时才为 TRUE;只有依据当前、权威且穷尽的机械来源时才为 FALSE;否则为 unknown。名册、CODEOWNERS、隐私元数据、分支所有权、PR 作者身份或 band 单独都不能证明 FALSE。不得通过探查或访谈来降低取值。用户主动提供的陈述可以提升深度或补充背景——绝不能用于确立外部受众为 FALSE。
  • 用户可以提升深度;Agent 只能提高深度,不能降低深度。
  • 将每项查表输入和结果写入分类字段。

**固定规则:**如果 docs/agents/project.md 有 ## Decision boundaries,应用会提高下限或绑定类型的行;忽略会降低核心下限的行(用一行说明)。若无该节 → 仅应用核心表格。

**完成条件:**深度为 Guarded 或 Accountable,且分类字段均已填写。

Judgment(逐字法律)

深度记录内容
Guarded最终裁决 + 至少 1 项逐字的人类判断要素
Accountable裁决 + 逐字的已接受风险 + 逐字的出错时应对方式

铁律:仅存储用户亲自撰写的原话。对于 Agent 撰写的风险陈述,用户只回复一个简单的“yes”/“ok”,这仅是裁决,不属于风险或应对文本。

指针:有条件时使用 harness interaction id,否则为 unavailable。

想法事实
“用户显然是这个意思”未经明确说明的文字不属于人类判断
“我会润色后对比他们的措辞”根据逐字法律,Polish Diff 属于捏造

**完成条件:**每项必需内容都必须是用户亲自撰写的逐字字节,或带有 withheld(reference) / withheld(unavailable) 处置令牌。

存储方式的确定

  1. 如 project.md 中有长期有效的仓库逐字存储政策,则直接适用,无需询问。
  2. 对每个人类判断要素都明确提供暂不披露的选项。
  3. 对可能敏感的文本,在按逐字内容存入仓库前有条件地确认一次。
  4. 在接受操作锁定内容前,展示确切载荷。
  5. 暂不披露 + 有定位信息 → 信封中填写 Storage-*: withheld(reference),并填写匹配的 Storage-Reference-*: <locator>。
  6. 暂不披露且无定位信息 → 只询问一次;若用户拒绝或信息不可用,则填写 withheld(unavailable) + Storage-Reference-*: unavailable;继续处理(W-opaque 不属于未完成工作)。
  7. 暂不披露的载荷正文必须是 RECORD.md 中的固定哨兵文本——不得将编辑后的文本标记为逐字内容。

任何写入前都要进行密钥扫描:

sh skills/ship/record-verdict/validate-records.sh --scan

扫描命中时,只能:改述 · 暂不披露 · 停止。

**完成条件:**每个人类判断要素都恰有一种存储处置,且扫描无命中或已停止。

证据与晋升

仅发布持久类型(commit|tag|pr|ci|release)。标签使用 <ref-name>@<object-id>(两部分都必须有)。定位信息必须持久——在展示载荷之前,将临时内容晋升至 Promoted-Evidence:(由 Agent 撰写)。后续证据仅写入信封中的 Execution-Outcome:。

**完成条件:**每条引用都是持久的,且晋升(如有)在锁定前完成。

生成与重新签发

  1. 锁定 Accepted: UTC(YYYYMMDD → ID 日期)。
  2. 令牌 = 6 个 Crockford 字符:通过 od 使用 /dev/urandom,否则使用 awk+$$+date。
  3. ID = DEC-YYYYMMDD-<token>。不设注册表。发生冲突时重新签发。

重新签发(仅追加):生成新 ID,重命名文件,追加 Reissued-from: + Reissued-as: <new-id> <UTC>。保持 Published: 和载荷字节不变。

完成条件:文件名主干与有效身份一致(见 RECORD.md)。

采用锚点(仅首次写入)

当即将发布第一条记录且不存在带内容标记的锚点时(首个非空行必须恰为 # Decision-Record Adoption Anchor):

  1. 写入 .skills/decisions/ADOPTION.md 一次:填写 Cutoff:(当前 UTC)+ 对每个可见标签填写 Baseline-Tag: <name>@<object-id>。
  2. 此后保持锚点不可变。不得根据最早的记录推断采用时间。

**完成条件:**在第一条记录之前或随其发布时,恰有一个带内容标记的锚点。

发布检查清单(先记录,再执行不可逆操作)

  1. 记录判断
  2. 确定存储位置
  3. 提升证据级别(如有)
  4. 显示精确载荷 → 人工确认(锁定 载荷)
  5. 扫描判断文本中的密钥
  6. 生成 ID;写入文件;将载荷摘要记录到 信封
  7. 验证:
sh skills/ship/record-verdict/validate-records.sh --mode=publish --record <file>
  1. 只有验证器针对已发布文件以状态码 0 退出后,才能执行不可逆操作
  2. 追加结果:在 信封 上添加 Execution-Outcome:

裁定要么有需要暂缓的不可逆操作,要么没有:merge、pr、 discard 和 release-approve 有;block 和 release-reject 没有—— 无论哪种情况,裁定都成立,只有记录可能丢失。

失败操作
扫描停止、判断缺失、验证器返回 1/2、写入失败——裁定包含不可逆操作暂缓该操作;报告裁定未执行,并指出阻止执行的原因
重试原样重复使用已记录的人工原话
block / release-reject 出现相同失败报告终局裁定未记录(问责不完整),并指出阻止记录的原因
发布成功,不可逆操作失败将失败追加为 Execution-Outcome:;记录仍然有效

完成条件: 在执行任何必要的不可逆操作之前,.skills/decisions/ 下已有通过验证器检查的文件;或者发布失败且已发出相应报告:对于包含不可逆操作的裁定,报告裁定未执行;对于 block / release-reject,报告终局裁定未记录;无论哪种情况,都要指出阻止执行或记录的原因。

危险信号

  • 未有终局人工裁定就发布,或在 {land-branch, release} 之外发布
  • 概述或润色判断文本
  • 引用 .skills/、临时路径或会话历史
  • 在验证器以状态码 0 退出前执行合并、创建 PR、丢弃更改或打标签
  • 以 Minimal 深度发布
  • 将深度降低到计算出的下限以下

评论

支持 Markdown