Skip to content

Commit 8e2e853

Browse files
gotalabgotalab
authored
Merge pull request #56 from gotalab/feature/context-replace
refactor: reorganize cc-sdd templates by OS and add Gemini CLI support
2 parents 4e5d7f2 + 962acc6 commit 8e2e853

File tree

116 files changed

+8391
-7159
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

116 files changed

+8391
-7159
lines changed

‎.claude/commands/kiro/spec-impl.md‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
---
22
description: Execute spec tasks using TDD methodology
3-
allowed-tools: Bash, Read, Write, Edit, MultiEdit, Grep, Glob, LS, WebFetch
3+
allowed-tools: Bash, Read, Write, Edit, MultiEdit, Grep, Glob, LS, WebFetch, WebSearch
44
argument-hint: <feature-name> [task-numbers]
55
---
66

‎.claude/commands/kiro/spec-requirements.md‎

Lines changed: 19 additions & 18 deletions
Original file line numberDiff line numberDiff line change
@@ -29,27 +29,28 @@ Read the existing requirements.md file created by spec-init to extract the proje
2929
### 2. Generate Complete Requirements
3030
Generate an initial set of requirements in EARS format based on the project description, then iterate with the user to refine them until they are complete and accurate.
3131

32-
Don't focus on code exploration in this phase. Instead, just focus on writing requirements which will later be turned into a design.
32+
Don't focus on implementation details in this phase. Instead, just focus on writing requirements which will later be turned into a design.
3333

3434
### Requirements Generation Guidelines
3535
1. **Focus on Core Functionality**: Start with the essential features from the user's idea
3636
2. **Use EARS Format**: All acceptance criteria must use proper EARS syntax
3737
3. **No Sequential Questions**: Generate initial version first, then iterate based on user feedback
3838
4. **Keep It Manageable**: Create a solid foundation that can be expanded through user review
39+
5. **Choose an appropriate subject**: For software projects, use the concrete system/service name (e.g., "Checkout Service"). For non-software, select a responsible subject (e.g., process/workflow, team/role, artifact/document, campaign, protocol).
3940

4041
### 3. EARS Format Requirements
4142

42-
**EARS (Easy Approach to Requirements Syntax)** is the mandatory format for acceptance criteria:
43+
**EARS (Easy Approach to Requirements Syntax)** is the recommended format for acceptance criteria:
4344

4445
**Primary EARS Patterns:**
45-
- WHEN [event/condition] THEN [system] SHALL [response]
46-
- IF [precondition/state] THEN [system] SHALL [response]
47-
- WHILE [ongoing condition] THE [system] SHALL [continuous behavior]
48-
- WHERE [location/context/trigger] THE [system] SHALL [contextual behavior]
46+
- WHEN [event/condition] THEN [system/subject] SHALL [response]
47+
- IF [precondition/state] THEN [system/subject] SHALL [response]
48+
- WHILE [ongoing condition] THE [system/subject] SHALL [continuous behavior]
49+
- WHERE [location/context/trigger] THE [system/subject] SHALL [contextual behavior]
4950

5051
**Combined Patterns:**
51-
- WHEN [event] AND [additional condition] THEN [system] SHALL [response]
52-
- IF [condition] AND [additional condition] THEN [system] SHALL [response]
52+
- WHEN [event] AND [additional condition] THEN [system/subject] SHALL [response]
53+
- IF [condition] AND [additional condition] THEN [system/subject] SHALL [response]
5354

5455
### 4. Requirements Document Structure
5556
Update requirements.md with complete content in the language specified in spec.json (check `.kiro/specs/$1/spec.json` for "language" field):
@@ -62,22 +63,22 @@ Update requirements.md with complete content in the language specified in spec.j
6263

6364
## Requirements
6465

65-
### Requirement 1: [Major Feature Area]
66-
**User Story:** As a [role], I want [feature], so that [benefit]
66+
### Requirement 1: [Major Objective Area]
67+
**Objective:** As a [role/stakeholder], I want [feature/capability/outcome], so that [benefit]
6768

6869
#### Acceptance Criteria
6970
This section should have EARS requirements
7071

71-
1. WHEN [event] THEN [system] SHALL [response]
72-
2. IF [precondition] THEN [system] SHALL [response]
73-
3. WHILE [ongoing condition] THE [system] SHALL [continuous behavior]
74-
4. WHERE [location/context/trigger] THE [system] SHALL [contextual behavior]
72+
1. WHEN [event] THEN [system/subject] SHALL [response]
73+
2. IF [precondition] THEN [system/subject] SHALL [response]
74+
3. WHILE [ongoing condition] THE [system/subject] SHALL [continuous behavior]
75+
4. WHERE [location/context/trigger] THE [system/subject] SHALL [contextual behavior]
7576

76-
### Requirement 2: [Next Major Feature Area]
77-
**User Story:** As a [role], I want [feature], so that [benefit]
77+
### Requirement 2: [Next Major Objective Area]
78+
**Objective:** As a [role/stakeholder], I want [feature/capability/outcome], so that [benefit]
7879

