kiro-spec-tasks

Name: kiro-spec-tasks
Author: gotalab

3.6kstars271forks

How to install kiro-spec-tasks?

gotalab/cc-sdd/kiro-spec-tasks

$npx -y skills add gotalab/cc-sdd --skill kiro-spec-tasks

Installs into the current project.

Summary

Generate implementation tasks for a specification

Files · 1

View on GitHub

SKILL.md

1	# Implementation Tasks Generator
2
3	<background_information>
4	- Success Criteria:
5	- All requirements mapped to specific tasks
6	- Tasks properly sized (1-3 hours each)
7	- Clear task progression with proper hierarchy
8	- Natural language descriptions focused on capabilities
9	- A lightweight task-plan sanity review confirms the task graph is executable before `tasks.md` is written
10	</background_information>
11
12	<instructions>
13	## Execution Steps
14
15	### Step 1: Load Context
16
17	Read all necessary context:
18	- `{{KIRO_DIR}}/specs/$1/spec.json`, `requirements.md`, `design.md`
19	- `{{KIRO_DIR}}/specs/$1/tasks.md` (if exists, for merge mode)
20	- Core steering context: `product.md`, `tech.md`, `structure.md`
21	- Additional steering files only when directly relevant to requirements coverage, design boundaries, runtime prerequisites, or team conventions that affect task executability
22
23	Validate approvals:
24	- If `-y` flag provided: Auto-approve requirements and design in spec.json. Tasks approval is also handled automatically in Step 4.
25	- Otherwise: Verify both approved (stop if not, see Safety & Fallback)
26	- Determine sequential mode based on presence of `--sequential`
27
28	### Step 2: Generate Implementation Tasks
29
30	Load generation rules and template:
31	- Read `rules/tasks-generation.md` from this skill's directory for principles
32	- If `sequential` is false: Read `rules/tasks-parallel-analysis.md` from this skill's directory for parallel judgement criteria
33	- Read `{{KIRO_DIR}}/settings/templates/specs/tasks.md` for format (supports `(P)` markers)
34
35	#### Parallel Research
36
37	The following research areas are independent and can be executed in parallel:
38	1. Context loading: Spec documents (requirements.md, design.md), steering files
39	2. Rules loading: tasks-generation.md, tasks-parallel-analysis.md, tasks template
40
41	If multi-agent is enabled, spawn sub-agents for each area above. Otherwise execute sequentially.
42
43	After all parallel research completes, synthesize findings before generating tasks.
44
45	Generate task list following all rules:
46	- Use language specified in spec.json
47	- Map all requirements to tasks
48	- When documenting requirement coverage, list numeric requirement IDs only (comma-separated) without descriptive suffixes, parentheses, translations, or free-form labels
49	- Ensure all design components included
50	- Verify task progression is logical and incremental
51	- Ensure each executable sub-task includes at least one detail bullet that states what "done" looks like in observable terms
52	- Keep normal implementation tasks within a single responsibility boundary; if work crosses boundaries, make it an explicit integration task
53	- Collapse single-subtask structures by promoting them to major tasks and avoid duplicating details on container-only major tasks (use template patterns accordingly)
54	- Apply `(P)` markers to tasks that satisfy parallel criteria (omit markers when sequential mode requested)
55	- Mark optional test coverage subtasks with `- [ ]*` only when they strictly cover acceptance criteria already satisfied by core implementation and can be deferred post-MVP
56	- If existing tasks.md found, merge with new content
57
58	### Step 3: Review Task Plan
59
60	- Keep the draft task plan in working memory; do NOT write `tasks.md` yet
61	- Run the `Task Plan Review Gate` from `rules/tasks-generation.md`
62	- Review coverage:
63	- Every requirement ID appears in at least one task
64	- Every design component, contract, integration point, runtime prerequisite, and validation concern is represented
65	- Review executability:
66	- Each sub-task is an executable 1-3 hour work unit
67	- Each sub-task has a verifiable deliverable
68	- Each executable sub-task includes an observable completion bullet
69	- No implicit prerequisites remain hidden
70	- `_Depends:_`, `_Boundary:_`, and `(P)` markers still match the dependency graph and architecture boundaries
71	- If issues are task-plan-local, repair the draft and re-run the review gate before writing
72	- Keep the review bounded to at most 2 repair passes
73	- If review exposes a real requirements/design gap or contradiction, stop and send the user back to requirements/design instead of inventing filler tasks
74
75	### Step 3.5: Run Task-Graph Sanity Review
76
77	Before writing `tasks.md`, run one lightweight independent sanity review of the task graph.
78
79	- If fresh subagent dispatch is available, spawn one fresh review subagent for this step. Otherwise perform the same review in the current context.
80	- Provide only file paths, the draft task plan, and merge context if an existing `tasks.md` is being updated. The reviewer should read `requirements.md`, `design.md`, and the task-generation rules directly instead of relying on a parent-synthesized coverage summary.
81	- Check only:
82	- hidden prerequisites or missing setup tasks
83	- dependency or ordering mistakes
84	- boundary o

People who liked this also viewed

