mission-specify

mission-specify

Requires: factory-mission 技能在 .agents/skills/factory-mission/references/executor.md（安装路径）中的共享执行器契约；使用 adlc-cli skills add tikalk/adlc-team-skills --skill factory-mission 安装。

在本地会话中 — 由你回答门禁问题

当未设置 ADLC_RUN_ID 时，当前会话中有人参与，且没有其他人会回答门禁问题。负责将门禁问题转发到 Slack 的 agentic-container 运行时仅存在于 runner pod 中。

1. 运行暂停时，轮到你处理，而不是任务结束了。 当 adlc-cli workflow run 或 resume 退出时，如果运行因门禁而暂停（adcli-cli workflow state show <run_id> 中显示 run_paused、status: paused），请向参与者询问门禁问题及其选项。然后运行 adlc-cli workflow resume <run_id> --input <verdict_input>=<answer> 并继续执行。绝不要在运行暂停且无人被询问的情况下结束本轮。
2. 每个批准 MR 的门禁之后，都必须有一个负责创建 MR 的步骤。 如果 gate 的消息承诺会创建 MR/PR，则后面必须跟一个 publish 步骤：对每个涉及变更的仓库运行 run-branch.sh 和 open-mr.sh，并写入 mr_url（多个 MR 时写入 mr_urls）。之后才能执行回写步骤，这样完成评论才能链接到真实的 MR。若门禁之后没有步骤来落实其答案，则计划存在缺陷；开始运行前先修复计划。
3. 结束本轮前，运行必须处于 completed、failed 或已中止状态；或者暂停在一个已向参与者询问过的门禁处。

此技能的作用

mission-specify 负责 mission SDD 系列中的 specify 阶段：它将任务的 brief.md 转换为 spec.md，其中每条验收标准都可以判定为是或否，并记录为此做出的决定。它遵循共享执行器契约（.agents/skills/factory-mission/references/executor.md）：specify 步骤读取 brief.md 并生成草稿，clarify 步骤读取 spec.md 并生成决策，reads_from 由编排器解析。本技能止步于规格说明；规划由 mission-plan 负责，构建由 mission-implement 负责，验证与收敛由 mission-verify 负责，而 REVIEW 和 SHIP 分别由 factory-review 和 factory-deploy 负责。

默认流程

1. 阅读 brief.md；将其中的目标、约束、非目标和成功标准视为输入，而非必须保留的原文。
2. 将每项成功标准改写为二元、可测量的结果 — 每项都要能通过一个问题判定是或否，并且依据是退出状态的命令、存在的制品，或能显示变更的差异。
3. 编写 spec.md：结果、约束、非目标、验收标准和范围之外的内容。每项验收标准都必须能追溯到它所改写的成功标准。
4. 明确指出任何无法测量的标准以及相互冲突的约束；不要用文字掩盖其中任何一项。
5. 在 clarify 阶段解决每个已指出的问题 — 在带门禁的运行中询问参与者；在自主模式下，则记录决定及其依据。最终的决定即为 clarify 输出。
6. 绝不选择技术方案，也不规划文件；这些属于后续阶段。

步骤契约

步骤	phase_type	output_type	reads_from	artifact
specify	generate	draft	brief.md	spec.md
clarify	clarify	decision	spec.md	—

门禁

此阶段没有门禁。

边界

• 不使用 worktree：隔离由编排器负责；本技能在交给它的目录树中工作。
• 不使用租约：绝不获取、续期或释放运行租约。
• 不写入跟踪器：不发表评论、不添加标签、不转换状态，也不创建 MR/PR。
• 不合并或批准：本技能绝不批准、合并或发布。
• 返回处理：无法测量的标准或相互冲突的约束会留在 clarify 阶段，直到问题解决；之后若证明规格说明有误，应通过负责该阶段的 clarify 阶段进行修正，绝不能在下游阶段悄悄修改验收标准。