Workflow Patterns
使用 Conductor 掌握 TDD 工作流
为缺乏条理的开发工作流和糟糕的测试覆盖率而困扰？本技能提供了一套结构化的 TDD 框架，包含阶段检查点、git 提交管理和验证协议，确保整个实现过程中的代码质量。
下载技能 ZIP
在 Claude 中上传
前往 设置 → 功能 → 技能 → 上传技能
开启并开始使用
测试它
正在使用“Workflow Patterns”。 帮助我在完成阶段 1 后创建检查点提交
预期结果:
- 正在运行自动化验证...
- 测试套件：47 个测试通过
- 覆盖率：87%（目标：80%）
- Linting：无错误
- 检查点提交已创建：def5678
- 计划已用检查点 SHA 更新
- 等待手动验证批准
正在使用“Workflow Patterns”。 指导我完成任务 2.1 的 TDD 工作流
预期结果:
- 步骤 1：选择下一个任务 - 任务 2.1 已标记
- 步骤 2：在 plan.md 中标记为进行中 [~]
- 步骤 3：RED - 编写失败的测试（test_validate_user_email）
- 步骤 4：GREEN - 实现最小代码（validate_email 方法）
- 步骤 5：REFACTOR - 提取模式，改进命名
- 步骤 6：验证覆盖率 >= 80%
- 步骤 7：记录任何偏差
- 步骤 8：创建结构化提交
- 步骤 9：附加带有摘要的 git notes
- 步骤 10：用提交 SHA 更新 plan.md
- 步骤 11：提交计划更新
安全审计
安全Static analysis detected 80 potential security issues in resources/implementation-playbook.md, all of which are false positives. The file contains Markdown documentation with bash code examples for educational purposes. The external_commands patterns are git command examples in code blocks (lines 25-571), not executable code. The weak_crypto findings are documentation text, not cryptographic implementations. This skill contains only documentation and no executable code, posing no security risk.
中风险问题 (1)
质量评分
你能构建什么
使用 TDD 实现新功能
开发人员遵循红 - 绿 - 重构循环实现新的用户认证功能，每个步骤都有适当的测试覆盖率和 git 提交。
建立阶段检查点
技术负责人在每个开发阶段结束时创建验证检查点，确保在继续之前满足质量门控要求。
追踪实现进度
开发人员通过用提交 SHA 更新 plan.md 并维护从计划到代码的可追溯性来追踪任务完成情况。
试试这些提示
我正在开始任务 2.1：实现用户验证。请帮助我遵循 TDD 工作流，先编写失败的测试，然后实现最小代码使其通过，最后重构以提高清晰度。
我已完成阶段 1 的所有任务。请帮助我创建带有验证的检查点提交：运行完整测试套件，检查覆盖率高于 80%，并生成手动验证清单。
请帮助我为任务 2.1 完成创建结构化提交消息，遵循格式：type(scope): subject，包含要点的项目符号正文，以及带有任务/轨道引用的页脚。
在实现过程中，我发现我们需要与计划不同的方法。请帮助我在 plan.md 和 tech-stack.md 中正确记录此偏差。
最佳实践
- 始终先编写失败的测试（RED）再进行实现（GREEN）- 切勿跳过 RED 阶段
- 创建原子提交 - 每次提交一个逻辑更改，每次提交后测试都应通过
- 在通过阶段检查点之前等待明确的用户批准 - 不要跳过验证门控
- 完成每个任务后立即更新 plan.md，附上提交 SHA 以便追溯
避免
- 在测试之前编写实现代码 - 这违反了 TDD 原则并降低测试有效性
- 将多个任务批量合并到一个提交中 - 这破坏了可追溯性并使语义回滚变得困难
- 未经检查点批准就进入下一阶段 - 这绕过了质量门控并可能导致技术债务累积
- 仅在完成多个任务后才更新 plan.md - 这会丢失可追溯性并使进度审计变得困难