planning-patterns

Generate executable, test-driven implementation plans with explicit file changes and commit actions.

161|25|Updated Oct 22, 2025
One-click install
npx skills add https://github.com/romiluz13/cc10x --skill planning-patterns-romiluz13
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: planning-patterns
Source: https://github.com/romiluz13/cc10x/tree/main/plugins/cc10x/skills/planning-patterns
Command: npx skills add https://github.com/romiluz13/cc10x --skill planning-patterns-romiluz13

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Provides structured, bite-sized planning templates that convert vague goals into executable tasks using TDD, spec-based planning, and DRY/YAGNI principles.

Core Features & Use Cases

  • Bite-sized task steps: Each task is 2-5 minutes of work with explicit actions.
  • Plan header template: Includes goal, architecture, tech stack, prerequisites.
  • No vagueness: Every step is specific and testable.
  • Use Case: Plan to implement a feature with test-driven steps and concrete file changes.

Quick Start

Create a plan using the required header, then fill in tasks as concrete steps such as "Write failing test", "Run tests to verify failure", "Implement minimal code", "Run tests to verify success", "Commit changes".

Frequently Asked Questions about planning-patterns

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

FAQPage Schema
How do I break down a software feature into executable task steps?

Task-breakdown converts vague goals into bite-sized, 2-5 minute steps using test-driven development. Each step specifies concrete actions—write failing test, implement code, verify—with explicit file changes, test scenarios, and acceptance criteria, enabling zero-context engineers to execute without ambiguity.

What's the best way to plan a feature using TDD and spec-based design?

Spec-based planning combines TDD principles with DRY and YAGNI to eliminate vague instructions. Create a plan header with goal, architecture, and tech stack, then enumerate tasks as specific, verifiable actions—each touching named files, defining test scenarios, and stating acceptance criteria for transparent progress.

How do I structure an implementation plan so any engineer can execute it without context?

Implementation planning requires a header template covering goal, architecture, and prerequisites, followed by concrete task steps. Each step must be testable, specify touched files and commit actions, include test scenarios, and state acceptance criteria—eliminating vagueness so unfamiliar engineers verify and complete work independently.

Can I use task-driven planning to reduce rework and scope creep?

Task-driven planning applies DRY and YAGNI principles to scope control. By committing to bite-sized, test-driven steps with explicit acceptance criteria and no vague instructions, teams avoid over-engineering, reduce rework cycles, and maintain focus on verified, deliverable increments rather than speculative features.

What makes a planning step specific enough to execute without guessing?

Specificity requires naming files touched, stating test scenarios to run, defining verifiable acceptance criteria, and describing concrete actions—not aspirations. Test-driven steps create checkpoints; each passes or fails objectively, eliminating interpretation and enabling any engineer to proceed or flag blockers with certainty.