القائمة
功能编码实现执行器（TDD 驱动）。读取任务规划，按 RED-GREEN-REFACTOR 循环执行开发任务。当用户说'完成XX功能的第N阶段'、'开始写代码'、'实现XX阶段'、'开发XX的数据层'等意图时触发。也支持增量变更任务，如'完成XX的变更任务 CR-XXX'。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
功能开发阶段使用。明确具体功能的业务需求和验收标准，产出功能需求文档 (FRD)。
功能任务规划。将技术方案拆解为细粒度、可执行的开发任务清单 (Task List)。
设计功能的技术实现方案。在功能需求明确后使用，产出包含API、数据库、核心逻辑的详细技术方案 (TDD)。
生成项目导航文档。基于项目核心文档生成 AGENT.md，作为 AI 助手的项目导航。
记录和查阅 AI 错题本。当发生错误或需要预警时使用，建立自我进化的反馈闭环，避免重复错误。
交互式 BUG 排查专家。通过持续提问和引导，逐步缩小问题范围，辅助用户定位 BUG 根源。
استنادا إلى تصنيف SOC المهني
| 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