auto-harness-santa

Files (1)

• SKILL.md

SKILL.md (first lines)

# Harness Santa

双独立 Reviewer 对抗验证——两个 Agent 独立审查，都通过才放行。

## 何时使用

- 高风险代码变更（安全、支付、核心逻辑）
- 生产部署前
- 复杂算法或多组件集成
- 用户说"Santa review"或"对抗验证"

## 何时不用

- 低风险改动（文档、配置、格式化）
- 有充分自动化测试覆盖的简单变更
- 探索性原型

## 执行流程

### Phase 1: Make a List（准备）

收集待审查的材料：
- 代码变更（git diff 或文件内容）
- 需求规格（如果有）
- 审查 Rubric（见下方模板）

### Phase 2: Check It Twice（双独立审查）

并行启动两个独立 Reviewer Agent：

**Reviewer A（Claude Agent）：**
```
你是独立的质量审查者。你没有看过其他任何审查意见。

## 待审查内容
{代码变更}

## 审查标准
{Rubric}

## 指令
逐项对照标准检查。对每一项：
- PASS: 完全满足，无问题
- FAIL: 发现具体问题（引用具体位置）

输出 JSON：
{
  "verdict": "PASS" | "FAIL",
  "checks": [{"criterion": "...", "result": "PASS|FAIL", "detail": "..."}],
  "critical_issues": ["..."],
  "suggestions": ["..."]
}

严格检查。你的工作是发现问题。
```

**Reviewer B（可选用 Codex `/codex:adversarial-review`，或另一个 Claude Agent）：**
同样的 Rubric，同样的代码变更，独立上下文。

**关键不变量：**
- 两个 Reviewer 互不可见（上下文隔离）
- 使用相同的 Rubric
- 并行执行

### Phase 3: Naughty or Nice（判决）

```
Reviewer A: PASS  AND  Reviewer B: PASS  →  NICE  →  放行
其他情况                                →  NAUGHTY  →  Phase 4
```

一个发现问题就算 NAUGHTY。

### Phase 4: Fix Until Nice（修复循环）

```
收集两个 Reviewer 的所有 issues
    ↓
派 Fix Agent 修复（只修 flagged issues，不做额外重构）
    ↓
重新启动两个全新 Reviewer Agent 审查修复后的代码
    ↓
最多 3 轮。超过 3 轮 → 升级给人工处理。
```

**关键：** 每轮修复后用全新 Agent 重审，防止锚定偏差。

## Rubric 模板

| 检查项 | PASS 条件 | FAIL 信号 |
|--------|----------|----------|
| 功能正确性 | 所有 spec 需求被覆盖 | 遗漏需求项 |
| 无幻觉 | 无虚构的 API/函数/URL | 引用不存在的东西 |
| 安全性 | 无硬编码密钥，输入有验证 | 发现敏感信息 |
| 一致性 | 无自相矛盾 | A 处说 X，B 处说 non-X |
| 技术正确性 | 代码可编译运行，逻辑正确 | 语法错误、逻辑 bug |
| 错误处理 | 异常路径有处理 | 缺少 error handling |

根据项目补充领域特定的检查项。

## 指标

- **First-pass rate**: 第一轮通过率（目标 >70%）
- **Mean iterations**: 平均修复轮数（目标 <1.5）
- **Reviewer agreement**: 两个 Reviewer 同时发现的问题占比
- **Escape rate**: Santa 通过但上线后发现的问题（目标 0）

## 跨模型扩展

Reviewer A 用 Claude，Reviewer B 用 Codex（`/codex:adversarial-review`）。不同模型有不同盲区，交叉审查进一步降低逃逸率。

## AI 工具内测试准出协议

只要任务涉及代码变更，AI 不能等用户提醒才验证。按下面顺序做：

1. 先判断风险等级：low / medium / high / release。
E2E PASS 不等于充分；如果只是 echo ok、空脚本、只 smoke、或没覆盖本次风险，用户报告要先说“现在还不能交付”，再说明测到了什么、没测到什么、下一步补什么；机器状态放最后，例如：机器状态：NOT_SUFFICIENT。DEGRADED 不能说成 PASS。
2. 识别测试能力：单测、lint、coverage、E2E、runtime smoke。
3. medium / high / release 任务必须有 E2E 证据；只有 low 小改可以不强制 E2E；找不到 E2E 入口时，先生成计划或只问一个具体启动问题。

From duoglas/simple-harness-kit, MIT.

More from duoglas/simple-harness-kit