kiro-spec-requirements

Name: kiro-spec-requirements
Author: gotalab

3.6kstars271forks

How to install kiro-spec-requirements?

gotalab/cc-sdd/kiro-spec-requirements

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

Installs into the current project.

Summary

Generate comprehensive requirements for a specification

Files · 1

View on GitHub

SKILL.md

1	# Requirements Generation
2
3	<background_information>
4	- Success Criteria:
5	- Create complete requirements document aligned with steering context
6	- Follow the project's EARS patterns and constraints for all acceptance criteria
7	- Focus on core functionality without implementation details
8	- Make inclusion/exclusion boundaries explicit when scope could otherwise be misread
9	- Update metadata to track generation status
10	</background_information>
11
12	<instructions>
13	## Execution Steps
14
15	1. Load Context:
16	- Read `{{KIRO_DIR}}/specs/$1/spec.json` for language and metadata
17	- Read `{{KIRO_DIR}}/specs/$1/brief.md` if it exists (discovery context: problem, approach, scope decisions, boundary candidates)
18	- Read `{{KIRO_DIR}}/specs/$1/requirements.md` for project description
19	- Core steering context: `product.md`, `tech.md`, `structure.md`
20	- Additional steering files only when directly relevant to feature scope, user personas, business/domain rules, compliance/security constraints, operational constraints, or existing product boundaries
21	- Relevant local agent skills or playbooks only when they clearly match the feature's host environment or use case and contain domain terminology or workflow rules that shape user-observable requirements
22
23	2. Read Guidelines:
24	- Read `rules/ears-format.md` from this skill's directory for EARS syntax rules
25	- Read `rules/requirements-review-gate.md` from this skill's directory for pre-write review criteria
26	- Read `{{KIRO_DIR}}/settings/templates/specs/requirements.md` for document structure
27
28	#### Parallel Research (sub-agent dispatch)
29
30	The following research areas are independent. Decide the optimal decomposition based on project complexity -- split, merge, add, or skip sub-agents as needed.
31
32	In main context (essential for requirements generation):
33	- Spec files: spec.json, brief.md, requirements.md (project description)
34	- EARS format rules, requirements review gate, requirements template
35	- Core steering: product.md, tech.md (directly inform scope and constraints)
36
37	Delegate to sub-agent (keeps exploration out of main context):
38	- Codebase hints (brownfield projects): Spawn a sub-agent to explore existing implementations that inform requirement scope. Ask it to summarize: (1) what already exists, (2) relevant interfaces/APIs, (3) patterns that new requirements should align with. Return a summary under 150 lines.
39	- Domain research (when external knowledge is needed): Spawn a sub-agent for web research on domain-specific requirements, standards, or best practices. Return a concise findings summary.
40	- Additional steering and playbooks: If many steering files or local agent playbooks exist, spawn a sub-agent to scan them and return only the sections relevant to this feature.
41
42	For greenfield projects with minimal codebase, skip sub-agent dispatch and load context directly. If multi-agent is not available, execute sequentially in main context.
43
44	After all research completes, synthesize findings in main context before generating requirements.
45
46	3. Generate Requirements Draft:
47	- Create initial requirements draft based on project description
48	- Group related functionality into logical requirement areas
49	- Apply EARS format to all acceptance criteria
50	- Use language specified in spec.json
51	- Preserve terminology continuity across phases:
52	- discovery = `Boundary Candidates`
53	- requirements = explicit inclusion/exclusion and adjacent expectations when needed
54	- design = `Boundary Commitments`
55	- tasks = `_Boundary:_`
56	- If scope could be misread, add lightweight boundary context without introducing implementation or architecture ownership detail
57	- Keep this as a draft until the review gate passes; do not write `requirements.md` yet
58
59	4. Review Requirements Draft:
60	- Run the `Requirements Review Gate` from `rules/requirements-review-gate.md`
61	- Review coverage, EARS compliance, ambiguity, adjacent expectations, and scope boundaries before finalizing
62	- If issues are local to the draft, repair the requirements and review again
63	- Keep the review bounded to at most 2 repair passes
64	- If the draft exposes a real scope ambiguity or contradiction, stop and ask the user to clarify instead of writing guessed requirements
65
66	5. Finalize and Update Metadata:
67	- Write `{{KIRO_DIR}}/specs/$1/requirements.md` only after the requirements review gate passes
68	- Set `phase: "requirements-generated"`
69	- Set `approvals.requirements.generated: true`
70	- Update `updated_at` timestamp
71
72	## Important Constraints
73
74	### Requirements Scope: WHAT, not HOW
75	Requirements describe user-observable behavior, not implementation. Use this to decide what belongs here vs. in design:
76
77	Ask the user about (requirements scope):
78	- Functional scope — what is

People who liked this also viewed

