PAD Mode

Turn messy requests into structured plans. PAD Mode (Plan → Act → Deliver) gives your AI agent project management superpowers — automatic task breakdown, liv...

Security Scan

The skill’s requirements, files, and runtime instructions are internally consistent with a planning/execution orchestration role (it’s an instruction-only PAD planner that creates plan documents and can spawn sub-agents for execution).

Purpose & Capability

Name/description (Plan→Act→Deliver) match the SKILL.md and included plan template. Requested artifacts (plan files, templates, status updates, sub-agents) are appropriate for a planning/execution orchestration skill and no unrelated credentials, binaries, or config paths are requested.

Instruction Scope

Instructions are focused on creating/updating plan documents, getting approvals, and then executing tasks (foreground or by spawning sub-agents). This is coherent, but the SKILL.md assumes platform capabilities (spawning sub-agents, sessions_send, writing 'plans/... .md' files and making tool calls during Act) without specifying low-level undo mechanics (e.g., how to 'undo any actions taken' after skipping approval). Users should note that execution steps may perform file writes, external API calls, or deployments once approved.

Install Mechanism

Instruction-only skill with no install spec or code to download; README suggests optional cloning from GitHub but the skill bundle itself contains only documentation and a template. No remote install URLs or extract operations are present.

Credentials

The skill declares no environment variables, credentials, or config paths. That is proportionate to an instruction-only planning skill. However, actual execution (deployments, third-party integrations) will rely on whatever platform/tool credentials the agent already has access to—those are not requested by this skill.

Persistence & Privilege

always is false and the skill does not request permanent elevated presence. It instructs spawning sub-agents and updating plan files in its workspace, which is consistent with its purpose. Autonomous invocation is allowed by platform default but is not unusual here.

Assessment

This skill appears coherent for structured planning and coordinated execution. Before installing, consider: (1) the skill will create and update plan files in the agent workspace and can spawn sub-agents that may perform actions (file edits, web/API calls, deployments) once you approve — ensure you trust the agent's existing tool/credential access; (2) the SKILL.md instructs 'undo' if approval is skipped but doesn't define how to roll back changes—ask the author how undo is implemented if rollback safety matters; (3) be cautious when approving background execution or deployment tasks that require external credentials (e.g., Railway, cloud providers) — those credentials are not requested by the skill but may be used by the agent if available. If you need tighter control, restrict the agent’s tool/credential access or require human approval for any task that touches external systems.

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.
2. 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.
3. Start executing without asking execution mode → Pause all execution. Ask the user Foreground/Background, wait for reply, then resume.
4. Complete tasks without updating plan file status → Immediately update the plan doc. Each task must reflect its actual state (🔄 In Progress → ✅ Done / ❌ Failed).
5. 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: plans/YYYY-MM-DD-<short-slug>.md
   • 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.
4. 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.
5. 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
2. Add entries to the change log section
3. Refine task breakdown and deliverables
4. Confirm scope boundaries — what's IN and what's OUT
5. 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 🔵 Confirmed
2. Lock the plan — no more scope changes without explicit user request
3. Summarize what will be executed: task list + expected deliverables
4. 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 🟢 Executing

🛑 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.
4. 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)
6. 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 ⏳ Pending Review
2. 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:

Task A (independent) ── sub-agent 1 ──┐
Task B (independent) ── sub-agent 2 ──┤── merge results ── update plan doc
Task C (depends on A) ── wait for A ──┘

Always update the plan doc from the main agent, not from sub-agents.

Plan Document Location

All plans live in: ~/.openclaw/workspace/plans/

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.