# Example Data Observability Quality CLAUDE.md

适用于数据可观测性平台、数据质量平台、指标对账仓库、数据血缘治理仓库或告警与异常检测平台。

这类项目的重点不是单个数据任务，而是质量规则、监控口径、异常信号、告警路径和修复闭环是否可解释、可持续。

## 适用信号

- 需求经常涉及数据质量规则、异常检测、监控告警、血缘说明、SLA/SLO、对账或根因分析
- 成功标准常常是异常可发现、规则可解释、告警可行动、修复可跟踪
- 项目通常同时关注规则定义、平台展示、通知链路和运行时成本

## 相对通用版的主要差异

### 1. 命令流更强调规则定义、验证与放行判断

- 建议链路：`/team-intake` -> `/team-plan` -> `/tdd` -> `/team-execute` -> `/verify` -> `/team-review`
- 如果同时改平台入口或治理文档，可补 `/harness-audit`

### 2. 项目约束更偏异常信号和告警闭环

- 必须写清规则口径、异常阈值、告警通道和处置责任
- 验证不能只看规则运行，还要看误报、漏报和告警可操作性
- review 需要记录当前可接受噪音与后续优化方向

### 3. 角色链路更偏架构、后端 / 数据与 QA

- 默认保留：`tech-lead`、`architect`、`backend-engineer`、`qa-engineer`
- 若存在平台运营台或监控台，再引入 `frontend-engineer`

## 一份更适合数据可观测性 / 质量平台的精简成品

````md
# Data Observability Quality Working Agreement

## 项目定位

- 类型：数据可观测性 / 数据质量平台
- 重点：规则口径、异常阈值、告警路径、血缘与修复闭环

## 默认角色

- `tech-lead`
- `architect`
- `backend-engineer`
- `qa-engineer`

## 默认命令流

1. `/team-intake`
2. `/team-plan`
3. `/tdd`
4. `/team-execute`
5. `/verify`
6. `/team-review`

## 项目约束

- 必须说明规则口径、异常阈值、告警路径和处置责任
- verify 需要覆盖误报、漏报、异常样本和告警有效性
- review 必须记录当前噪音接受度与后续优化建议

## 常用提示模板

```text
/team-intake
目标：为数据可观测性平台新增质量规则并补齐告警与修复闭环
范围：规则定义、异常检测、告警通道、结果汇总、测试计划
不做：无关分析台 UI 改造
约束：必须说明规则口径、误报/漏报风险、告警责任和处置路径
```

```text
/verify
请基于当前质量规则改动，汇总异常检测结果、误报/漏报、告警有效性和可直接进入 /team-review 的结论。
```
````