mission-brief

mission-brief

此技能的功能

mission-brief 会接收功能描述，将其整理为一份 任务简报（目标、约束、成功标准），生成带有提示词的有序 步骤列表，并执行这些步骤——每个步骤都会分派给一个子 Agent，其提示词会触发已安装的 SDD 技能。无需 YAML 工作流文件、无需为每个框架单独配置文件，也无需检测配置文件。步骤提示词使用规范的 SDD 术语（specify、plan、implement、converge），适用于任何 SDD 技能集——由模型调用的技能会自动触发，基于命令的框架会按文件名匹配；如果两者都不存在，子 Agent 就会直接执行。

适用场景

• “端到端构建此功能”：你提供描述，mission-brief 会编排并运行流水线：specify → plan → implement ↔ converge。
• 你希望有一个带熔断器和审计跟踪的 converge 循环。
• 你希望跨会话恢复中断的任务 （mission-brief --resume）。
• 你希望跨会话无人值守运行（mission-brief --async）。

不适用场景

• 单个小改动——直接完成即可；任务会带来额外开销。
• 你已经有规范和任务，只想实现其中一项——直接调用 implement 技能。

任务简报模板

生成步骤前，会将描述整理为：

## Mission Brief

**Goal**: <what to build — one sentence>
**Constraints**: <tech stack, limitations, dependencies, requirements>
**Non-Goals**: <what is explicitly out of scope — e.g., "no database storage, local memory cache only">
**Success Criteria**:
- <measurable outcome 1>
- <measurable outcome 2>
- <measurable outcome 3>

简报有两个用途：

1. 提前明确完成标准——为 converge 步骤的独立性检查提供依据（检查器会根据这些标准进行验证）。
2. 将任务上下文传递到每个步骤的委派提示词中，使每个子 Agent 无需重新阅读之前的步骤，也能获得完整上下文。

输入

$ARGUMENTS

上方 $ARGUMENTS 区块中的文本就是你的任务描述——立即据此继续。不要询问用户想构建什么。

先从参数中解析标志，再将剩余文本视为 spec_description：

• --async / --sync——执行模式标志（覆盖配置默认值）。
• --resume——明确从状态中恢复。
• 其他所有内容——任务描述（spec_description）。

如果没有描述且未指定 --resume：根据功能名称尽力推导描述（Git 分支，或最近一次状态中的功能）。如果指定了 --resume 但没有状态：报告“No interrupted mission found”并停止。

功能名称推导：将描述转换为小写、以连字符连接的 slug，并移除停用词（a、an、the、new、to、with、for、add、fix、update）。示例： “add a new react dashboard with telemetry” → react-dashboard-telemetry。 如果 .adlc/workflow/runs/ 中已存在同名目录，则依次追加 -2、-3 等。

流程

所有路径都相对于当前工作目录（Agent 执行任务的项目根目录）。除非明确说明，否则不要在子目录中查找配置或状态。

阶段 0 — 配置

1. mkdir -p .adlc/workflow（以及 .adlc/workflow/tmp、.adlc/workflow/runs）。
2. 如果 .adlc/workflow/workflow-config.yml 不存在，则从技能的 config-template.yml 复制（该文件与此 SKILL.md 位于同一目录）。
3. 读取 .adlc/workflow/workflow-config.yml。如果字段缺失，则使用以下默认值：

workflow:
  execution: sync            # sync | async
  supervision: gated         # gated | hybrid | autonomous
  max_iterations: 5
  max_spec_corrections: 2
  circuit_breaker: 3
  quality_threshold: null    # optional 0-100, blocks DONE below threshold
  # models: { strong: "...", fast: "..." }   # optional

解析最终执行模式：--async/--sync 标志 > 配置中的 execution > sync。如果指定了 --async 且 supervision 为 gated/hybrid：发出警告（“async forces ungated; running autonomous”），并在本次运行中将其视为 autonomous。