6 picks

Type

kiro-spec-tasks

3.6kstars271forks

View on GitHub

How to install kiro-spec-tasks?

gotalab/cc-sdd/kiro-spec-tasks

$npx -y skills add gotalab/cc-sdd --skill kiro-spec-tasks

Installs into the current project.

Summary

Generate implementation tasks for a specification

Files · 1

View on GitHub

SKILL.md

1	# Implementation Tasks Generator
2
3	<background_information>
4	- Success Criteria:
5	- All requirements mapped to specific tasks
6	- Tasks properly sized (1-3 hours each)
7	- Clear task progression with proper hierarchy
8	- Natural language descriptions focused on capabilities
9	- A lightweight task-plan sanity review confirms the task graph is executable before `tasks.md` is written
10	</background_information>
11
12	<instructions>
13	## Execution Steps
14
15	### Step 1: Load Context
16
17	Read all necessary context:
18	- `{{KIRO_DIR}}/specs/$1/spec.json`, `requirements.md`, `design.md`
19	- `{{KIRO_DIR}}/specs/$1/tasks.md` (if exists, for merge mode)
20	- Core steering context: `product.md`, `tech.md`, `structure.md`
21	- Additional steering files only when directly relevant to requirements coverage, design boundaries, runtime prerequisites, or team conventions that affect task executability
22
23	Validate approvals:
24	- If `-y` flag provided: Auto-approve requirements and design in spec.json. Tasks approval is also handled automatically in Step 4.
25	- Otherwise: Verify both approved (stop if not, see Safety & Fallback)
26	- Determine sequential mode based on presence of `--sequential`
27
28	### Step 2: Generate Implementation Tasks
29
30	Load generation rules and template:
31	- Read `rules/tasks-generation.md` from this skill's directory for principles
32	- If `sequential` is false: Read `rules/tasks-parallel-analysis.md` from this skill's directory for parallel judgement criteria
33	- Read `{{KIRO_DIR}}/settings/templates/specs/tasks.md` for format (supports `(P)` markers)
34
35	#### Parallel Research
36
37	The following research areas are independent and can be executed in parallel:
38	1. Context loading: Spec documents (requirements.md, design.md), steering files
39	2. Rules loading: tasks-generation.md, tasks-parallel-analysis.md, tasks template
40
41	If multi-agent is enabled, spawn sub-agents for each area above. Otherwise execute sequentially.
42
43	After all parallel research completes, synthesize findings before generating tasks.
44
45	Generate task list following all rules:
46	- Use language specified in spec.json
47	- Map all requirements to tasks
48	- When documenting requirement coverage, list numeric requirement IDs only (comma-separated) without descriptive suffixes, parentheses, translations, or free-form labels
49	- Ensure all design components included
50	- Verify task progression is logical and incremental
51	- Ensure each executable sub-task includes at least one detail bullet that states what "done" looks like in observable terms
52	- Keep normal implementation tasks within a single responsibility boundary; if work crosses boundaries, make it an explicit integration task
53	- Collapse single-subtask structures by promoting them to major tasks and avoid duplicating details on container-only major tasks (use template patterns accordingly)
54	- Apply `(P)` markers to tasks that satisfy parallel criteria (omit markers when sequential mode requested)
55	- Mark optional test coverage subtasks with `- [ ]*` only when they strictly cover acceptance criteria already satisfied by core implementation and can be deferred post-MVP
56	- If existing tasks.md found, merge with new content
57
58	### Step 3: Review Task Plan
59
60	- Keep the draft task plan in working memory; do NOT write `tasks.md` yet
61	- Run the `Task Plan Review Gate` from `rules/tasks-generation.md`
62	- Review coverage:
63	- Every requirement ID appears in at least one task
64	- Every design component, contract, integration point, runtime prerequisite, and validation concern is represented
65	- Review executability:
66	- Each sub-task is an executable 1-3 hour work unit
67	- Each sub-task has a verifiable deliverable
68	- Each executable sub-task includes an observable completion bullet
69	- No implicit prerequisites remain hidden
70	- `_Depends:_`, `_Boundary:_`, and `(P)` markers still match the dependency graph and architecture boundaries
71	- If issues are task-plan-local, repair the draft and re-run the review gate before writing
72	- Keep the review bounded to at most 2 repair passes
73	- If review exposes a real requirements/design gap or contradiction, stop and send the user back to requirements/design instead of inventing filler tasks
74
75	### Step 3.5: Run Task-Graph Sanity Review
76
77	Before writing `tasks.md`, run one lightweight independent sanity review of the task graph.
78
79	- If fresh subagent dispatch is available, spawn one fresh review subagent for this step. Otherwise perform the same review in the current context.
80	- Provide only file paths, the draft task plan, and merge context if an existing `tasks.md` is being updated. The reviewer should read `requirements.md`, `design.md`, and the task-generation rules directly instead of relying on a parent-synthesized coverage summary.
81	- Check only:
82	- hidden prerequisites or missing setup tasks
83	- dependency or ordering mistakes
84	- boundary o

People who liked this also viewed

6 picks

Type