# Plan Tasks

> 在执行复杂任务前，按 Rumelt《好战略，坏战略》全书的动态模块生成可审阅、可证伪的战略方案。用户调用 /plan-tasks，要求先给方案、实施计划、任务拆解、防跑偏方案，或任务涉及多个文件或模块、架构变化、重构、竞争路线、关键未知、强依赖、多人或多代理协作、高影响、高风险或高返工成本时使用。

- Skill: `lingxiaobc/plan-tasks` (Agent Skill, multi-file: 16 files)
- Install (CLI): `npx skillmds@latest add lingxiaobc/plan-tasks`
- Raw SKILL.md: https://api.skillmd.com/api/skills/lingxiaobc/plan-tasks/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools, Productivity
- Author: lingxiaobc (https://skillmd.com/u/lingxiaobc)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/lingxiaobc/plan-tasks

---


# Plan Tasks

## Purpose and state boundary

Build a causal strategy before execution, then track only work the user explicitly approves. Treat `$ARGUMENTS` as the task when present; otherwise use the current request and relevant conversation context.

There are two phases:

1. **Planning:** inspect only read-only context, produce `DRAFT` or `READY_FOR_REVIEW`, then stop.
2. **Approved execution:** begin only after the user explicitly approves the current plan or named `A-*` actions; create or update a `TASK/` tracker and execute only inside that scope.

During planning, never edit target files, create a tracker, run mutating commands, publish, deploy, commit, send an external message, or take an irreversible action. `allowed-tools` pre-approves read tools; it is not a security sandbox. Continue to obey Claude Code permissions, project instructions, protected paths, privacy rules, and the user's authorization.

## Parse inputs and load only needed knowledge

Accept an optional override in the task text:

- `--modules M-03,M-07` adds requested modules.
- `--exclude M-04` requests removal of conditional modules.

Before planning, always read these files completely:

1. [references/routing.md](references/routing.md)
2. [references/core-kernel-and-bad-strategy.md](references/core-kernel-and-bad-strategy.md) (`M-01`)
3. [references/plan-contract.md](references/plan-contract.md)

Classify the task with `routing.md`, record the route, then read every selected module below. Do not load unselected method files merely to appear comprehensive.

| Module | Read when selected |
| --- | --- |
| `M-02` | [leverage-and-proximate-objectives.md](references/leverage-and-proximate-objectives.md) |
| `M-03` | [system-design-and-focus.md](references/system-design-and-focus.md) |
| `M-04` | [scope-and-advantage.md](references/scope-and-advantage.md) |
| `M-05` | [dynamics-and-inertia.md](references/dynamics-and-inertia.md) |
| `M-06` | [integrated-action-design.md](references/integrated-action-design.md) |
| `M-07` | [hypothesis-and-learning.md](references/hypothesis-and-learning.md) |
| `M-08`, `M-09` | [alternatives-and-reality-check.md](references/alternatives-and-reality-check.md) |

Read [references/examples.md](references/examples.md) only when the task is vague, conflicting, exploratory, or difficult to classify. Keep `[GSBS]` author claims separate from `[AI-EXT]` AI-collaboration controls. Never attribute prompts, permissions, validators, schemas, or approval gates to Richard Rumelt.

## Planning workflow

1. Establish requirements, facts, constraints, unknowns, assumptions, tools, permissions, and prohibited actions without expanding authority.
2. Classify seven routing dimensions: uncertainty, dependency, reversibility, scope/capability, legacy inertia, environmental dynamics, and coordination complexity. Apply mandatory-module rules before accepting a user exclusion.
3. Select one mode:
   - `full` for complex, ambiguous, multi-stage, high-impact, cross-module, or costly-to-reverse work;
   - `diagnostic-exploration` when evidence cannot support one primary diagnosis;
   - `compact` only for an explicitly requested, simple, low-risk, reversible task.
4. Formulate the kernel: facts and constraints -> diagnosis or alternatives -> guiding policy and non-goals -> proximate objective/leverage -> coherent actions.
5. Apply each selected module to a named field or ID in the plan. Listing a module without changing the plan is invalid.
6. Define action interfaces: `addresses`, `implements`, input, output, dependencies, permissions, and observable acceptance. Put gates before weak links and keep only causally coherent work.
7. State a testable hypothesis, smallest feasible test, failure signal, and the layer to revisit after failure. Use genuine alternatives instead of defending the first answer.
8. Run the bad-strategy audit: reject fluff, goals posing as strategy, avoided choices, unfocused objectives, blue-sky objectives, and template completion without causal links.
9. Output exactly `rumelt-task-plan/v2` from the contract. Use `DRAFT` for unresolved hard errors or material decisions; otherwise use `READY_FOR_REVIEW`. Never set `APPROVED` for the user.

If a plan is saved to an authorized path, run:

```text
python "${CLAUDE_SKILL_DIR}/scripts/validate-plan.py" <plan.md>
```

Fix every `ERROR`; expose any `WARN` as a review question or an accepted risk. Present the plan version, selected modules, pivotal assumption, approval scope, and remaining user decisions. Stop without executing the target task.

## Approval and tracking

Treat approval as valid only when the user has seen the current version and explicitly approves the whole plan or named `A-*` actions. Silence, the original request, `READY_FOR_REVIEW`, low apparent risk, or self-judgment is never approval. Approval never expands tools, directories, data access, external sends, destructive operations, or privacy permissions.

After valid approval:

1. Read [references/task-tracking-contract.md](references/task-tracking-contract.md) completely.
2. Create `TASK/TASK_<descriptive-name>.md` only if no tracker exists.
3. Copy the approved plan ID/version, routing snapshot, module set, diagnosis, policy, proximate objective, non-goals, approval scope, permissions, and completion criteria.
4. Decompose only approved `A-*` actions into verifiable `T-*` checkbox items. Update each item immediately after its acceptance condition passes.
5. Pause and issue a revised `READY_FOR_REVIEW` plan if strategy, selected modules, scope, permissions, acceptance, or external effects change materially.
6. Validate a saved tracker after creation, material updates, and completion:

```text
python "${CLAUDE_SKILL_DIR}/scripts/validate-task-tracker.py" <TASK-file.md> [--plan <approved-plan.md>]
```

## Non-negotiable gates

1. Do not design action without a supported diagnosis or an explicit exploration objective.
2. Do not call a statement a guiding policy unless it chooses and rejects routes.
3. Do not select a module without a traceable application in the plan.
4. Do not allow user overrides to remove `M-01` or a high-risk mandatory module.
5. Do not execute or create `TASK/` before explicit approval of the current plan.