阶段 1 — 恢复检查（仅限 --resume）

<FEATURE_DIR> = .adlc/workflow/runs/<feature>/（在阶段 4 中定义，但 此处会检查任务是否已完成）。

如果传入了 --resume：

1. 读取 .adlc/workflow/.mission-state.json。
2. 如果 <FEATURE_DIR>/mission-log.json 存在 → 报告“功能 X 的任务已完成。审计记录：…” → 停止。
3. 如果状态文件存在且 completed_steps 非空 → 恢复：从 state.steps 加载步骤 列表，跳转到阶段 5（执行），从第一个未完成的步骤开始。
4. 如果没有状态文件 → 报告“未找到中断的任务。运行 mission-brief \"<desc>\" 以启动任务。” → 停止。

如果未传入 --resume，且存在 completed_steps 非空的状态文件：询问——“功能 X 存在中断的任务（已完成 N/M 个步骤）。运行 mission-brief --resume 继续，或确认从头开始 （这会丢弃状态）。”不要默默覆盖。

阶段 2 — 任务简报

将 spec_description 整理到任务简报模板中：

1. 目标：用一句话提炼核心目标。
2. 约束：根据描述和项目上下文推断技术栈、限制和要求（检查 package.json、go.mod、 语言文件和现有规范）。如果不明确，保留占位符并标记为需要用户填写。
3. 非目标：推断 1–2 项合理的边界或功能，并明确排除，以保持实现聚焦且简单。如果无法 推断，则标记为“无”。
4. 成功标准：推导出 2–5 项可衡量的结果。如果描述含糊，则根据功能类型生成合理的默认值，并标记为“建议 — 如有需要可编辑”。

向用户展示简报：

• 同步 + 有门控/混合模式 → 展示简报，并在继续前询问用户确认或修改。
• 同步 + 自主模式 → 如果成功标准为“TBD”或为空，停止： “自主模式需要可检查的完成标准。”否则无需确认，直接继续。
• --async → 无需确认，直接继续（自主、无门控）。

将简报存储在 .mission-state.json.brief 中。

阶段 3 — 路由分类与可选阶段

分类为 spec / change / quick：

路由	适用情形	步骤
spec	新功能、全新项目、“添加/创建/构建”	头脑风暴？ → 规范定义 → 澄清？ → 规划 → 任务 → 分析？ → 实施↺收敛 → 追踪？
change	修改、已有项目、“修复/更新/重构”	规范定义 → 实施↺收敛
quick	小任务、琐碎任务、“只需/快速/简单”	仅实施（以完整简报作为输入）

仅针对 spec 路由，评估可选阶段的候选项（自动处理， 记录在状态中；若监督模式为有门控/混合模式，用户需在运行时门控处逐项批准）：

阶段	候选条件
brainstorm	提示词涉及架构或含糊不清（“设计”“方法”“比较”“我们该怎么做”，存在多个可行方案）
clarify	成功标准含糊 / 缺少约束
analyze	路由为 spec（对称）
trace	提示词提及持久化、审计、可追溯性、合规性

阶段 4 — 命令发现与生成步骤列表

4a. 命令/技能发现

阅读 references/agent-integrations.md（与此 SKILL.md 一起）。对于表中列出的每个 Agent 目录，检查它是否存在于项目根目录中。 将发现的目录记录在状态中：

"discovered": {
  "skills_dirs": [".claude/skills"],
  "commands_dirs": [{"dir": ".opencode/commands", "ext": ".md"}]
}

此发现过程仅在生成时执行一次，并在 --resume 时复用。完整算法请参阅参考文件。

4a.1 本地技能清单（通用技能路由）

发现技能目录（4a）后，汇总所有 skills_dirs 中已安装技能的清单。对于每个包含 SKILL.md 的 <skills_dir>/<skill-name>/ 子目录：

