菜单
Use when an already-defined new behavior or high-risk implementation contract needs a failing test before implementation, or the user explicitly requests TDD; diagnosed bugs stay with ccdawn-bug-review, while simple or mechanical work uses targeted verification.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when a user message needs Chinese-first intent inference, low-confidence collaborative clarification, routing, workflow weight control, skill choice, review/testing/planning/debugging/evaluation routing, proactive multi-thread collaboration or conflict coordination, continuation handling, execution permission inference, or protection from process over-escalation.
Use when active development or explicit refactoring has concrete code-structure risk: a source file is accumulating independently changing responsibilities, a class/component/function is hard to navigate or test, repeated changes touch distant sections, or the user asks to split a giant file; do not use for line count alone, generated/vendor/migration/schema/fixture files, or cohesive modules that remain easier to maintain together.
Use when the user explicitly enables an automated same-project multi-thread development loop that keeps peer Codex tasks progressing, recovers conflicts or stale coordination, integrates verified work into local main, and closes cleanup without repeated gates; do not use before opt-in, for one-off coordination, remote publication without permission, or subagent creation.
Use when existing independent Codex App threads work in the same project and need peer advice, collaboration proposals, shared progress awareness, ownership arbitration, conflict pause/resume, discussion, merge coordination, status exchange, or handoff through native thread tools without creating subagents.
Use when a verified or integrated software change has concrete temporary artifacts, generated noise, stale claims, merged local branches, or disposable worktrees to clean, or when the user explicitly asks to remove development residue or old branches.
Use when the user or project rules explicitly request project-local memory/dashboard initialization or updates, or when an existing `.docs/project-memory/` is needed for cross-session recovery, durable decisions, blockers, parallel-agent coordination, or formal handoff; do not auto-initialize or sync it for ordinary development.
| name | ccdawn-bdd-tdd-development |
| description | Use when an already-defined new behavior or high-risk implementation contract needs a failing test before implementation, or the user explicitly requests TDD; diagnosed bugs stay with ccdawn-bug-review, while simple or mechanical work uses targeted verification. |
| license | MIT |
只对已明确的新行为或高风险实现契约使用最小 RED/GREEN 闭环，不承担未知根因诊断，不生成仪式性文档、逐步旁白或代理审查链。
ccdawn-score-loop、下一个已授权任务、ccdawn-development-cleanup、ccdawn-pr-review、ccdawn-brt 或 BLOCKED。ccdawn-brt 或更具体 owner，复合任务不吞其他 owner。下一步建议: <一个具体动作>。按子任务判断，不给整个请求贴 TDD 标签。机械替换、样式/文案、普通配置、生成代码、小适配，或已有验证足够时直接轻量实现。
Bug、异常、失败测试或构建失败由 ccdawn-bug-review 主责；可测性能目标/回归由 ccdawn-performance-engineering 主责。两者即使使用 RED/GREEN 也不加载本 skill。只有预期行为和 owning surface 已明确的新增/变更契约，或用户明确要求 TDD，才由本 skill 主责。
分数下降、metric 未提升、candidate reject 或 online worse 是实验结果，不是 TDD RED，返回 ccdawn-score-loop。只有预期输入输出明确的 harness/parser/schema/seed/shape/NaN/打包 bug 留在这里。
强信号：确定性行为回归；状态/数据/权限/安全/迁移/公共 API 风险；失败路径易遗漏；跨模块行为只能靠自动化证明；或用户明确要求 TDD。文件多、描述长和 Superpowers always 不构成触发。
给定/当/则；只有真实分叉才展示。围绕可观察行为组织测试，不为每个函数/分支建测试，不默认创建 .feature、矩阵或长 Gherkin。优先复用 fixture/helper；测试基础设施成本过高时改用最小集成测试、结构检查或可逆 probe，并说明缺口。出现 mock/test-only API 风险时才读取 testing-anti-patterns.md，正式 Gherkin 才读取 references/gherkin.md。
默认不派发子代理。只有 lane 独立、写入面不重叠、可单独验证且收益明显高于上下文/审查/合并成本时才派一个紧凑实现 Agent；主 Agent 检查 diff 并重跑证据。共享文件和顺序依赖留在当前上下文。
RED 原因错误先修测试/环境；GREEN 未通过就在当前边界修复；测试意图与需求冲突则回 BRT；自动化不可行时报告替代证据和风险，不伪造 TDD。
开发结果:
- 模式: LIGHTWEIGHT / COMPACT_TDD
- 变更: <行为与文件>
- 证据: RED...；GREEN...；回归...
- 风险: <无或真实缺口>
下一步建议: <继续已授权任务或收口>
LIGHTWEIGHT 不虚构 RED/GREEN。验证通过后自动进入下一个已授权项；普通任务不输出 Task Graph、ledger、自审矩阵或阶段菜单。