CodeFlow Guard

使用本 Skill 审查代码变更时，先稳定收集审查上下文，再按风险规则输出报告。

审查流程

1. 优先运行上下文采集脚本：

node /scripts/collect-review-context.js --repo .

1. 如果用户提供测试命令，传入脚本：

node /scripts/collect-review-context.js --repo . --test-cmd ""

1. 是当前 SKILL.md 所在目录；在本仓库测试时是 .skills/codeflow-guard，安装到业务仓库时通常是 .codebuddy/skills/codeflow-guard。
2. 如果 Skill 安装在子目录但要审查业务仓库，使用 --repo "<业务仓库路径>"；未指定路径时脚本审查目标仓库全部可审查文件，并自动排除 Skill 自身目录。
3. 如果用户指定审查范围，使用可重复的 --path "<文件或目录>"；脚本只审查指定范围，并自动纳入直接相对引用文件。
4. 如果脚本不可用，再手动运行 git status --short --branch、git diff --stat、git diff --name-status、git diff --check、git diff 和相关测试命令。
5. 读取 references/risk-rubric.md 判断风险等级。
6. 读取 references/output-template.md 生成最终报告。

风险等级

• P0：阻断合并，可能导致严重安全、数据、资金、隐私或生产事故
• P1：高风险，必须修复或补充验证
• P2：中风险，建议修复或补充测试
• P3：低风险，优化建议

输出硬约束

• 使用中文输出。
• 先把脚本输出中的 Review Brief 和 Review Files 当作审查任务单：待判断文件必须逐个进入“变更摘要”，疑似风险信号必须逐个核验。
• 脚本输出的事实数据是权威来源，包括待判断文件数、Git diff 变更文件数、Diff 状态、测试执行状态、测试执行结果、静态扫描发现跳过测试总数和行号证据；最终报告若与脚本事实冲突，必须先重新核查并以脚本数据为准。
• 目录名不能作为跳过理由；examples/、samples/、demo/、test/ 等路径只要在待判断文件中，就按实际变更审查。
• 严格使用 references/output-template.md 的分节顺序，不要省略任何必填章节。
• 脚本只负责收集证据和疑似风险信号；最终风险等级、风险计数和合并建议必须由 LLM 根据 references/risk-rubric.md 与上下文判断。
• 如果最终报告缺少“审查上下文”“风险计数”“Top 3 必须修复项”“关键风险”“测试建议”“合并前检查清单”“复审标准”中的任一章节，必须在输出前自行重写。
• 结论区必须一项一行，禁止把“合并建议、总体风险、一句话摘要”挤在同一行。
• 避免宽表格。关键风险使用卡片式条目，方便窄窗口阅读。
• 顶部一句话摘要控制在 35 个汉字以内，只写最核心风险，不堆叠长句。
• 引用仓库根目录下的相对路径。优先使用 Changed Line Anchors 和 Current File Snapshots 中的当前文件行号。
• Top 3 和每个关键风险标题必须包含 path:line；如果是删除行导致的风险，使用 path:旧行号 并在证据里标注“删除行”。
• 如果行号无法确认，只写文件路径和函数名，不要编造行号。
• Sensitive Literal Findings 和 Review Signals 是证据来源，不是最终结论；必须核验上下文后再决定是否进入“关键风险”和风险计数。
• 敏感证据只能引用脚本输出的脱敏值。命中 key/token/secret/password/apikey/connection string/Authorization 的字面量或日志值必须脱敏；即使未命中关键词，只要 LLM 根据上下文判断可能是凭据、身份标识、隐私或可复用访问数据，也必须脱敏。脱敏格式统一为“仅保留前缀 + *”：保留原值前 10%（向上取整）且最多 4 个字符、最少 1 个字符，其余全部替换为 *；禁止保留后缀和输出完整值。若发现报告中出现完整敏感值，必须在输出前重写该段。
• Top 3 候选必须优先考虑：认证绕过、硬编码密钥/令牌、数据/资金风险、关键测试被跳过。
• “测试覆盖率”只能在采集上下文出现 coverage 工具结果时使用；否则只能写“通过/失败/跳过数量”。
• 测试未运行时，结论区“测试执行结果”必须写“无执行结果”；不要写“通过=0，失败=0，跳过=0”。静态扫描发现的跳过测试总数需单列展示。
• 不要混用“静态扫描发现跳过测试总数”和“本次需处理的跳过测试”；前者取脚本事实，后者由 LLM 结合当前审查目标、风险路径和变更相关性判断。两者不一致时必须说明筛选依据。
• 发现与本次审查目标或 P0/P1 风险路径相关的 test.skip、describe.skip、it.skip、t.Skip、pytest.mark.skip 或测试输出 skipped 时，必须列为测试风险。
• 审查上下文必须同时写“待判断文件数、审查类型、审查模式、Git diff 变更文件数、Diff 状态”；Git diff 变更文件数 = 0 不代表本次无审查内容。若审查类型是静态审查或静态巡检，不要把风险写成本次 diff 引入。
• 风险计数按“关键风险”条目数量统计；同一根因可合并为一个条目，但计数与条目总数必须一致。
• 只有 Syntax Check、测试输出或构建输出明确失败时，才能写语法错误、解析失败或应用无法启动。
• 只基于代码变更、测试结果和采集上下文中的证据下结论。
• 最后给出“可合并 / 补测后合并 / 不建议合并”的判断和复审标准。

输出前自检

最终回答前逐项检查：

1. 结论区是否分行展示合并建议、总体风险、摘要、风险计数、测试执行状态、测试执行结果、静态扫描发现跳过测试总数和本次需处理的跳过测试。
2. Review Brief 中每个待判断文件是否都进入“变更摘要”，并给出文件级判断。
3. Review Brief 中每个疑似风险信号是否都被核验，并在关键风险、测试建议或变更摘要中说明处理结果。
4. 是否包含审查上下文中的采集命令、测试命令和 Diff 检查结果。
5. 是否包含 Top 3 必须修复项，且每项都有 path:line。
6. 关键风险是否使用卡片式条目，并包含风险、证据、影响、建议、推荐测试。
7. Sensitive Literal Findings 是否被逐项核验，且没有展示完整敏感值。
8. 最终风险等级、风险计数和合并建议是否基于 risk-rubric.md 与证据，而不是照抄脚本信号。
9. 是否明确“测试执行结果”“静态扫描发现跳过测试总数”和“本次需处理的跳过测试”三个口径，且没有误写成覆盖率。
10. 是否包含合并前检查清单和复审标准。