1. 读取 SKILL.md 的 frontmatter（--- 分隔符之间的 YAML）。
2. 提取 name 和 description（如果缺少 frontmatter 或无法解析，则回退到目录名）。
3. 在 discovered.local_skills 中记录一条：

"discovered": {
  "skills_dirs": [".claude/skills"],
  "commands_dirs": [{"dir": ".opencode/commands", "ext": ".md"}],
  "local_skills": [
    {"name": "tdd", "path": ".claude/skills/tdd", "description": "Test-driven development with red-green-refactor..."},
    {"name": "grill-me", "path": ".claude/skills/grill-me", "description": "Get relentlessly interviewed about a plan..."},
    {"name": "code-review", "path": ".claude/skills/code-review", "description": "Two-axis review of the diff..."}
  ]
}

此清单与供应商无关——它涵盖来自任何来源的技能（mattpocock/skills、addy osmani/agent-skills、superpowers、自定义团队技能，或任何符合 Agent-Skills 标准的仓库）。清单会在调度时（Phase 5）传递给每个子 Agent，以便大模型判断当前步骤适用哪项技能——不使用硬编码的阶段到技能映射表。

4b. 生成步骤列表

根据路由和可选阶段候选项生成有序步骤列表。每个步骤都是一个结构化对象，存储在 state.steps 中：

{
  "id": "specify",
  "phase": "specify",
  "tier": "strong",
  "prompt": "Write a feature specification for the goal below. ...",
  "status": "pending"
}

步骤列表是可供审阅的产物——在门控/混合模式下，执行前先向用户展示：

## Mission Steps

1. [specify]  (strong) Write a feature specification for: react dashboard with telemetry
2. [plan]     (strong) Break down the specification into an implementation plan
3. [tasks]    (fast)   Generate the detailed task list from the plan
4. [implement](strong) Implement the next pending task from the plan
5. [converge] (fast)   Review the implementation against the spec and success criteria
   ↺ loop 4–5 until converged (max 5 iterations, circuit breaker 3)

对于 quick 路由：单个 implement 步骤，输入为完整简报。

对于 change 路由：specify + implement↺converge 循环（不含可选阶段）。

对于 spec 路由：完整流水线，并将可选阶段作为门控候选项插入。

步骤提示词的构建

每个步骤的 prompt 由三部分组成：

1. 阶段指令——每个阶段采用规范的 SDD 术语：

阶段	层级	指令
brainstorm	强	“探索实现下述目标的方案及其权衡。考虑多个可行解决方案，并给出推荐设计。”
specify	强	“为下述目标编写功能规格说明。包含需求、约束和可衡量的成功标准。”
clarify	快	“审查规格说明并与团队沟通，解决任何含糊的成功标准或缺失的约束。”
plan	强	“将规格说明拆解为实施计划，包含有序且可验证的任务。”
tasks	快	“根据计划生成详细任务列表——每项任务都必须包含确切的文件路径和验证步骤。”
analyze	快	“在实施前对计划进行对抗性审查。质疑每一项非平凡决策。”
implement	强	“实施计划中的下一个待办任务。遵循测试驱动实践。”
converge	快	“根据规格说明和成功标准审查实施结果。独立验证——你负责检查，而非实施。”
trace	快	“将此功能开发过程中作出的决策记录为 ADR 或交接文档。”

2. 任务简报上下文——将 Phase 2 中的目标、约束和成功标准附加到每个提示词中。

3. 委派封装——执行器在调度时添加（Phase 5）。封装中包含 discovered.local_skills，以便子 Agent 决定当前步骤是否需要调用某项已安装技能。

Phase 5 — 执行步骤列表

创建一个与 state.steps 对应的 todowrite 列表。将 completed_steps 中的步骤标记为已完成。每完成一个步骤后更新列表。

步骤调度

对于每个 status: pending 的步骤：

1. 输出：

   ## Workflow Step: <id>
   
   **Phase**: <phase> (<tier>)
   

