compliance-policy-check

合规策略检查

概述

在执行前，根据框架策略和规则约束评估设计／计划。适用于受监管或高风险的变更。

适用时机

• 为新制品启动创建者工作流之前
• HIGH／EPIC 实施阶段之前
• 反思时发现反复出现的策略违规

铁律

1. 合规检查期间绝不执行或修改代码——此技能只评估策略一致性；确认合规后，必须另行实施。
2. HIGH／EPIC 实施之前始终先运行合规检查——绕过合规检查的高风险变更会造成未被发现的策略偏移，随着时间推移逐渐累积，最终导致系统性违规。
3. 始终报告发现的问题，并提供具体的修正任务和负责的 Agent——只写含糊的“策略违规”而不提供可执行的修正步骤，无法促成问题修复；每个 FAIL 和 CONDITIONAL 都必须包含具体任务。
4. 合规不完整时绝不报告 PASS——满足 80% 策略要求的计划应判定为 CONDITIONAL，而非 PASS；部分合规会掩盖剩余违规，并造成虚假的信心。
5. 修正后始终重新检查，而非只检查一次——实施前只进行一次合规检查并不充分；重大变更后应再次验证，确认修正已完成。

工作流

步骤 1：收集策略背景

• 阅读 .claude/rules/ 中的相关文件
• 阅读适用的工作流／Agent 约束
• 如有需要，阅读强制执行钩子的文档

步骤 2：评估拟议变更

根据以下内容进行评估：

1. 创建者防护和制品生命周期规则
2. 路由和专家优先要求
3. 安全与质量门禁要求
4. 记忆／搜索／节省令牌的策略预期

步骤 3：给出决策

返回以下一种策略决策：

• PASS：符合策略
• CONDITIONAL：采取所需的缓解措施后允许
• FAIL：不符合策略

使用以下输出格式：

{
  "decision": "PASS|CONDITIONAL|FAIL",
  "policyFindings": ["..."],
  "requiredMitigations": [],
  "evidencePaths": ["..."],
  "recommendedNextStep": "..."
}

输出规范

对于 CONDITIONAL 和 FAIL，请提供精确的修正任务和责任归属（Agent 类型）。

反模式

反模式	失败原因	正确做法
在合规检查期间实施代码	混淆评估与实施	仅进行评估；PASS 后另行实施
因变更“很小”而跳过合规检查	小型变更也可能悄无声息地引入策略违规	按比例对所有 HIGH／EPIC 工作进行合规检查
合规不完整时报告 PASS	掩盖未解决的违规；造成虚假的信心	报告 CONDITIONAL，并列出具体所需修正
报告违规时未提供修正措施，内容含糊	没有明确的后续步骤，违规问题就不会得到修复	对每个 FAIL／CONDITIONAL，列出 Agent、任务和目标文件
实施前只检查一次	变更后的合规偏移无法被发现	重大实施变更后重新检查合规性

记忆规范

将反复出现的策略偏移模式记录到 .claude/context/memory/issues.md，将已稳定的控制措施记录到 .claude/context/memory/decisions.md。