plan

Decomposes specs into ordered, verifiable implementation tasks with acceptance criteria.

Updated Aug 10, 2026
One-click install
npx skills add https://github.com/ledtorch/coding-agent-workflow --skill plan-ledtorch
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: plan
Source: https://github.com/ledtorch/coding-agent-workflow/tree/main/skills/plan
Command: npx skills add https://github.com/ledtorch/coding-agent-workflow --skill plan-ledtorch

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Large or vague development requests lead agents to make hundreds of invisible decisions that surface as bugs later. This Skill turns a spec or feature request into a structured plan document of small, independently verifiable tasks before any code is written. ## Core Features & Use Cases - Vertical task slicing: Breaks work into complete, testable slices (schema + API + UI) rather than horizontal layers, each passing a six-point "small enough" definition. - Dependency and conflict mapping: Builds a logic map of task dependencies and shared surfaces (files, stores, API contracts) to justify sequential vs. parallel scheduling. - Reuse review: Searches the codebase for existing components, stores, and endpoints so the plan extends what exists instead of duplicating it. - Use Case: Given a request like "add user registration", produce a references/build-registration.md plan with phased tasks, acceptance criteria, review checks, checkpoints, and risk mitigations ready for a builder agent to execute. ## Quick Start Ask the agent to plan the work: "Break the user registration feature into an implementation plan with ordered tasks and acceptance criteria."

Frequently Asked Questions about plan

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

FAQPage Schema
How do I break a large feature request into implementable tasks?

Slice the request vertically so each task delivers one complete, testable path rather than one layer. Each task must touch at most 5 files, stay within one subsystem, have at most 3 acceptance criteria, and fit in a single focused session.

How to decide if coding tasks can run in parallel?

Build a logic map of dependencies and shared surfaces first. Tasks may run in parallel only when they share no files, stores, API contracts, or database tables; tasks sharing a contract can parallelize only after a task pins that contract down.

When should I not use a task breakdown planning workflow?

Skip full planning for single-file changes with obvious scope, or when a spec already contains well-defined tasks. The planning overhead only pays off when work is large, vague, or spans multiple subsystems.

Does the planning skill write or modify any code?

No, planning is strictly read-only. The only output is a plan document saved under references/ containing the task list, logic map, schedule, and risks; implementation is handled separately by a build step.

What makes a task small enough to implement in one session?

A task passes when it touches at most 5 files, stays in one subsystem, has at most 3 acceptance criteria, fits in roughly 2 hours of agent work, ends in a working system state, and has no "and" in its title.