Skip to content

Commit 1de3ea9

Browse files
kbwokbwo
authored
Merge pull request #108 from kbwo/refactor/effect-2025.10.05--feawture/spinner
use Effect TS and improve loading handler
2 parents b8302c2 + 646acf5 commit 1de3ea9

File tree

73 files changed

+14625
-1942
lines changed

Some content is hidden

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

73 files changed

+14625
-1942
lines changed

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

Lines changed: 459 additions & 0 deletions
Large diffs are not rendered by default.

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

Lines changed: 62 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,62 @@
1+
---
2+
description: Execute spec tasks using TDD methodology
3+
allowed-tools: Bash, Read, Write, Edit, MultiEdit, Grep, Glob, LS, WebFetch, WebSearch
4+
argument-hint: <feature-name> [task-numbers]
5+
---
6+
7+
# Execute Spec Tasks with TDD
8+
9+
Execute implementation tasks for **$1** using Kent Beck's Test-Driven Development methodology.
10+
11+
## Instructions
12+
13+
### Pre-Execution Validation
14+
Validate required files exist for feature **$1**:
15+
- Requirements: `.kiro/specs/$1/requirements.md`
16+
- Design: `.kiro/specs/$1/design.md`
17+
- Tasks: `.kiro/specs/$1/tasks.md`
18+
- Metadata: `.kiro/specs/$1/spec.json`
19+
20+
### Context Loading
21+
22+
**Core Steering:**
23+
- Structure: @.kiro/steering/structure.md
24+
- Tech Stack: @.kiro/steering/tech.md
25+
- Product: @.kiro/steering/product.md
26+
27+
**Custom Steering:**
28+
- Additional `*.md` files in `.kiro/steering/` (excluding structure.md, tech.md, product.md)
29+
30+
**Spec Documents for $1:**
31+
- Metadata: @.kiro/specs/$1/spec.json
32+
- Requirements: @.kiro/specs/$1/requirements.md
33+
- Design: @.kiro/specs/$1/design.md
34+
- Tasks: @.kiro/specs/$1/tasks.md
35+
36+
### Task Execution
37+
1. **Feature**: $1
38+
2. **Task numbers**: $2 (optional, defaults to all pending tasks)
39+
3. **Load all context** (steering + spec documents)
40+
4. **Execute selected tasks** using TDD methodology
41+
42+
### TDD Implementation
43+
For each selected task:
44+
45+
1. **RED**: Write failing tests first
46+
2. **GREEN**: Write minimal code to pass tests
47+
3. **REFACTOR**: Clean up and improve code structure
48+
4. **Verify**:
49+
- All tests pass
50+
- No regressions in existing tests
51+
- Code quality and test coverage maintained
52+
5. **Mark Complete**: Update checkbox from `- [ ]` to `- [x]` in tasks.md
53+
54+
**Note**: Follow Kent Beck's TDD methodology strictly, implementing only the specific task requirements.
55+
56+
## Implementation Notes
57+
58+
- **Feature**: Use `$1` for feature name
59+
- **Tasks**: Use `$2` for specific task numbers (optional)
60+
- **Validation**: Check all required spec files exist
61+
- **TDD Focus**: Always write tests before implementation
62+
- **Task Tracking**: Update checkboxes in tasks.md as completed

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

Lines changed: 86 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,86 @@
1+
---
2+
description: Initialize a new specification with detailed project description and requirements
3+
allowed-tools: Bash, Read, Write, Glob
4+
argument-hint: <project-description>
5+
---
6+
7+
# Spec Initialization
8+
9+
Initialize a new specification based on the provided project description:
10+
11+
**Project Description**: $ARGUMENTS
12+
13+
## Task: Initialize Specification Structure
14+
15+
**SCOPE**: This command initializes the directory structure and metadata based on the detailed project description provided.
16+
17+
### 1. Generate Feature Name
18+
Create a concise, descriptive feature name from the project description ($ARGUMENTS).
19+
**Check existing `.kiro/specs/` directory to ensure the generated feature name is unique. If a conflict exists, append a number suffix (e.g., feature-name-2).**
20+
21+
### 2. Create Spec Directory
22+
Create `.kiro/specs/[generated-feature-name]/` directory with:
23+
- `spec.json` - Metadata and approval tracking
24+
- `requirements.md` - Lightweight template with project description
25+
26+
**Note**: design.md and tasks.md will be created by their respective commands during the development process.
27+
28+
### 3. Initialize spec.json Metadata
29+
Create initial metadata with approval tracking:
30+
```json
31+
{
32+
"feature_name": "[generated-feature-name]",
33+
"created_at": "current_timestamp",
34+
"updated_at": "current_timestamp",
35+
"language": "en",
36+
"phase": "initialized",
37+
"approvals": {
38+
"requirements": {
39+
"generated": false,
40+
"approved": false
41+
},
42+
"design": {
43+
"generated": false,
44+
"approved": false
45+
},
46+
"tasks": {
47+
"generated": false,
48+
"approved": false
49+
}
50+
},
51+
"ready_for_implementation": false
52+
}
53+
```
54+
55+
### 4. Create Requirements Template
56+
Create requirements.md with project description:
57+
```markdown
58+
# Requirements Document
59+
60+
## Project Description (Input)
61+
$ARGUMENTS
62+
63+
## Requirements
64+
<!-- Will be generated in /kiro:spec-requirements phase -->
65+
```
66+
67+
### 5. Update CLAUDE.md Reference
68+
Add the new spec to the active specifications list with the generated feature name and a brief description.
69+
70+
## Next Steps After Initialization
71+
72+
Follow the strict spec-driven development workflow:
73+
1. **`/kiro:spec-requirements <feature-name>`** - Create and generate requirements.md
74+
2. **`/kiro:spec-design <feature-name>`** - Create and generate design.md (requires approved requirements)
75+
3. **`/kiro:spec-tasks <feature-name>`** - Create and generate tasks.md (requires approved design)
76+
77+
**Important**: Each phase creates its respective file and requires approval before proceeding to the next phase.
78+
79+
## Output Format
80+
81+
After initialization, provide:
82+
1. Generated feature name and rationale
83+
2. Brief project summary
84+
3. Created spec.json path
85+
4. **Clear next step**: `/kiro:spec-requirements <feature-name>`
86+
5. Explanation that only spec.json was created, following stage-by-stage development principles

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