6 picks

Type

kiro-spec-requirements

3.6kstars271forks

View on GitHub

How to install kiro-spec-requirements?

gotalab/cc-sdd/kiro-spec-requirements

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

Installs into the current project.

Summary

Generate comprehensive requirements for a specification

Files · 1

View on GitHub

SKILL.md

1	# Requirements Generation
2
3	<background_information>
4	- Success Criteria:
5	- Create complete requirements document aligned with steering context
6	- Follow the project's EARS patterns and constraints for all acceptance criteria
7	- Focus on core functionality without implementation details
8	- Make inclusion/exclusion boundaries explicit when scope could otherwise be misread
9	- Update metadata to track generation status
10	</background_information>
11
12	<instructions>
13	## Execution Steps
14
15	1. Load Context:
16	- Read `{{KIRO_DIR}}/specs/$1/spec.json` for language and metadata
17	- Read `{{KIRO_DIR}}/specs/$1/brief.md` if it exists (discovery context: problem, approach, scope decisions, boundary candidates)
18	- Read `{{KIRO_DIR}}/specs/$1/requirements.md` for project description
19	- Core steering context: `product.md`, `tech.md`, `structure.md`
20	- Additional steering files only when directly relevant to feature scope, user personas, business/domain rules, compliance/security constraints, operational constraints, or existing product boundaries
21	- Relevant local agent skills or playbooks only when they clearly match the feature's host environment or use case and contain domain terminology or workflow rules that shape user-observable requirements
22
23	2. Read Guidelines:
24	- Read `rules/ears-format.md` from this skill's directory for EARS syntax rules
25	- Read `rules/requirements-review-gate.md` from this skill's directory for pre-write review criteria
26	- Read `{{KIRO_DIR}}/settings/templates/specs/requirements.md` for document structure
27
28	#### Parallel Research (sub-agent dispatch)
29
30	The following research areas are independent. Decide the optimal decomposition based on project complexity -- split, merge, add, or skip sub-agents as needed.
31
32	In main context (essential for requirements generation):
33	- Spec files: spec.json, brief.md, requirements.md (project description)
34	- EARS format rules, requirements review gate, requirements template
35	- Core steering: product.md, tech.md (directly inform scope and constraints)
36
37	Delegate to sub-agent (keeps exploration out of main context):
38	- Codebase hints (brownfield projects): Spawn a sub-agent to explore existing implementations that inform requirement scope. Ask it to summarize: (1) what already exists, (2) relevant interfaces/APIs, (3) patterns that new requirements should align with. Return a summary under 150 lines.
39	- Domain research (when external knowledge is needed): Spawn a sub-agent for web research on domain-specific requirements, standards, or best practices. Return a concise findings summary.
40	- Additional steering and playbooks: If many steering files or local agent playbooks exist, spawn a sub-agent to scan them and return only the sections relevant to this feature.
41
42	For greenfield projects with minimal codebase, skip sub-agent dispatch and load context directly. If multi-agent is not available, execute sequentially in main context.
43
44	After all research completes, synthesize findings in main context before generating requirements.
45
46	3. Generate Requirements Draft:
47	- Create initial requirements draft based on project description
48	- Group related functionality into logical requirement areas
49	- Apply EARS format to all acceptance criteria
50	- Use language specified in spec.json
51	- Preserve terminology continuity across phases:
52	- discovery = `Boundary Candidates`
53	- requirements = explicit inclusion/exclusion and adjacent expectations when needed
54	- design = `Boundary Commitments`
55	- tasks = `_Boundary:_`
56	- If scope could be misread, add lightweight boundary context without introducing implementation or architecture ownership detail
57	- Keep this as a draft until the review gate passes; do not write `requirements.md` yet
58
59	4. Review Requirements Draft:
60	- Run the `Requirements Review Gate` from `rules/requirements-review-gate.md`
61	- Review coverage, EARS compliance, ambiguity, adjacent expectations, and scope boundaries before finalizing
62	- If issues are local to the draft, repair the requirements and review again
63	- Keep the review bounded to at most 2 repair passes
64	- If the draft exposes a real scope ambiguity or contradiction, stop and ask the user to clarify instead of writing guessed requirements
65
66	5. Finalize and Update Metadata:
67	- Write `{{KIRO_DIR}}/specs/$1/requirements.md` only after the requirements review gate passes
68	- Set `phase: "requirements-generated"`
69	- Set `approvals.requirements.generated: true`
70	- Update `updated_at` timestamp
71
72	## Important Constraints
73
74	### Requirements Scope: WHAT, not HOW
75	Requirements describe user-observable behavior, not implementation. Use this to decide what belongs here vs. in design:
76
77	Ask the user about (requirements scope):
78	- Functional scope — what is

People who liked this also viewed

6 picks

Type