Install
openclaw skills install @huangjk1103/3c12646Mission Control
任务追踪与方案确认系统（Moss单Agent执行版）。当收到涉及代码编写、文件操作、SubAgent任务委派、联网检索的任务时，必须调用此Skill进行方案分析和Boss确认。触发场景：(1)收到新任务需执行，(2)任务确认，(3)进度更新，(4)任务完成。核心功能：(1)自动判断是否需要走流程，(2)求是分析（3次迭代），(3)方案生成，(4)Boss方案确认，(5)执行追踪，(6)报告生成。
Mission-Control Skill（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. 步骤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 的关系
| 阶段 | 使用 Skill |
|---|---|
| 阶段2（方案生成） | qiushi（求是）— 每次迭代必须调用 |
| 阶段5（报告） | qiushi（批评与自我批评）— 复盘 |
| 其他阶段 | mission-control 本身 |
十、静态规范重构为任务卡（Conversion Pattern）
当 Boss 说"按 mission-control 格式把它重构为任务卡"时，适用本节。
触发判断
| Boss 措辞 | 是否触发重构流程 |
|---|---|
| "把它重构为任务卡" | ✅ 触发 |
| "按 mission-control 格式" | ✅ 触发 |
| "生成 project-intake.md" | ✅ 触发 |
| "方案确认"（新任务） | ❌ 走标准 Stage 1-5 |
重构三原则
- 保留为原则：原文件的科学内容/数据/约束全部保留到新文件，不删内容
- 补充为原则：缺失的 mission-control 字段（任务编号/验收标准/禁止事项/产出要求/Moss填写区）必须补全
- 原文件保留：重构任务不改原文件，除非 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：交付
字段填充对照表
| mission-control 必填字段 | 填充来源 |
|---|---|
| 任务编号 | 自动生成 T-YYYYMMDD-NNN |
| 任务目标 | 原文件 Section 1.3 科学目标 |
| 验收标准 | 参照 project-intake.md 模板 + 行业惯例制定（可基于科学目标推导） |
| 禁止事项 | 原文件"禁止行为清单"（Section 8） |
| 上下文背景 | 原文件"项目背景"（Section 1）+ 历史积累 |
| 数据与资源 | 原文件"数据描述"（Section 2）+ "环境与工具"（Section 3） |
| 产出要求 | 原文件"输出文件要求"（Section 6） |
| 优先级 | 高（博士毕业后转录组数据挖掘，关系到发表） |
| 期望完成时间 | 留空，待 Boss 补充 |
| Moss填写区 | 新增 Section |
| 版本变更记录 | 新增，说明重构前后版本差异 |
重构任务的风险预案
| 风险 | 对策 |
|---|---|
| 原文件内容字段缺失（无验收标准等） | 基于科学目标+行业惯例推导，Boss 确认时补充 |
| Boss 未告知期望完成时间 | 留空，明确标注"待定" |
| 重构后原文件是否删除 | 默认保留，除非 Boss 明确要求覆盖 |
禁止行为（新增）
- ❌ 重构时删除原文件的科学内容/数据约束
- ❌ 未获 Boss 确认就执行文件覆盖
- ❌ 重构时将"静态规范格式"误当作"动态任务卡格式"使用（两者定位不同）
📎 重构实例（含完整字段填充对照）：
references/2026-05-19-static-spec-conversion.md
十一、常见陷阱（Pitfalls）
| 陷阱 | 错误做法 | 正确做法 |
|---|---|---|
| 静态规范当作任务卡 | PROJECT_SPEC.md 就是静态规范，直接用作任务卡会导致无验收标准/无执行追踪 | 先重构为 project-intake.md 再使用 |
| 重构时删内容"觉得不重要" | 跳过原文件某些 Section | 以保留为原则，补充为原则，Boss 说删才删 |
| 期望完成时间留空不标注 | 留空但不说 | 明确标注"（待定）"，让 Boss 知道需要补充 |
Related skills
- Downloads
- Security audit
- Review
- Last updated
- 2mo ago
- Current version
- v1.0.0
- License
- MIT-0