2. 如果该步骤是 converge 步骤（阶段为 converge），则在委派提示词前添加独立性提示：

   你正在评估另一位 Agent 完成的工作。不要假设实现正确——请独立对照规范进行验证。尝试从最主要的来源确认每项要求是否不成立（运行测试、检查文件、搜索引用）。你是检查者，不是实现者。

   重要：确认未引入任何列在 Non-Goals 下的功能或实现。如果构建了任何范围外的内容，请将 CONTINUE 作为结果信号，并在摘要中列出违反非目标的情况。

3. 使用以下提示词原样委派给子 Agent：

   You are being invoked by the `mission-brief` executor.
   
   ## Task
   
   <step.prompt>
   
   ## Mission Brief
   
   **Goal**: <goal>
   **Constraints**: <constraints>
   **Non-Goals**: <non-goals>
   **Success Criteria**: <success criteria>
   
   ## Available Skills in This Workspace
   
   <LOCAL_SKILLS_LIST>
   
   The list above shows skills installed in this workspace from any source
   (ADLC team skills, mattpocock/skills, addy osmani/agent-skills,
   superpowers, or custom). Review each skill's name and description.
   If one matches the goal of your current task, **invoke it** (via the
   skill tool or by reading its SKILL.md inline) and use it to execute
   this step. If multiple skills could apply, pick the best fit. If none
   apply, proceed with direct execution.
   
   ## How to execute
   
   Try these in order:
   
   1. **Skill match**: If an installed skill's description matches this task,
      invoke it (via skill tool or by reading its SKILL.md inline).
   
   2. **Command match**: If a command file for this phase exists, read and
      execute it. <DISCOVERED_PATHS>
      Look for a file whose name matches the phase (e.g., `*specify*`,
      `*implement*`, `*converge*`).
   
   3. **Direct execution**: If neither exists, execute the task directly using
      your available tools.
   
   **Confidence Self-Estimation**:
   Evaluate your confidence (HIGH/MEDIUM/LOW) in this implementation or task. If
   you are missing critical context, have low confidence, or find the requirements
   ambiguous, report `Confidence score: LOW` (or `MEDIUM`) and list the specific
   unresolved details in your return summary.
   
   If you found a skill or command, note its name in your summary.
   
   Do NOT follow handoffs to other skills or commands — return your results to
   the executor when you finish.
   
   Return:
   1. A 1-2 sentence summary (mention which skill/command you used, if any).
   2. Files changed (if any).
   3. Test results (if any).
   4. Outcome signal: DONE | CONTINUE | SPEC_CORRECTION_NEEDED.
      - DONE: work is complete and verified.
      - CONTINUE: more work is needed (tasks remain, review found issues).
      - SPEC_CORRECTION_NEEDED: verification found spec-level issues that
        require re-running specify. Include a `spec_corrections` field with
        the specific issues.
   5. (optional) Quality score: "X/Y (Z%)" — if a verification skill ran
      quality gates, report the score.
   6. (optional) Gate summary: "N passed, M failed" — if quality gates were
      checked, list which passed and which failed.
   7. (optional) Confidence score: HIGH | MEDIUM | LOW. Self-estimated confidence in the correctness of your work.
   8. (optional) Unresolved details: <brief description of what is uncertain or missing context>.
   

   <LOCAL_SKILLS_LIST> 将替换为根据 discovered.local_skills 构建的格式化列表。每个条目都显示技能名称、路径和描述：

   - **tdd** (`.claude/skills/tdd`) — Test-driven development with red-green-refactor...
   - **grill-me** (`.claude/skills/grill-me`) — Get relentlessly interviewed about a plan...
   - **code-review** (`.claude/skills/code-review`) — Two-axis review of the diff...
   

   如果 discovered.local_skills 为空，则 <LOCAL_SKILLS_LIST> 将替换为：“此工作区中未检测到自定义技能。”

   <DISCOVERED_PATHS> 将替换为从 state.discovered 中发现的目录：

   • 如果 commands_dirs 非空：“检查以下位置： .opencode/commands/ (.md)、.claude/commands/ (.md)、...”
   • 如果 skills_dirs 非空：“已安装的技能位于： .claude/skills/、...”
   • 如果两者都为空：“检查你的运行环境中的 commands/skills 目录，或参阅 references/agent-integrations.md 了解已知位置。”

