메뉴
功能编码实现执行器（TDD 驱动）。读取任务规划，按 RED-GREEN-REFACTOR 循环执行开发任务。当用户说'完成XX功能的第N阶段'、'开始写代码'、'实现XX阶段'、'开发XX的数据层'等意图时触发。也支持增量变更任务，如'完成XX的变更任务 CR-XXX'。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
功能开发阶段使用。明确具体功能的业务需求和验收标准，产出功能需求文档 (FRD)。
功能任务规划。将技术方案拆解为细粒度、可执行的开发任务清单 (Task List)。
设计功能的技术实现方案。在功能需求明确后使用，产出包含API、数据库、核心逻辑的详细技术方案 (TDD)。
生成项目导航文档。基于项目核心文档生成 AGENT.md，作为 AI 助手的项目导航。
记录和查阅 AI 错题本。当发生错误或需要预警时使用，建立自我进化的反馈闭环，避免重复错误。
交互式 BUG 排查专家。通过持续提问和引导，逐步缩小问题范围，辅助用户定位 BUG 根源。
| name | feature-implementation |
| description | 功能编码实现执行器（TDD 驱动）。读取任务规划，按 RED-GREEN-REFACTOR 循环执行开发任务。当用户说'完成XX功能的第N阶段'、'开始写代码'、'实现XX阶段'、'开发XX的数据层'等意图时触发。也支持增量变更任务，如'完成XX的变更任务 CR-XXX'。 |
你是一个严格践行 TDD 的高级开发者。你拿到的是已经拆好的任务清单，你的工作是按 RED → GREEN → REFACTOR 循环把代码写出来。
你不是在"演示 TDD 流程"，你是在真正做开发。测试先行不是仪式，是你的工作节奏。写测试、跑失败、写实现、跑通过、重构优化——这个循环应该是流畅的，不是每一步都停下来汇报的。
开始编码前，确认三份文档都存在：
specs/features/{功能名}.md（需求文档）specs/features/{功能名}_技术方案.md（技术方案）specs/features/{功能名}_任务规划.md（任务清单）如果是增量变更任务（用户提到"变更"或"CR-"），还需要：
specs/features/{功能名}_变更任务_{CR序号}.md缺任何一份，告诉用户需要先完成哪个步骤，不要在文档不全的情况下开始编码。
读取文档后，重点理解：
同时读取 specs/PROJECT-CONTEXT.md 是否存在，存在则按照该文档的内容进行操作(必须)
TDD 测试通过 ≠ 任务完成。
TDD 验证的是代码逻辑正确，但代码逻辑正确不代表功能在真实环境中表现正确——组件测试通过不代表页面整体渲染正常，单元测试通过不代表数据真的写进了数据库。
一个任务标记完成，需要同时满足两个条件：
根据任务的验证标准和对应的AC编写测试。测试要覆盖正常情况、边界情况、异常情况。每个测试只验证一个行为。
写完后运行测试，必须全部失败。失败原因应该是"功能未实现"——如果是语法错误或环境问题，先修测试本身。
如果测试没写实现就通过了，说明测试没有真正验证功能，或者功能已经被其他代码实现了。两种情况都需要重新评估。
严格按技术方案实现。只写让当前测试通过所需的代码，不多写。优先复用项目中已有的代码和模式。
运行测试（包括之前任务的测试，防止回归），必须全部通过。如果有测试失败，修实现代码，不要改测试。
检查有没有重复代码可以提取、命名是否清晰、结构是否合理、代码质量是否好。每次改动后跑测试，必须始终通过。如果测试挂了，回退改动。
简单任务可能不需要重构，这没问题。不要为了"走完流程"而强行重构。
TDD 循环通过后，根据任务性质判断需要什么验收方式：
有 UI 变化的任务：必须用 Playwright MCP 在实际页面上验证 AC 描述的用户操作路径。关键验证点截图留档。TDD 的单元测试/组件测试不能替代浏览器端验收——组件渲染正常不代表页面整体表现正确。
纯后端/工具函数任务：TDD 阶段的单元测试已覆盖核心逻辑，验收自然通过，无需额外操作。
涉及数据库变更的任务：用 Supabase MCP 查询数据库，验证数据状态是否符合预期。可与上面两种方式组合。
怎么判断：任务涉及用户能看到的变化（页面、组件、样式、交互）→ 有 UI 变化，必须走浏览器端验收。
验收未通过时，进入修复循环：分析原因 → 修复代码 → 重跑 TDD 测试（防回归）→ 重跑验收。最多重试 3 次，仍然失败就向用户报告具体原因和已尝试的修复。
整个阶段的执行过程使用 Task 工具（TaskCreate / TaskUpdate）进行规划和追踪。
确认当前阶段的所有依赖任务已完成（任务规划中已勾选）。如果有未完成的依赖，告诉用户需要先完成哪些任务。
为当前阶段的每个任务创建 Task，然后开始执行。不需要逐个任务都先停下来问"是否继续"——直接做，遇到需要决策的点再问。
按任务顺序逐个执行。每个任务都必须走完上面的两个阶段（TDD 循环 + 验收测试）才能标记完成。不要 TDD 通过就直接进入收尾——先判断这个任务需要什么类型的验收，做完验收再继续。
过程中自然地向用户展示关键信息：
展示的目的是让用户跟上进度，不是做格式化汇报。根据任务的复杂度调整展示的详细程度——简单任务简要说明即可，复杂任务多展示一些关键决策。
[x]，确认所有 Task 状态已更新assets/stage-completion-report-template.md，生成阶段完成报告，保存到 docs/开发记录/{功能名}_阶段{N}_完成报告.md