计划模式
当用户想要一个计划而非执行时，使用此技能。
核心行为
本轮对话中，你仅负责计划。
- 不实现代码。
- 不编辑除计划markdown文件外的项目文件。
- 不运行变更性终端命令、不提交、不推送，也不执行任何外部操作。
- 你可以使用只读命令/工具检查仓库或其他上下文。
- 你的交付物是一个保存在活动工作区
.hermes/plans/下的Markdown计划。
输出要求
编写具体且可操作的Markdown计划。
在相关时包含：
- 目标
- 当前上下文/假设
- 建议方法
- 分步计划
- 可能更改的文件
- 测试/验证
- 风险、权衡和未解决的问题
如果任务与代码相关，请包含确切的文件路径、可能的测试目标和验证步骤。
保存位置
使用 write_file 将计划保存在以下位置：
.hermes/plans/YYYY-MM-DD_HHMMSS-<slug>.md
将其视为相对于活动工作目录/后端工作区的路径。Hermes文件工具具有后端感知能力，因此使用此相对路径可将计划保留在工作区中，适用于本地、docker、ssh、modal和daytona后端。
如果运行时提供了特定目标路径，请使用该确切路径。
否则，在 .hermes/plans/ 下自行创建一个合理的带时间戳的文件名。
交互风格
- 如果请求足够清晰，直接编写计划。
- 如果没有明确指令伴随
/plan，则从当前对话上下文中推断任务。 - 如果确实不明确，则提出简短的澄清问题，而不是猜测。
- 保存计划后，简要回复你计划的内容和保存的路径。
编写高质量计划
技能其余部分是关于如何编写好的实施计划的技巧——即上述Markdown文件的内容。
概述
编写全面的实施计划，假设实施者对代码库上下文一无所知且品味可疑。记录他们需要的所有信息：要操作哪些文件、完整代码、测试命令、要检查的文档、如何验证。给他们小块任务。DRY。YAGNI。TDD。频繁提交。
假设实施者是一位熟练的开发人员，但对工具集或问题领域几乎一无所知。假设他们不太了解好的测试设计。
核心原则： 好的计划使实施变得显而易见。如果有人需要猜测，则计划不完整。
何时需要完整的实施计划
始终在以下情况之前使用：
- 实施多步骤功能
- 分解复杂需求
- 通过子代理驱动开发委派给子代理
在以下情况不要跳过：
- 功能看似简单（假设会导致错误）
- 你计划自己实施（未来的你需要指导）
- 单独工作（文档很重要）
小块任务粒度
每个任务 = 2-5分钟的专注工作。
每一步都是一个操作：
- "编写失败的测试" — 一步
- "运行它以确保失败" — 一步
- "编写最简代码以使测试通过" — 一步
- "运行测试并确保通过" — 一步
- "提交" — 一步
太大：
### 任务1：构建认证系统
[5个文件中的50行代码]
合适大小：
### 任务1：创建带email字段的User模型
[1个文件中的10行]
### 任务2：向User添加密码哈希字段
[1个文件中的8行]
### 任务3：创建密码哈希工具函数
[1个文件中的15行]
计划文档结构
头部（必需）
每个计划必须以下列内容开头：
# [功能名称] 实施计划
> **针对Hermes：** 使用子代理驱动开发技能逐任务实施此计划。
**目标：** [一句话描述构建的内容]
**架构：** [2-3句话描述方法]
**技术栈：** [关键技术/库]
---
任务结构
每个任务遵循以下格式：
### 任务N：[描述性名称]
**目标：** 此任务完成什么（一句话）
**文件：**
- 创建：`exact/path/to/new_file.py`
- 修改：`exact/path/to/existing.py:45-67`（如果已知行号）
- 测试：`tests/path/to/test_file.py`
**步骤1：编写失败的测试**
```python
def test_specific_behavior():
result = function(input)
assert result == expected
```
**步骤2：运行测试以验证失败**
运行：`pytest tests/path/test.py::test_specific_behavior -v`
预期：FAIL — "function not defined"
**步骤3：编写最简实现**
```python
def function(input):
return expected
```
**步骤4：运行测试以验证通过**
运行：`pytest tests/path/test.py::test_specific_behavior -v`
预期：PASS
**步骤5：提交**
```bash
git add tests/path/test.py src/path/file.py
git commit -m "feat: add specific feature"
```
编写过程
步骤1：理解需求
阅读并理解：
- 功能需求
- 设计文档或用户描述
- 验收标准
- 约束条件
步骤2：探索代码库
使用Hermes工具理解项目：
# 理解项目结构
search_files("*.py", target="files", path="src/")
# 查看类似功能
search_files("similar_pattern", path="src/", file_glob="*.py")
# 检查现有测试
search_files("*.py", target="files", path="tests/")
# 读取关键文件
read_file("src/app.py")
步骤3：设计方法
决定：
- 架构模式
- 文件组织
- 需要的依赖
- 测试策略
步骤4：编写任务
按顺序创建任务：
- 设置/基础设施
- 核心功能（每个采用TDD）
- 边界情况
- 集成
- 清理/文档
步骤5：添加完整细节
对每个任务，包含：
- 确切的文件路径（不是"配置文件"而是
src/config/settings.py） - 完整的代码示例（不是"添加验证"而是实际代码）
- 确切的命令及预期输出
- 验证步骤证明任务有效
步骤6：审查计划
检查：
- 任务是顺序且逻辑的
- 每个任务是小块的（2-5分钟）
- 文件路径是确切的
- 代码示例是完整的（可复制粘贴）
- 命令是确切的，带有预期输出
- 没有缺失的上下文
- 应用了DRY、YAGNI、TDD原则
原则
DRY（不要重复自己）
坏： 在3个地方复制粘贴验证 好： 提取验证函数，到处使用
YAGNI（你不需要它）
坏： 为未来需求添加"灵活性" 好： 仅实现当前所需
# 坏 — YAGNI违规
class User:
def __init__(self, name, email):
self.name = name
self.email = email
self.preferences = {} # 现在不需要！
self.metadata = {} # 现在不需要！
# 好 — YAGNI
class User:
def __init__(self, name, email):
self.name = name
self.email = email
TDD（测试驱动开发）
每个产生代码的任务都应包含完整的TDD周期：
- 编写失败的测试
- 运行以验证失败
- 编写最简代码
- 运行以验证通过
有关详细信息，请参见 test-driven-development 技能。
频繁提交
每项任务后提交：
git add [files]
git commit -m "type: description"
常见错误
模糊的任务
坏： "添加认证" 好： "创建包含email和password_hash字段的User模型"
不完整的代码
坏： "步骤1：添加验证函数" 好： "步骤1：添加验证函数" 后跟完整的函数代码
缺少验证
坏： "步骤3：测试它工作"
好： "步骤3：运行 pytest tests/test_auth.py -v，预期：3通过"
缺少文件路径
坏： "创建模型文件"
好： "创建：src/models/user.py"
执行交接
保存计划后，提供执行方法：
"计划已完成并保存。准备使用子代理驱动开发执行——我将为每个任务派遣一个全新的子代理，进行两阶段评审（规范合规性然后代码质量）。要继续吗？"
执行时，使用 subagent-driven-development 技能：
- 每个任务使用包含完整上下文的
delegate_task全新子代理 - 每个任务后进行规范合规性评审
- 规范通过后进行代码质量评审
- 仅当两个评审都批准后才继续
记住
小块任务（每个2-5分钟）
确切的文件路径
完整的代码（可复制粘贴）
确切的命令及预期输出
验证步骤
DRY、YAGNI、TDD
频繁提交
好的计划使实施变得显而易见。