Mission Control — 任务控制中心

Mission-Control 技能（v3.0 单 Agent 执行版） 核心理念 方案确认制：所有涉及代码/文件操作的任务，必须先与 Boss 确认方案后才执行。 求是迭代制：方案阶段必须经过 3 次"求是-分析-修正"迭代循环。 单 Agent 执行制：全程由 Moss（主 Agent）执行，无 SubAgent / 专家 agent 中间层。

一、自动判断标准（Agent 自行扫描） 收到任务 ↓ 扫描任务内容： ├── 有 .py/.sh/.js/.md/.yaml/.json 等文件操作？ → 需要 ├── 有代码/脚本生成或修改？ → 需要 ├── 有 SubAgent 委派？ → 需要 ├── 有研究性联网检索？ → 需要 ├── 有 terminal/命令行操作？ → 需要 └── 只有纯对话/简单问答（<1分钟）？ → 不需要 ↓ 模糊情况 → 主动向 Boss 确认："这个任务是否需要走方案确认流程？"

二、完整工作流程（5阶段，阶段2内含3次迭代） ┌─────────────────────────────────────────────────────────────────┐ │ Stage 1: 任务接收与判断 │ │ - 扫描任务内容，按客观标准判断是否需要走 mission-control │ │ - 不需要 → 直接执行，回复末尾注明"本次任务无需方案确认" │ │ - 需要 → 继续 │ └─────────────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────────────┐ │ Stage 2: 任务定义 + 方案生成（含3次迭代） │ │ - 生成 t-requirement.md │ │ - 迭代1：初稿方案 → 调用 qiushi skill 求是审视主要矛盾 │ │ - 迭代2：深化补充 → 调用 qiushi skill 求是审视逻辑链 │ │ - 迭代3：修正完善 → 调用 qiushi skill 求是审视风险点 │ │ - 生成 t-plan.md（含3次迭代过程记录） │ └─────────────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────────────┐ │ Stage 3: Boss 确认 │ │ - 展示完整方案（含3次迭代结论） │ │ - 等待 Boss 回复"可以" │ │ - Boss 不确认 → 记录意见 → 回到 Stage 2 重新迭代 │ └─────────────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────────────┐ │ Stage 4: 执行 │ │ - Moss 按 t-plan.md 执行 │ │ - 每步记录到 t-log.md（动作 + 产出 + 状态） │ │ - 遇阻 → 立即上报，不绕路 │ └─────────────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────────────┐ │ Stage 5: 报告 │ │ - 生成 t-report.md │ │ - 向 Boss 交付结论和产出路径 │ └─────────────────────────────────────────────────────────────────┐

三、任务目录结构 /home/huang/.hermes/mission_control/{YYYY-MM-DD}/ ├── T-YYYYMMDD-001/ │ ├── t-requirement.md # 任务需求 │ ├── t-plan.md # 任务方案（含3次迭代过程） │ ├── t-log.md # 执行日志（每步状态+结果） │ └── t-report.md # 任务完成报告 ├── T-YYYYMMDD-002/ │ └── ...

四、项目输入卡（Project Intake） 什么时候使用

九、禁止行为 Moss 读取逻辑 任务目录存在 project-intake.md？ ├── 是 → Moss 读取所有字段，补充到 t-requirement.md，直接进入 Stage 2 └── 否 → Moss 正常生成 t-requirement.md（Stage 2 内补充信息）

五、文件模板 project-intake.md（项目输入卡 — Boss 填写） 模板路径：templates/project-intake.md 每次任务开始前，Boss 将此文件放入任务目录并填写。Moss 读取优先。 t-requirement.md（任务需求） # 任务需求

基本信息

• 任务编号：T-YYYYMMDD-NNN
• 创建时间：YYYY-MM-DD HH:mm
• 状态：待执行

Boss原始需求 （原文记录）

任务目标 （清晰定义要达成什么）

任务范围 （明确边界：做什么 / 不做什么）

数据与资源

• 输入数据：（文件路径、描述）
• 工具/Skill：（需要用到的skill）
• 其他资源：

验收标准 （如何判断任务完成）

t-plan.md（任务方案 — 单 Agent 版） # 任务方案

基本信息

• 任务编号：T-YYYYMMDD-NNN
• 状态：待确认 / 已确认

一、求是分析（3次迭代过程）

迭代1：主要矛盾识别

• 求是审视内容：（调用 qiushi skill 后的分析）
• 识别的主要矛盾：
• 初步方案方向：

迭代2：逻辑链深化

• 求是审视内容：
• 补充的信息：
• 修正的内容：

迭代3：风险与完善

• 求是审视内容：
• 确认的风险点：
• 最终方案：

二、执行方案

步骤清单

• 步骤1：... → 预期结果：...
• 步骤2：... → 预期结果：...
• ...

风险预案

• 风险1：... → 对策：...

三、Boss确认

• 确认时间：
• 确认意见：
• 是否通过：/

t-log.md（执行日志） # 执行日志

Step 1：xxxxx

• 时间：YYYY-MM-DD HH:mm
• 状态：完成 / 出错 / 进行中
• 执行动作：（做了什么）
• 产出文件：
• 错误说明：（如有）

Step 2：xxxxx

• 时间：YYYY-MM-DD HH:mm
• 状态：完成 / 出错 / 进行中
• 执行动作：（做了什么）
• 产出文件：
• 错误说明：（如有）

t-report.md（任务完成报告） # 任务完成报告

基本信息

• 任务编号：T-YYYYMMDD-NNN
• 完成时间：YYYY-MM-DD HH:mm
• 执行时长：X小时X分
• 状态：完成 / 中断 / 失败

任务摘要 （简要说明完成了什么）

执行步骤回顾 （简要列出执行的步骤）

中断/错误说明 （如有）

任务产出

• 产出文件路径：
• 产出内容摘要：

六、任务编号规则 格式：T-YYYYMMDD-NNN T：Task 固定前缀 YYYYMMDD：任务接受日期 NNN：当日序号（从 001 开始，按自然日期重置）

七、进度汇报格式 Moss 向 Boss 汇报的格式： 【HH:mm】任务 T-YYYYMMDD-NNN 进度更新

• 当前阶段：Stage X/5
• 当前步骤：Step N/M
• 状态：完成 / 进行中 / 出错
• 说明：（简要描述）

八、禁止行为 未经客观判断就默认"不需要走 mission-control" 未生成 t-requirement.md 就跳过方案阶段 阶段2 未完成3次迭代就进入 Boss 确认 未获 Boss 确认就让 Moss 执行 执行过程不记录到 t-log.md 任务中断/出错不写明原因就停止 不生成 t-report.md 就结束任务

九、与 qiushi Skill 的关系 阶段 使用 Skill 阶段2（方案生成） qiushi（求是）— 每次迭代必须调用 阶段5（报告） qiushi（批评与