split-into-tasks

Split implementation-ready specs into independently deliverable vertical tasks with risk-justified review checkpoints.

Updated Sep 17, 2026
One-click install
npx skills add https://github.com/hkw2028/toy-project --skill split-into-tasks-hkw2028
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: split-into-tasks
Source: https://github.com/hkw2028/toy-project/tree/main/.agents/skills/split-into-tasks
Command: npx skills add https://github.com/hkw2028/toy-project --skill split-into-tasks-hkw2028

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Large specs with multiple outcomes are hard to deliver and review as one unit. This Skill turns an approved spec into the fewest independently deliverable vertical tasks, each with observable acceptance criteria, genuine blockers, and only risk-justified review checkpoints. ## Core Features & Use Cases - Outcome-based task splitting: Proposes the fewest independently usable and verifiable outcomes instead of splitting by CRUD actions or technical layers, and keeps a single coherent workflow as the spec itself. - Approval-gated handoff: Presents the complete task map for user approval before writing any task files to docs/specs/<slug>/tasks/ using a structured template. - Revision and supersede handling: Preserves completed task history, marks replaced tasks as superseded with revision evidence, and moves blocker references to approved replacements. - Use Case: Given a spec covering personal todos, collaboration, and reminders, the Skill proposes three vertical tasks with dependency blockers, waits for approval, then writes one task file per deliverable. ## Quick Start Ask the assistant to split the approved spec at docs/specs/<slug>/spec.md into independently deliverable tasks and show the breakdown for approval.

Frequently Asked Questions about split-into-tasks

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

FAQPage Schema
How do I split a spec into tasks for implementation?

Point the Skill at an existing docs/specs/<slug>/spec.md and it proposes the fewest independently deliverable vertical outcomes with acceptance criteria and blockers. It writes task files only after you approve the breakdown.

What makes a good task breakdown for a software spec?

A good breakdown uses the fewest independently usable and verifiable outcomes rather than splitting by CRUD actions or technical layers. Each task states delivered behavior, observable acceptance criteria, focused verification, and genuine blockers with reasons.

Can I split tasks without an existing spec file?

No. The Skill requires docs/specs/<slug>/spec.md to exist and stops if it is missing, asking for an implementation-ready spec instead of inventing a breakdown from conversation alone.

When should a task breakdown include review checkpoints?

Add an intermediate review checkpoint only when a material error could compound through dependent work or when deterministic checks cannot settle risks like security, permissions, migrations, or external contracts. Low-risk boundaries verified by automated tests need no checkpoint.

What happens to completed tasks when the breakdown is revised?

Tasks with recorded completion history are preserved and marked superseded with revision evidence naming the replacement and reason. Unfinished replaced tasks are removed, and dependent blockers move to the replacement task.

Why does the task breakdown omit files and function names?

Implementation derives the technical approach just in time from the current repository, so task files record outcomes, constraints, and verification rather than predicted files, functions, code structure, or internal sequences.