79-
1. WHEN [event] THEN [system] SHALL [response]
80-
2. WHEN [event] AND [condition] THEN [system] SHALL [response]
80+
1. WHEN [event] THEN [system/subject] SHALL [response]
81+
2. WHEN [event] AND [condition] THEN [system/subject] SHALL [response]
8182

8283
### Requirement 3: [Additional Major Areas]
8384
[Continue pattern for all major functional areas]

‎.claude/commands/kiro/spec-tasks.md‎

Lines changed: 21 additions & 21 deletions
Original file line numberDiff line numberDiff line change
@@ -39,17 +39,17 @@ Generate detailed implementation tasks for feature: **$1**
3939
- Format exactly as:
4040
```markdown
4141
- [ ] 1. Major task description
42-
- [ ] 1.1 Sub-task description
43-
- Detail item 1
44-
- Detail item 2
45-
- _Requirements: X.X, Y.Y_
42+
- [ ] 1.1 Sub-task description
43+
- Detail item 1
44+
- Detail item 2
45+
- _Requirements: X.X, Y.Y_
4646

47-
- [ ] 1.2 Sub-task description
48-
- Detail items...
49-
- _Requirements: X.X_
47+
- [ ] 1.2 Sub-task description
48+
- Detail items...
49+
- _Requirements: X.X_
5050

5151
- [ ] 2. Next major task (NOT 1 again!)
52-
- [ ] 2.1 Sub-task...
52+
- [ ] 2.1 Sub-task...
5353
```
5454

5555
### Task Generation Rules
@@ -89,19 +89,19 @@ Generate detailed implementation tasks for feature: **$1**
8989
- _Requirements: All requirements need foundational setup_
9090

