القائمة
执行 TDD 红绿重构循环（RED→GREEN→REFACTOR→REPEAT），通过先写失败测试、最小代码实现、保持绿色重构的节奏驱动开发。当启动功能开发、需要测试驱动节奏、进行迭代编码、追求高测试覆盖率时使用。提供检查清单和节奏控制。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
实现关注点分离，确保不同职责模块化和边界清晰。当需要架构分层设计、模块职责划分、横切关注点处理时使用。覆盖层次分离、功能分离、横切关注点三大维度，提供分离检查清单和耦合问题的诊断修复方法。
应用面向对象设计五大原则（单一职责、开闭、里氏替换、接口隔离、依赖倒置），系统化评审类与模块设计质量。当需要评审架构设计、重构现有代码、审查类职责划分时使用。支持多层次检查清单和违反原则的诊断修复。
识别并消除过度设计，确保只实现当前明确需要的功能。当需要评审功能范围、重构冗余代码、权衡技术债务时使用。覆盖功能必要性、过度设计信号、技术债务权衡三大维度，提供具体的识别标准和删减建议。
多维度审查 Markdown 文档质量，覆盖结构、内容、格式、引用、元数据五大维度。当需要评审文档质量、统一格式规范、验收交付文档时使用。提供分级检查清单、通过标准、常见问题修复指南，支持从快速检查到深度审计的多层次需求。
识别并消除知识重复，确保系统中每条知识有唯一权威表示。当需要重构代码、整理文档、优化配置、建立单一数据源时使用。覆盖代码重复、数据冗余、文档重复三大维度，提供具体消除策略和权衡建议。
评估用户故事质量的六维度框架（独立性、可协商、有价值、可估算、小粒度、可测试），系统化审查需求质量。当需要编写用户故事、评审需求文档、拆分史诗故事时使用。提供分级检查清单和低质量故事的改进建议。
| name | tdd-cycle |
| description | 执行 TDD 红绿重构循环（RED→GREEN→REFACTOR→REPEAT），通过先写失败测试、最小代码实现、保持绿色重构的节奏驱动开发。当启动功能开发、需要测试驱动节奏、进行迭代编码、追求高测试覆盖率时使用。提供检查清单和节奏控制。 |
| stage | EXECSPEC_FULFILL |
| level_supported | ["L1-STREAMLINED"] |
Scope: EXECSPEC_FULFILL — Fulfill ExecSpec（落实 ExecSpec）
版本: 0.1.0（占位）| 创建日期: 2025-11-27
TDD Cycle 是测试驱动开发的核心循环：
┌─────────────────────────────────────────────────────┐
│ 🔄 TDD Cycle │
├─────────────────────────────────────────────────────┤
│ ┌─────┐ │
│ │ RED │ ← 写失败的测试 │
│ └──┬──┘ │
│ ↓ │
│ ┌─────┐ │
│ │GREEN│ ← 最小代码让测试通过 │
│ └──┬──┘ │
│ ↓ │
│ ┌──────────┐ │
│ │REFACTOR │ ← 重构，保持测试绿色 │
│ └────┬─────┘ │
│ └──────→ REPEAT │
└─────────────────────────────────────────────────────┘
核心节奏：
>>tdd_check_l1 # 检查 TDD 节奏
>>coverage_report_l1 # 测试覆盖率报告
// GOAL: GOAL-XXX-001
describe('功能描述', () => {
it('should ...', () => {
// 测试代码
});
});
问题：测试写得太大 解决：每个测试只验证一个行为
问题：不知道先测什么 解决：从最简单的 Happy Path 开始
问题：写了太多代码 解决：只写让测试通过的最小代码
问题：想一步到位 解决：接受"丑陋"的代码，重构阶段再优化
问题：跳过重构 解决：每次 GREEN 后强制问自己"能更简单吗？"
问题：重构时破坏测试 解决：小步重构，每步都运行测试
TODO: 待细化覆盖率检查脚本和 TDD 节奏监控