4. 等待子 Agent 返回。

5. 立即更新 .mission-state.json——在执行下一步之前。将子 Agent 返回的值存储在 step_results.<id> 下：

   • 将 1–2 句话的摘要存储为 step_results.<id>.output
   • 将置信度评分存储为 step_results.<id>.confidence（如果未提供，则默认为 HIGH）
   • 将未解决的细节存储为 step_results.<id>.unresolved
   • 将 <id> 附加到 completed_steps
   • 将 state.steps[N].status 标记为 completed
   • 写入状态文件。丢弃子 Agent 的完整响应。

   置信度升级门槛：如果解析出的置信度评分为 LOW，且当前监督模式为 autonomous 或 hybrid：

   • 自动将监督模式升级为 gated，以便验证此步骤。
   • 暂停执行，并向用户展示子 Agent 的发现和未解决的细节：

     “⚠️ 子 Agent 已完成步骤 ，但因以下原因报告了 LOW 置信度：[未解决的细节]。监督模式已自动升级为 gated。请检查更改并确认是否继续？（是/否）”

   • 等待用户明确确认后再继续步骤列表。如果用户确认，则继续；如果用户拒绝，则暂停任务。

6. 如果该步骤是 implement，则将以下内容附加到 <FEATURE_DIR>/iterations.md：

   ## Iteration <N> - <date>
   - Files changed: <list>
   - Summary: <1-2 sentences>
   - Tests: <pass/fail>
   

7. 如果 converge 子 Agent 返回的结果信号为 SPEC_CORRECTION_NEEDED → 停止并返回 spec_correction_needed 至 Phase 6。不要继续。

门控步骤（仅限 sync、gated/hybrid）

当监督模式为 gated 或 hybrid 时，执行器会内联插入门控（不是单独的步骤，而是执行器行为）：

• specify 之后（gated + hybrid）：询问“规范已创建。是否在实现前进行检查？” → 继续 / 修改（重新运行 specify）/ 中止。
• 每次 implement 之后（仅 gated）：询问“实现已完成。是否运行收敛检查？” → 继续 / 修改（重新运行 implement）/ 中止。
• 最终签署（gated + hybrid）：converge 之后，询问“收敛检查已通过。是否检查并批准完成？” → 批准 / 拒绝（暂停）。

对于 --async 或 autonomous：不设门控，也不进行最终签署。

将门控选项存储在 step_results.<id>_gate.output.choice 中。

收敛循环（实现 ↔ 收敛）

实现和收敛步骤构成一个 do-while 循环：

1. 执行 implement 步骤（第 N 次迭代）。
2. 执行 converge 步骤。
3. 检查收敛子 Agent 的结果信号：
   • DONE → 退出循环，进入阶段 6。
   • CONTINUE → 增加 consecutive_tasks_appended，检查断路器（见下文）；如果未超过 max_iterations，则从第 1 步重复。

使用带迭代前缀的 ID进行跟踪：loop_0_implement、loop_1_implement 等。步骤的 id 保持不变；只有 completed_steps 条目会添加前缀。

断路器。 在状态中跟踪 consecutive_tasks_appended。每次收敛步骤后，如果信号为 CONTINUE，则递增；如果为 DONE，则重置为 0。如果计数达到 circuit_breaker（默认值为 3）→ 停止循环并返回 failed：「断路器：连续 N 次迭代未能收敛。需要人工审核——循环未能收敛。」此计数器会在恢复时保留。

分数回退跟踪。 在状态中跟踪 consecutive_score_regressions（初始化为 0）。每次收敛步骤返回质量分数后：

