--- name: "mission-control" description: "任务追踪与方案确认系统（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（任务需求） ```markdown # 任务需求 ## 基本信息 - **任务编号**：T-YYYYMMDD-NNN - **创建时间**：YYYY-MM-DD HH:mm - **状态**：待执行 ## Boss原始需求 （原文记录） ## 任务目标 （清晰定义要达成什么） ## 任务范围 （明确边界：做什么 / 不做什么） ## 数据与资源 - 输入数据：（文件路径、描述） - 工具/Skill：（需要用到的skill） - 其他资源： ## 验收标准 （如何判断任务完成） ``` ### t-plan.md（任务方案 — 单 Agent 版） ```markdown # 任务方案 ## 基本信息 - **任务编号**：T-YYYYMMDD-NNN - **状态**：待确认 / 已确认 ## 一、求是分析（3次迭代过程） ### 迭代1：主要矛盾识别 - **求是审视内容**：（调用 qiushi skill 后的分析） - **识别的主要矛盾**： - **初步方案方向**： ### 迭代2：逻辑链深化 - **求是审视内容**： - **补充的信息**： - **修正的内容**： ### 迭代3：风险与完善 - **求是审视内容**： - **确认的风险点**： - **最终方案**： ## 二、执行方案 ### 步骤清单 1. 步骤1：... → 预期结果：... 2. 步骤2：... → 预期结果：... 3. ... ### 风险预案 - 风险1：... → 对策：... ## 三、Boss确认 - **确认时间**： - **确认意见**： - **是否通过**：✅/❌ ``` ### t-log.md（执行日志） ```markdown # 执行日志 ## Step 1：xxxxx - **时间**：YYYY-MM-DD HH:mm - **状态**：✅完成 / ❌出错 / ⏳进行中 - **执行动作**：（做了什么） - **产出文件**： - **错误说明**：（如有） ## Step 2：xxxxx - **时间**：YYYY-MM-DD HH:mm - **状态**：✅完成 / ❌出错 / ⏳进行中 - **执行动作**：（做了什么） - **产出文件**： - **错误说明**：（如有） ``` ### t-report.md（任务完成报告） ```markdown # 任务完成报告 ## 基本信息 - **任务编号**：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 | ### 重构三原则 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：交付 ``` ### 字段填充对照表 | 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 知道需要补充 |