Lines changed: 130 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,130 @@
1+
---
2+
description: Generate comprehensive requirements for a specification
3+
allowed-tools: Bash, Glob, Grep, LS, Read, Write, Edit, MultiEdit, Update, WebSearch, WebFetch
4+
argument-hint: <feature-name>
5+
---
6+
7+
# Requirements Generation
8+
9+
Generate comprehensive requirements for feature: **$1**
10+
11+
## Context Validation
12+
13+
### Steering Context
14+
- Architecture context: @.kiro/steering/structure.md
15+
- Technical constraints: @.kiro/steering/tech.md
16+
- Product context: @.kiro/steering/product.md
17+
- Custom steering: Load all "Always" mode custom steering files from .kiro/steering/
18+
19+
### Existing Spec Context
20+
- Current spec directory: !`bash -c 'ls -la .kiro/specs/$1/'`
21+
- Current requirements: `.kiro/specs/$1/requirements.md`
22+
- Spec metadata: `.kiro/specs/$1/spec.json`
23+
24+
## Task: Generate Initial Requirements
25+
26+
### 1. Read Existing Requirements Template
27+
Read the existing requirements.md file created by spec-init to extract the project description.
28+
29+
### 2. Generate Complete Requirements
30+
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.
31+
32+
Don't focus on implementation details in this phase. Instead, just focus on writing requirements which will later be turned into a design.
33+
34+
### Requirements Generation Guidelines
35+
1. **Focus on Core Functionality**: Start with the essential features from the user's idea
36+
2. **Use EARS Format**: All acceptance criteria must use proper EARS syntax
37+
3. **No Sequential Questions**: Generate initial version first, then iterate based on user feedback
38+
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") instead of a generic subject. For non-software, choose a responsible subject (e.g., process/workflow, team/role, artifact/document, campaign, protocol).
40+
41+
### 3. EARS Format Requirements
42+
43+
**EARS (Easy Approach to Requirements Syntax)** is the recommended format for acceptance criteria:
44+
45+
**Primary EARS Patterns:**
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]
50+
51+
**Combined Patterns:**
52+
- WHEN [event] AND [additional condition] THEN [system/subject] SHALL [response]
53+
- IF [condition] AND [additional condition] THEN [system/subject] SHALL [response]
54+
55+
### 4. Requirements Document Structure
56+
Update requirements.md with complete content in the language specified in spec.json (check `.kiro/specs/$1/spec.json` for "language" field):
57+
58+
```markdown
59+
# Requirements Document
60+
61+
## Introduction
62+
[Clear introduction summarizing the feature and its business value]
63+
64+
## Requirements
65+
66+
### Requirement 1: [Major Objective Area]
67+
**Objective:** As a [role/stakeholder], I want [feature/capability/outcome], so that [benefit]
68+
69+
#### Acceptance Criteria
70+
This section should have EARS requirements
71+
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]
76+
77+
### Requirement 2: [Next Major Objective Area]
78+
**Objective:** As a [role/stakeholder], I want [feature/capability/outcome], so that [benefit]
79+
80+
1. WHEN [event] THEN [system/subject] SHALL [response]
81+
2. WHEN [event] AND [condition] THEN [system/subject] SHALL [response]
82+
83+
### Requirement 3: [Additional Major Areas]
84+
[Continue pattern for all major functional areas]
85+
```
86+
87+
### 5. Update Metadata
88+
Update spec.json with:
89+
```json
90+
{
91+
"phase": "requirements-generated",
92+
"approvals": {
93+
"requirements": {
94+
"generated": true,
95+
"approved": false
96+
}
97+
},
98+
"updated_at": "current_timestamp"
99+
}
100+
```
101+
102+
### 6. Document Generation Only
103+
Generate the requirements document content ONLY. Do not include any review or approval instructions in the actual document file.
104+
105+
---
106+
107+
## Next Phase: Interactive Approval
108+
109+
After generating requirements.md, review the requirements and choose:
110+
111+
**If requirements look good:**
112+
Run `/kiro:spec-design $1 -y` to proceed to design phase
113+
114+
**If requirements need modification:**
115+
Request changes, then re-run this command after modifications
116+
117+
The `-y` flag auto-approves requirements and generates design directly, streamlining the workflow while maintaining review enforcement.
118+
119+
## Instructions
120+
121+
1. **Check spec.json for language** - Use the language specified in the metadata
122+
2. **Generate initial requirements** based on the feature idea WITHOUT asking sequential questions first
123+
3. **Apply EARS format** - Use proper EARS syntax patterns for all acceptance criteria
124+
4. **Focus on core functionality** - Start with essential features and user workflows
125+
5. **Structure clearly** - Group related functionality into logical requirement areas
126+
6. **Make requirements testable** - Each acceptance criterion should be verifiable
127+
7. **Update tracking metadata** upon completion
128+
129+
Generate requirements that provide a solid foundation for the design phase, focusing on the core functionality from the feature idea.
130+
think

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

