kiro-spec-engine 1.5.2 → 1.6.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +72 -0
- package/docs/quick-start.md +34 -652
- package/lib/adoption/adoption-strategy.js +4 -9
- package/lib/commands/adopt.js +4 -4
- package/package.json +1 -1
- package/template/.kiro/README.md +126 -233
package/CHANGELOG.md
CHANGED
|
@@ -5,6 +5,78 @@ All notable changes to this project will be documented in this file.
|
|
|
5
5
|
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
|
|
6
6
|
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
|
|
7
7
|
|
|
8
|
+
## [1.6.0] - 2026-01-24
|
|
9
|
+
|
|
10
|
+
### Changed - BREAKING CONCEPTUAL CHANGE 🎯
|
|
11
|
+
|
|
12
|
+
**Repositioned kse from "tool" to "methodology enforcer"**
|
|
13
|
+
|
|
14
|
+
This is a fundamental shift in how kse should be understood and used:
|
|
15
|
+
|
|
16
|
+
**Before (WRONG approach):**
|
|
17
|
+
- `.kiro/README.md` was a "kse command manual"
|
|
18
|
+
- Taught AI "how to use kse tool"
|
|
19
|
+
- Listed 20+ commands with examples
|
|
20
|
+
- Users had to "learn kse" before using it
|
|
21
|
+
|
|
22
|
+
**After (CORRECT approach):**
|
|
23
|
+
- `.kiro/README.md` is a "project development guide"
|
|
24
|
+
- Explains project follows Spec-driven methodology
|
|
25
|
+
- AI's role: follow the methodology, not learn the tool
|
|
26
|
+
- kse commands are helpers used automatically when needed
|
|
27
|
+
|
|
28
|
+
**Key insight from user feedback:**
|
|
29
|
+
> "After installing kse, just tell AI to read .kiro/README.md.
|
|
30
|
+
> AI will understand the methodology and naturally use kse commands
|
|
31
|
+
> to solve problems, rather than memorizing command syntax."
|
|
32
|
+
|
|
33
|
+
**What changed:**
|
|
34
|
+
- `.kiro/README.md` - Completely rewritten as methodology guide (not tool manual)
|
|
35
|
+
- `kse adopt` completion message - Now says "Tell AI to read README" instead of "Create your first spec"
|
|
36
|
+
- `docs/quick-start.md` - Simplified from 5-minute tool tutorial to 2-minute methodology introduction
|
|
37
|
+
- Removed detailed Spec creation examples (that's AI's job, not user's manual work)
|
|
38
|
+
|
|
39
|
+
**Impact:**
|
|
40
|
+
- Users don't need to "learn kse" anymore
|
|
41
|
+
- AI tools understand project methodology by reading README
|
|
42
|
+
- Natural workflow: User asks for feature → AI creates Spec → AI implements
|
|
43
|
+
- kse becomes invisible infrastructure, not a tool to master
|
|
44
|
+
|
|
45
|
+
**Migration:**
|
|
46
|
+
- Existing projects: Run `kse adopt --force` to get new README
|
|
47
|
+
- Tell your AI: "Please read .kiro/README.md to understand project methodology"
|
|
48
|
+
- AI will automatically understand and follow Spec-driven approach
|
|
49
|
+
|
|
50
|
+
This aligns kse with its true purpose: **enforcing development methodology**, not being a CLI tool to learn.
|
|
51
|
+
|
|
52
|
+
## [1.5.5] - 2026-01-24
|
|
53
|
+
|
|
54
|
+
### Added
|
|
55
|
+
- AI-friendly `.kiro/README.md` template explaining kse commands and usage
|
|
56
|
+
- Comprehensive kse command reference for AI tools (status, workflows, context export, etc.)
|
|
57
|
+
- AI workflow guide with step-by-step instructions for common tasks
|
|
58
|
+
- Spec structure documentation for AI understanding
|
|
59
|
+
- Best practices section for AI tools using kse
|
|
60
|
+
|
|
61
|
+
### Changed
|
|
62
|
+
- Updated `.kiro/README.md` template to focus on kse CLI usage instead of Kiro Spec system philosophy
|
|
63
|
+
- Simplified template file list in adoption strategy (removed obsolete files)
|
|
64
|
+
- Fixed template path in adoption strategy to point to correct location (`template/.kiro`)
|
|
65
|
+
|
|
66
|
+
### Fixed
|
|
67
|
+
- AI tools can now understand what kse is and how to use it by reading `.kiro/README.md`
|
|
68
|
+
- Adoption command now correctly copies README from template
|
|
69
|
+
|
|
70
|
+
## [1.5.4] - 2026-01-24
|
|
71
|
+
|
|
72
|
+
### Fixed
|
|
73
|
+
- Context exporter test to handle both possible error messages (tasks.md not found or Task not found)
|
|
74
|
+
|
|
75
|
+
## [1.5.3] - 2026-01-24
|
|
76
|
+
|
|
77
|
+
### Fixed
|
|
78
|
+
- Context exporter test to match actual error message format
|
|
79
|
+
|
|
8
80
|
## [1.5.2] - 2026-01-24
|
|
9
81
|
|
|
10
82
|
### Fixed
|
package/docs/quick-start.md
CHANGED
|
@@ -1,711 +1,93 @@
|
|
|
1
1
|
# Quick Start Guide
|
|
2
2
|
|
|
3
|
-
> Get
|
|
4
|
-
|
|
5
|
-
---
|
|
6
|
-
|
|
7
|
-
**Version**: 1.0.0
|
|
8
|
-
**Last Updated**: 2026-01-23
|
|
9
|
-
**Estimated Time**: 5 minutes
|
|
10
|
-
**Audience**: Beginners
|
|
3
|
+
> Get your project using Spec-driven development in 2 minutes
|
|
11
4
|
|
|
12
5
|
---
|
|
13
6
|
|
|
14
7
|
## What You'll Learn
|
|
15
8
|
|
|
16
|
-
|
|
17
|
-
- ✅
|
|
18
|
-
- ✅
|
|
19
|
-
- ✅ Export context for your AI tool
|
|
20
|
-
- ✅ Use AI to implement features based on your Spec
|
|
21
|
-
- ✅ Track task progress
|
|
22
|
-
|
|
23
|
-
---
|
|
24
|
-
|
|
25
|
-
## Prerequisites
|
|
26
|
-
|
|
27
|
-
Before starting, ensure you have:
|
|
28
|
-
- **Node.js** 14 or higher ([Download](https://nodejs.org/))
|
|
29
|
-
- **npm** 6 or higher (comes with Node.js)
|
|
30
|
-
- Basic command-line knowledge
|
|
31
|
-
- An AI coding tool (Claude, Cursor, Windsurf, Copilot, etc.)
|
|
32
|
-
|
|
33
|
-
Check your versions:
|
|
34
|
-
```bash
|
|
35
|
-
node --version # Should show v14.0.0 or higher
|
|
36
|
-
npm --version # Should show 6.0.0 or higher
|
|
37
|
-
```
|
|
9
|
+
- ✅ Install kse and adopt it in your project
|
|
10
|
+
- ✅ Tell your AI about the methodology
|
|
11
|
+
- ✅ Let AI work according to Spec-driven approach
|
|
38
12
|
|
|
39
13
|
---
|
|
40
14
|
|
|
41
15
|
## Step 1: Install kse (30 seconds)
|
|
42
16
|
|
|
43
|
-
Install kse globally using npm:
|
|
44
|
-
|
|
45
17
|
```bash
|
|
46
18
|
npm install -g kiro-spec-engine
|
|
47
19
|
```
|
|
48
20
|
|
|
49
|
-
|
|
50
|
-
```
|
|
51
|
-
added 50 packages in 5s
|
|
52
|
-
```
|
|
53
|
-
|
|
54
|
-
**Verify installation:**
|
|
21
|
+
Verify:
|
|
55
22
|
```bash
|
|
56
23
|
kse --version
|
|
57
24
|
```
|
|
58
25
|
|
|
59
|
-
**Expected output:**
|
|
60
|
-
```
|
|
61
|
-
1.3.0
|
|
62
|
-
```
|
|
63
|
-
|
|
64
|
-
**Troubleshooting:**
|
|
65
|
-
- **"kse: command not found"** → Restart your terminal or check your PATH
|
|
66
|
-
- **Permission errors on macOS/Linux** → Use `sudo npm install -g kiro-spec-engine`
|
|
67
|
-
- **Windows permission errors** → Run terminal as Administrator
|
|
68
|
-
|
|
69
26
|
---
|
|
70
27
|
|
|
71
|
-
## Step 2: Adopt
|
|
72
|
-
|
|
73
|
-
Navigate to your project directory (or create a new one):
|
|
28
|
+
## Step 2: Adopt in Your Project (30 seconds)
|
|
74
29
|
|
|
75
30
|
```bash
|
|
76
|
-
# For existing project
|
|
77
31
|
cd your-project
|
|
78
|
-
|
|
79
|
-
# Or create a new project
|
|
80
|
-
mkdir my-awesome-app
|
|
81
|
-
cd my-awesome-app
|
|
82
|
-
git init # kse works best with git projects
|
|
83
|
-
```
|
|
84
|
-
|
|
85
|
-
**Adopt kse:**
|
|
86
|
-
```bash
|
|
87
32
|
kse adopt
|
|
88
33
|
```
|
|
89
34
|
|
|
90
|
-
|
|
91
|
-
|
|
92
|
-
|
|
93
|
-
|
|
94
|
-
✓ Created specs/ directory
|
|
95
|
-
✓ Created steering/ directory
|
|
96
|
-
✓ Generated CORE_PRINCIPLES.md
|
|
97
|
-
✓ Generated ENVIRONMENT.md
|
|
98
|
-
✓ Generated CURRENT_CONTEXT.md
|
|
99
|
-
|
|
100
|
-
✅ Project successfully adopted kse!
|
|
101
|
-
|
|
102
|
-
Next steps:
|
|
103
|
-
1. Create your first Spec: kse create-spec 01-00-my-feature
|
|
104
|
-
2. Read the guide: .kiro/README.md
|
|
105
|
-
```
|
|
106
|
-
|
|
107
|
-
**What was created:**
|
|
108
|
-
```
|
|
109
|
-
your-project/
|
|
110
|
-
├── .kiro/
|
|
111
|
-
│ ├── specs/ # Your Specs will live here
|
|
112
|
-
│ ├── steering/ # AI behavior rules
|
|
113
|
-
│ │ ├── CORE_PRINCIPLES.md
|
|
114
|
-
│ │ ├── ENVIRONMENT.md
|
|
115
|
-
│ │ └── CURRENT_CONTEXT.md
|
|
116
|
-
│ └── README.md # Kiro system documentation
|
|
117
|
-
```
|
|
118
|
-
|
|
119
|
-
**Verification:**
|
|
120
|
-
```bash
|
|
121
|
-
kse status
|
|
122
|
-
```
|
|
123
|
-
|
|
124
|
-
**Expected output:**
|
|
125
|
-
```
|
|
126
|
-
Project: my-awesome-app
|
|
127
|
-
Specs: 0
|
|
128
|
-
Status: Ready
|
|
129
|
-
```
|
|
35
|
+
This creates `.kiro/` directory with:
|
|
36
|
+
- `README.md` - Project development guide
|
|
37
|
+
- `steering/` - Development rules
|
|
38
|
+
- `specs/` - Where Specs will live
|
|
130
39
|
|
|
131
40
|
---
|
|
132
41
|
|
|
133
|
-
## Step 3:
|
|
134
|
-
|
|
135
|
-
Let's create a Spec for a user login feature:
|
|
136
|
-
|
|
137
|
-
```bash
|
|
138
|
-
kse create-spec 01-00-user-login
|
|
139
|
-
```
|
|
140
|
-
|
|
141
|
-
**Expected output:**
|
|
142
|
-
```
|
|
143
|
-
✓ Created spec: 01-00-user-login
|
|
144
|
-
✓ Created requirements.md
|
|
145
|
-
✓ Created design.md
|
|
146
|
-
✓ Created tasks.md
|
|
147
|
-
|
|
148
|
-
📝 Next steps:
|
|
149
|
-
1. Edit requirements.md to define what you're building
|
|
150
|
-
2. Edit design.md to define how you'll build it
|
|
151
|
-
3. Edit tasks.md to break down implementation steps
|
|
152
|
-
```
|
|
153
|
-
|
|
154
|
-
### 3.1 Write Requirements
|
|
155
|
-
|
|
156
|
-
Open `.kiro/specs/01-00-user-login/requirements.md` and write:
|
|
157
|
-
|
|
158
|
-
```markdown
|
|
159
|
-
# User Login Feature
|
|
160
|
-
|
|
161
|
-
## Overview
|
|
162
|
-
Enable users to log in to the application using email and password.
|
|
42
|
+
## Step 3: Tell Your AI (1 minute)
|
|
163
43
|
|
|
164
|
-
|
|
44
|
+
**In your AI tool (Cursor, Claude, Windsurf, etc.), say:**
|
|
165
45
|
|
|
166
|
-
### US-1: User Login
|
|
167
|
-
**As a** user
|
|
168
|
-
**I want to** log in with my email and password
|
|
169
|
-
**So that** I can access my account
|
|
170
|
-
|
|
171
|
-
### US-2: Login Validation
|
|
172
|
-
**As a** user
|
|
173
|
-
**I want to** see clear error messages when login fails
|
|
174
|
-
**So that** I know what went wrong
|
|
175
|
-
|
|
176
|
-
## Functional Requirements
|
|
177
|
-
|
|
178
|
-
### FR-1: Login Form
|
|
179
|
-
The system shall provide a login form with:
|
|
180
|
-
- Email input field
|
|
181
|
-
- Password input field
|
|
182
|
-
- Submit button
|
|
183
|
-
|
|
184
|
-
### FR-2: Credential Validation
|
|
185
|
-
**WHEN** user submits valid credentials
|
|
186
|
-
**THEN** system authenticates user and redirects to dashboard
|
|
187
|
-
|
|
188
|
-
**WHEN** user submits invalid credentials
|
|
189
|
-
**THEN** system displays error message "Invalid email or password"
|
|
190
|
-
|
|
191
|
-
### FR-3: Input Validation
|
|
192
|
-
**WHEN** user submits empty email
|
|
193
|
-
**THEN** system displays error "Email is required"
|
|
194
|
-
|
|
195
|
-
**WHEN** user submits invalid email format
|
|
196
|
-
**THEN** system displays error "Please enter a valid email"
|
|
197
|
-
|
|
198
|
-
**WHEN** user submits password shorter than 6 characters
|
|
199
|
-
**THEN** system displays error "Password must be at least 6 characters"
|
|
200
|
-
|
|
201
|
-
## Non-Functional Requirements
|
|
202
|
-
|
|
203
|
-
### NFR-1: Security
|
|
204
|
-
- Passwords must be hashed before storage
|
|
205
|
-
- Use bcrypt with salt rounds >= 10
|
|
206
|
-
- Implement rate limiting (max 5 attempts per minute)
|
|
207
|
-
|
|
208
|
-
### NFR-2: Performance
|
|
209
|
-
- Login response time < 500ms
|
|
210
|
-
- Support 100 concurrent login requests
|
|
211
|
-
|
|
212
|
-
### NFR-3: Usability
|
|
213
|
-
- Clear error messages
|
|
214
|
-
- Accessible form (WCAG 2.1 Level AA)
|
|
215
|
-
|
|
216
|
-
## Acceptance Criteria
|
|
217
|
-
|
|
218
|
-
- [ ] User can log in with valid email and password
|
|
219
|
-
- [ ] User sees error message with invalid credentials
|
|
220
|
-
- [ ] Email validation works correctly
|
|
221
|
-
- [ ] Password validation works correctly
|
|
222
|
-
- [ ] Passwords are hashed in database
|
|
223
|
-
- [ ] Rate limiting prevents brute force attacks
|
|
224
|
-
- [ ] Login response time is under 500ms
|
|
225
46
|
```
|
|
226
|
-
|
|
227
|
-
### 3.2 Write Design
|
|
228
|
-
|
|
229
|
-
Open `.kiro/specs/01-00-user-login/design.md` and write:
|
|
230
|
-
|
|
231
|
-
```markdown
|
|
232
|
-
# User Login - Design Document
|
|
233
|
-
|
|
234
|
-
## Overview
|
|
235
|
-
This design implements a secure user login system with email/password authentication, input validation, and rate limiting.
|
|
236
|
-
|
|
237
|
-
## Architecture
|
|
238
|
-
|
|
239
|
-
### System Components
|
|
240
|
-
|
|
241
|
-
```mermaid
|
|
242
|
-
graph TD
|
|
243
|
-
A[Login Form] --> B[AuthController]
|
|
244
|
-
B --> C[ValidationService]
|
|
245
|
-
B --> D[AuthService]
|
|
246
|
-
D --> E[UserRepository]
|
|
247
|
-
D --> F[TokenService]
|
|
248
|
-
E --> G[Database]
|
|
47
|
+
Please read .kiro/README.md to understand how this project works.
|
|
249
48
|
```
|
|
250
49
|
|
|
251
|
-
|
|
252
|
-
|
|
253
|
-
|
|
254
|
-
|
|
255
|
-
**Request:**
|
|
256
|
-
```json
|
|
257
|
-
{
|
|
258
|
-
"email": "user@example.com",
|
|
259
|
-
"password": "secret123"
|
|
260
|
-
}
|
|
261
|
-
```
|
|
262
|
-
|
|
263
|
-
**Success Response (200):**
|
|
264
|
-
```json
|
|
265
|
-
{
|
|
266
|
-
"success": true,
|
|
267
|
-
"token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
|
|
268
|
-
"user": {
|
|
269
|
-
"id": "123",
|
|
270
|
-
"email": "user@example.com",
|
|
271
|
-
"name": "John Doe"
|
|
272
|
-
}
|
|
273
|
-
}
|
|
274
|
-
```
|
|
275
|
-
|
|
276
|
-
**Error Response (401):**
|
|
277
|
-
```json
|
|
278
|
-
{
|
|
279
|
-
"success": false,
|
|
280
|
-
"error": "Invalid email or password"
|
|
281
|
-
}
|
|
282
|
-
```
|
|
283
|
-
|
|
284
|
-
**Error Response (429):**
|
|
285
|
-
```json
|
|
286
|
-
{
|
|
287
|
-
"success": false,
|
|
288
|
-
"error": "Too many login attempts. Please try again later."
|
|
289
|
-
}
|
|
290
|
-
```
|
|
291
|
-
|
|
292
|
-
## Component Design
|
|
293
|
-
|
|
294
|
-
### AuthController
|
|
295
|
-
**Responsibility:** Handle HTTP requests for authentication
|
|
296
|
-
|
|
297
|
-
**Methods:**
|
|
298
|
-
- `login(req, res)` - Process login request
|
|
299
|
-
- `validateRequest(req)` - Validate request format
|
|
300
|
-
|
|
301
|
-
### ValidationService
|
|
302
|
-
**Responsibility:** Validate user input
|
|
303
|
-
|
|
304
|
-
**Methods:**
|
|
305
|
-
- `validateEmail(email)` - Check email format
|
|
306
|
-
- `validatePassword(password)` - Check password requirements
|
|
307
|
-
- Returns: `{ valid: boolean, errors: string[] }`
|
|
308
|
-
|
|
309
|
-
### AuthService
|
|
310
|
-
**Responsibility:** Business logic for authentication
|
|
311
|
-
|
|
312
|
-
**Methods:**
|
|
313
|
-
- `authenticate(email, password)` - Verify credentials
|
|
314
|
-
- `generateToken(user)` - Create JWT token
|
|
315
|
-
- `hashPassword(password)` - Hash password with bcrypt
|
|
316
|
-
|
|
317
|
-
### UserRepository
|
|
318
|
-
**Responsibility:** Database operations for users
|
|
319
|
-
|
|
320
|
-
**Methods:**
|
|
321
|
-
- `findByEmail(email)` - Get user by email
|
|
322
|
-
- `updateLastLogin(userId)` - Update last login timestamp
|
|
323
|
-
|
|
324
|
-
### RateLimiter
|
|
325
|
-
**Responsibility:** Prevent brute force attacks
|
|
326
|
-
|
|
327
|
-
**Configuration:**
|
|
328
|
-
- Max attempts: 5 per minute per IP
|
|
329
|
-
- Block duration: 15 minutes after limit exceeded
|
|
330
|
-
|
|
331
|
-
## Data Models
|
|
332
|
-
|
|
333
|
-
### User
|
|
334
|
-
```javascript
|
|
335
|
-
{
|
|
336
|
-
id: string,
|
|
337
|
-
email: string,
|
|
338
|
-
passwordHash: string,
|
|
339
|
-
name: string,
|
|
340
|
-
createdAt: Date,
|
|
341
|
-
lastLoginAt: Date
|
|
342
|
-
}
|
|
343
|
-
```
|
|
344
|
-
|
|
345
|
-
## Security Considerations
|
|
346
|
-
|
|
347
|
-
1. **Password Hashing:** Use bcrypt with 10 salt rounds
|
|
348
|
-
2. **JWT Tokens:** Sign with secret key, expire in 24 hours
|
|
349
|
-
3. **Rate Limiting:** Implement per-IP rate limiting
|
|
350
|
-
4. **Input Sanitization:** Sanitize all user inputs
|
|
351
|
-
5. **HTTPS Only:** Enforce HTTPS in production
|
|
352
|
-
|
|
353
|
-
## Error Handling
|
|
354
|
-
|
|
355
|
-
| Error | HTTP Code | Message |
|
|
356
|
-
|-------|-----------|---------|
|
|
357
|
-
| Invalid credentials | 401 | "Invalid email or password" |
|
|
358
|
-
| Missing email | 400 | "Email is required" |
|
|
359
|
-
| Invalid email format | 400 | "Please enter a valid email" |
|
|
360
|
-
| Missing password | 400 | "Password is required" |
|
|
361
|
-
| Password too short | 400 | "Password must be at least 6 characters" |
|
|
362
|
-
| Rate limit exceeded | 429 | "Too many login attempts. Please try again later." |
|
|
363
|
-
| Server error | 500 | "An error occurred. Please try again." |
|
|
364
|
-
|
|
365
|
-
## Technology Stack
|
|
366
|
-
|
|
367
|
-
- **Backend:** Node.js + Express
|
|
368
|
-
- **Database:** PostgreSQL
|
|
369
|
-
- **Authentication:** JWT (jsonwebtoken)
|
|
370
|
-
- **Password Hashing:** bcrypt
|
|
371
|
-
- **Rate Limiting:** express-rate-limit
|
|
372
|
-
- **Validation:** validator.js
|
|
373
|
-
|
|
374
|
-
## Requirements Traceability
|
|
375
|
-
|
|
376
|
-
| Requirement | Design Component |
|
|
377
|
-
|-------------|------------------|
|
|
378
|
-
| FR-1: Login Form | AuthController.login() |
|
|
379
|
-
| FR-2: Credential Validation | AuthService.authenticate() |
|
|
380
|
-
| FR-3: Input Validation | ValidationService |
|
|
381
|
-
| NFR-1: Security | bcrypt, JWT, RateLimiter |
|
|
382
|
-
| NFR-2: Performance | Indexed database queries |
|
|
383
|
-
| NFR-3: Usability | Clear error messages in API responses |
|
|
384
|
-
```
|
|
385
|
-
|
|
386
|
-
### 3.3 Write Tasks
|
|
387
|
-
|
|
388
|
-
Open `.kiro/specs/01-00-user-login/tasks.md` and write:
|
|
389
|
-
|
|
390
|
-
```markdown
|
|
391
|
-
# User Login - Implementation Tasks
|
|
392
|
-
|
|
393
|
-
## Phase 1: Setup and Models
|
|
394
|
-
|
|
395
|
-
- [ ] 1.1 Set up project dependencies
|
|
396
|
-
- Install express, bcrypt, jsonwebtoken, validator, express-rate-limit
|
|
397
|
-
- Configure TypeScript (if using)
|
|
398
|
-
|
|
399
|
-
- [ ] 1.2 Create User model and database schema
|
|
400
|
-
- Define User interface/class
|
|
401
|
-
- Create database migration for users table
|
|
402
|
-
- Add indexes on email field
|
|
403
|
-
|
|
404
|
-
## Phase 2: Core Services
|
|
405
|
-
|
|
406
|
-
- [ ] 2.1 Implement ValidationService
|
|
407
|
-
- Create validateEmail() method
|
|
408
|
-
- Create validatePassword() method
|
|
409
|
-
- Write unit tests
|
|
410
|
-
|
|
411
|
-
- [ ] 2.2 Implement AuthService
|
|
412
|
-
- Create hashPassword() method
|
|
413
|
-
- Create authenticate() method
|
|
414
|
-
- Create generateToken() method
|
|
415
|
-
- Write unit tests
|
|
416
|
-
|
|
417
|
-
- [ ] 2.3 Implement UserRepository
|
|
418
|
-
- Create findByEmail() method
|
|
419
|
-
- Create updateLastLogin() method
|
|
420
|
-
- Write unit tests
|
|
421
|
-
|
|
422
|
-
## Phase 3: API Implementation
|
|
423
|
-
|
|
424
|
-
- [ ] 3.1 Implement AuthController
|
|
425
|
-
- Create login() endpoint handler
|
|
426
|
-
- Add request validation
|
|
427
|
-
- Add error handling
|
|
428
|
-
- Write integration tests
|
|
429
|
-
|
|
430
|
-
- [ ] 3.2 Implement rate limiting
|
|
431
|
-
- Configure express-rate-limit
|
|
432
|
-
- Apply to login endpoint
|
|
433
|
-
- Test rate limiting behavior
|
|
434
|
-
|
|
435
|
-
## Phase 4: Testing and Documentation
|
|
436
|
-
|
|
437
|
-
- [ ] 4.1 Write comprehensive tests
|
|
438
|
-
- Unit tests for all services
|
|
439
|
-
- Integration tests for API endpoint
|
|
440
|
-
- Test error scenarios
|
|
441
|
-
- Test rate limiting
|
|
442
|
-
|
|
443
|
-
- [ ] 4.2 Create API documentation
|
|
444
|
-
- Document request/response formats
|
|
445
|
-
- Add example requests
|
|
446
|
-
- Document error codes
|
|
447
|
-
|
|
448
|
-
- [ ] 4.3 Manual testing
|
|
449
|
-
- Test with valid credentials
|
|
450
|
-
- Test with invalid credentials
|
|
451
|
-
- Test input validation
|
|
452
|
-
- Test rate limiting
|
|
453
|
-
- Test performance (response time < 500ms)
|
|
454
|
-
|
|
455
|
-
## Phase 5: Deployment
|
|
456
|
-
|
|
457
|
-
- [ ] 5.1 Environment configuration
|
|
458
|
-
- Set up environment variables
|
|
459
|
-
- Configure JWT secret
|
|
460
|
-
- Configure database connection
|
|
461
|
-
|
|
462
|
-
- [ ] 5.2 Deploy to staging
|
|
463
|
-
- Deploy code
|
|
464
|
-
- Run smoke tests
|
|
465
|
-
- Verify functionality
|
|
466
|
-
|
|
467
|
-
## Notes
|
|
468
|
-
- All passwords must be hashed before storage
|
|
469
|
-
- Use environment variables for secrets
|
|
470
|
-
- Follow project coding standards
|
|
471
|
-
- Write tests before marking tasks complete
|
|
472
|
-
```
|
|
50
|
+
**Your AI will learn:**
|
|
51
|
+
- This project follows Spec-driven development
|
|
52
|
+
- Every feature starts with a Spec (requirements + design + tasks)
|
|
53
|
+
- How to work with this methodology
|
|
473
54
|
|
|
474
55
|
---
|
|
475
56
|
|
|
476
|
-
## Step 4:
|
|
57
|
+
## Step 4: Start Working
|
|
477
58
|
|
|
478
|
-
|
|
59
|
+
**Just ask your AI to implement features:**
|
|
479
60
|
|
|
480
|
-
```bash
|
|
481
|
-
kse context export 01-00-user-login
|
|
482
|
-
```
|
|
483
|
-
|
|
484
|
-
**Expected output:**
|
|
485
61
|
```
|
|
486
|
-
|
|
487
|
-
✓ Context size: 3.2 KB
|
|
488
|
-
✓ Ready to use with AI tools
|
|
62
|
+
I need a user login feature with email and password.
|
|
489
63
|
```
|
|
490
64
|
|
|
491
|
-
**
|
|
492
|
-
|
|
493
|
-
|
|
494
|
-
|
|
495
|
-
|
|
496
|
-
|
|
497
|
-
- Formatted for AI consumption
|
|
498
|
-
|
|
499
|
-
---
|
|
500
|
-
|
|
501
|
-
## Step 5: Use Your AI Tool (1 minute)
|
|
502
|
-
|
|
503
|
-
Now use your AI tool to implement the feature. Choose your tool:
|
|
504
|
-
|
|
505
|
-
### Option A: Claude Code / ChatGPT
|
|
506
|
-
|
|
507
|
-
1. **Open the context file:**
|
|
508
|
-
```bash
|
|
509
|
-
# On macOS
|
|
510
|
-
cat .kiro/specs/01-00-user-login/context-export.md | pbcopy
|
|
511
|
-
|
|
512
|
-
# On Windows
|
|
513
|
-
type .kiro\specs\01-00-user-login\context-export.md | clip
|
|
514
|
-
|
|
515
|
-
# On Linux
|
|
516
|
-
cat .kiro/specs/01-00-user-login/context-export.md | xclip -selection clipboard
|
|
517
|
-
```
|
|
518
|
-
|
|
519
|
-
2. **Start a new conversation** with Claude or ChatGPT
|
|
520
|
-
|
|
521
|
-
3. **Paste the context** and say:
|
|
522
|
-
```
|
|
523
|
-
I've provided the complete Spec for a user login feature.
|
|
524
|
-
Please implement task 1.1: "Set up project dependencies"
|
|
525
|
-
```
|
|
526
|
-
|
|
527
|
-
4. **Claude/ChatGPT will:**
|
|
528
|
-
- Understand your requirements and design
|
|
529
|
-
- Generate the appropriate code
|
|
530
|
-
- Follow your architecture decisions
|
|
531
|
-
|
|
532
|
-
### Option B: Cursor
|
|
533
|
-
|
|
534
|
-
1. **Generate a task-specific prompt:**
|
|
535
|
-
```bash
|
|
536
|
-
kse prompt generate 01-00-user-login 1.1
|
|
537
|
-
```
|
|
538
|
-
|
|
539
|
-
2. **Open Cursor Composer** (Cmd+K or Ctrl+K)
|
|
540
|
-
|
|
541
|
-
3. **Paste the generated prompt**
|
|
542
|
-
|
|
543
|
-
4. **Cursor will:**
|
|
544
|
-
- Read your Spec files
|
|
545
|
-
- Generate code matching your design
|
|
546
|
-
- Create or modify files directly
|
|
547
|
-
|
|
548
|
-
### Option C: Windsurf / Cline
|
|
549
|
-
|
|
550
|
-
1. **Simply tell the AI:**
|
|
551
|
-
```
|
|
552
|
-
Use kse to check the spec for 01-00-user-login and implement task 1.1
|
|
553
|
-
```
|
|
554
|
-
|
|
555
|
-
2. **The AI will:**
|
|
556
|
-
- Automatically run `kse context export 01-00-user-login`
|
|
557
|
-
- Read the exported context
|
|
558
|
-
- Implement the task
|
|
559
|
-
- Update task status
|
|
560
|
-
|
|
561
|
-
### Option D: VS Code + Copilot
|
|
562
|
-
|
|
563
|
-
1. **Create a new file** (e.g., `src/auth/AuthController.js`)
|
|
65
|
+
**Your AI will:**
|
|
66
|
+
1. Suggest creating a Spec first
|
|
67
|
+
2. Help you define requirements
|
|
68
|
+
3. Design the solution
|
|
69
|
+
4. Break down into tasks
|
|
70
|
+
5. Implement according to the Spec
|
|
564
71
|
|
|
565
|
-
|
|
566
|
-
```javascript
|
|
567
|
-
// Task 1.1: Set up project dependencies
|
|
568
|
-
// See: .kiro/specs/01-00-user-login/design.md
|
|
569
|
-
//
|
|
570
|
-
// Install: express, bcrypt, jsonwebtoken, validator, express-rate-limit
|
|
571
|
-
```
|
|
572
|
-
|
|
573
|
-
3. **Copilot will:**
|
|
574
|
-
- Suggest code based on your Spec
|
|
575
|
-
- Follow your design patterns
|
|
576
|
-
- Generate appropriate implementations
|
|
72
|
+
**The AI uses kse commands automatically** - you don't need to learn them.
|
|
577
73
|
|
|
578
74
|
---
|
|
579
75
|
|
|
580
|
-
##
|
|
581
|
-
|
|
582
|
-
As you complete tasks, update the task status:
|
|
583
|
-
|
|
584
|
-
**Edit** `.kiro/specs/01-00-user-login/tasks.md`:
|
|
76
|
+
## That's It!
|
|
585
77
|
|
|
586
|
-
|
|
587
|
-
- [x] 1.1 Set up project dependencies ← Changed from [ ] to [x]
|
|
588
|
-
- [ ] 1.2 Create User model and database schema
|
|
589
|
-
```
|
|
78
|
+
You're now using Spec-driven development. Your AI understands the methodology and will follow it.
|
|
590
79
|
|
|
591
|
-
**
|
|
592
|
-
```bash
|
|
593
|
-
kse status
|
|
594
|
-
```
|
|
595
|
-
|
|
596
|
-
**Expected output:**
|
|
597
|
-
```
|
|
598
|
-
Project: my-awesome-app
|
|
599
|
-
Specs: 1
|
|
600
|
-
|
|
601
|
-
Spec: 01-00-user-login
|
|
602
|
-
Total tasks: 15
|
|
603
|
-
Completed: 1
|
|
604
|
-
In progress: 0
|
|
605
|
-
Not started: 14
|
|
606
|
-
Progress: 6.7%
|
|
607
|
-
```
|
|
80
|
+
**Key insight:** You don't "use kse" - your project "follows Spec-driven methodology" and kse helps enforce it.
|
|
608
81
|
|
|
609
82
|
---
|
|
610
83
|
|
|
611
84
|
## Next Steps
|
|
612
85
|
|
|
613
|
-
|
|
614
|
-
|
|
615
|
-
### Learn More About Integration
|
|
616
|
-
|
|
617
|
-
Choose your AI tool for detailed guidance:
|
|
618
|
-
- **[Cursor Guide](tools/cursor-guide.md)** - Deep dive into Cursor integration
|
|
619
|
-
- **[Claude Guide](tools/claude-guide.md)** - Best practices for Claude Code
|
|
620
|
-
- **[Windsurf Guide](tools/windsurf-guide.md)** - Automated workflows with Windsurf
|
|
621
|
-
- **[Generic Guide](tools/generic-guide.md)** - Works with any AI tool
|
|
622
|
-
|
|
623
|
-
### Explore Advanced Features
|
|
624
|
-
|
|
625
|
-
- **[Integration Modes](integration-modes.md)** - Native, Manual, and Watch Mode
|
|
86
|
+
- **[Integration Modes](integration-modes.md)** - Understand how AI tools work with kse
|
|
626
87
|
- **[Spec Workflow](spec-workflow.md)** - Deep dive into Spec creation
|
|
627
|
-
- **[
|
|
628
|
-
|
|
629
|
-
### See Real Examples
|
|
630
|
-
|
|
631
|
-
- **[API Feature Example](examples/add-rest-api/)** - Complete RESTful API Spec
|
|
632
|
-
- **[UI Feature Example](examples/add-user-dashboard/)** - React dashboard Spec
|
|
633
|
-
- **[CLI Feature Example](examples/add-export-command/)** - CLI command Spec
|
|
634
|
-
|
|
635
|
-
---
|
|
636
|
-
|
|
637
|
-
## Troubleshooting
|
|
638
|
-
|
|
639
|
-
### Issue: "kse: command not found"
|
|
640
|
-
|
|
641
|
-
**Solution:**
|
|
642
|
-
1. Restart your terminal
|
|
643
|
-
2. Check if npm global bin is in PATH:
|
|
644
|
-
```bash
|
|
645
|
-
npm config get prefix
|
|
646
|
-
```
|
|
647
|
-
3. Add to PATH if needed (macOS/Linux):
|
|
648
|
-
```bash
|
|
649
|
-
export PATH="$(npm config get prefix)/bin:$PATH"
|
|
650
|
-
```
|
|
651
|
-
|
|
652
|
-
### Issue: Context file is too large for AI tool
|
|
653
|
-
|
|
654
|
-
**Solution:** Generate task-specific prompts:
|
|
655
|
-
```bash
|
|
656
|
-
kse prompt generate 01-00-user-login 1.1
|
|
657
|
-
```
|
|
658
|
-
|
|
659
|
-
This creates a smaller, focused context for just that task.
|
|
660
|
-
|
|
661
|
-
### Issue: AI doesn't follow my design
|
|
662
|
-
|
|
663
|
-
**Solution:**
|
|
664
|
-
1. Make your design.md more detailed
|
|
665
|
-
2. Add code examples in design.md
|
|
666
|
-
3. Be explicit in your prompt: "Strictly follow the design document"
|
|
667
|
-
4. Include steering rules:
|
|
668
|
-
```bash
|
|
669
|
-
kse context export 01-00-user-login --steering
|
|
670
|
-
```
|
|
671
|
-
|
|
672
|
-
### Issue: Can't find my Spec files
|
|
673
|
-
|
|
674
|
-
**Solution:**
|
|
675
|
-
All Specs are in `.kiro/specs/`:
|
|
676
|
-
```bash
|
|
677
|
-
ls .kiro/specs/
|
|
678
|
-
```
|
|
679
|
-
|
|
680
|
-
### More Help
|
|
681
|
-
|
|
682
|
-
- 📖 **[Troubleshooting Guide](troubleshooting.md)** - Common issues and solutions
|
|
683
|
-
- 🤔 **[FAQ](faq.md)** - Frequently asked questions
|
|
684
|
-
- 💬 **[GitHub Discussions](https://github.com/yourusername/kiro-spec-engine/discussions)** - Community help
|
|
685
|
-
|
|
686
|
-
---
|
|
687
|
-
|
|
688
|
-
## Summary
|
|
689
|
-
|
|
690
|
-
You've learned how to:
|
|
691
|
-
- ✅ Install and set up kse
|
|
692
|
-
- ✅ Create structured Specs with requirements, design, and tasks
|
|
693
|
-
- ✅ Export context for AI tools
|
|
694
|
-
- ✅ Use AI to implement features based on Specs
|
|
695
|
-
- ✅ Track implementation progress
|
|
696
|
-
|
|
697
|
-
**The kse workflow:**
|
|
698
|
-
```
|
|
699
|
-
Create Spec → Export Context → AI Implements → Update Tasks → Repeat
|
|
700
|
-
```
|
|
701
|
-
|
|
702
|
-
**Ready to build your next feature?** 🚀
|
|
703
|
-
|
|
704
|
-
```bash
|
|
705
|
-
kse create-spec 02-00-your-next-feature
|
|
706
|
-
```
|
|
88
|
+
- **[Tool Guides](tools/)** - Tool-specific tips
|
|
707
89
|
|
|
708
90
|
---
|
|
709
91
|
|
|
710
|
-
**Version**:
|
|
711
|
-
**Last Updated**: 2026-01-
|
|
92
|
+
**Version**: 2.0.0
|
|
93
|
+
**Last Updated**: 2026-01-24
|
|
@@ -41,14 +41,12 @@ class AdoptionStrategy {
|
|
|
41
41
|
/**
|
|
42
42
|
* Gets the path to template directory
|
|
43
43
|
* This would be embedded in the kse package
|
|
44
|
-
* For now, we'll use a placeholder
|
|
45
44
|
*
|
|
46
45
|
* @returns {string}
|
|
47
46
|
*/
|
|
48
47
|
getTemplatePath() {
|
|
49
|
-
//
|
|
50
|
-
|
|
51
|
-
return path.join(__dirname, '../../templates/kiro');
|
|
48
|
+
// Template is at template/.kiro/ in the package
|
|
49
|
+
return path.join(__dirname, '../../template/.kiro');
|
|
52
50
|
}
|
|
53
51
|
|
|
54
52
|
/**
|
|
@@ -107,15 +105,12 @@ class AdoptionStrategy {
|
|
|
107
105
|
|
|
108
106
|
// Define template structure
|
|
109
107
|
const templateFiles = [
|
|
108
|
+
'README.md',
|
|
110
109
|
'steering/CORE_PRINCIPLES.md',
|
|
111
110
|
'steering/ENVIRONMENT.md',
|
|
112
111
|
'steering/CURRENT_CONTEXT.md',
|
|
113
112
|
'steering/RULES_GUIDE.md',
|
|
114
|
-
'
|
|
115
|
-
'README.md',
|
|
116
|
-
'ultrawork-application-guide.md',
|
|
117
|
-
'ultrawork-integration-summary.md',
|
|
118
|
-
'sisyphus-deep-dive.md'
|
|
113
|
+
'specs/SPEC_WORKFLOW_GUIDE.md'
|
|
119
114
|
];
|
|
120
115
|
|
|
121
116
|
for (const file of templateFiles) {
|
package/lib/commands/adopt.js
CHANGED
|
@@ -399,11 +399,11 @@ async function adoptCommand(options = {}) {
|
|
|
399
399
|
|
|
400
400
|
console.log();
|
|
401
401
|
console.log(chalk.blue('💡 Next steps:'));
|
|
402
|
-
console.log(' 1.
|
|
403
|
-
console.log(' 2.
|
|
404
|
-
console.log(' 3. Check
|
|
402
|
+
console.log(' 1. Tell your AI: "Read .kiro/README.md to understand project methodology"');
|
|
403
|
+
console.log(' 2. Start working: Ask AI to implement features following Spec-driven approach');
|
|
404
|
+
console.log(' 3. Check progress: ' + chalk.cyan('kse status'));
|
|
405
405
|
console.log();
|
|
406
|
-
console.log(chalk.red('🔥') + '
|
|
406
|
+
console.log(chalk.red('🔥') + ' Project now follows Spec-driven development!');
|
|
407
407
|
} else {
|
|
408
408
|
console.log(chalk.red('❌ Adoption failed'));
|
|
409
409
|
console.log();
|
package/package.json
CHANGED
package/template/.kiro/README.md
CHANGED
|
@@ -1,288 +1,181 @@
|
|
|
1
|
-
#
|
|
1
|
+
# Project Development Guide
|
|
2
2
|
|
|
3
|
-
>
|
|
3
|
+
> **AI Tools: Read this first!** This project follows Spec-driven development methodology.
|
|
4
4
|
|
|
5
5
|
---
|
|
6
6
|
|
|
7
|
-
## 🎯
|
|
7
|
+
## 🎯 How This Project Works
|
|
8
8
|
|
|
9
|
-
|
|
10
|
-
- **
|
|
11
|
-
-
|
|
12
|
-
-
|
|
9
|
+
This project uses **Spec-driven development** - a structured approach where:
|
|
10
|
+
- Every feature starts with a **Spec** (requirements + design + tasks)
|
|
11
|
+
- All work is tracked and documented
|
|
12
|
+
- AI tools help implement features according to Specs
|
|
13
13
|
|
|
14
|
-
|
|
15
|
-
|
|
16
|
-
|
|
17
|
-
|
|
18
|
-
|
|
19
|
-
|
|
20
|
-
**挑战**:
|
|
21
|
-
- AI session 启动时会加载所有 Steering 文档
|
|
22
|
-
- 历史数据和详细内容会快速消耗 token
|
|
23
|
-
- Token 耗尽导致无法继续执行任务
|
|
24
|
-
|
|
25
|
-
**解决方案**:
|
|
26
|
-
- **分层管理**:稳定规则(CORE_PRINCIPLES)+ 动态场景(CURRENT_CONTEXT)
|
|
27
|
-
- **精简原则**:Steering 只保留核心信息,详细内容放到 Spec 目录
|
|
28
|
-
- **主动管控**:每个 Spec 完成后及时更新 CURRENT_CONTEXT
|
|
29
|
-
|
|
30
|
-
### 问题 2:规范一致性难以保持
|
|
14
|
+
**Your role as AI:**
|
|
15
|
+
- When user requests a feature → Check if Spec exists, if not, help create one
|
|
16
|
+
- When implementing → Follow the Spec's requirements and design
|
|
17
|
+
- When stuck → Read the Spec documents for context
|
|
18
|
+
- Track progress by updating task status
|
|
31
19
|
|
|
32
|
-
|
|
33
|
-
-
|
|
34
|
-
-
|
|
35
|
-
-
|
|
36
|
-
|
|
37
|
-
**解决方案**:
|
|
38
|
-
- **Spec 驱动**:所有工作基于 Spec 推进
|
|
39
|
-
- **统一规范**:CORE_PRINCIPLES 适用于所有 Spec
|
|
40
|
-
- **产物归档**:所有产物归档到对应的 Spec 目录
|
|
20
|
+
**The tool `kse` helps you:**
|
|
21
|
+
- Check project status: `kse status`
|
|
22
|
+
- Find Specs: `kse workflows`
|
|
23
|
+
- Get context: `kse context export <spec-name>`
|
|
24
|
+
- But you don't need to memorize commands - use them when needed
|
|
41
25
|
|
|
42
26
|
---
|
|
43
27
|
|
|
44
|
-
##
|
|
45
|
-
|
|
46
|
-
### Steering 目录(AI 每次启动时加载)
|
|
47
|
-
|
|
48
|
-
| 文件 | 职责 | Token 影响 | 更新频率 |
|
|
49
|
-
|------|------|-----------|---------|
|
|
50
|
-
| **RULES_GUIDE.md** | 索引和快速参考 | 低 | 很少 |
|
|
51
|
-
| **CORE_PRINCIPLES.md** | 核心开发规范 | 中 | 很少 |
|
|
52
|
-
| **ENVIRONMENT.md** | 环境配置 | 低 | 很少 |
|
|
53
|
-
| **CURRENT_CONTEXT.md** | 当前 Spec 场景 | **高** ⚠️ | 每个 Spec |
|
|
28
|
+
## 📋 Development Workflow
|
|
54
29
|
|
|
55
|
-
###
|
|
30
|
+
### When User Asks You to Implement a Feature
|
|
56
31
|
|
|
32
|
+
**Step 1: Check if Spec exists**
|
|
57
33
|
```
|
|
58
|
-
.kiro/specs/
|
|
59
|
-
├── SPEC_WORKFLOW_GUIDE.md # Spec 工作流指南
|
|
60
|
-
└── {spec-name}/ # 具体的 Spec
|
|
61
|
-
├── requirements.md # 需求文档
|
|
62
|
-
├── design.md # 设计文档(可选)
|
|
63
|
-
├── tasks.md # 任务列表(可选)
|
|
64
|
-
├── scripts/ # 脚本
|
|
65
|
-
├── diagnostics/ # 诊断文档
|
|
66
|
-
└── results/ # 执行结果
|
|
34
|
+
Look in .kiro/specs/ directory
|
|
67
35
|
```
|
|
68
36
|
|
|
69
|
-
|
|
70
|
-
|
|
71
|
-
|
|
72
|
-
|
|
73
|
-
|
|
74
|
-
|
|
75
|
-
|
|
76
|
-
|
|
77
|
-
-
|
|
78
|
-
-
|
|
79
|
-
|
|
80
|
-
|
|
81
|
-
-
|
|
82
|
-
|
|
83
|
-
|
|
84
|
-
-
|
|
85
|
-
|
|
86
|
-
|
|
87
|
-
|
|
88
|
-
|
|
89
|
-
|
|
90
|
-
|
|
91
|
-
|
|
92
|
-
|
|
93
|
-
**实践**:
|
|
94
|
-
- ✅ CORE_PRINCIPLES 保持稳定,很少修改
|
|
95
|
-
- ✅ ENVIRONMENT 记录项目特定的环境配置
|
|
96
|
-
- ✅ CURRENT_CONTEXT 随 Spec 动态更新
|
|
97
|
-
|
|
98
|
-
### 3. 上下文的聚焦性
|
|
99
|
-
|
|
100
|
-
**原则**:
|
|
101
|
-
- CURRENT_CONTEXT 只保留当前 Spec 的核心信息
|
|
102
|
-
- 历史数据归档到 Spec 目录,不占用 Steering 空间
|
|
103
|
-
- 每个 Spec 开始前必须更新 CURRENT_CONTEXT
|
|
104
|
-
|
|
105
|
-
**实践**:
|
|
106
|
-
- ✅ 每个新 Spec 开始前:更新 CURRENT_CONTEXT
|
|
107
|
-
- ✅ Spec 推进中:及时精简已完成内容
|
|
108
|
-
- ✅ Spec 完成后:清空 CURRENT_CONTEXT
|
|
109
|
-
|
|
110
|
-
---
|
|
111
|
-
|
|
112
|
-
## 🚀 如何在新项目中使用?
|
|
113
|
-
|
|
114
|
-
### 步骤 1:复制 Steering 模板
|
|
115
|
-
|
|
37
|
+
**Step 2: If Spec exists**
|
|
38
|
+
- Read `requirements.md` - understand what to build
|
|
39
|
+
- Read `design.md` - understand how to build it
|
|
40
|
+
- Read `tasks.md` - see implementation steps
|
|
41
|
+
- Implement according to the Spec
|
|
42
|
+
- Update task status as you complete work
|
|
43
|
+
|
|
44
|
+
**Step 3: If no Spec exists**
|
|
45
|
+
- Suggest creating a Spec first
|
|
46
|
+
- Help user define requirements
|
|
47
|
+
- Help design the solution
|
|
48
|
+
- Break down into tasks
|
|
49
|
+
- Then implement
|
|
50
|
+
|
|
51
|
+
**Why Spec-first?**
|
|
52
|
+
- Clear requirements prevent misunderstandings
|
|
53
|
+
- Design decisions are documented
|
|
54
|
+
- Progress is trackable
|
|
55
|
+
- Knowledge is preserved
|
|
56
|
+
|
|
57
|
+
### When User Asks About Project Status
|
|
58
|
+
|
|
59
|
+
Check what's happening:
|
|
116
60
|
```bash
|
|
117
|
-
|
|
118
|
-
cp -r template-project/.kiro/ new-project/.kiro/
|
|
61
|
+
kse status
|
|
119
62
|
```
|
|
120
63
|
|
|
121
|
-
|
|
122
|
-
|
|
123
|
-
更新为新项目的实际环境:
|
|
124
|
-
- 服务器信息(如有)
|
|
125
|
-
- 数据库配置
|
|
126
|
-
- 部署方式
|
|
127
|
-
- AI 权限范围
|
|
128
|
-
|
|
129
|
-
### 步骤 3:清空 CURRENT_CONTEXT.md
|
|
130
|
-
|
|
131
|
-
删除旧项目的场景信息,标记为"无活跃 Spec"。
|
|
64
|
+
This shows all Specs and their progress.
|
|
132
65
|
|
|
133
|
-
###
|
|
66
|
+
### When You Need Context
|
|
134
67
|
|
|
135
|
-
|
|
136
|
-
|
|
137
|
-
|
|
68
|
+
If you need to understand a feature:
|
|
69
|
+
```bash
|
|
70
|
+
kse context export <spec-name>
|
|
71
|
+
```
|
|
138
72
|
|
|
139
|
-
|
|
140
|
-
- 项目名称
|
|
141
|
-
- 技术栈
|
|
142
|
-
- 示例
|
|
73
|
+
This generates a summary of requirements, design, and tasks.
|
|
143
74
|
|
|
144
75
|
---
|
|
145
76
|
|
|
146
|
-
##
|
|
147
|
-
|
|
148
|
-
### 标准流程
|
|
77
|
+
## 📁 Project Structure
|
|
149
78
|
|
|
150
79
|
```
|
|
151
|
-
|
|
152
|
-
|
|
153
|
-
|
|
154
|
-
|
|
155
|
-
|
|
156
|
-
|
|
157
|
-
|
|
158
|
-
|
|
159
|
-
|
|
160
|
-
|
|
161
|
-
|
|
162
|
-
|
|
163
|
-
|
|
80
|
+
.kiro/
|
|
81
|
+
├── README.md # This file - project development guide
|
|
82
|
+
├── specs/ # All Specs live here
|
|
83
|
+
│ └── {spec-name}/ # Individual Spec
|
|
84
|
+
│ ├── requirements.md # What we're building
|
|
85
|
+
│ ├── design.md # How we'll build it
|
|
86
|
+
│ ├── tasks.md # Implementation steps
|
|
87
|
+
│ └── ... # Other artifacts
|
|
88
|
+
├── steering/ # Development rules
|
|
89
|
+
│ ├── CORE_PRINCIPLES.md # Core development principles
|
|
90
|
+
│ ├── ENVIRONMENT.md # Project environment
|
|
91
|
+
│ └── CURRENT_CONTEXT.md # Current work context
|
|
92
|
+
└── tools/ # Tool configurations
|
|
164
93
|
```
|
|
165
94
|
|
|
166
|
-
|
|
167
|
-
|
|
168
|
-
|
|
169
|
-
-
|
|
170
|
-
- ✅ 产物有上下文,易于理解和维护
|
|
171
|
-
- ✅ 可以追溯需求和设计决策
|
|
172
|
-
- ✅ 团队协作更清晰
|
|
173
|
-
- ✅ 知识沉淀在 Spec 中
|
|
174
|
-
|
|
175
|
-
**不用 Spec 的问题**:
|
|
176
|
-
- ❌ 脚本散落在项目各处,难以查找
|
|
177
|
-
- ❌ 缺乏上下文,不知道为什么要这样做
|
|
178
|
-
- ❌ 无法追溯需求来源
|
|
179
|
-
- ❌ 临时文件堆积,项目混乱
|
|
180
|
-
- ❌ 知识流失
|
|
95
|
+
**Key files:**
|
|
96
|
+
- `.kiro/steering/CORE_PRINCIPLES.md` - Development principles for this project
|
|
97
|
+
- `.kiro/steering/CURRENT_CONTEXT.md` - What we're currently working on
|
|
98
|
+
- `.kiro/specs/{spec-name}/` - Feature specifications
|
|
181
99
|
|
|
182
100
|
---
|
|
183
101
|
|
|
184
|
-
##
|
|
185
|
-
|
|
186
|
-
### 1. 主动管控 Token
|
|
187
|
-
|
|
188
|
-
**时机**:
|
|
189
|
-
- 每完成一组任务后:精简 tasks.md
|
|
190
|
-
- 每完成一个阶段后:精简 CURRENT_CONTEXT
|
|
191
|
-
- 发现 token 使用率 > 50% 时:立即精简
|
|
192
|
-
- 阶段切换时:更新 CURRENT_CONTEXT 聚焦新阶段
|
|
193
|
-
|
|
194
|
-
**策略**:
|
|
195
|
-
- ❌ 删除:已完成阶段的详细配置、命令、表格
|
|
196
|
-
- ❌ 删除:历史测试数据和性能对比表格
|
|
197
|
-
- ❌ 删除:详细的问题排查流程和检查清单
|
|
198
|
-
- ✅ 保留:当前阶段的核心信息和关键经验
|
|
199
|
-
|
|
200
|
-
### 2. 保持 Steering 精简
|
|
102
|
+
## 📖 What is a Spec?
|
|
201
103
|
|
|
202
|
-
|
|
203
|
-
- CURRENT_CONTEXT 只保留当前信息
|
|
204
|
-
- 历史数据归档到 Spec 目录
|
|
205
|
-
- 详细配置放到 Spec 文档中
|
|
104
|
+
A Spec is a complete feature definition with three parts:
|
|
206
105
|
|
|
207
|
-
|
|
208
|
-
-
|
|
209
|
-
-
|
|
210
|
-
-
|
|
211
|
-
-
|
|
106
|
+
### 1. requirements.md - WHAT we're building
|
|
107
|
+
- User stories
|
|
108
|
+
- Functional requirements
|
|
109
|
+
- Acceptance criteria
|
|
110
|
+
- Non-functional requirements
|
|
212
111
|
|
|
213
|
-
###
|
|
112
|
+
### 2. design.md - HOW we'll build it
|
|
113
|
+
- Architecture
|
|
114
|
+
- Component design
|
|
115
|
+
- API design
|
|
116
|
+
- Technology choices
|
|
214
117
|
|
|
215
|
-
|
|
216
|
-
-
|
|
217
|
-
-
|
|
218
|
-
-
|
|
118
|
+
### 3. tasks.md - Implementation steps
|
|
119
|
+
- Ordered task list
|
|
120
|
+
- Task dependencies
|
|
121
|
+
- Implementation notes
|
|
219
122
|
|
|
220
|
-
|
|
221
|
-
-
|
|
222
|
-
-
|
|
223
|
-
-
|
|
224
|
-
|
|
225
|
-
### 4. 知识的沉淀
|
|
226
|
-
|
|
227
|
-
**原则**:
|
|
228
|
-
- 通用经验沉淀到 CORE_PRINCIPLES
|
|
229
|
-
- Spec 特定经验保留在 Spec 目录
|
|
230
|
-
- 定期回顾和更新规范
|
|
231
|
-
|
|
232
|
-
**时机**:
|
|
233
|
-
- Spec 完成后:总结经验教训
|
|
234
|
-
- 新 Spec 开始前:评估现有规则是否适用
|
|
235
|
-
- 发现重复问题时:更新 CORE_PRINCIPLES
|
|
123
|
+
**Task status:**
|
|
124
|
+
- `- [ ]` Not started
|
|
125
|
+
- `- [-]` In progress
|
|
126
|
+
- `- [x]` Completed
|
|
236
127
|
|
|
237
128
|
---
|
|
238
129
|
|
|
239
|
-
##
|
|
130
|
+
## 💡 Working with This Project
|
|
240
131
|
|
|
241
|
-
###
|
|
132
|
+
### DO:
|
|
133
|
+
- ✅ Check for existing Specs before starting work
|
|
134
|
+
- ✅ Follow requirements and design in Specs
|
|
135
|
+
- ✅ Update task status as you work
|
|
136
|
+
- ✅ Read steering rules for project-specific guidelines
|
|
137
|
+
- ✅ Ask user if requirements are unclear
|
|
242
138
|
|
|
243
|
-
|
|
244
|
-
-
|
|
245
|
-
-
|
|
139
|
+
### DON'T:
|
|
140
|
+
- ❌ Start implementing without understanding requirements
|
|
141
|
+
- ❌ Ignore the design document
|
|
142
|
+
- ❌ Create files in wrong locations
|
|
143
|
+
- ❌ Skip updating task status
|
|
246
144
|
|
|
247
|
-
|
|
248
|
-
- 立即精简 CURRENT_CONTEXT
|
|
249
|
-
- 将详细数据归档到 Spec 目录
|
|
250
|
-
- 只保留当前阶段的核心信息
|
|
145
|
+
---
|
|
251
146
|
|
|
252
|
-
|
|
147
|
+
## 🔍 Finding Information
|
|
253
148
|
|
|
254
|
-
|
|
255
|
-
-
|
|
256
|
-
- 文件组织混乱
|
|
149
|
+
**Need to understand a feature?**
|
|
150
|
+
→ Read `.kiro/specs/{spec-name}/requirements.md` and `design.md`
|
|
257
151
|
|
|
258
|
-
|
|
259
|
-
|
|
260
|
-
- 按照规范重新组织文件
|
|
261
|
-
- 将散落的产物归档到 Spec 目录
|
|
152
|
+
**Need to know what to work on?**
|
|
153
|
+
→ Read `.kiro/specs/{spec-name}/tasks.md`
|
|
262
154
|
|
|
263
|
-
|
|
155
|
+
**Need project context?**
|
|
156
|
+
→ Read `.kiro/steering/CURRENT_CONTEXT.md`
|
|
264
157
|
|
|
265
|
-
|
|
266
|
-
|
|
267
|
-
- 缺乏上下文,难以理解
|
|
158
|
+
**Need development rules?**
|
|
159
|
+
→ Read `.kiro/steering/CORE_PRINCIPLES.md`
|
|
268
160
|
|
|
269
|
-
|
|
270
|
-
|
|
271
|
-
- 不要在根目录生成临时文件
|
|
272
|
-
- 遵循 Spec 驱动开发原则
|
|
161
|
+
**Need to check status?**
|
|
162
|
+
→ Run `kse status`
|
|
273
163
|
|
|
274
164
|
---
|
|
275
165
|
|
|
276
|
-
##
|
|
166
|
+
## 🚀 Quick Start for AI
|
|
167
|
+
|
|
168
|
+
1. **User asks you to implement something**
|
|
169
|
+
2. **You check**: Does a Spec exist for this? (`kse workflows` or check `.kiro/specs/`)
|
|
170
|
+
3. **If yes**: Read the Spec and implement according to it
|
|
171
|
+
4. **If no**: Suggest creating a Spec first, help user define it
|
|
172
|
+
5. **While working**: Update task status in `tasks.md`
|
|
173
|
+
6. **When done**: Mark tasks complete
|
|
277
174
|
|
|
278
|
-
|
|
279
|
-
- **核心开发原则**: `.kiro/steering/CORE_PRINCIPLES.md`
|
|
280
|
-
- **环境配置**: `.kiro/steering/ENVIRONMENT.md`
|
|
281
|
-
- **当前场景**: `.kiro/steering/CURRENT_CONTEXT.md`
|
|
282
|
-
- **Spec 工作流指南**: `.kiro/specs/SPEC_WORKFLOW_GUIDE.md`
|
|
175
|
+
**Remember**: You're not just writing code, you're following a structured development process. The Spec is your guide.
|
|
283
176
|
|
|
284
177
|
---
|
|
285
178
|
|
|
286
|
-
|
|
287
|
-
|
|
288
|
-
|
|
179
|
+
**Project Type**: Spec-driven development
|
|
180
|
+
**Last Updated**: 2026-01-24
|
|
181
|
+
**Purpose**: Guide AI tools to work effectively with this project
|