• 如果当前分数 < 上一次分数 → 增加 consecutive_score_regressions
• 如果当前分数 >= 上一次分数 → 重置为 0
• 如果 consecutive_score_regressions 达到 circuit_breaker（默认值为 3）→ 停止：「断路器：连续 N 次分数回退。质量呈下降趋势——需要人工审核。」此计数器会在恢复时保留。

质量阈值强制执行。 如果设置了 quality_threshold（非 null），且收敛子 Agent 返回 DONE，但质量分数低于阈值 → 改为视作 CONTINUE（工作尚未达到要求的质量标准）。

上下文预算感知

每个步骤结束后，都要总结并丢弃子 Agent 的完整响应。步骤达到 5 个或更多后，主动建议：「会话内容越来越多——你可以继续，也可以开始新的聊天并运行 mission-brief --resume。」如果响应变得重复，建议开始新的聊天。

阶段 6 — 完成路由

所有步骤完成后（或信号要求返回时），根据该信号采取相应操作：

spec_correction_needed（由收敛子 Agent 返回为 SPEC_CORRECTION_NEEDED）：

1. 读取状态。如果 spec_corrections >= max_spec_corrections → 停止：「规范反复未通过评估（N/M）。需要人工审核规范。」保留状态以供检查。
2. 否则：增加 spec_corrections，将所有步骤状态重置为 pending（重新运行整个流水线），重新执行（阶段 5），然后重复阶段 6。

converged 或 tasks_appended（循环结束）：

• sync + gated/hybrid → 需要人工签核：显示 iterations.md 中的审计记录；询问「收敛已通过。审核并批准完成？」→ 批准后继续；拒绝则暂停（「任务已暂停以供审核。解决问题后运行 mission-brief --resume。」）。
• sync + autonomous，或 --async → 跳过签核。
• 将 .mission-state.json 移至 .adlc/workflow/runs/<feature>/mission-log.json（审计记录——不会删除）。
• 报告：

  ## Mission Complete
  - Feature: <feature>
  - Route: <route>
  - Execution: <sync|async>
  - Supervision: <mode>
  - Signal: <converged|tasks_appended>
  - Spec corrections: <n>/<max>
  - Audit trail: .adlc/workflow/runs/<feature>/mission-log.json
  

failed：报告错误；保留状态以供检查。用户可以重新运行 mission-brief --resume。

安全机制

• 监督模式：gated（默认）会在执行过程中设置关卡；autonomous 可自由运行，但要求完成标准可核查（拒绝“待定”）；hybrid 仅在规格审查和最终签核时设置关卡。
• 置信度升级：如果子 Agent 在执行期间报告 Confidence score: LOW，系统将覆盖 autonomous/hybrid 模式，强制设置交互式人工关卡。
• 非目标约束：任务简报包含范围外的边界。收敛步骤充当独立评估者，明确检查并拒绝任何违反非目标的情况。
• 异步运行会强制取消关卡：--async 与 gated/hybrid 配置组合时 → 发出警告并改为 autonomous。
• 内循环上限：max_iterations（默认值为 5）。
• 断路器：连续 N 次迭代未能收敛后停止（默认值为 3）——防止无限循环；恢复运行时仍会保留此状态。
• 外循环上限：max_spec_corrections（默认值为 2），由收敛子 Agent 发出的 SPEC_CORRECTION_NEEDED 信号触发。
• 分数回退检测：如果质量分数连续 N 次迭代呈下降趋势（circuit_breaker），即使子 Agent 报告 CONTINUE，也会停止循环。
• 质量阈值：如果已配置，低于阈值时会阻止 DONE——并将其视为 CONTINUE。
• 收敛独立性提示：收敛子 Agent 会独立验证。
• 审计跟踪：iterations.md + mission-log.json——不会删除。
• 状态持久化：.mission-state.json 可在上下文压缩或重启后保留。
• 明确恢复：使用 mission-brief --resume；全新运行 mission-brief 时，会先询问是否覆盖中断状态。

