Breakdown

Skill kt3k/skills/skills/breakdown

Skills for developing software carefully and steadily. Plan tasks, review code, and refine design to improve overall quality.

Install

npx -y skills add kt3k/skills --skill breakdown

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
3 stars3 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Break down a given task into subtasks with time estimates. Analyzes the codebase and task requirements to produce a structured plan with estimated effort for each step.

SKILL.md

2.9 KB, as published. Nobody here has run it

Task Breakdown Skill

Given a task description (from the user or the current conversation context), perform the following:

Understand the task: Read relevant source files, configs, and documentation to fully understand the scope of the task.
Identify subtasks: Decompose the task into concrete, actionable subtasks. Each subtask should be:
- Small enough to be completed in a single focused session
- Independent where possible (minimize sequential dependencies)
- Clearly scoped with a defined "done" state
- Leaf nodes must be size M or smaller. If a leaf node would be L or XL, break it down further.
Estimate effort: For each subtask, assign a complexity size based on the scope of changes involved:
- XS: Single location, obvious change — renaming, config tweak, one-line fix
- S: A few locations in one file, well-understood — adding a field, writing a simple test
- M: Multiple locations or files, some design decisions — new function, refactor a module, integration work
- L: Cross-cutting across multiple modules, significant design decisions — new feature, major refactor
- XL: New subsystem or architecture-level change, many unknowns — large migration, multi-file redesign

Output format: Present the breakdown as a tree structure that reflects the hierarchy and dependencies of the work:

## Task Breakdown: <task title>

## Specifications

- <key requirement or behavior 1>
- <key requirement or behavior 2>
- <constraint or edge case>
...

## Subtasks

- [ ] <high-level phase 1> [L]
  - [ ] <subtask 1.1> [S]
  - [ ] <subtask 1.2> [M]
    - [ ] <sub-subtask 1.2.1> [XS]
- [ ] <high-level phase 2> [M]
  - [ ] <subtask 2.1> [S]
  - [ ] <subtask 2.2> [S]
- [ ] <high-level phase 3> [S]

## Subtask Details

### 1. <high-level phase 1>
<what this phase accomplishes and why>

#### 1.1 <subtask 1.1>
<what to do, which files/modules are involved, acceptance criteria>

#### 1.2 <subtask 1.2>
...

### 2. <high-level phase 2>
...

Parent nodes represent phases or groups of related work; leaf nodes represent atomic tasks.
Estimates on parent nodes reflect the total effort of their children (not additional work).
Nesting depth should match the natural structure of the task

Save option: After presenting the breakdown, ask the user whether they want to save the plan as plan.md in the current working directory. If the user agrees, write the breakdown to plan.md.

Guidelines

If the task is unclear or underspecified, ask clarifying questions before producing the breakdown.
Do NOT start implementing. This skill only produces the plan.