justify 是一个变更审查技能，核心目标是判断“修好问题的最小改动”是否被做成了“不断加代码”。它针对 AI 倾向添加代码而非修复根因的系统性偏见，审计六类模式：加 workaround 而非修根因、改测试预期而非修实现、新建 helper 而非复用、加错误处理而非预防错误、加兼容层而非删除旧代码、包 try/catch 而非修异常源。
适用时机：实现完成后、提交或创建 PR 前、自查变更质量时、scope-guard 标记 RED/YELLOW 时。不适用于写代码之前，也不用于判断功能是否属于范围。
用法分步：一，用 git merge-base 确定 base 分支，并用 git diff --stat、--shortstat、--diff-filter=A/M/D 收集变更。二，按维度打 0-3 分并加权计算附加偏见分数：行数比 2 倍权重、新文件 2 倍、测试逻辑改动 3 倍、新抽象 1 倍、workaround 模式 2 倍；聚合分对应 GREEN 继续、YELLOW 逐项说明、RED 重新思考、STOP 很可能方向错误。三，检查 Iron Law：测试驱动实现，而非反过来；若断言值被改、测试被删或跳过、异常预期被放宽、mock 返回值被改、测试被重命名，均需明确说明需求是否真的变了。四，做最小干预与不变式影响分析；涉及架构、数据结构、API 契约、错误策略、并发模型等设计不变式冲突时，不得静默选择，应向人呈现 Preserve/Layer/Revise 三个选项并标注人工复核。五，输出 Justification Report，包含分数、Iron Law 状态、逐文件理由、风险评级与 Burden of Proof 表；未证明必要性的改动应移除或重做。若已有相关技能，可在报告通过前把非平凡但有理由的改动记录到 docs/tradeoffs.md。
限制：面向已完成变更的审计，不替代写前设计；不自动决定不变式取舍；须在 git 仓库中使用。其他收费、平台、效果信息资料未提供。