常见自我开脱

自我开脱	实际情况
“这是个小任务，我就跳过收敛循环吧”	小任务使用 quick 路径（仅实现）。如果归类为规格/变更任务，循环就是重点。
“我稍后再运行关卡”	设置关卡是为了尽早发现偏差。跳过规格关卡意味着基于未经审查的规格进行实现。
“异步运行也可以保留关卡，我会回答问题”	异步运行期间无人监看。异步运行会强制取消关卡；如果需要关卡，请使用同步运行。
“状态文件只是累赘，我要删掉它”	它是恢复和审计机制。删除它会丢失检查点、恢复能力和审计跟踪。
“我只要重新运行 mission-brief 就能恢复”	不加 --resume 时会收到询问，而且可能覆盖状态。请使用 mission-brief --resume。
“我不需要任务简报，直接开始编码就行”	简报会强制明确成功标准。没有这些标准，收敛步骤就没有可供核查的依据。

危险信号

• 执行每个步骤后，都没有写入 .mission-state.json。
• 在 --async 运行中插入关卡。
• 在自主模式下，成功标准为“待定”时跳过任务简报。
• 将子 Agent 的完整响应读入工作记忆，而不是先总结再丢弃。
• 未经询问就覆盖中断状态（全新运行 mission-brief，但未使用 --resume）。
• 完成后删除 .mission-state.json，而不是将其移至 mission-log.json。
• 将特定 Agent 的命令目录写死，而不是使用从 state.discovered 中发现的路径。
• 忽略收敛子 Agent 发出的 SPEC_CORRECTION_NEEDED 信号，仍继续执行并视为 DONE。
• 忽略子 Agent 的 LOW 置信度报告，未升级至人工处理便继续执行。
• 放任违反非目标的情况通过收敛步骤，且未报告 CONTINUE。

验证

• .adlc/workflow/workflow-config.yml 存在（如果不存在，则从模板复制）。
• .mission-state.json 包含：brief（目标／约束／成功标准）、steps（包含阶段／层级／提示词／状态的有序列表）、discovered（skills_dirs + commands_dirs + local_skills）、completed_steps（只增不减）。
• 每个 implement 步骤都会在 iterations.md 中新增一条记录。
• 完成后，.adlc/workflow/runs/<feature>/ 下会存在 mission-log.json。
• 没有状态信息时使用 --resume，会报告 "No interrupted mission found" 并停止。
• 存在 mission-log.json 时使用 --resume，会报告 "already completed"。
• 委派提示词包含发现的路径（而不是硬编码列表）。
• 委派提示词包含根据 discovered.local_skills 构建的 <LOCAL_SKILLS_LIST>（列表为空时 → "No custom skills detected"）。
• 仅在同步的门控／混合运行中出现门控步骤，在 --async 中绝不出现。
• converge 发出的 SPEC_CORRECTION_NEEDED 信号会被路由到 Phase 6（不会被视为 DONE 或 CONTINUE）。
• 如果设置了 quality_threshold，低于阈值的 converge 评分会被视为 CONTINUE。
• 子 Agent 报告 Confidence score: LOW 时，会自动将监督审核切换为 gated。
• brief 中会成功填充 Non-Goals 部分，并将其传递到每个子 Agent 的提示词上下文中。

配置

• .adlc/workflow/workflow-config.yml — 执行、监督、预算、质量阈值和可选的模型映射表。参见 config-template.yml。
• references/agent-integrations.md — 完整的 Agent→目录映射表。新增 Agent 或约定发生变化时，请更新此表。执行器会在生成时读取该文件，以发现命令和 skills。

示例会话

# Start a sync gated mission
mission-brief "add a new react dashboard with telemetry"

# Run unattended across sessions
mission-brief --async "refactor the auth module to use JWT"

# Resume after a session restart or a paused gate
mission-brief --resume