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
2. references/core-kernel-and-bad-strategy.md (M-01)
3. 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.

Read 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:

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 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:

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.