From ts-dev-kit
Breaks PRDs into ordered production-ready engineering tasks with embedded success criteria, tests, benchmarks, and non-functional requirements for /execute-task execution. Use for PRD-to-tasks conversion and feature planning as mergeable PRs.
How this skill is triggered — by the user, by Claude, or both
Slash command
/ts-dev-kit:generate-task [prd-file-path | task-without-context | epic-task | big-task][prd-file-path | task-without-context | epic-task | big-task]The summary Claude sees in its skill listing — used to decide when to auto-load this skill
<prd>
<phase_1_read_prd> Read the PRD document fully. Extract and organize:
<phase_2_analyze_codebase> Before decomposing tasks, understand the target project:
<phase_3_identify_implementation_units> Map every PRD requirement to concrete implementation units. An implementation unit is any atomic change: a new schema, a route, a component, a migration, a shared type, a test file, a config entry, an i18n key.
For each unit, identify:
Standard dependency ordering (lower layers before higher):
Orphan-free rule — every consumer of a resource must be in the same task as its producer OR in a later task that explicitly depends on the producer's task:
<phase_4_group_into_tasks> Group implementation units into tasks. Apply these rules in order:
Rule 1 — 30-file limit: a task may create or modify at most 30 files. If a natural group exceeds this, split on domain boundaries (data layer, API layer, UI layer, test layer).
Rule 2 — Production-ready delivery: every task, when merged in order, must leave the application in a runnable state — no broken imports, unresolved references, orphaned i18n keys, or missing migrations.
Rule 3 — Forward dependency only: if TASK_N requires output from TASK_M, then M < N. No task may depend on a later task.
Rule 4 — Mergeable without breaking: use feature flags, graceful degradation, or empty-state handling so earlier tasks don't expose incomplete UX to end users.
Rule 5 — Clear value delivery: each task must deliver a demonstrable increment — a working endpoint, a rendered component, a passing test suite. Avoid tasks with no visible or testable outcome.
Recommended grouping (adapt per feature):
Split tasks at domain boundaries when a group would exceed 30 files. </phase_4_group_into_tasks>
<phase_5_define_verification_criteria> For each task, derive its verification criteria from the PRD. These become binding requirements embedded in the task document and executed by /execute-task.
Success criteria — select PRD acceptance criteria that apply to this task's scope. Write them as testable assertions:
Baseline checks — what to capture BEFORE making changes:
Post-change checks — what to verify AFTER changes, mapped 1:1 to each success criterion.
Performance benchmarks — from PRD NFRs or domain defaults:
Non-functional requirements — scope PRD NFRs to this task's domain:
<phase_6_generate_task_documents> Generate a document for each task using the template from template.md.
Before saving, validate each document:
Fix any violation before saving. </phase_6_generate_task_documents>
Save each task document to: ``` [project-root]/docs/features/[FEATURE_NAME]/TASK_[TASK_NUMBER].md ```After saving all tasks, print a summary table:
| Task | Title | Files | Depends on | Key deliverable |
|---|---|---|---|---|
| TASK_01 | ... | N files | none | ... |
| TASK_02 | ... | N files | TASK_01 | ... |
npx claudepluginhub jgamaraalv/ts-dev-kit --plugin ts-dev-kitGenerates ordered task YAML from PRD markdown file with sequential IDs, dependencies, descriptions, and acceptance criteria. Use after creating or reviewing a PRD for implementation planning.
Breaks a PRD into engineering tasks and hands off to Linear, GitHub Issues, OpenSpec, gstack, Symphony, or markdown. Useful for structured project breakdown and task tracking.
Creates structured implementation task breakdowns from proposal, design, and specification artifacts, outputting self-contained per-task files for subagents.