---
description: 评估开发计划 — 将方案交给 Momus 审查，通过后进入实施
---

# 开发方案审查

⛔ 本阶段仅调整方案文本，**禁止编写代码**。

**第一步：提取方案保存到文件**

将当前对话中的开发方案整理为结构化 Markdown，写入 `.omo/plans/<简短描述>.md`（目录不存在则创建）。字段须与 `/dev-new` 的方案输出完全对齐，确保 Momus 基于完整信息审查。

文档结构（功能开发按子任务分组；Bug 修复视为单子任务，根因分析并入实现思路）：

```markdown
# 开发方案：<标题>

## 场景
功能开发 / Bug 修复

## 任务目标

## 子任务

### <子任务标题 或 "根因修复">
- **涉及文件**（新增/修改/删除）：
- **实现思路**（做什么及原因；Bug 修复在此写根因分析）：
- **验收标准**（可观测，如"API 返回 200 且数据格式正确"）：
- **代码检查命令**（`tsc --noEmit`、`eslint` 等，从 `AGENTS.md` 提取）：
- **测试脚本**（项目有测试框架则必填）：

## 依赖关系
## 风险点

## 整体验证步骤
项目级验证命令（`yarn test`、`yarn tsc` 等）+ 端到端验证
```

> 多个子任务时，每个 `###` 分组重复上述五个字段；字段无内容写"无"，不留空。

**第二步：调用 Momus 审查**

使用 `task(subagent_type="momus")`，prompt **必须只含文件路径**（Momus 设计要求，内联内容会被拒绝）：

```
.omo/plans/xxx.md
```

> Momus 会自行读取文件，从架构合理性、子任务粒度、代码规范、完整性、边界情况、可维护性、简洁性等角度审查。

**第三步：处理审查结果**

- **OKAY** → 引导用户 `/dev-fire`
- **调整建议** → 整理反馈给用户 → 修改方案文件 → 用 `session_id` 再次提交 Momus → 循环直到 OKAY

每轮往返对用户透明，展示 Momus 反馈和你的调整。Momus 意见作参考，最终方案用户确认。