Skill: yipxiyi/pad-mode (version 1.1.2)

--- name: pad-mode description: | Turn messy requests into structured plans. PAD Mode (Plan → Act → Deliver) gives your AI agent project management superpowers — automatic task breakdown, live progress tracking, sub-agent parallel execution, and human approval gates. Use /pad for complex tasks that need more than a single-shot answer. Perfect for plan mode, project planning, task planning, workflow planning, and multi-step execution. Triggers: 1. Slash command: "/pad" in conversation 2. Explicit keywords: "pad mode", "plan mode", "make a plan", "plan this out" 3. Auto-detect: When the user's request is complex (3+ distinct tasks, multi-file changes, architectural decisions, or ambiguous requirements), proactively suggest entering PAD mode. Use when: user wants structured execution tracking for non-trivial tasks, not for simple one-shot questions or commands. --- # PAD Mode (Plan → Act → Deliver) ## Overview PAD Mode transforms ambiguous requests into structured, trackable execution plans. Five phases: **Plan → Discuss → Approve → Act → Deliver**. PAD Mode is a **general execution framework**, not a coding-only workflow. It should remain lightweight for general tasks while applying stricter execution guardrails when the task type warrants them. ## ⚠️ 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 and the minimum files required to create or resume the plan. 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. **Mark a task done without verification** → Reopen the task immediately. In Phase 4, every task must follow `Execute → Verify → Mark done`. 6. **Deliver without button/text confirmation** → Do NOT auto-archive. Send the completion summary with buttons (or text fallback) and wait for user response. 7. **Use oversized tasks when the work can be reasonably split** → Stop and decompose the task before continuing. PAD tasks should be small enough to track, verify, and recover from failure cleanly. 8. **Skip required review for high-risk work** → Pause before completion and trigger review or explicit self-review. ## Definition of Done A task is not complete because work was attempted. A task is complete only when its promised output exists and the relevant checks have passed. Before marking any task `✅ Done`, confirm the relevant items below: - The deliverable exists and matches the task description - The critical verification step has been run and passed - Key result notes are written into the plan doc or execution log - Dependencies and downstream task impacts are updated if needed - If the task failed or partially succeeded, it is marked `❌ Failed` instead of `✅ Done` Task-specific additions: - **Coding tasks:** relevant tests/build/lint/checks run when applicable - **Research tasks:** conclusions clearly separate facts, evidence, and inference - **Ops tasks:** post-change health check completed, and rollback or risk note captured when relevant - **Content tasks:** output checked for audience, format, tone, and completeness If verification is missing, the task is still in progress. ## 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. Do not overwhelm. 6. Identify the **task type** early when possible: `coding`, `research`, `ops`, `content`, or `general`. 7. Default to **small task sizing**. A good PAD task is usually scoped to about **2 to 15 minutes** of focused work. If a task has multiple outputs, multiple dependencies, or broad undefined scope, split it further. 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 is IN and what is 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) 6. Use task-type-aware planning guardrails: - **coding:** define files/modules affected, expected behavior, and intended verification - **research:** define question, source expectations, and desired decision output - **ops:** define target system, risk level, pre-checks, and post-checks - **content:** define audience, tone, format, and deliverable shape - **general:** define output, success condition, and obvious constraints 7. Before approval, confirm this execution checklist is satisfied: - Goal is clear - Scope boundaries are clear - Dependencies are known - Key risks or unknowns are identified - Deliverables are concrete and verifiable Continue until the user says the plan is good, looks good, or 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 has not 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. If channel supports buttons, use `Foreground` / `Background` buttons. Otherwise ask as text and wait. 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 unless parallelization is explicitly appropriate - 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 dependency order. Independent tasks may run in parallel via sub-agents. 6. For **every task**, use the mandatory loop below: - Update task status to `🔄 In Progress` in the plan doc - **Execute:** do the work required for the task - **Verify:** run the relevant check for that task type - **Mark done:** only if verification passed, update notes and mark `✅ Done` - If execution or verification fails, mark `❌ Failed`, document the issue, and propose a fix, retry, or skip path - Notify the user immediately after each task completes or fails - Do not stop at “next I will…” when the next concrete action is already known; advance to the next real checkpoint or record a real blocker first 7. Verification guidance by task type: - **coding:** run the most relevant checks available, such as tests, lint, build, typecheck, or focused manual validation - **research:** verify that conclusions are supported by cited evidence and clearly distinguish fact from inference - **ops:** verify system state after the change, confirm service health or command outcome, and record rollback notes if relevant - **content:** verify output against audience, brief, format, and completeness - **general:** verify against the task's explicit success condition 8. Trigger review before completion when any of the following apply: - Changes span 3 or more files - Architecture or workflow structure changes materially - High-risk commands or system modifications are involved - Bulk automated edits are performed - External write actions or irreversible effects are involved Review may be done by a reviewer sub-agent or by explicit self-review if no sub-agent is appropriate. 9. If a task reveals that the plan needs adjustment: - Pause execution - Update the plan doc and change log - Ask the user before continuing ### Execution Lease / Watchdog When a PAD run enters `🟢 Executing`, treat it as a live workstream that must not silently stall. 1. Create or assume an execution lease for the active PAD plan. 2. A lease should be short-lived and renewable. A good default is about 10 minutes. 3. Renew the lease whenever one of these happens: - a task status changes in the plan doc - the execution log gets a real progress entry - a verification step completes - a real blocker is documented 4. If the lease is close to expiring, do not reply with a vague intent statement. Either: - complete the next concrete checkpoint, or - record the blocker explicitly in the plan doc 5. If a watchdog wake finds a PAD plan still in `🟢 Executing` with overdue lease and no fresh progress, it should resume the plan instead of merely reminding. Resume by: - reading the active plan - identifying the first unfinished or in-progress task - executing the next concrete step - updating the plan doc after the checkpoint or blocker 6. Inserted side requests do not cancel the lease. After handling the side request, return to the active PAD plan unless the user explicitly changes priority. 7. Do not use the watchdog to create fake progress. A watchdog recovery must produce one of two outcomes only: - a real checkpoint completed, or - a real blocker recorded 8. End the lease only when the plan leaves `🟢 Executing` for `⏳ Pending Review`, `✅ Completed`, or an explicitly paused state. ## 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 ## Interruption Recovery When a PAD run is already in `🟢 Executing`, treat it as the current primary workstream. - Handle short inserted requests if needed, but do not silently abandon the PAD run. - After the inserted work, return to the active PAD plan unless the user explicitly pauses or replaces it. - Before sending any non-PAD reply, check whether an executing PAD plan exists and whether the reply is advancing it, pausing it, or explicitly deferring it. - If none of those are true, return to the PAD plan first. ## Task Types PAD Mode should stay general, but task type should influence execution rigor. ### coding - Prefer explicit files/modules and expected behavior - Prefer verification via tests/lint/build/typecheck/manual checks as applicable - Trigger review more readily for broad changes ### research - Define the decision question clearly - Prefer source-backed conclusions - Clearly separate facts, evidence, and inference ### ops - Start with state inspection when possible - Treat riskier actions with stronger caution and verification - Record post-change checks and rollback notes when relevant ### content - Anchor on audience, tone, and format - Verify for completeness and usability before marking done ### general - Keep structure simple - Still require a concrete deliverable and explicit success condition ## Sub-agent Roles Sub-agents are not just extra workers. Assign them clear roles when useful. - **Explorer:** gather context, inspect codebases, collect research inputs, or map a system - **Implementer:** perform the actual modification or execution work - **Reviewer:** inspect output for issues, edge cases, regressions, or risky assumptions - **Verifier:** run checks and confirm the task meets its done criteria - **Summarizer:** merge outputs into a concise delivery package for the user Not every PAD run needs all roles. Use only the roles that create clear value. ## 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 does not 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 (for example, "continue the last plan"), search for it in `plans/`, read the doc, identify the last completed task, and resume from there.

