mcpField
Q
quality-gate

quality-gate

github.com/athola测试与质量34389 次安装1 天前更新
代码仓库

关于 quality-gate

面向 egregore 工作项的质量阶段编排技能，用于自审和拉取请求审查。它按步骤分派规范检查与对应技能，并记录结论，也可发布 GitHub 审查。

主要功能

  1. 01按质量步骤分派检查
  2. 02运行对应规范检查
  3. 03调用审查与优化技能
  4. 04支持自审和 PR 审查
  5. 05记录结论并发布 PR 审查

适用场景

  1. 01提交 PR 前检查变更
  2. 02审查其他 Agent 的拉取请求
  3. 03运行指定质量步骤

安装

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

$npx skills add https://github.com/athola/claude-night-market --skill quality-gate

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

详细介绍

质量门禁

何时使用

  • 对 egregore 工作项运行质量检查
  • 创建 PR 前进行自我审查
  • 以 PR 审查模式审查其他 Agent 的 PR

何时不使用

  • 在 egregore 流水线之外进行手动代码审查
  • 一次性 lint 或格式检查（直接使用 make lint）

编排 egregore 流水线的 QUALITY 阶段。 每个质量步骤都会运行 codex 中的规范检查， 并调用映射的技能。

路由表

步骤规范技能模式
代码审查C1,C2,C3,C4,C5pensive:unified-reviewself, pr
精简-conserve:unbloatself
代码优化-pensive:code-refinementself
更新测试-sanctum:update-testsself
更新文档C5sanctum:update-docs, scribe:slop-detectorself

输入

编排器调用此技能时会提供：

  • step：要运行的质量步骤（例如“code-review”）
  • mode：“self-review”或“pr-review”
  • work_item_id：清单中的工作项 ID
  • branch：包含更改的 git 分支
  • pr_number：（仅限 PR 审查模式）PR 编号

自我审查工作流

当 mode 为“self-review”时：

  1. 获取更改的文件：git diff --name-only main...HEAD
  2. 从 conventions/codex.yml 加载规范
  3. 筛选映射到当前步骤的规范
  4. 通过 conventions.py 运行规范检查
  5. 对更改的文件调用映射的技能
  6. 汇总所有发现
  7. 计算评定结果
自动修复循环

如果存在阻塞性发现：

  1. 尝试修复每项发现（取决于技能）
  2. 将修复提交到工作项分支
  3. 重新运行规范检查
  4. 如果尝试 3 次后仍有阻塞项，评定结果为 “fix-required”
评定结果计算
if no findings:
    verdict = "pass"
elif all findings are severity "warning":
    verdict = "pass-with-warnings"
elif blocking findings remain after auto-fix:
    verdict = "fix-required"

将评定结果记录在清单决策中：

{
  "step": "code-review",
  "chose": "pass-with-warnings",
  "why": "2 warnings (C4: noqa in hooks), 0 blocking"
}
完成完整性（可选，默认关闭）

默认情况下，循环会无限期自主运行：系统会记录 fix-required 判定，但仅凭该判定不会阻止事项继续推进。这保留了以往无需人工干预的运行方式。

当 config.pipeline.completion_integrity 为 true 时，判定会成为一道 Agent 无法巧言绕过的关卡：

  1. 系统会将 fix-required 判定作为步骤失败报告给编排器，因此在存在未解决的阻塞问题时，事项无法推进到交付阶段。系统会在原地重试；达到 max_attempts 上限后，事项会标记为 failed，并提醒监督者（绝不会悄然标记为 completed）。
  2. 无论 auto_merge 如何设置，合并都会暂缓，等待人工审查：PR 会准备就绪，但保持开放状态。

这样一来，“完成”由验证器（规范检查加上已映射的审查技能）来判定，而不是由 Agent 自说自话。这一原则源自已发布的 Agent harness，KbWen/agentic-os 对此表述得最为贴切：Agent“仍然可以偷工减料，只是不能在它无法控制的检查环节上蒙混过关”。这些 harness 中反复出现的模式包括：

模式作用来源
将验证器关卡作为完成判定依据将“完成”绑定到 Agent 无法伪造的测试、lint 或结果哈希Aider、snarktank/ralph、gaasher
完成承诺 + 最大迭代次数上限字符串匹配“完成”并不足够；还需配合迭代上限和手动中止anthropics ralph-wiggum
Agent 无法控制的证据关卡通过钩子或 CI 强制执行凭据扫描、测试执行验证和阶段日志解析KbWen/agentic-os
保留改进 / 回退退步的账本为每项更改评分，回退退步，并记录到仅追加的账本以供审查gaasher/Agent-Loop-Skills
可读性锚点持久化的当前状态文件或仓库映射文件，让人工可以重新进入循环Aider 仓库映射、agentic-os
人工观察者检查点观察早期迭代，监控差异，并将循环留给已定义的问题anthropics、ghuntley

更多理由：应先让非法状态无法表示，再对其进行防护，因为隐藏不可能情况的回退机制会导致静默损坏，而不是可定位的崩溃。Armin Ronacher，《The Coming Loop》（2026），https://lucumr.pocoo.org/2026/6/23/the-coming-loop/。该标志默认关闭；启用它意味着有意选择让人工担任最终裁决者。

PR 审查工作流

当模式为 "pr-review" 时：

  1. 获取 PR 差异：gh pr diff <number> --name-only
  2. 加载规范，并筛选出代码审查步骤
  3. 对已更改的文件运行规范检查
  4. 对差异调用 pensive:unified-review
  5. 收集所有发现
发布审查

将发现映射到 GitHub 审查：

  • 没有发现：使用 gh api POST 审查， 事件为 "APPROVE"
  • 仅有警告：POST 审查，事件为 "COMMENT"， 将发现作为行内评论
  • 存在阻塞问题：POST 审查，事件为 "REQUEST_CHANGES"，将阻塞问题作为行内评论， 并添加 "must fix" 前缀

每项发现的评论格式：

[egregore:{convention_id}] {message}

Convention: {convention_name}
Severity: {severity}

质量配置

工作项可以包含 quality_config 字段：

{
  "skip": ["unbloat"],
  "only": ["code-review", "update-docs"]
}
  • skip：要跳过的步骤列表（运行其他所有步骤）
  • only：要运行的步骤列表（跳过其他所有步骤）
  • 如果两者都已设置，则以 only 为准
  • 如果两者都未设置，则运行所有步骤（默认）

按步骤筛选规范

并非所有规范都会在每个步骤中运行。上方的路由 表定义了哪些规范适用于哪些步骤。质量关卡会在运行检查前， 相应地筛选已加载的 codex。

退出条件

  • 已执行所有适用的规范检查
  • 已调用所有映射的技能
  • 已计算判定并记录到清单中
  • 对于 PR 审查：已发布 GitHub 审查

评论

支持 Markdown