用途：在单次会话中完成一个范围较小任务的计划与实现，是 create-plan → implement-plan 流水线的轻量版本，保留书面计划、验证和代码审查的纪律，但减少流程仪式。
范围闸门（硬性规则）：仅限小任务，最多约 3 个阶段、单一子系统。在评估、计划和实现中途都要检查；一旦出现更多阶段或第二个子系统就停止，说明扩大原因，并移交给 /desplega:create-plan，把已存在的 yolo 计划作为输入上下文传入。继续硬做会让一次性任务变成难以审查的巨型 diff，升级移交是成功而非失败。
第 1 步评估仪式：读提示词动态决定。目标明确、做法显然、无明显取舍则直接开始，不提问题。不明确则做一次轻量询问：单次打包 AskUserQuestion 调用，最多 2–3 个决策，每个问题附带推荐答案（遵循 desplega:ask-user 约定）。事实与决策分离：事实自行查证，可通过按 desplega:delegate-work 路由的后台子智能体完成，只把真正的决策交给用户。仅一轮；若答案显示问题复杂，则触发范围闸门。
第 2 步 Yolo 计划：实现前创建 thoughts/<username|shared>/plans-yolo/YYYY-MM-DD-<slug>.md（已知用户名则用其名，否则 shared），并在实现过程中持续更新，它是运行日志而非事前产物。含 frontmatter（date、topic、status：in-progress | done | escalated）以及 Goal、Decisions、Todo、Verification 段落。Verification 中放可运行命令（类型检查、测试、lint 等）。完成待办即勾选，做决策即追加。会话中断时该文件即为交接物。若被触及系统存在设计文档（thoughts/*/design-docs/<system-slug>.md），需阅读并遵守其 Invariants 与 Boundaries，冲突时向用户报告而非绕开编码。
第 3 步实现：按待办清单推进，派生子智能体按 desplega:delegate-work 路由，代码达到 desplega:engineering-standards 标准，并同步维护计划文件。
第 4 步验证：运行 Verification 段中的每条命令，全部通过；修复并重跑，绝不在检查失败时报完成。
第 5 步快速代码审查：对 diff 运行 desplega:code-reviewing。规格来源为 yolo 计划加上被触及系统的设计文档，两者都传给 Spec 智能体；即使 yolo 计划未重述，设计文档的 Invariants 仍具约束力。修复 Critical 与 Important 发现，Minor 记入计划文件。
第 6 步提交：用简洁说明变更的提交信息提交（仅当用户未表示自行处理提交时）。随后报告：交付内容、验证结果、审查结果、yolo 计划路径。
限制：仅适用于小范围任务；超出即移交；不替代完整计划流程。资料未提供收费、价格、平台等信息。