path: README.md
content: # PAD Mode for OpenClaw

<img width="1536" height="776" alt="PAD Mode" src="https://github.com/user-attachments/assets/097ea4bf-a70b-4579-8246-5a578cf2e3a4" />

**Plan → Act → Deliver** — A structured task execution skill for OpenClaw.

[![ClawHub](https://img.shields.io/badge/ClawHub-install%20pad--mode-blue)](https://clawhub.ai/yipxiyi/pad-mode)
[![Version](https://img.shields.io/badge/version-1.1.2-green)](https://clawhub.ai/yipxiyi/pad-mode)
[![License](https://img.shields.io/badge/license-MIT-yellow)](./LICENSE)

[中文](./README_zh.md)

---

## Before → After

**Without PAD Mode:**
> User: "Refactor the auth module to use JWT instead of sessions"
>
> Agent: *starts editing files immediately, breaks login flow halfway through, forgets to update tests, declares "done" when the main file is edited but middleware still uses sessions*

**With PAD Mode:**
> User: "Refactor the auth module to use JWT instead of sessions"
>
> Agent: Creates a plan with 5 tasks (token generation, middleware update, test updates, migration script, cleanup), waits for approval, executes each with status tracking, asks you to verify before archiving.

The difference: **structured decomposition + confirmation gates = reliable execution**.

---

## Key Features

- 📋 **Plan Document** — Every task has a concrete, verifiable deliverable. "Optimize the code" becomes "Reduce API response time from 800ms to 200ms by adding Redis caching to the user endpoint".
- 🔄 **Foreground / Background** — Run complex plans in background (sub-agent) with real-time progress pushed to you.
- ✅ **Completion Gate** — Plans never auto-close. You review and confirm before archiving.
- 📦 **Parallel Execution** — Independent tasks run concurrently via sub-agents.
- 🔁 **Resumable** — Interrupted plans can be picked up from the last checkpoint.
- 📝 **Change Log** — Every modification is tracked in the plan document.

## Status Flow

```
🟡 Discussing → 🔵 Confirmed → 🟢 Executing → ⏳ Pending Review → ✅ Completed
                                                                               ↓
                                                          🔧 Changes Needed → back to Discuss
```

---

## Installation

### ClawHub (Recommended)

```bash
clawhub install pad-mode
```

### From source

```bash
git clone https://github.com/Yipxiyi/PAD-Mode-for-openclaw.git
cp -r PAD-Mode-for-openclaw ~/.openclaw/workspace/skills/pad-mode/
```

---

## Triggers

| Method | Example | When it fires |
|--------|---------|---------------|
| Slash command | `/pad` | Always — creates a plan |
| Keywords | "make a plan", "plan this out", "做个计划" | Detects planning intent |
| Auto-detect | 3+ distinct tasks, multi-file changes, architectural decisions | Complex requests |

**Auto-detect fires when:**
- ✅ "Add user auth with login, signup, password reset, and email verification" (4 tasks)
- ✅ "Migrate the database from MySQL to PostgreSQL" (multi-step, risky)
- ✅ "Refactor the payment module and add Stripe integration" (2+ concerns)

**Auto-detect does NOT fire when:**
- ❌ "Fix the typo in header.js" (single, simple)
- ❌ "What does this function do?" (question, not task)

---

## How It Works

Four phases with enforcement at every step:

```
  PLAN            DISCUSS         ACT             DELIVER
  Decompose       Iterate         Execute         Confirm
  ├ Create plan   ├ Refine scope  ├ Track each    ├ Review all
  ├ Break into    ├ Lock          │ task status   ├ ✅ or 🔧
  │ tasks         │ deliverables  ├ Progress      └ Archive
  └ No research   └ Max 4 Qs      │ updates       │
                                   └ Foreground /  │
                                      Background   │
                                                    │
                                   ◄── Loop if changes needed ──►
```

## ⚠️ Enforcement

PAD Mode treats these as hard blockers, not suggestions:

| Rule | If violated |
|------|-------------|
| Never skip approval (Phase 3) | Halt, undo actions, return to Phase 3 |
| No research during planning | Discard results, plan structure only |
| Must ask execution mode | Pause all work, wait for user reply |
| Always update task status | Immediately fix plan doc |
| Never auto-archive | Wait for user confirmation |

---

## Real Example

**User request:** "Build a REST API for a todo app with CRUD operations, user auth, and deploy to Railway"

**Generated plan (`plans/2026-03-31-todo-api.md`):**

```markdown
# 📋 Todo REST API

**Status:** 🔵 Confirmed
**Created:** 2026-03-31 14:00

## Task Breakdown
- [x] **T1.1** Initialize Express project with TypeScript
  - Deliverable: Project scaffold with tsconfig, package.json, folder structure
  - Dependencies: none
- [x] **T1.2** Implement CRUD endpoints (GET/POST/PUT/DELETE /todos)
  - Deliverable: 4 working endpoints with validation
  - Dependencies: T1.1
- [ ] **T2.1** Add JWT authentication
  - Deliverable: Login/register endpoints, auth middleware
  - Dependencies: T1.1
- [ ] **T3.1** Write tests
  - Deliverable: 80%+ coverage on endpoints
  - Dependencies: T1.2, T2.1
- [ ] **T4.1** Deploy to Railway
  - Deliverable: Live URL with health check passing
  - Dependencies: T3.1
```

---

## Background

Inspired by the structured planning modes in **OpenAI Codex** and **Anthropic Claude Code**, which proved that LLMs perform significantly better when forced to plan before executing. PAD Mode brings this pattern to OpenClaw with additional features:

- **User confirmation gates** (plan approval + completion review)
- **Foreground/background execution** choice
- **Real-time progress tracking** via plan documents
- **Sub-agent parallelism** for independent tasks
- **Enforcement rules** that prevent common agent mistakes

The goal: make OpenClaw as reliable for long-running tasks as it is for quick one-shots.

## License

MIT


path: README_zh.md
content: # PAD Mode for OpenClaw

<img width="1536" height="776" alt="PAD Mode" src="https://github.com/user-attachments/assets/097ea4bf-a70b-4579-8246-5a578cf2e3a4" />

**Plan → Act → Deliver** — 一个为 OpenClaw 设计的结构化任务执行 Skill。

[![ClawHub](https://img.shields.io/badge/ClawHub-install%20pad--mode-blue)](https://clawhub.ai/yipxiyi/pad-mode)
[![Version](https://img.shields.io/badge/version-1.1.2-green)](https://clawhub.ai/yipxiyi/pad-mode)
[![License](https://img.shields.io/badge/license-MIT-yellow)](./LICENSE)

[English](./README.md)

---

## 效果对比

**没有 PAD Mode：**
> 用户："把认证模块从 session 改成 JWT"
>
> Agent：*立刻开始改文件，改到一半登录流程坏了，忘了更新测试，主文件改完就说"搞定了"，但中间件还在用 session*

**有 PAD Mode：**
> 用户："把认证模块从 session 改成 JWT"
>
> Agent：创建一个 5 步计划（token 生成、中间件更新、测试更新、迁移脚本、清理），等你确认后逐个执行并更新状态，最后让你验收再归档。

区别在于：**结构化拆解 + 确认门槛 = 可靠执行**。

---

## 核心特性

- 📋 **计划文档** — 每个任务有明确可交付物。"优化代码"变成"通过 Redis 缓存用户接口，将响应时间从 800ms 降到 200ms"
- 🔄 **前台/后台执行** — 复杂计划可转后台（sub-agent），进度实时推送给你
- ✅ **完成门槛** — 计划不会自动关闭，必须你确认验收才算完
- 📦 **并行执行** — 独立任务通过 sub-agent 并行处理
- 🔁 **可恢复** — 中断的计划可以从上次进度继续
- 📝 **变更日志** — 每次修改都记录在计划文档中

## 状态流转

```
🟡 讨论中 → 🔵 已确认 → 🟢 执行中 → ⏳ 待确认 → ✅ 已完成
                                                      ↓
                                    🔧 需要修改 → 回到讨论
```

---

## 安装

### ClawHub（推荐）

```bash
clawhub install pad-mode
```

### 从源码安装

```bash
git clone https://github.com/Yipxiyi/PAD-Mode-for-openclaw.git
cp -r PAD-Mode-for-openclaw ~/.openclaw/workspace/skills/pad-mode/
```

---

## 触发方式

| 方式 | 示例 | 何时触发 |
|------|------|---------|
| 斜杠命令 | `/pad` | 始终触发 |
| 关键词 | "做个计划"、"plan mode"、"帮我规划" | 检测到规划意图 |
| 自动检测 | 3+ 独立任务、多文件修改、架构决策 | 复杂需求自动建议 |

**会触发的场景：**
- ✅ "加个用户认证，要有登录、注册、密码重置、邮箱验证"（4 个任务）
- ✅ "把数据库从 MySQL 迁移到 PostgreSQL"（多步骤、高风险）
- ✅ "重构支付模块，顺便接 Stripe"（多个关注点）

**不会触发的场景：**
- ❌ "修一下 header.js 的拼写错误"（单一简单任务）
- ❌ "这个函数是干嘛的？"（问题是提问，不是任务）

---

## 工作流程

四个阶段，每一步都有执行纪律：

```
  PLAN            DISCUSS         ACT             DELIVER
  拆解            讨论            执行            交付
  ├ 创建计划      ├ 完善范围      ├ 逐个任务      ├ 验收全部
  ├ 拆成任务      ├ 锁定          │ 状态追踪      ├ ✅ 或 🔧
  │              │ 可交付物      ├ 进度推送      └ 归档
  └ 不做调研      └ 最多 4 个问题  └ 前台/后台      │
                                                    │
                                   ◄── 如需修改回到讨论 ──►
```

## ⚠️ 强制规则

PAD Mode 把以下规则当作硬性阻断，不是建议：

| 规则 | 违反后果 |
|------|---------|
| 不得跳过审批（Phase 3） | 立即停止，撤回操作，回到 Phase 3 |
| 计划阶段不做调研 | 丢弃所有调研结果 |
| 必须询问执行模式 | 暂停所有工作，等待用户回复 |
| 必须更新任务状态 | 立即修正计划文档 |
| 不得自动归档 | 等待用户确认 |

---

## 实际案例

**用户请求：** "做一个 Todo App 的 REST API，要 CRUD、用户认证、部署到 Railway"

**生成的计划 (`plans/2026-03-31-todo-api.md`)：**

```markdown
# 📋 Todo REST API

**状态:** 🔵 已确认
**创建:** 2026-03-31 14:00

## 任务拆解
- [x] **T1.1** 初始化 Express + TypeScript 项目
  - 交付物: 项目脚手架，含 tsconfig、package.json、目录结构
  - 依赖: 无
- [x] **T1.2** 实现 CRUD 接口（GET/POST/PUT/DELETE /todos）
  - 交付物: 4 个带验证的可用接口
  - 依赖: T1.1
- [ ] **T2.1** 添加 JWT 认证
  - 交付物: 登录/注册接口 + 认证中间件
  - 依赖: T1.1
- [ ] **T3.1** 编写测试
  - 交付物: 接口测试覆盖率 80%+
  - 依赖: T1.2, T2.1
- [ ] **T4.1** 部署到 Railway
  - 交付物: 线上 URL，健康检查通过
  - 依赖: T3.1
```

---

## 开发背景

灵感来自 **OpenAI Codex** 和 **Anthropic Claude Code** 的结构化计划模式。它们证明了一个事实：**强制 LLM 先计划再执行，能显著提高长任务的成功率。**

PAD Mode 在此基础上增加了：
- **用户确认关卡**（计划审批 + 完成验收）
- **前台/后台执行**选择
- **实时进度追踪**（通过计划文档）
- **Sub-agent 并行**（独立任务同时跑）
- **强制执行规则**（防止 Agent 常见错误）

目标：让 OpenClaw 处理长任务时跟处理短任务一样靠谱。

## License

MIT


path: assets/plan-template.md
content: # 📋 {Project Name}

**Status:** 🟡 Discussing | 🔵 Confirmed | 🟢 Executing | ⏳ Pending Review | ✅ Completed | 📦 Archived
**Created:** {YYYY-MM-DD HH:mm}
**Archived:** {archive time, leave empty if not archived}
**Deliverables:** {specific, verifiable final outputs}

---

## Requirements Analysis

**Original Request:**
> {user's exact words}

**Understanding:**
- {your interpretation and assumptions}

**Scope:**
- ✅ In scope: {what's included}
- ❌ Out of scope: {what's excluded}

---

## Task Breakdown

### Phase 1: {Phase Name}

- [ ] **T1.1** {Task description}
  - Deliverable: {specific output}
  - Dependencies: none
  - Status: ⬜ Pending

- [ ] **T1.2** {Task description}
  - Deliverable: {specific output}
  - Dependencies: T1.1
  - Status: ⬜ Pending

### Phase 2: {Phase Name}

- [ ] **T2.1** {Task description}
  - Deliverable: {specific output}
  - Dependencies: T1.2
  - Status: ⬜ Pending

---

## Open Questions

> _Questions that need user input before execution_

1. {question — offer A/B/C if applicable}

---

## Change Log

| Time | Change |
|------|--------|
| {YYYY-MM-DD HH:mm} | Initial plan created |

---

## Execution Log

> _Key execution records_

| Time | Task | Result | Notes |
|------|------|--------|-------|
| {YYYY-MM-DD HH:mm} | T1.1 | ✅/❌ | {brief description} |


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal:  | SkillSpector:  ()