planning-methodology

Guide structured software task planning with complexity scoring and sub-problem decomposition.

Updated Feb 15, 2026

Search Tags:#planning #architecture #methodology #decomposition #complexity #project-management #software-design

One-click install

npx skills add https://github.com/tvishwanadha/skills --skill planning-methodology-tvishwanadha

Or copy as Structured Prompt for Agent▼

Please help me install this Agent Skill.
Skill: planning-methodology
Source: https://github.com/tvishwanadha/skills/tree/main/plugins/planner/skills/planning-methodology
Command: npx skills add https://github.com/tvishwanadha/skills --skill planning-methodology-tvishwanadha

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This skill should be loaded during plan mode, when creating a plan, implementation planning, architecture design, feature breakdown, task breakdown, project planning, or solution design. Provides enhanced planning methodology with complexity scoring, sub-problem decomposition, and plan review.

Core Features & Use Cases

Enhanced workflow for the built-in plan mode. Uses a draft-score-design loop: load project constraints early, draft a lightweight plan, score complexity against the draft, then flesh out the full design.

Phase 1: Understanding

Load Project Constraints Before launching Explore subagents, try to load local-plan-standards. If found, extract its rules as planning constraints - these may inform what to explore (e.g., design patterns to follow, architectural boundaries, conventions to verify). If not found, proceed without constraints.

Phase 2: Draft Plan Launch a Plan Task subagent to create a lightweight structural plan for the full task. Provide it with:

The task description and research context from Phase 1
Project constraints loaded in Phase 1 (if any)

The draft should include:

High-level approach (1-2 sentences)
Key files to modify (verified against codebase)
Rough ordered steps (one line each)
Any project constraints that apply

This draft is not the final plan - its purpose is to give complexity scoring a concrete artifact to assess.

Phase 3: Score Complexity Score the task across 7 dimensions (1-10 each) based on the draft plan. The draft is intentionally lightweight and will understate rough edges - when uncertain, round up:

| Dimension | 1-3 (Low) | 4-6 (Moderate) | 7-10 (High) | |-----------|-----------|-----------------|--------------| | Scope | 1-3 files, single component | 4-9 files, 2-3 components | 10+ files, cross-cutting | | Novelty | Extending existing pattern | Adapting known pattern to new context | New pattern, no existing precedent | | Dependencies | No external integration | 1-2 integration points, well-documented | 3+ integrations, unclear interfaces | | Ambiguity | Clear requirements, obvious approach | Some open questions, 2-3 viable approaches | Underspecified, requires research or user clarification | | Risk | Easily reversible, local impact | Moderate blast radius, testable | Hard to reverse, wide blast radius, affects shared state | | Concurrency | Sequential, no shared state | Some async/parallel, manageable state | Complex state management, race conditions possible | | Domain | Standard CRUD/glue code | Moderate algorithmic complexity | Advanced algorithms, specialized domain knowledge |

Compute the composite score as a weighted average (Scope and Novelty at 1.5x):

composite = (scope1.5 + novelty1.5 + dependencies + ambiguity + risk + concurrency + domain) / 8.0

Present the assessment to the user:

Complexity: N/10 - 1-line rationale

| Dimension | Score | Rationale | |-----------|-------|-----------| | Scope | N | brief note | | Novelty | N | brief note | | Dependencies | N | brief note | | Ambiguity | N | brief note | | Risk | N | brief note | | Concurrency | N | brief note | | Domain | N | brief note |

Phase 4: Design

Flesh out the draft into a detailed plan using Plan Task subagents. First, classify the task tier to determine whether to decompose.

Decomposition

Classify the tier, checking from most to least complex:

Complex if composite >= 7 or any single dimension >= 8. Decompose.
Moderate if composite >= 4 or any single dimension >= 7. Consider decomposing, especially if multiple dimensions scored >= 6.
Simple otherwise. Skip decomposition.

When decomposing, aim for sub-problems that would individually score below 5. If that granularity isn't achievable, still decompose as far as practical - any reduction in complexity helps. Only skip decomposition if the task is truly indivisible. Launch parallel Plan subagents for decomposed sub-problems, or a single Plan subagent otherwise.

Plan Subagent Inputs

Every Plan subagent receives:

The draft plan from Phase 2 (or the relevant sub-problem scope if decomposed)
Research context gathered in Phase 1
Project constraints loaded in Phase 1 (if any)
Brief descriptions of sibling sub-problems, if decomposed (for interface awareness)

Expected Output

Each plan should include: approach, files to modify (verified against codebase), ordered implementation steps, interfaces with sibling sub-problems (if decomposed), and risks.

Include at the top of the plan file:

Complexity: N/10 (tier) - 1-line rationale

Synthesis (decomposed plans only)

After all parallel Plan subagents complete, synthesize sub-plans into a single plan:

Verify interfaces between sub-problems are consistent (shared files, data formats, ordering dependencies)
Resolve conflicts where sub-plans make incompatible assumptions
Establish a global implementation order - which sub-problems can be implemented in parallel and which have sequential dependencies

Phase 5: Review

Before calling ExitPlanMode:

Load planner:review-plan, passing the plan file path
If critical or high findings exist, address them before proceeding
Present review findings alongside the plan for user approval

Frequently Asked Questions about planning-methodology

High-intent search queries and answers about installing and using this skill.

FAQPage Schema

How do I break down complex software architecture design into manageable sub-problems?▼

Software architecture design is broken down using a draft-score-design loop that creates a lightweight plan, scores complexity across seven dimensions, and decomposes tasks into sub-problems for detailed planning. This ensures manageable implementation phases.

What is the best way to score project complexity before starting feature decomposition?▼

Project complexity is scored across seven dimensions—scope, novelty, dependencies, ambiguity, risk, concurrency, and domain—using a weighted average to classify tasks as simple, moderate, or complex. This determines if decomposition is required.

How do I create a structured implementation plan for a large software project?▼

Creating a structured implementation plan involves loading project constraints, drafting an initial approach, scoring complexity, and fleshing out detailed steps with files to modify and risk assessments. The plan synthesizes parallel sub-problem designs.

When should I decompose a software task into smaller planning sub-problems?▼

Task decomposition is required when the composite complexity score reaches 7 or higher, or if any single complexity dimension scores 8 or above. Decomposition aims to reduce sub-problem complexity scores below 5 for safer implementation.

Does this planning methodology support integrating local project standards and constraints?▼

Local project standards are integrated by loading local-plan-standards during the initial exploration phase, extracting design patterns and architectural boundaries as constraints. These rules inform the structural plan and sub-problem interfaces.

How do I verify interface consistency when synthesizing parallel software design plans?▼

Interface consistency is verified during the synthesis phase by checking shared files, data formats, and ordering dependencies between decomposed sub-problems. Conflicts from incompatible assumptions are resolved to establish a global implementation order.