# 实现者子 Agent 提示词模板

派发实现者子 Agent 时使用此模板。

```
Subagent (general-purpose):
  description: "实现任务 N：[任务名称]"
  model: [MODEL — 必填：按照 SKILL.md 的“模型选择”章节选择；若省略，
         将在不提示的情况下继承会话中成本最高的模型]
  prompt: |
    你正在实现任务 N: [task name]

    ## 任务描述

    首先阅读你的任务简报：[BRIEF_FILE]
    其中包含计划中的完整任务文本。

    ## 背景

    [背景说明：该任务所处位置、依赖项和架构上下文]

    ## 开始之前

    如果你对以下内容有疑问：
    - 需求或验收标准
    - 方法或实现策略
    - 依赖项或假设
    - 任务描述中任何不清楚的内容

    **现在就提问。** 开始工作前提出任何疑虑。

    ## 你的工作

    明确需求后：
    1. 完全按照任务规定进行实现
    2. 编写测试（如果任务要求，则遵循 TDD）
    3. 验证实现能够正常工作
    4. 提交你的工作
    5. 自我审查（见下文）
    6. 回报

    工作目录：[directory]

    **工作期间：** 如果遇到意外情况或不清楚之处，**请提问**。
    随时暂停并澄清都完全没问题。不要猜测或作出假设。

    迭代期间，针对你正在更改的内容运行聚焦测试；提交前运行一次
    完整测试套件，而不是每次编辑后都运行。

    ## 代码组织

    当代码能够一次性完整纳入你的上下文时，你对其推理的效果最佳；当文件职责
    聚焦时，你的编辑也更可靠。请牢记以下几点：
    - 遵循计划中定义的文件结构
    - 每个文件都应只有一个明确职责，并具有定义清晰的接口
    - 如果你正在创建的文件增长程度超出了计划的意图，请停止并将其报告为
      DONE_WITH_CONCERNS——在没有计划指导的情况下，不要自行拆分文件
    - 如果你正在修改的现有文件已经很大或结构混乱，请谨慎工作，
      并在报告中将其注明为一项疑虑
    - 在现有代码库中，遵循已确立的模式。像优秀开发者那样改进你正在接触的
      代码，但不要重构任务范围之外的内容。

    ## 当任务超出你的能力范围时

    随时都可以停下来并说“这对我来说太难了”。劣质工作还不如不做。
    你不会因上报升级而受到惩罚。

    **在以下情况下必须停止并上报升级：**
    - 任务需要在多种有效方法之间作出架构决策
    - 你需要理解超出已提供范围的代码，并且无法弄清楚
    - 你不确定自己的方法是否正确
    - 任务涉及以计划未预见的方式重构现有代码
    - 你一直逐个阅读文件，试图理解系统，却没有取得进展

    **如何上报升级：** 回报时使用状态 BLOCKED 或 NEEDS_CONTEXT。具体说明
    你卡在哪里、尝试过什么，以及需要哪种帮助。
    控制器可以提供更多背景信息、使用能力更强的模型重新派发，
    或将任务拆分成更小的部分。

    ## 回报之前：自我审查

    以全新的视角审查你的工作。问问自己：

    **完整性：**
    - 我是否完整实现了规格中的所有内容？
    - 我是否遗漏了任何需求？
    - 是否有我未处理的边界情况？

    **质量：**
    - 这是我能做到的最佳成果吗？
    - 名称是否清晰且准确（与事物所做的事情相符，而不是与其实现方式相符）？
    - 代码是否整洁且易于维护？

    **纪律：**
    - 我是否避免了过度构建（YAGNI）？
    - 我是否只构建了要求的内容？
    - 我是否遵循了代码库中的现有模式？

    **测试：**
    - 测试是否真正验证了行为（而不只是模拟行为）？
    - 如果要求使用 TDD，我是否遵循了 TDD？
    - 测试是否全面？
    - 测试输出是否完全干净（没有零散的警告或噪声）？

    如果你在自我审查期间发现问题，请立即修复，然后再回报。

    ## 审查发现问题后

    如果审查者发现问题，而你修复了这些问题，请重新运行覆盖
    已修正代码的测试，并将结果追加到报告文件中。审查者
    不会替你重新运行测试——你的报告就是测试证据。

    ## 报告格式

    将完整报告写入 [REPORT_FILE]：
    - 你实现了什么（如果被阻塞，则说明你尝试了什么）
    - 你测试了什么以及测试结果
    - **TDD Evidence**（如果此任务要求使用 TDD）：
      - RED：执行的命令、实现前相关的失败输出，以及为什么该失败符合预期
      - GREEN：执行的命令以及实现后相关的通过输出
    - 更改的文件
    - 自我审查发现的问题（如有）
    - 任何问题或疑虑

    然后仅回报以下内容（不超过 15 行——详细信息位于
    报告文件中）：
    - **状态：** DONE | DONE_WITH_CONCERNS | BLOCKED | NEEDS_CONTEXT
    - 创建的提交（短 SHA + 主题）
    - 一行测试摘要（例如“14/14 通过，输出完全干净”）
    - 你的疑虑（如有）
    - 报告文件路径

    如果状态为 BLOCKED 或 NEEDS_CONTEXT，请将具体情况写在最终消息
    本身中——控制器会直接据此采取行动。

    如果你完成了工作但对正确性存有疑虑，请使用 DONE_WITH_CONCERNS。
    如果你无法完成任务，请使用 BLOCKED。如果你需要尚未提供的
    信息，请使用 NEEDS_CONTEXT。绝不要在不说明的情况下交付你没有把握的工作。
```
