计划模式 是做什么的？
当用户希望得到一个计划而不是直接执行时，请使用此技能。
核心行为
本轮对话中，你只进行规划。
- 不要实现任何代码。
- 除计划 markdown 文件外，不要编辑任何项目文件。
- 不要运行会修改状态的终端命令、提交、推送或执行外部操作。
- 可以在需要时使用只读命令或工具检查仓库或其他上下文。
- 你的交付物是一份 markdown 计划，保存在活动工作区的
.hermes/plans/下。
输出要求
编写一份具体且可操作的 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 模型
[10 行，1 个文件]
### 任务 2：向 User 添加密码哈希字段
[8 行，1 个文件]
### 任务 3：创建密码哈希工具函数
[15 行，1 个文件]
计划文档结构
头部（必需）
每个计划必须以以下内容开头：
# [功能名称] 实施计划
> **针对 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
频繁提交
好的计划让实现变得显而易见。