taiyi-dev

Files (1)

• SKILL.md

SKILL.md (first lines)

# taiyi-dev — TDD 开发

> 进入本阶段前请优先读 `.taiyi/changes/<slug>/PHASE-CONTEXT.md`（~500 tokens），不要全量加载上游工件。

## 框架集成

本阶段使用以下框架：

| 框架 | 用途 | 何时加载 |
|------|------|---------|
| **Harness** | 阶段门禁与推进（`apply` 清单 · `status` → `continue`；legacy：`npx taiyi apply/complete`） | 全程 |
| **Superpowers** | `test-driven-development` — TDD 红→绿→重构循环 | 步骤 1（强制） |
| **Superpowers** | `systematic-debugging` — 测试失败时诊断 | 异常处理时 |
| **Superpowers** | `verification-before-completion` — 完成前验证 | 完成前 |

**GStack / OpenSpec / Spec-Kit / OMO** 在本阶段不涉及。

## 前置门禁（Pre-flight）

### 0.1 上游确认
- task 阶段已过关（`engineTruth` 确认）
- TASK.md 中无未解决的 `[depends_on: ?]`
- 当前 git 分支干净（无未提交的临时修改）

### 0.2 Profile 判定

| Profile | 开发要求 |
|---------|---------|
| `full` | 全 TDD（红→绿→重构）+ 全部 0.x 检查 + self-review(R1-R11) |
| `api/ui` | 同 full |
| `lite` | TDD 可选，0.x 检查中的 0.5（破坏性变更）必须执行 |
| `micro/spike` | 仅 0.1（grep 已有抽象）+ 0.5（破坏性变更） |
| `nano` | TDD 可选，0.5 必须执行 |

### 0.3 前置检查清单
- [ ] task 阶段已过关
- [ ] todo 列表已就绪（每个 T0X 一个 todo 项）
- [ ] 理解 TASK.md 的 verify 标准和 write_files 边界

---

## 步骤

**dev 无 json 视图**：过关证据为 `.dev-complete`（`command` + `exitCode: 0`）。实现边界仍来自 `task.json` / 渲染后的 `TASK.md`。

### 0. 上下文加载

先读 PHASE-CONTEXT.md 确认范围，再读 TASK.md 拿到任务清单。**不写不在 TASK 中的功能。**

### 0.1 沿用已有抽象 grep（强制）

写新代码前 grep 同类模式，贴入 SUMMARY：

```
# grep -rn "class.*Adapter" src/  → 找到 LLMAdapter 抽象基类
# grep -rn "from.*middleware" src/ → 找到 LoggingMiddleware 模式
```

**不 grep 直接写 = 制造重复抽象**。

### 0.2 扫 LESSONS（强制）

```
grep -rn "LESSON" .taiyi/changes/<slug>/ 2>/dev/null || echo "无 LESSONS"
```

对 active 条目声明差异。相同方案已记录失败教训 → **停手，选不同方案**。

### 0.3 UI 任务额外检查

确认 UI-DESIGN.md 存在。颜色/字体/间距从 UI-DESIGN.md 派生。**禁硬编码 hex**。

### 0.4 Schema 变更检查

生成可逆迁移（up + down）。grep 确认数据库当前结构，避免迁移冲突。

### 0.5 破坏性变更高门槛

命中任一 → **STOP，展示引用分析结果，等用户明确指示**：
- 删除 ≥ 5 行代码
- 修改公共导出（export function / export class）
- 改 API 端点签名（path / method / request body）
- 改 DB Schema 列名或类型

---

### 1. TDD 红→绿→重构（强制）

<tdd_enforcement>
STEP A — WRITE FAILING TEST ONLY
  - Write the test that defines the expected behavior. Do NOT touch business logic yet.
  - The test MUST be a real assertion (not console.log, not TODO).

STEP B — CAPTURE RED EVIDENCE（MANDATORY）
  - Run the test script. Capture the RED (failing) terminal output.
  - PASTE the failing output into .dev-complete as evidence under "RED: <test-id>".
  - DO NOT proceed to step C without RED evidence.

STEP C — IMPLEMENT GREEN
  - Write the minimum production code to make the test pass.
  - Re-run the exact same test. Capture GREEN (passing) output.
  - Paste GREEN output into .dev-complete alongside the RED evidence.

STEP D — REFACTOR
  - Optional cleanup. Tests MUST stay green.

<three_case_rule>
最低测试覆盖 (强制) — 每个新函数必须 ≥ 3 个 test case:
  1. happy case — 正常输入返回预期输出
  2. edge case — 边界输入 (空/null/0/最大值/Unicode/...)
  3. error case — 异常输入 (类型错/null/无效格式) 走 error 处理分支

禁止单 case 提交. 三个 case 缺一即视为覆盖不足.

反模式 (禁止):
  - 只测 happy path 不测边界
  - console.log / TODO 代替断言
  - 把 3 个 case 写成"复用同一断言"的循环 (虽然技术正确但语义模糊)
</three_case_rule>

From Dong90/oh-my-taiyiforge, MIT.

More from Dong90/oh-my-taiyiforge