人工智能AI 应用交互助手AI Agent【免费下载链接】ironclawIronClaw is an Agent OS focused on privacy, security and extensibility项目地址https://gitcode.com/gh_mirrors/iro/ironclaw点击查看免费下载本文围绕 IronClaw 仓库中的review-readiness技能skills/review-readiness/SKILL.md展开讲解如何为每个活跃 PR 分支维护一份「审查就绪度」状态文件将代码审查、测试、安全审查、QA 审查与静态检查的状态汇总为一张可读的看板并用明确的裁决逻辑READY / ALMOST READY / NOT READY / BLOCKED把合并决策从「凭感觉」变成「凭证据」。读完本文你将掌握该技能的状态文件 Schema、自动更新触发点、裁决规则以及它与security-review、qa-review、commitments 信号系统的协作方式并能在自己的仓库中直接落地这套流程。一、技能是什么一段 YAML 前置元数据 一套流程在 IronClaw 中SKILL.md是技能Skill的载体技能解析、校验与确定性选择评分由 crates/domains/ironclaw_skills crate 负责其 README 明确定义了「技能是什么」以及「哪些技能在确定性匹配请求」。review-readiness技能的 frontmatter 定义了它的激活面--- name: review-readiness version: 0.1.0 description: PR readiness dashboard — tracks which reviews have been completed per branch and gates merge decisions. Shows code review, tests, security, QA, and linting status. activation: keywords: - review readiness - ready to merge - PR readiness - ship checklist - merge checklist - review status - PR status - can I merge - ready to ship patterns: - (?i)(is|are) (this|it|PR|the PR) ready (to|for) (merge|ship|review) - (?i)(review|merge|ship) (readiness|checklist|status) - (?i)what (checks|reviews) are (missing|left|needed) tags: - developer - review - process max_context_tokens: 1200 ---关键设计点关键词 正则双通道激活既支持 review readiness、can I merge 这类显式关键词也支持 Is this PR ready to merge?、What checks are missing? 这类自然语言问句的(?i)大小写不敏感正则模式。当用户问「这个 PR 可以合并了吗」技能就会被激活而不是等到用户背出技能名。max_context_tokens: 1200说明该技能被注入上下文时占用约 1200 token 的预算提示其正文应当保持精简、聚焦于流程而非长篇论述。标签定位developer / review / process属于开发者工作流类技能。这种「激活元数据 正文流程」的结构在仓库中得到系统级支撑技能选择器的确定性评分不依赖环境时间、网络或文件系统效应见 crates/domains/ironclaw_skills/README.md而技能正文通过include_str!从prompts/*.md加载禁止内联为 Rust 字符串常量。也就是说SKILL.md本身既是给 Agent 看的提示词也是被解析、校验、打分后按需注入的运行时产物。二、核心机制每个分支一份就绪度状态文件技能的核心主张是「以证据门槛gate合并决策而不是靠直觉Gate merges on evidence, not gut feel」。实现方式是为每个活跃 PR 分支维护一个就绪度状态文件projects/owner-repo/readiness/branch-slug.md例如某个仓库的feature-branch-name分支、PR #123其状态文件路径就是projects/owner/repo/readiness/feature-branch-name.md。文件使用 frontmatter Markdown 表格的混合格式兼具机器可读解析 frontmatter 字段与人类可读表格呈现的特性--- type: review-readiness repo: owner/repo branch: feature-branch-name pr_number: 123 updated_at: YYYY-MM-DD --- # Review Readiness — PR #123 | Check | Status | Last Run | Score | Notes | |-------|--------|----------|-------|-------| | Code review | completed | 2026-03-28 | — | Approved by alice | | Tests | passing | 2026-03-28 | — | CI green, 3 new tests | | Security review | completed | 2026-03-28 | 85/100 | 1 P3 finding (accepted) | | QA review | pending | — | — | Not yet run | | Linting | passing | 2026-03-28 | — | Zero warnings | ## Verdict: NOT READY Missing: QA review ## Findings log - [2026-03-28] Security: P3 — missing rate limit on new endpoint (accepted risk) - [2026-03-28] Code review: approved, 2 nits addressed结构拆解frontmatter 字段type固定为review-readiness、repoowner/repo、branch分支名、pr_number、updated_at最近更新日期供看板判断数据时效。五类检查项Code review代码审查、Tests测试、Security review安全审查、QA reviewQA 审查、Linting静态检查每项含Status、Last Run、Score仅安全/QA 审查有 0-100 健康分、Notes附注如审查人、CI 状态、遗留发现。Verdict 行直接给出当前裁决如NOT READY并列明缺失项让任何人都能在 3 秒内判断该分支能否合并。Findings log追加式审计日志记录每次审查的发现与处置如「P3 缺失限流已接受风险」为后续裁决提供历史证据链。三、何时使用三种触发场景技能定义了三个明确的使用时机分别对应不同的 Agent 行为。场景一检查就绪度Is this PR ready? / Can I merge?这是最常用的入口流程如下读取该分支的就绪度文件若文件不存在创建一个将所有检查项标为pending的新文件即「未审查 默认未就绪」这是保守且诚实的默认值呈现看板把表格原样展示给用户全部通过→ 回复 Ready to merge.存在缺失项→ 回复 Not ready. Missing: . Run/security-reviewand/qa-reviewto complete.直接给出补齐路径。注意第 5 步的回复不仅是告知「不行」还指明了「用什么命令补齐」——技能与技能之间通过斜杠命令互相调用形成闭环。场景二审查技能完成后回写当/security-review或/qa-review执行完毕Agent 必须用结果与评分更新就绪度文件。这是状态文件保持新鲜的唯一途径安全/QA 审查不是孤立的动作而是就绪度流水线review readiness pipeline中的一环——skills/security-review/SKILL.md 与 skills/qa-review/SKILL.md 的正文都明确写着「As part of the review readiness pipeline (/review-readiness)」作为触发条件之一。场景三晨间简报Morning brief对于标记为 READY TO MERGE已批准 CI 绿的 PR晨间简报还要额外核查就绪度如果安全审查或 QA 审查缺失必须显式注明例如READY TO MERGE (code CI), but security review not run.这条规则的价值在于代码批准 CI 通过只是「代码层面就绪」不代表「发布层面就绪」。晨间简报通过把这种差异显式化避免「CI 绿了就顺手合并」的惯性操作。四、自动化更新就绪度文件由谁写入就绪度文件不是靠人工维护而是由以下事件驱动更新检查项更新来源Code reviewPR 获得 GitHub 批准approval或变更请求changes-requested时TestsCI 状态green / red / pendingSecurity review分支上运行/security-review时QA review分支上运行/qa-review时LintingCI 或手动运行cargo clippy/eslint的输出这套「事件 → 文件」映射说明该技能设计上假定存在一个工作区workspace文件系统对应技能描述中的projects/目录约定且 CI/审查工具的输出可以被 Agent 读取并落盘。注意 Linting 同时支持 CI 与手动两种来源因为在本地跑cargo clippy或eslint后再回写也是合法的更新路径。五、裁决逻辑四级状态机技能将合并就绪度收敛为四个离散状态状态判定条件READY所有检查项完成无未解决的 P1/P2 发现CI 绿ALMOST READY所有检查项完成但存在已接受的发现或 CI 仍 pendingNOT READY一项或多项检查尚未运行BLOCKED存在未解决的 P1 发现或 CI 失败这套逻辑的精髓在于对「缺陷」与「缺失」的区分NOT READY 是流程问题只是「还没做」补跑/security-review、/qa-review即可推进BLOCKED 是质量红线存在未解决的 P1critical发现或 CI 红此时任何补跑动作都不能解除封锁必须先解决发现本身ALMOST READY 是灰色地带检查都做完了但要么有「已接受」的发现例如 P3 已接受风险要么 CI 还在跑——可以合并但需要知情人点头。P1/P2/P3 的分级来自 skills/security-review/SKILL.md 的评分体系P1critical每个 -30 分、P2high每个 -15 分、P3medium每个 -5 分最终折算成 0-100 的 Health Score——这正是就绪度看板中Score列的来源。同理skills/qa-review/SKILL.md 也有自己的健康分算法覆盖缺口每个 -10、缺失边界用例每个 -5、回归风险每个 -15、质量问题每个 -5两类评分共同填充看板的 Score 列让「85/100」这类数字背后有可追溯的扣分依据。六、Effort estimates把「剩余工作」翻译成「时间成本」就绪度看板在呈现剩余工作时要求同时给出 AI 辅助与人工两种耗时估算Missing: QA review (~15min AI-assisted, ~2h manual)Missing: Security review (~10min AI-assisted, ~1h manual)这一设计的目的是重构成本认知reframes the cost在 AI 辅助下补齐审查的边际成本很低QA 约 15 分钟、安全约 10 分钟「完整性是廉价的」。这既降低了用户拖延补齐的心理门槛也让「NOT READY」不再是令人沮丧的拒绝而是一个几分钟就能跨过的台阶。七、与相邻技能的协作一条完整的「审查流水线」review-readiness不是孤岛它处于一组技能协作的枢纽位置。仓库skills/目录下与之直接协作的技能包括skills/security-review/SKILL.md按 OWASP Top 10 思路系统审查注入、认证授权、数据暴露、密码学、供应链与硬编码密钥六类问题输出 P1/P2/P3 分级发现与 Health Score并遵循「fix-first」模型能自动修复的直接修并标记[AUTO-FIXED]。其发现的严重程度直接决定就绪度裁决P1 未解决 → BLOCKED。skills/qa-review/SKILL.md从覆盖分析、边界用例、回归风险、测试计划生成、测试健康度五个维度审查变更同样输出 Health Score 与覆盖率缺口清单是就绪度看板中 QA 行的数据源。skills/review-checklist/SKILL.md一份基于 IronClaw 自身 PR 上自动化审查者Copilot、Gemini 等高频反馈归纳的合并前清单覆盖数据库事务、密钥脱敏redact_params()、反 SSRF 的 DNS 预解析、字节索引切片s[..n]禁令、LlmProvidertrait 包装链委托等 IronClaw 特有工程约束——它相当于就绪度看板背后的「检查项明细」从仓库 tests/fixtures 的实践经验中沉淀而来。流水线时序用户问 Is this PR ready? →review-readiness激活读取/创建状态文件并呈现看板若缺失安全审查 → 引导运行/security-review完成后回写结果与评分若缺失 QA 审查 → 引导运行/qa-review完成后回写结果与评分CI 状态、GitHub approval、lint 结果由事件自动回写所有检查完成且无 P1/P2 未决 → 裁决升为 READY晨间简报可标记 Ready to merge。八、与 commitments 系统的联动发现即义务就绪度并非终点——审查发现会流入 IronClaw 的 commitments承诺/义务跟踪体系安全审查P1 发现写入projects/commitments/signals/pending/security-slug.md并标记immediacy: promptP2/P3 标记immediacy: batchP1 还会自动在projects/commitments/open/创建urgency: critical的 commitment见 skills/security-review/SKILL.md 的 Tracking 章节。这与 skills/commitment-triage/SKILL.md 的 immediacy 规则realtime/prompt/batch完全对齐。QA 审查变更代码上的覆盖缺口 →obligation_type: testing、immediacy: batch的信号缺失回归测试 →immediacy: prompt风险更高测试健康度下滑趋势在周度回顾weekly retro中标记见 skills/qa-review/SKILL.md 的 Integration 章节。误报管理若用户驳回某安全发现模式会被记录到projects/commitments/calibration.md避免重复标记false positive management。这意味着「NOT READY」清单中的每一项背后都可能挂着一条可追踪的 commitment——审查不是一次性动作而是进入长期义务跟踪回路。九、源码级佐证路由语料中的 merge-readiness该技能在仓库中的行为可以被实测语料印证。crates/domains/ironclaw_skills/tests/fixtures/routing_corpus.json 是技能选择路由的确定性测试语料其中包含一个与本技能直接相关的 case{ id: merge-readiness, class: conflict, prompt: Is this PR ready to merge, and which checks or reviews are still missing?, relevant: [review-readiness], forbidden: [coding], expect_no_match: false, baseline_selected: [review-checklist, review-readiness, qa-review, security-review] }该 case 验证了三件事相关性判定提问 Is this PR ready to merge, and which checks or reviews are still missing? 时review-readiness被判定为 relevant命中技能激活正则(?i)(is|are) (this|it|PR|the PR) ready (to|for) (merge|ship|review)冲突规避coding被列为 forbidden避免在问「能否合并」时误触发「改代码」技能基线选择在无精确路由的历史基线中系统同时选中了review-checklist、review-readiness、qa-review、security-review四件套——与技能文档中「引导运行/security-review与/qa-review补全检查」的流程一致。同一语料中还有security-audit、qa-test-plan、security-and-qa-review、pre-merge-checklist等 case 把review-readiness列为 forbidden说明该技能被刻意设计为「聚合/裁决型」而非「执行型」——具体的安全或 QA 深挖由专项技能完成review-readiness只负责汇总与裁决避免重复劳动。运行该语料测试的命令见 crates/domains/ironclaw_skills/README.mdcargo test -p ironclaw_skills cargo test -p ironclaw_skills --test routing_corpus # selection corpus (tests/fixtures)十、落地建议把看板带进自己的仓库结合上述机制将review-readiness模式落地到任意 Git 仓库的实践要点约定目录在 workspace 中固定projects/owner-repo/readiness/目录以branch-slug.md命名slugify小写、连字符、无特殊字符、最长 50 字符——与 skills/commitment-triage/SKILL.md 的文件命名约定一致统一 Schema每个文件严格使用 frontmattertype/repo/branch/pr_number/updated_at 五列检查表 Verdict Findings log 的结构保证机器可解析事件驱动更新把 GitHub webhook / CI 回调 / 斜杠命令结果都接到状态文件的写入逻辑上让updated_at与 Last Run 保持真实裁决自动化将 READY / ALMOST READY / NOT READY / BLOCKED 四态判定固化为函数P1 未决或 CI 红时强制 BLOCKED不给人肉放行留后门与义务系统打通P1/P2 发现与覆盖缺口同步进入 commitments 信号流让「审查结论」转化为「待办义务」晨间简报复用把就绪度核查并入每日简报凡是 code CI 就绪但安全/QA 未跑 的 PR 一律显式标注。一个重要的适用前提该技能依赖 workspace 文件系统与projects/目录约定在 IronClaw 中由 skills/commitments 相关技能体系共同支撑若在纯 CI 工具链如仅有 GitHub Actions中使用需要自行实现「事件 → 状态文件」的桥接。本文所有流程与示例均以当前仓库 skills/review-readiness/SKILL.md 的实际内容为准。赞分享人工智能AI 应用交互助手AI Agent【免费下载链接】ironclawIronClaw is an Agent OS focused on privacy, security and extensibility项目地址https://gitcode.com/gh_mirrors/iro/ironclaw点击查看免费下载相关推荐PR Review Triage Skill 实战指南用 pr-review-triage 为 AI PR Babysitter 循环建立可靠的合并就绪判定PR Review Triage Skill 实战指南用 pr review triage 为 AI PR Babysitter 循环建立可靠的合并就绪判定人工智能AI AgentAgent 工作流CLI研发协作AI 技能MCP 服务Yuxi 测试套件边界治理与 readiness 就绪探测一次以证据驱动的测试精简实践Yuxi 测试套件边界治理与 readiness 就绪探测一次以证据驱动的测试精简实践 导读 本文讲解 Yuxi 知识智能体平台在测试治理上的一次关键工程决策人工智能大模型AI AgentRAG多智能体知识图谱后端前端claude-mem babysit 技能实战用 Claude Code 看护 PR 直到合并就绪claude mem babysit 技能实战用 Claude Code 看护 PR 直到合并就绪 这篇文章围绕 claude mem 仓库中 plugin/人工智能Agent 记忆RAGMCP 服务知识图谱AI 插件创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考