Planning

What This Skill Is

Planning is the structured approach of breaking down complex objectives into executable steps before taking action. It operates as a preparatory phase where goals are analyzed, requirements are identified, and a sequence of operations is designed.

In AI-assisted work, planning transforms vague intentions into concrete specifications. Instead of stating "build a website," planning produces component lists, data flow diagrams, dependency maps, and implementation order. It creates a shared understanding between human intent and machine execution.

Planning differs from immediate execution in its emphasis on foresight. It considers edge cases, resource constraints, and potential failure modes before any code is written or any task is performed. The output of planning is not a finished product, but a roadmap that makes execution predictable and measurable.

Why This Skill Matters

Without planning, AI interactions tend to follow a trial-and-error pattern. A request is made, partial results emerge, gaps are identified, and iterations follow. This cycle consumes time and obscures the root causes of problems.

When planning is absent, several predictable failures occur. Requirements are discovered mid-implementation, requiring structural changes. Dependencies between components are overlooked, creating integration problems. Edge cases remain unaddressed until they cause production failures. The scope expands gradually as new needs surface during execution.

Planning prevents these issues by forcing consideration of the full problem space before resources are committed. It surfaces contradictions in requirements, identifies necessary information that is missing, and reveals dependencies that affect implementation order. The result is fewer course corrections and more predictable outcomes.

More critically, planning creates artifacts that serve as communication tools. A plan can be reviewed, critiqued, and adjusted before expensive work begins. This allows errors in reasoning to be caught when they are cheap to fix, rather than after implementation is underway.

Core Concepts

Decomposition

Decomposition is the recursive breaking of complex goals into smaller, independently verifiable subgoals. Each subgoal should be concrete enough that its completion is unambiguous. Effective decomposition produces a hierarchy where high-level goals branch into implementable tasks, which is the core of Task Decomposition.

Decomposition follows the principle of atomicity: each task should address one concern and produce one artifact. A task like "implement the authentication system" is insufficiently decomposed. Better is "define user schema," "implement password hashing," "create session management," and "build login endpoints."

Dependency Mapping

Dependencies are relationships where one task cannot begin or complete until another task finishes. Planning identifies these relationships to establish a valid execution order. Some dependencies are strict (task A must complete before task B starts), while others are partial (task B can begin but cannot complete until task A finishes).

Dependency mapping reveals parallelization opportunities. Independent tasks can be executed simultaneously, reducing overall completion time. It also exposes critical paths—sequences of dependent tasks where delays directly impact the final deadline.

Constraint Identification

Constraints are limitations on acceptable solutions. They include technical constraints (compatibility requirements, performance targets), resource constraints (time, budget, computational capacity), and process constraints (team structure, communication protocols).

Planning surfaces constraints early so they can inform solution design. A performance requirement of "sub-100ms response times" influences database selection and caching strategy. This connects to Constraint Encoding practices.

Risk Assessment

Risks are events that could prevent successful completion. They include technical risks (unproven technologies, performance uncertainty), external risks (API changes, dependency deprecation), and scope risks (requirements evolution, understanding gaps).

Planning assesses risks by estimating likelihood and impact. High-impact, high-likelihood risks are addressed through mitigation strategies—prototyping uncertain components, establishing fallback options, or gathering missing information. Lower-priority risks are monitored during execution.

Verification Criteria

Each planned task needs clear completion criteria. These criteria define what "done" means for that task. Verification criteria should be observable and testable: "the function returns a 200 status code for valid input" rather than "the function works." This clarity is essential for effective Evaluation.

Clear criteria prevent ambiguity about progress. They enable objective assessment of whether a task is complete and allow blockers to be identified early. When criteria are undefined, work tends to drift as boundaries of completion shift during implementation.

How This Skill Is Used

Planning typically follows a progression from understanding to specification. The process begins by clarifying the objective: what problem is being solved and what constitutes success. This high-level understanding anchors all subsequent decisions.

Next, the planning phase identifies the context in which the work will occur. Existing systems, architectural patterns, and technical constraints are documented. This context prevents plans that are theoretically sound but practically incompatible with the environment, which is where Context Management becomes critical.

The core planning work involves decomposition and dependency mapping. The objective is broken into subgoals, subgoals into tasks, and tasks into steps. Dependencies between these elements are identified and organized into a structured execution sequence. The result is typically represented as a hierarchy or a directed graph.

Throughout this decomposition, constraints and risks are documented. Each task is examined for potential failure modes and missing information. Tasks with high uncertainty are flagged for investigation or prototyping before full implementation.

The planning output is reviewed before execution begins. This review checks for logical consistency, completeness, and feasibility. Gaps are addressed, dependencies are verified, and the plan is adjusted based on feedback. Only after this validation does execution proceed.

During implementation, the plan serves as a reference. Actual progress is measured against planned milestones. Deviations from the plan trigger reassessment—either the plan was incorrect and needs updating, or execution has gone off-track and requires correction.

Common Mistakes

Over-Planning

Planning can become a form of procrastination. When planning extends beyond the point of diminishing returns, it delays useful work without improving outcomes. The signal of over-planning is iteration on details that will be resolved quickly during implementation.

