generate-task

Name: generate-task
Author: jgamaraalv

9installs0forks

How to install generate-task?

jgamaraalv/ts-dev-kit/generate-task

$npx -y skills add jgamaraalv/ts-dev-kit --skill generate-task

Installs into the current project.

Summary

Breaks a PRD into ordered, production-ready engineering tasks ready for execution by /execute-task. Use when: (1) converting a PRD document into executable engineering tasks, (2) planning feature delivery as a sequence of mergeable, self-contained pull requests, (3) the user says

Files · 1

View on GitHub

SKILL.md

1	<prd>
2	$ARGUMENTS
3	</prd>
4
5	<workflow>
6	Follow each phase in order.
7
8	<phase_1_read_prd>
9	Read the PRD document fully. Extract and organize:
10	- Functional requirements — numbered, atomic conditions
11	- Acceptance criteria — how feature completion is verified
12	- Non-functional requirements — performance, security, accessibility, scalability targets
13	- Scope — what is included and what is explicitly excluded
14	- User journeys — key flows and their steps
15	- Success metrics and KPIs
16	</phase_1_read_prd>
17
18	<phase_2_analyze_codebase>
19	Before decomposing tasks, understand the target project:
20	1. Read CLAUDE.md and root package.json — project structure, package manager, tech stack, key directories.
21	2. Identify where implementation units live — backend routes, frontend pages, shared types, database schemas, tests.
22	3. Search for patterns similar to the feature being built — use Grep/Glob to find related files and establish co-location conventions.
23	4. List the domain areas the feature touches — database, API, shared, frontend, tests, config.
24	</phase_2_analyze_codebase>
25
26	<phase_3_identify_implementation_units>
27	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.
28
29	For each unit, identify:
30	- File path (exact, following codebase conventions)
31	- Action: create or modify
32	- Domain: database \| api \| shared \| frontend \| test \| config \| docs
33	- Dependencies: which other units must exist first
34
35	Standard dependency ordering (lower layers before higher):
36	1. Shared types, constants, i18n keys, env variables
37	2. Database migrations and schema updates
38	3. API routes, handlers, validation schemas
39	4. Shared hooks, utilities, helper functions
40	5. UI components (atoms → molecules → organisms)
41	6. Pages and routes composing components
42	7. Tests (unit, integration, E2E)
43	8. Config and infrastructure changes
44	9. Documentation updates
45
46	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:
47	- New i18n key + every component using that key → same task (or key in TASK_N, component in TASK_M where M > N and TASK_M depends on TASK_N)
48	- New database column + migration that adds it → same task
49	- New shared type + every immediate consumer → same task
50	- New component + the page that renders it → same task (unless page is intentionally deferred to a later task)
51	</phase_3_identify_implementation_units>
52
53	<phase_4_group_into_tasks>
54	Group implementation units into tasks. Apply these rules in order:
55
56	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).
57
58	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.
59
60	Rule 3 — Forward dependency only: if TASK_N requires output from TASK_M, then M < N. No task may depend on a later task.
61
62	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.
63
64	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.
65
66	Recommended grouping (adapt per feature):
67	1. Foundation — shared types, constants, i18n keys, env variables
68	2. Data layer — database schema, migrations, ORM models
69	3. API layer — routes, handlers, validation schemas, error codes
70	4. Core UI — reusable components, hooks, state management
71	5. Feature pages — pages and routes composing the core UI
72	6. Tests & polish — comprehensive test suites, accessibility audit, performance tuning
73	7. Documentation — CLAUDE.md updates, API docs, migration guides
74
75	Split tasks at domain boundaries when a group would exceed 30 files.
76	</phase_4_group_into_tasks>
77
78	<phase_5_define_verification_criteria>
79	For each task, derive its verification criteria from the PRD. These become

People who liked this also viewed

6 picks

Type

generate-task

9installs0forks

View on GitHub

How to install generate-task?

jgamaraalv/ts-dev-kit/generate-task

$npx -y skills add jgamaraalv/ts-dev-kit --skill generate-task

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	<prd>
2	$ARGUMENTS
3	</prd>
4
5	<workflow>
6	Follow each phase in order.
7
8	<phase_1_read_prd>
9	Read the PRD document fully. Extract and organize:
10	- Functional requirements — numbered, atomic conditions
11	- Acceptance criteria — how feature completion is verified
12	- Non-functional requirements — performance, security, accessibility, scalability targets
13	- Scope — what is included and what is explicitly excluded
14	- User journeys — key flows and their steps
15	- Success metrics and KPIs
16	</phase_1_read_prd>
17
18	<phase_2_analyze_codebase>
19	Before decomposing tasks, understand the target project:
20	1. Read CLAUDE.md and root package.json — project structure, package manager, tech stack, key directories.
21	2. Identify where implementation units live — backend routes, frontend pages, shared types, database schemas, tests.
22	3. Search for patterns similar to the feature being built — use Grep/Glob to find related files and establish co-location conventions.
23	4. List the domain areas the feature touches — database, API, shared, frontend, tests, config.
24	</phase_2_analyze_codebase>
25
26	<phase_3_identify_implementation_units>
27	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.
28
29	For each unit, identify:
30	- File path (exact, following codebase conventions)
31	- Action: create or modify
32	- Domain: database \| api \| shared \| frontend \| test \| config \| docs
33	- Dependencies: which other units must exist first
34
35	Standard dependency ordering (lower layers before higher):
36	1. Shared types, constants, i18n keys, env variables
37	2. Database migrations and schema updates
38	3. API routes, handlers, validation schemas
39	4. Shared hooks, utilities, helper functions
40	5. UI components (atoms → molecules → organisms)
41	6. Pages and routes composing components
42	7. Tests (unit, integration, E2E)
43	8. Config and infrastructure changes
44	9. Documentation updates
45
46	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:
47	- New i18n key + every component using that key → same task (or key in TASK_N, component in TASK_M where M > N and TASK_M depends on TASK_N)
48	- New database column + migration that adds it → same task
49	- New shared type + every immediate consumer → same task
50	- New component + the page that renders it → same task (unless page is intentionally deferred to a later task)
51	</phase_3_identify_implementation_units>
52
53	<phase_4_group_into_tasks>
54	Group implementation units into tasks. Apply these rules in order:
55
56	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).
57
58	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.
59
60	Rule 3 — Forward dependency only: if TASK_N requires output from TASK_M, then M < N. No task may depend on a later task.
61
62	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.
63
64	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.
65
66	Recommended grouping (adapt per feature):
67	1. Foundation — shared types, constants, i18n keys, env variables
68	2. Data layer — database schema, migrations, ORM models
69	3. API layer — routes, handlers, validation schemas, error codes
70	4. Core UI — reusable components, hooks, state management
71	5. Feature pages — pages and routes composing the core UI
72	6. Tests & polish — comprehensive test suites, accessibility audit, performance tuning
73	7. Documentation — CLAUDE.md updates, API docs, migration guides
74
75	Split tasks at domain boundaries when a group would exceed 30 files.
76	</phase_4_group_into_tasks>
77
78	<phase_5_define_verification_criteria>
79	For each task, derive its verification criteria from the PRD. These become

People who liked this also viewed

6 picks

Type