Lines changed: 97 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,97 @@
1+
---
2+
description: Show specification status and progress
3+
allowed-tools: Bash, Read, Glob, Write, Edit, MultiEdit, Update
4+
argument-hint: <feature-name>
5+
---
6+
7+
# Specification Status
8+
9+
Show current status and progress for feature: **$1**
10+
11+
## Spec Context
12+
13+
### Spec Files
14+
- Spec directory: !`bash -c 'ls -la .kiro/specs/$1/ 2>/dev/null || echo "No spec directory found"'`
15+
- Spec metadata: `.kiro/specs/$1/spec.json`
16+
- Requirements: `.kiro/specs/$1/requirements.md`
17+
- Design: `.kiro/specs/$1/design.md`
18+
- Tasks: `.kiro/specs/$1/tasks.md`
19+
20+
### All Specs Overview
21+
- Available specs: !`bash -c 'ls -la .kiro/specs/ 2>/dev/null || echo "No specs directory found"'`
22+
- Active specs: !`bash -c 'find .kiro/specs/ -name "spec.json" -exec grep -l "implementation_ready.*true" {} \; 2>/dev/null || echo "No active specs"'`
23+
24+
## Task: Generate Status Report
25+
26+
Create comprehensive status report for the specification in the language specified in spec.json (check `.kiro/specs/$1/spec.json` for "language" field):
27+
28+
### 1. Specification Overview
29+
Display:
30+
- Feature name and description
31+
- Creation date and last update
32+
- Current phase (requirements/design/tasks/implementation)
33+
- Overall completion percentage
34+
35+
### 2. Phase Status
36+
For each phase, show:
37+
- ✅ **Requirements Phase**: [completion %]
38+
- Requirements count: [number]
39+
- Acceptance criteria defined: [yes/no]
40+
- Requirements coverage: [complete/partial/missing]
41+
42+
- ✅ **Design Phase**: [completion %]
43+
- Architecture documented: [yes/no]
44+
- Components defined: [yes/no]
45+
- Diagrams created: [yes/no]
46+
- Integration planned: [yes/no]
47+
48+
- ✅ **Tasks Phase**: [completion %]
49+
- Total tasks: [number]
50+
- Completed tasks: [number]
51+
- Remaining tasks: [number]
52+
- Blocked tasks: [number]
53+
54+
### 3. Implementation Progress
55+
If in implementation phase:
56+
- Task completion breakdown
57+
- Current blockers or issues
58+
- Estimated time to completion
59+
- Next actions needed
60+
61+
#### Task Completion Tracking
62+
- Parse tasks.md checkbox status: `- [x]` (completed) vs `- [ ]` (pending)
63+
- Count completed vs total tasks
64+
- Show completion percentage
65+
- Identify next uncompleted task
66+
67+
### 4. Quality Metrics
68+
Show:
69+
- Requirements coverage: [percentage]
70+
- Design completeness: [percentage]
71+
- Task granularity: [appropriate/too large/too small]
72+
- Dependencies resolved: [yes/no]
73+
74+
### 5. Recommendations
75+
Based on status, provide:
76+
- Next steps to take
77+
- Potential issues to address
78+
- Suggested improvements
79+
- Missing elements to complete
80+
81+
### 6. Steering Alignment
82+
Check alignment with steering documents:
83+
- Architecture consistency: [aligned/misaligned]
84+
- Technology stack compliance: [compliant/non-compliant]
85+
- Product requirements alignment: [aligned/misaligned]
86+
87+
## Instructions
88+
89+
1. **Check spec.json for language** - Use the language specified in the metadata
90+
2. **Parse all spec files** to understand current state
91+
3. **Calculate completion percentages** for each phase
92+
4. **Identify next actions** based on current progress
93+
5. **Highlight any blockers** or issues
94+
6. **Provide clear recommendations** for moving forward
95+
7. **Check steering alignment** to ensure consistency
96+
97+
Generate status report that provides clear visibility into spec progress and next steps.

0 commit comments

Comments
 (0)