PAD Mode (Plan → Act → Deliver)
Overview
PAD Mode transforms ambiguous requests into structured, trackable execution plans. Five phases: Plan → Discuss → Approve → Act → Deliver.
⚠️ Enforcement
Violating the rules below is considered an execution failure. Treat the 🛑 STOP points as hard blockers — not suggestions.
- 1. Skip Phase 3 Approve and jump to execution → Halt immediately. Undo any actions taken. Return to Phase 3, update status to
🔵 Confirmed, and wait for explicit user approval. - Do deep research during Plan phase → Discard all research results. The Plan phase is for structure only — no tool calls, no web searches, no file reads beyond the template.
- Start executing without asking execution mode → Pause all execution. Ask the user Foreground/Background, wait for reply, then resume.
- Complete tasks without updating plan file status → Immediately update the plan doc. Each task must reflect its actual state (
🔄 In Progress → ✅ Done / ❌ Failed). - Deliver without button/text confirmation → Do NOT auto-archive. Send the completion summary with buttons (or text fallback) and wait for user response.
Phase 1: Plan
When triggered, analyze the user's request and create a plan document.
If the trigger is bare /pad with no additional context, do NOT guess or infer from conversation history. Instead, ask the user directly:
What do you want to plan? Give me the task and I'll break it down.
Wait for the user to provide a clear request before proceeding.
- 1. Create the plan file: INLINECODE5
- Use the template at
assets/plan-template.md
- Slug = 2-4 word summary of the task, hyphenated, lowercase
- 2. Fill in:
- Title, status (
🟡 Discussing), timestamp
- Original requirement (user's words verbatim)
- Understanding (your interpretation — confirm this is correct)
- Initial task breakdown with tentative deliverables
- 3. Do NOT do extensive research first. Present a concise summary with the main tasks. Deep research happens after approval.
- If there are 2-3 clear choices for any design decision, frame it as multiple choice (A/B/C) so the user can answer quickly.
- Ask up to 4 clarifying questions max. Don't overwhelm.
Present the plan summary to the user and wait for feedback.
Phase 2: Discuss
Iterate on the plan based on user feedback:
- 1. Update the plan document with each round of changes
- Add entries to the change log section
- Refine task breakdown and deliverables
- Confirm scope boundaries — what's IN and what's OUT
- Each task MUST have a concrete, verifiable deliverable
- ❌ "optimize the code" (vague)
- ✅ "Refactor auth module: extract token validation to
auth/validator.js, update login route to use new module, tests passing" (specific)
Continue until the user says the plan is good / looks good / approved.
Phase 3: Approve
When the user confirms the plan:
- 1. Update status to INLINECODE9
- Lock the plan — no more scope changes without explicit user request
- Summarize what will be executed: task list + expected deliverables
- Move to Phase 4
🛑 STOP. Do NOT proceed to Phase 4 until ALL of the following are true:
- - [ ] Plan status is
🔵 Confirmed (updated in the plan file) - [ ] User has explicitly approved via text ("确认"/"approved"/"go"/"looks good") OR clicked an approval button
- [ ] Scope boundaries are locked in the plan doc
If the user hasn't responded yet, DO NOT execute. Wait. Do not infer approval from silence or from earlier messages in the conversation.
Phase 4: Act
Execute tasks with live tracking:
- 1. Update status to INLINECODE11
🛑 STOP. Before ANY tool calls or task execution, ask the user about execution mode:
This plan has N tasks and will take some time. Would you like to run it in the foreground (real-time updates) or background (notify when done)?
DO NOT start any tool calls, web searches, file writes, or other actions until the user replies with their preferred mode. Use buttons (Foreground / Background) if the channel supports them; otherwise wait for text reply.
- 2.
> This plan has N tasks and will take some time. Would you like to run it in the foreground (real-time updates) or background (notify when done)?
- If channel supports buttons: use
Foreground /
Background buttons
- Otherwise: send as text, wait for user's text reply
- 3. Foreground mode: Work through tasks directly, notifying after each one.
- Background mode: Spawn a sub-agent with the plan context. The sub-agent:
- Reads the plan document
- Executes tasks sequentially
- Sends progress updates to the main session after each task via
sessions_send
- Main agent forwards updates to the user
- 5. Work through tasks in order of dependencies (independent tasks may run in parallel via sub-agents)
- For each task:
- Update task status to
🔄 In Progress in the plan doc
- Execute the work
- On success: mark
✅ Done, fill in notes with what was done
- On failure: mark
❌ Failed, document the issue, propose a fix or skip
-
Notify the user immediately after each task completes
- 7. If a task reveals that the plan needs adjustment:
- Pause execution
- Update the plan doc and change log
- Ask the user before continuing
Phase 5: Deliver
After all tasks are marked complete, do NOT automatically close the plan. Instead:
- 1. Update status to INLINECODE20
- Send a completion summary to the user:
> 📋 Plan "XXX" — all tasks completed. Deliverables:
> - T1.1 ✅ xxx
> - T2.1 ✅ xxx
> ...
>
> Does everything look good? Any changes needed?
🛑 STOP. Do NOT auto-archive. Send confirmation and WAIT for user response:
- - If channel supports buttons: send
✅ Archive / 🔧 Changes Needed buttons, wait for click - If text only: send summary, wait for user reply matching "archive"/"done"/"looks good" or "changes"/"modify"/"needs work"
- If no response: do nothing. Do NOT assume approval from silence.
- 4. If user clicks Archive (or confirms via text):
- Update status to
✅ Completed
- Add archive timestamp to the plan doc
- Send final confirmation
- 5. If user clicks Changes Needed (or requests changes via text):
- Go back to Phase 2 (Discuss) to refine
- Add new tasks if needed
- Resume Phase 4 execution
Parallel Execution
When tasks are independent (no shared dependencies), use sub-agents for parallel execution:
CODEBLOCK0
Always update the plan doc from the main agent, not from sub-agents.
Plan Document Location
All plans live in: INLINECODE24
Create the directory if it doesn't exist. Use read to check an existing plan before creating a new one for the same topic.
Resuming a Plan
If the user references an existing plan (e.g., "continue the last plan"), search for it in plans/, read the doc, identify the last completed task, and resume from there.
PAD 模式（计划 → 讨论 → 批准 → 执行 → 交付）
概述
PAD 模式将模糊的请求转化为结构化、可追踪的执行计划。共五个阶段：计划 → 讨论 → 批准 → 执行 → 交付。
⚠️ 强制执行
违反以下规则将被视为执行失败。请将 🛑 停止点视为硬性阻断——而非建议。
- 1. 跳过阶段3（批准）直接进入执行 → 立即停止。撤销所有已执行的操作。返回阶段3，将状态更新为 🔵 已确认，并等待用户明确批准。
- 在计划阶段进行深度调研 → 丢弃所有调研结果。计划阶段仅用于构建结构——不得调用工具、搜索网络、或读取模板以外的文件。
- 未询问执行模式即开始执行 → 暂停所有执行。询问用户前台/后台模式，等待回复，然后继续。
- 完成任务但未更新计划文件状态 → 立即更新计划文档。每个任务必须反映其实际状态（🔄 进行中 → ✅ 已完成 / ❌ 失败）。
- 未经按钮/文字确认即交付 → 不要自动归档。发送包含按钮（或文字回退）的完成摘要，并等待用户响应。
阶段1：计划
触发时，分析用户请求并创建计划文档。
如果触发条件仅为裸 /pad 且无额外上下文，不要猜测或从对话历史推断。而是直接询问用户：
你想计划什么？告诉我任务，我来分解。
等待用户提供明确请求后再继续。
- 1. 创建计划文件：plans/YYYY-MM-DD-<短标识>.md
- 使用 assets/plan-template.md 中的模板
- 标识 = 任务的2-4字摘要，小写，用连字符连接
- 2. 填写：
- 标题、状态（🟡 讨论中）、时间戳
- 原始需求（用户原话）
- 理解（你的解读——确认正确）
- 初步任务分解及暂定交付物
- 3. 不要先做大量调研。 呈现包含主要任务的简洁摘要。深度调研在批准后进行。
- 如果任何设计决策有2-3个明确选项，将其设为多选题（A/B/C），以便用户快速回答。
- 最多提出4个澄清问题。不要过多。
向用户呈现计划摘要并等待反馈。
阶段2：讨论
根据用户反馈迭代计划：
- 1. 每次修改后更新计划文档
- 在变更日志部分添加条目
- 细化任务分解和交付物
- 确认范围边界——哪些包含在内，哪些排除在外
- 每个任务必须有一个具体、可验证的交付物
- ❌ 优化代码（模糊）
- ✅ 重构认证模块：将令牌验证提取到 auth/validator.js，更新登录路由以使用新模块，测试通过（具体）
持续进行，直到用户表示计划良好/看起来不错/已批准。
阶段3：批准
当用户确认计划时：
- 1. 将状态更新为 🔵 已确认
- 锁定计划——未经用户明确请求，不得更改范围
- 总结将要执行的内容：任务列表 + 预期交付物
- 进入阶段4
🛑 停止。 在以下所有条件满足之前，不得进入阶段4：
- - [ ] 计划状态为 🔵 已确认（已在计划文件中更新）
- [ ] 用户已通过文字（确认/approved/go/looks good）或点击批准按钮明确批准
- [ ] 范围边界已在计划文档中锁定
如果用户尚未回复，不要执行。等待。不要从沉默或对话中的早期消息推断批准。
阶段4：执行
实时追踪执行任务：
- 1. 将状态更新为 🟢 执行中
🛑 停止。 在任何工具调用或任务执行之前，询问用户执行模式：
此计划有N个任务，需要一些时间。您希望在前台（实时更新）还是后台（完成后通知）运行？
在用户回复其首选模式之前，不要开始任何工具调用、网络搜索、文件写入或其他操作。如果渠道支持，使用按钮（前台 / 后台）；否则等待文字回复。
- 2.
> 此计划有N个任务，需要一些时间。您希望在前台（实时更新）还是后台（完成后通知）运行？
- 如果渠道支持按钮：使用 前台 / 后台 按钮
- 否则：以文字形式发送，等待用户文字回复
- 3. 前台模式：直接处理任务，每完成一个通知一次。
- 后台模式：生成一个带有计划上下文的子代理。子代理：
- 读取计划文档
- 按顺序执行任务
- 通过 sessions_send 在每项任务后向主会话发送进度更新
- 主代理将更新转发给用户
- 5. 按依赖顺序处理任务（独立任务可通过子代理并行运行）
- 对于每个任务：
- 在计划文档中将任务状态更新为 🔄 进行中
- 执行工作
- 成功时：标记为 ✅ 已完成，在备注中填写完成内容
- 失败时：标记为 ❌ 失败，记录问题，提出修复方案或跳过
-
每项任务完成后立即通知用户
- 7. 如果某个任务显示计划需要调整：
- 暂停执行
- 更新计划文档和变更日志
- 在继续之前询问用户
阶段5：交付
在所有任务标记为完成后，不要自动关闭计划。而是：
- 1. 将状态更新为 ⏳ 待审核
- 向用户发送完成摘要：
> 📋 计划XXX——所有任务已完成。交付物：
> - T1.1 ✅ xxx
> - T2.1 ✅ xxx
> ...
>
> 一切看起来都好吗？需要任何修改吗？
🛑 停止。 不要自动归档。发送确认并等待用户响应：
- - 如果渠道支持按钮：发送 ✅ 归档 / 🔧 需要修改 按钮，等待点击
- 如果仅文字：发送摘要，等待用户回复匹配archive/done/looks good或changes/modify/needs work
- 如果没有响应：不做任何操作。不要从沉默中推断批准。
- 4. 如果用户点击归档（或通过文字确认）：
- 将状态更新为 ✅ 已完成
- 在计划文档中添加归档时间戳
- 发送最终确认
- 5. 如果用户点击需要修改（或通过文字请求修改）：
- 返回阶段2（讨论）进行细化
- 如有需要添加新任务
- 恢复阶段4执行
并行执行
当任务相互独立（无共享依赖）时，使用子代理进行并行执行：
任务A（独立）── 子代理1 ──┐
任务B（独立）── 子代理2 ──┤── 合并结果 ── 更新计划文档
任务C（依赖A）── 等待A ──┘
始终从主代理更新计划文档，而非子代理。
计划文档位置
所有计划位于：~/.openclaw/workspace/plans/
如果目录不存在则创建。在为新计划创建前，先使用 read 检查同一主题的现有计划。
恢复计划
如果用户引用现有计划（例如，继续上一个计划），在 plans/ 中搜索，读取文档，识别最后一个已完成的任务，然后从那里继续。