Planning should stop when the next level of detail is more efficiently discovered through execution rather than speculation. For software tasks, this typically occurs when tasks are defined at the level of "implement this function with these parameters," not "write these specific lines of code."

Under-Decomposition

Leaving tasks at too high a level creates hidden complexity. A task like "integrate the payment provider" encompasses API research, authentication setup, webhook handling, error cases, testing, and documentation. Implementing this as a single task inevitably reveals sub-steps mid-execution, disrupting flow and creating integration points that aren't independently verifiable. Proper Task Decomposition prevents this.

The corrective approach is aggressive decomposition: continue breaking tasks down until each one produces a single, testable artifact. If a task requires more than a few hours of focused work, it is likely under-decomposed.

Ignoring Reverse Dependencies

Most dependency analysis focuses on forward dependencies (what must come before). Reverse dependencies (what must come after) are equally important. If task A produces an interface that task B consumes, task B's requirements should inform task A's design. Ignoring reverse dependencies leads to interfaces that don't match consumer needs.

Effective planning traces dependencies in both directions. For each task, identify what it depends on and what depends on it. This ensures that handoffs between tasks are clean and that contracts between components satisfy all consumers.

Planning Without Information

Some planning gaps cannot be resolved through analysis alone—they require investigation. Attempting to plan around unknowns produces speculative designs that often prove incorrect. Common examples include planning database schemas without understanding query patterns or planning APIs without knowing consumer requirements.

When critical information is missing, the correct planning move is to create a research task. "Investigate feasible approaches for X" or "Prototype Y to validate assumptions" are legitimate planning outputs. These tasks generate the information needed for detailed planning, creating a cycle of Iteration.

Treating Plans as Static

Plans represent understanding at a point in time. As work progresses, understanding improves. New constraints emerge, assumptions are invalidated, and better approaches become visible. Treating the initial plan as immutable guarantees deviation from reality.

Effective plans are living documents. They are updated when new information surfaces, when tasks reveal unexpected complexity, or when external conditions change. The plan is a tool for navigation, not a fixed route.

When This Skill Is Needed

Planning is essential when work extends beyond trivial modifications. Adding a configuration option to an existing system may not require formal planning, but adding a new feature with multiple components certainly does.

Multi-person work demands planning. Coordination requires shared understanding of who is doing what, in what order, and with what dependencies. Without planning, parallel work conflicts, integration fails, and effort is duplicated.

Unfamiliar problem spaces benefit from planning. When the domain or technical approach is new, planning provides structure for gathering information and testing assumptions. The plan organizes research activities and ensures that critical questions are answered before implementation.

High-stakes work requires planning. Production changes, user-facing features, and architectural decisions have significant failure costs. Planning reduces risk by forcing consideration of failure modes and by establishing verification criteria.

Time-constrained work benefits from planning. Paradoxically, taking time to plan saves time overall. The planning overhead is recovered through fewer course corrections, less rework, and more efficient execution. When deadlines are tight, planning prevents false starts and ensures that work directly contributes to the objective.

How This Skill Connects to Other Skills

Planning provides structure that makes other skills more effective. Decomposition connects directly to task breakdown and prioritization. The ability to identify dependencies requires understanding system architecture and component relationships. Risk assessment draws on analytical thinking and pattern recognition from past experience.

Planning informs execution skills. Clear task definitions enable focused implementation work. Dependency mapping supports efficient scheduling and resource allocation. Verification criteria provide targets for testing and validation.

Planning relies on foundational cognitive skills. Critical thinking evaluates plans for logical consistency and completeness. Abstraction allows planning at multiple levels of detail, from high-level architecture to specific implementation steps. Systems thinking reveals how changes in one component affect others.

Related Skills

Prerequisite Skills

Task Decomposition: Can't plan what you haven't decomposed into manageable units.

Complementary Skills

Reasoning: Planning requires reasoning about dependencies, consequences, and resource allocation.

Constraint Handling: Planning happens within constraints; skills reinforce each other—planning identifies constraints, constraint handling manages them.

Skill Boundaries

Planning does not replace implementation. A perfect plan with no execution produces no value. Planning is a preparatory phase, not the work itself. At some point, the plan must be set aside and actual work must begin.

Planning cannot create information that doesn't exist. Plans based on insufficient understanding are speculation, not planning. When critical information is missing, the correct response is to gather that information, not to construct elaborate plans around assumptions.

Planning does not compensate for vague objectives. A plan requires a clear goal. If the objective is ambiguous ("make the system better" or "improve performance"), planning cannot create specificity. The goal must be clarified before meaningful planning is possible.

Planning has limits of complexity. Very large systems cannot be planned in complete detail from the outset. Attempting to do so produces unusable documents and massive waste. The appropriate approach is hierarchical planning: detail the near term, outline the medium term, and acknowledge uncertainty for the long term.

Planning is not a substitute for communication. Plans in isolation create misalignment. Planning is a social process involving discussion, negotiation, and shared understanding. The artifacts produced during planning matter less than the shared mental model they create.