Mission-Control Skill（v3.0 单 Agent 执行版）

核心理念

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

一、自动判断标准（Agent 自行扫描）

收到任务
    ↓
扫描任务内容：
    ├── 有 .py/.sh/.js/.md/.yaml/.json 等文件操作？    → 需要 ✅
    ├── 有代码/脚本生成或修改？                         → 需要 ✅
    ├── 有 SubAgent 委派？                               → 需要 ✅
    ├── 有研究性联网检索？                               → 需要 ✅
    ├── 有 terminal/命令行操作？                         → 需要 ✅
    └── 只有纯对话/简单问答（\x3C1分钟）？                   → 不需要 ❌
    ↓
模糊情况 → 主动向 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. 步骤1：... → 预期结果：...
2. 步骤2：... → 预期结果：...
3. ...

### 风险预案
- 风险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 的关系

十、静态规范重构为任务卡（Conversion Pattern）

当 Boss 说"按 mission-control 格式把它重构为任务卡"时，适用本节。

触发判断

重构三原则

1. 保留为原则：原文件的科学内容/数据/约束全部保留到新文件，不删内容
2. 补充为原则：缺失的 mission-control 字段（任务编号/验收标准/禁止事项/产出要求/Moss填写区）必须补全
3. 原文件保留：重构任务不改原文件，除非 Boss 明确要求覆盖

重构流程（压缩版，4步）

Stage 1：任务接收与判断
  ↓ Boss说"重构为任务卡" → 需要 ✅
Stage 2：求是分析（1次迭代足够，纯文本转换无复杂矛盾）
  → 主要矛盾：格式目的不同（静态规范 vs 动态任务卡）
  → 矛盾性质：非对抗性 → 方案：以保留为原则，补充缺失字段
Stage 3：展示方案 → Boss确认"可以"
Stage 4：执行
  1. 读取原文件完整内容
  2. 生成 project-intake.md（新文件）
  3. 生成 t-plan.md（含迭代过程）
  4. 生成 t-log.md（空壳）
  5. 生成 t-report.md
Stage 5：交付

字段填充对照表

重构任务的风险预案

禁止行为（新增）

• ❌ 重构时删除原文件的科学内容/数据约束
• ❌ 未获 Boss 确认就执行文件覆盖
• ❌ 重构时将"静态规范格式"误当作"动态任务卡格式"使用（两者定位不同）

📎 重构实例（含完整字段填充对照）：references/2026-05-19-static-spec-conversion.md

十一、常见陷阱（Pitfalls）