9191
- [ ] 2. Build authentication and user management system
92-
- [ ] 2.1 Implement core authentication functionality
93-
- Set up user data storage with validation rules
94-
- Implement secure authentication mechanism
95-
- Build user registration functionality
96-
- Add login and session management features
97-
- _Requirements: 7.1, 7.2_
98-
99-
- [ ] 2.2 Enable email service integration
100-
- Implement secure credential storage system
101-
- Build authentication flow for email providers
102-
- Create email connection validation logic
103-
- Develop email account management features
104-
- _Requirements: 5.1, 5.2, 5.4_
92+
- [ ] 2.1 Implement core authentication functionality
93+
- Set up user data storage with validation rules
94+
- Implement secure authentication mechanism
95+
- Build user registration functionality
96+
- Add login and session management features
97+
- _Requirements: 7.1, 7.2_
98+
99+
- [ ] 2.2 Enable email service integration
100+
- Implement secure credential storage system
101+
- Build authentication flow for email providers
102+
- Create email connection validation logic
103+
- Develop email account management features
104+
- _Requirements: 5.1, 5.2, 5.4_
105105
```
106106

107107
### Requirements Coverage Check

‎.claude/commands/kiro/validate-design.md‎

Lines changed: 180 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,180 @@
1+
---
2+
description: Interactive technical design quality review and validation
3+
allowed-tools: Bash, Glob, Grep, Read, Task, WebFetch, WebSearch
4+
argument-hint: <feature-name>
5+
---
6+
7+
# Technical Design Validation
8+
9+
Interactive design quality review for feature: **$1**
10+
11+
## Context Loading
12+
13+
### Prerequisites Validation
14+
- Design document must exist: `.kiro/specs/$1/design.md`
15+
- If not exist, stop with message: "Run `/kiro:spec-design $1` first to generate design document"
16+
17+
### Review Context
18+
- Spec metadata: @.kiro/specs/$1/spec.json
19+
- Requirements document: @.kiro/specs/$1/requirements.md
20+
- Design document: @.kiro/specs/$1/design.md
21+
- Core steering documents:
22+
- Architecture: @.kiro/steering/structure.md
23+
- Technology: @.kiro/steering/tech.md
24+
- Product context: @.kiro/steering/product.md
25+
- Custom steering: All additional `.md` files in `.kiro/steering/` directory
26+
27+
## Task: Interactive Design Quality Review
28+
29+
### Review Methodology
30+
31+
**Focus**: Critical issues only - limit to 3 most important concerns
32+
**Format**: Interactive dialogue with immediate feedback and improvement suggestions
33+
**Outcome**: GO/NO-GO decision with clear rationale
34+
35+
### Core Review Criteria
36+
37+
#### 1. Existing Architecture Alignment (Critical)
38+
**Evaluation Points**:
39+
- Integration with existing system boundaries and layers
40+
- Consistency with established architectural patterns
41+
- Proper dependency direction and coupling management
42+
- Alignment with current module organization and responsibilities
43+
44+
**Review Questions**:
45+
- Does this design respect existing architectural boundaries?
46+
- Are new components properly integrated with existing systems?
47+
- Does the design follow established patterns and conventions?
48+
49+
#### 2. Design Consistency & Standards
50+
**Evaluation Points**:
51+
- Adherence to project naming conventions and code standards
52+
- Consistent error handling and logging strategies
53+
- Uniform approach to configuration and dependency management
54+
- Alignment with established data modeling patterns
55+
56+
**Review Questions**:
57+
- Is the design consistent with existing code standards?
58+
- Are error handling and configuration approaches unified?
59+
- Does naming and structure follow project conventions?
60+
61+
#### 3. Extensibility & Maintainability
62+
**Evaluation Points**:
63+
- Design flexibility for future requirements changes
64+
- Clear separation of concerns and single responsibility principle
65+
- Testability and debugging considerations
66+
- Documentation and code clarity requirements
67+
68+
**Review Questions**:
69+
- How well does this design handle future changes?
70+
- Are responsibilities clearly separated and testable?
71+
- Is the design complexity appropriate for the requirements?
72+
73+
#### 4. Type Safety & Interface Design
74+
**Evaluation Points** (for TypeScript projects):
75+
- Proper type definitions and interface contracts
76+
- Avoidance of `any` types and unsafe patterns
77+
- Clear API boundaries and data structure definitions
78+
- Input validation and error handling coverage
79+
80+
**Review Questions**:
81+
- Are types properly defined and interfaces clear?
82+
- Is the API design robust and well-defined?
83+
- Are edge cases and error conditions handled appropriately?
84+
85+
### Interactive Review Process
86+
87+
#### Step 1: Design Analysis
88+
Thoroughly analyze the design document against all review criteria, identifying the most critical issues that could impact:
89+
- System integration and compatibility
90+
- Long-term maintainability
91+
- Implementation complexity and risks
92+
- Requirements fulfillment accuracy
93+
94+
#### Step 2: Critical Issues Identification
95+
**Limit to 3 most important concerns maximum**. For each critical issue:
96+
97+
**Issue Format**:
98+
```
99+
🔴 **Critical Issue [1-3]**: [Brief title]
100+
**Concern**: [Specific problem description]
101+
**Impact**: [Why this matters for the project]
102+
**Suggestion**: [Concrete improvement recommendation]
103+
```
104+
105+
#### Step 3: Design Strengths Recognition
106+
Acknowledge 1-2 strong aspects of the design to maintain balanced feedback.
107+
108+
#### Step 4: GO/NO-GO Decision
109+
110+
**GO Criteria**:
111+
- No critical architectural misalignment
112+
- Requirements adequately addressed
113+
- Implementation path is clear and reasonable
114+
- Risks are acceptable and manageable
115+
116+
**NO-GO Criteria**:
117+
- Fundamental architectural conflicts
118+
- Critical requirements not addressed
119+
- Implementation approach has high failure risk
120+
- Design complexity disproportionate to requirements
121+
122+
### Output Format
123+
124+
Generate review in the language specified in spec.json (check `.kiro/specs/$1/spec.json` for "language" field):
125+
126+
#### Design Review Summary
127+
Brief overview of the design's overall quality and readiness.
128+
129+
#### Critical Issues (Maximum 3)
130+
For each issue identified:
131+
- **Issue**: Clear problem statement
132+
- **Impact**: Why it matters
133+
- **Recommendation**: Specific improvement suggestion
134+
135+
#### Design Strengths
136+
1-2 positive aspects worth highlighting.
137+
138+
#### Final Assessment
139+
**Decision**: GO / NO-GO
140+
**Rationale**: Clear reasoning for the decision
141+
**Next Steps**: What should happen next
142+
143+
#### Interactive Discussion
144+
Engage in dialogue about:
145+
- Designer's perspective on identified issues
146+
- Alternative approaches or trade-offs
147+
- Clarification of design decisions
148+
- Agreement on necessary changes (if any)
149+
150+
## Review Guidelines
151+
152+
1. **Critical Focus**: Only flag issues that significantly impact success
153+
2. **Constructive Tone**: Provide solutions, not just criticism
154+
3. **Interactive Approach**: Engage in dialogue rather than one-way evaluation
155+
4. **Balanced Assessment**: Recognize both strengths and weaknesses
156+
5. **Clear Decision**: Make definitive GO/NO-GO recommendation
157+
6. **Actionable Feedback**: Ensure all suggestions are implementable
158+
159+
## Instructions
160+
161+
1. **Load all context documents** - Understand full project scope
162+
2. **Analyze design thoroughly** - Review against all criteria
163+
3. **Identify critical issues only** - Focus on most important problems
164+
4. **Engage interactively** - Discuss findings with user
165+
5. **Make clear decision** - Provide definitive GO/NO-GO
166+
6. **Guide next steps** - Clear direction for proceeding
167+
168+
**Remember**: This is quality assurance, not perfection seeking. The goal is ensuring the design is solid enough to proceed to implementation with acceptable risk.
169+
170+
---
171+
172+
## Next Phase: Task Generation
173+
174+
After design validation:
175+
176+
**If design passes validation (GO decision):**
177+
Run `/kiro:spec-tasks $1` to generate implementation tasks
178+
179+
**Auto-approve and proceed:**
180+
Run `/kiro:spec-tasks $1 -y` to auto-approve requirements and design, then generate tasks directly

0 commit comments

Comments
 (0)