specpulse 1.0.3__tar.gz → 1.0.4__tar.gz
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.
- {specpulse-1.0.3/specpulse.egg-info → specpulse-1.0.4}/PKG-INFO +48 -34
- {specpulse-1.0.3 → specpulse-1.0.4}/README.md +47 -33
- {specpulse-1.0.3 → specpulse-1.0.4}/pyproject.toml +1 -1
- {specpulse-1.0.3 → specpulse-1.0.4}/specpulse/__init__.py +1 -1
- specpulse-1.0.4/specpulse/resources/commands/claude/plan.md +73 -0
- specpulse-1.0.4/specpulse/resources/commands/claude/pulse.md +52 -0
- specpulse-1.0.4/specpulse/resources/commands/claude/spec.md +81 -0
- specpulse-1.0.4/specpulse/resources/commands/claude/task.md +78 -0
- specpulse-1.0.4/specpulse/resources/commands/gemini/plan.toml +51 -0
- specpulse-1.0.4/specpulse/resources/commands/gemini/pulse.toml +24 -0
- specpulse-1.0.4/specpulse/resources/commands/gemini/spec.toml +37 -0
- specpulse-1.0.4/specpulse/resources/commands/gemini/task.toml +57 -0
- {specpulse-1.0.3 → specpulse-1.0.4/specpulse.egg-info}/PKG-INFO +48 -34
- {specpulse-1.0.3 → specpulse-1.0.4}/specpulse.egg-info/SOURCES.txt +16 -1
- specpulse-1.0.4/tests/test_100_coverage.py +328 -0
- specpulse-1.0.4/tests/test_100_percent_coverage.py +461 -0
- specpulse-1.0.4/tests/test_ai_commands.py +136 -0
- specpulse-1.0.4/tests/test_cli_advanced.py +277 -0
- specpulse-1.0.4/tests/test_cli_comprehensive.py +611 -0
- specpulse-1.0.4/tests/test_command_integration.py +182 -0
- specpulse-1.0.4/tests/test_complete_coverage.py +338 -0
- specpulse-1.0.4/tests/test_console_advanced.py +230 -0
- specpulse-1.0.4/tests/test_console_comprehensive.py +561 -0
- specpulse-1.0.4/tests/test_core_comprehensive.py +486 -0
- specpulse-1.0.4/tests/test_full_coverage.py +541 -0
- specpulse-1.0.4/tests/test_gemini_commands.py +130 -0
- specpulse-1.0.4/tests/test_git_utils.py +270 -0
- specpulse-1.0.4/tests/test_git_utils_comprehensive.py +698 -0
- specpulse-1.0.4/tests/test_validator_comprehensive.py +613 -0
- specpulse-1.0.3/specpulse/resources/commands/claude/plan.md +0 -54
- specpulse-1.0.3/specpulse/resources/commands/claude/pulse.md +0 -36
- specpulse-1.0.3/specpulse/resources/commands/claude/spec.md +0 -47
- specpulse-1.0.3/specpulse/resources/commands/claude/task.md +0 -56
- specpulse-1.0.3/specpulse/resources/commands/gemini/plan.toml +0 -48
- specpulse-1.0.3/specpulse/resources/commands/gemini/pulse.toml +0 -45
- specpulse-1.0.3/specpulse/resources/commands/gemini/spec.toml +0 -33
- specpulse-1.0.3/specpulse/resources/commands/gemini/task.toml +0 -51
- {specpulse-1.0.3 → specpulse-1.0.4}/LICENSE +0 -0
- {specpulse-1.0.3 → specpulse-1.0.4}/MANIFEST.in +0 -0
- {specpulse-1.0.3 → specpulse-1.0.4}/requirements.txt +0 -0
- {specpulse-1.0.3 → specpulse-1.0.4}/setup.cfg +0 -0
- {specpulse-1.0.3 → specpulse-1.0.4}/setup.py +0 -0
- {specpulse-1.0.3 → specpulse-1.0.4}/specpulse/cli/__init__.py +0 -0
- {specpulse-1.0.3 → specpulse-1.0.4}/specpulse/cli/main.py +0 -0
- {specpulse-1.0.3 → specpulse-1.0.4}/specpulse/core/__init__.py +0 -0
- {specpulse-1.0.3 → specpulse-1.0.4}/specpulse/core/specpulse.py +0 -0
- {specpulse-1.0.3 → specpulse-1.0.4}/specpulse/core/validator.py +0 -0
- {specpulse-1.0.3 → specpulse-1.0.4}/specpulse/resources/memory/constitution.md +0 -0
- {specpulse-1.0.3 → specpulse-1.0.4}/specpulse/resources/memory/context.md +0 -0
- {specpulse-1.0.3 → specpulse-1.0.4}/specpulse/resources/memory/decisions.md +0 -0
- {specpulse-1.0.3 → specpulse-1.0.4}/specpulse/resources/scripts/pulse-init.sh +0 -0
- {specpulse-1.0.3 → specpulse-1.0.4}/specpulse/resources/scripts/pulse-plan.sh +0 -0
- {specpulse-1.0.3 → specpulse-1.0.4}/specpulse/resources/scripts/pulse-spec.sh +0 -0
- {specpulse-1.0.3 → specpulse-1.0.4}/specpulse/resources/scripts/pulse-task.sh +0 -0
- {specpulse-1.0.3 → specpulse-1.0.4}/specpulse/resources/templates/plan.md +0 -0
- {specpulse-1.0.3 → specpulse-1.0.4}/specpulse/resources/templates/spec.md +0 -0
- {specpulse-1.0.3 → specpulse-1.0.4}/specpulse/resources/templates/task.md +0 -0
- {specpulse-1.0.3 → specpulse-1.0.4}/specpulse/utils/__init__.py +0 -0
- {specpulse-1.0.3 → specpulse-1.0.4}/specpulse/utils/console.py +0 -0
- {specpulse-1.0.3 → specpulse-1.0.4}/specpulse/utils/git_utils.py +0 -0
- {specpulse-1.0.3 → specpulse-1.0.4}/specpulse.egg-info/dependency_links.txt +0 -0
- {specpulse-1.0.3 → specpulse-1.0.4}/specpulse.egg-info/entry_points.txt +0 -0
- {specpulse-1.0.3 → specpulse-1.0.4}/specpulse.egg-info/not-zip-safe +0 -0
- {specpulse-1.0.3 → specpulse-1.0.4}/specpulse.egg-info/requires.txt +0 -0
- {specpulse-1.0.3 → specpulse-1.0.4}/specpulse.egg-info/top_level.txt +0 -0
- {specpulse-1.0.3 → specpulse-1.0.4}/tests/test_cli.py +0 -0
- {specpulse-1.0.3 → specpulse-1.0.4}/tests/test_core.py +0 -0
@@ -1,6 +1,6 @@
|
|
1
1
|
Metadata-Version: 2.4
|
2
2
|
Name: specpulse
|
3
|
-
Version: 1.0.
|
3
|
+
Version: 1.0.4
|
4
4
|
Summary: Specification-Driven Development Framework
|
5
5
|
Home-page: https://github.com/specpulse
|
6
6
|
Author: SpecPulse
|
@@ -66,7 +66,11 @@ Dynamic: requires-python
|
|
66
66
|
|
67
67
|
SpecPulse revolutionizes AI-assisted development by enforcing a **specification-first approach**. Instead of jumping straight into code, SpecPulse ensures every feature starts with clear specifications, validated plans, and tracked tasks - guaranteeing quality from day one.
|
68
68
|
|
69
|
-
> **Latest Update (v1.0.
|
69
|
+
> **Latest Update (v1.0.4)**:
|
70
|
+
> - ✅ **100% Working AI Commands**: Both Claude and Gemini commands now properly support arguments
|
71
|
+
> - ✅ **95% Test Coverage**: Comprehensive test suite with 193+ tests
|
72
|
+
> - ✅ **Fixed Command Formats**: Claude uses `$ARGUMENTS`, Gemini uses `{{args}}`
|
73
|
+
> - ✅ **Enhanced Documentation**: Clearer examples and usage instructions
|
70
74
|
|
71
75
|
### Why SpecPulse?
|
72
76
|
|
@@ -114,25 +118,21 @@ specpulse init --ai gemini
|
|
114
118
|
|
115
119
|
```bash
|
116
120
|
# Initialize a new feature
|
117
|
-
/pulse
|
121
|
+
/pulse user-authentication
|
122
|
+
# Creates structure for 001-user-authentication feature
|
118
123
|
|
119
|
-
# Create the specification
|
120
|
-
/spec create
|
121
|
-
|
122
|
-
# Validate the specification
|
123
|
-
/spec validate
|
124
|
+
# Create the specification
|
125
|
+
/spec create user login with OAuth2 and email/password
|
126
|
+
# Or just: /spec (for interactive mode)
|
124
127
|
|
125
128
|
# Generate implementation plan
|
126
129
|
/plan generate
|
127
|
-
|
128
|
-
# Validate plan against constitution
|
129
|
-
/plan validate
|
130
|
+
# Or: /plan validate (to check existing plan)
|
130
131
|
|
131
132
|
# Break down into tasks
|
132
133
|
/task breakdown
|
133
|
-
|
134
|
-
#
|
135
|
-
/task status
|
134
|
+
# Or: /task update (to update task status)
|
135
|
+
# Or: /task status (to see progress)
|
136
136
|
```
|
137
137
|
|
138
138
|
### Step 4: Validate & Ship
|
@@ -244,28 +244,41 @@ Stop guessing what users want:
|
|
244
244
|
|
245
245
|
### 🤖 Deep AI Integration
|
246
246
|
|
247
|
-
**
|
247
|
+
**How AI Commands Work:**
|
248
|
+
|
249
|
+
Claude and Gemini use slash commands that accept arguments via `$ARGUMENTS`:
|
250
|
+
|
248
251
|
```bash
|
249
|
-
#
|
250
|
-
/
|
251
|
-
|
252
|
-
#
|
253
|
-
/
|
254
|
-
/
|
255
|
-
/
|
256
|
-
|
257
|
-
#
|
258
|
-
/plan generate # Create implementation plan from spec
|
259
|
-
/plan validate # Validate plan against constitution
|
260
|
-
|
261
|
-
# Task management
|
262
|
-
/task breakdown # Generate tasks from plan
|
263
|
-
/task update # Update task status
|
264
|
-
/task status # Show task progress
|
252
|
+
/pulse user-authentication # Start new feature with name
|
253
|
+
/spec create OAuth2 login # Create specification with description
|
254
|
+
/spec update # Update existing specification
|
255
|
+
/spec validate # Validate specification completeness
|
256
|
+
/plan generate # Generate plan from specification
|
257
|
+
/plan validate # Validate plan against constitution
|
258
|
+
/task breakdown # Create task list from plan
|
259
|
+
/task update # Update task statuses
|
260
|
+
/task status # Show current progress
|
265
261
|
```
|
266
262
|
|
267
|
-
**
|
268
|
-
|
263
|
+
**Behind the Scenes:**
|
264
|
+
- Commands capture arguments using `$ARGUMENTS` variable
|
265
|
+
- Shell scripts in `scripts/` folder process the arguments
|
266
|
+
- AI reads templates from `templates/` folder
|
267
|
+
- Results are saved in `specs/`, `plans/`, `tasks/` folders
|
268
|
+
- Memory system tracks progress in `memory/` folder
|
269
|
+
|
270
|
+
**Claude vs Gemini:**
|
271
|
+
- **Claude**: Uses Markdown command files (`.claude/commands/*.md`) with YAML frontmatter
|
272
|
+
- Arguments passed via `$ARGUMENTS` variable to shell scripts
|
273
|
+
- **Gemini**: Uses TOML command files (`.gemini/commands/*.toml`) with simple format
|
274
|
+
- Arguments handled via `{{args}}` placeholder in prompts
|
275
|
+
- Both support arguments and work the same way from user perspective
|
276
|
+
|
277
|
+
**Command Arguments:**
|
278
|
+
- Commands can accept arguments: `/command arg1 arg2`
|
279
|
+
- Claude: Arguments passed to scripts via `$ARGUMENTS`
|
280
|
+
- Gemini: Arguments injected via `{{args}}` placeholder
|
281
|
+
- Commands can be used without arguments for interactive mode
|
269
282
|
|
270
283
|
## 📊 Real-World Impact
|
271
284
|
|
@@ -425,7 +438,8 @@ Built with inspiration from:
|
|
425
438
|
## 🚦 Project Status
|
426
439
|
|
427
440
|
[](https://github.com/specpulse/specpulse)
|
428
|
-
[](https://github.com/specpulse/specpulse)
|
442
|
+
[](https://github.com/specpulse/specpulse)
|
429
443
|
[](https://github.com/specpulse/specpulse)
|
430
444
|
|
431
445
|
---
|
@@ -21,7 +21,11 @@
|
|
21
21
|
|
22
22
|
SpecPulse revolutionizes AI-assisted development by enforcing a **specification-first approach**. Instead of jumping straight into code, SpecPulse ensures every feature starts with clear specifications, validated plans, and tracked tasks - guaranteeing quality from day one.
|
23
23
|
|
24
|
-
> **Latest Update (v1.0.
|
24
|
+
> **Latest Update (v1.0.4)**:
|
25
|
+
> - ✅ **100% Working AI Commands**: Both Claude and Gemini commands now properly support arguments
|
26
|
+
> - ✅ **95% Test Coverage**: Comprehensive test suite with 193+ tests
|
27
|
+
> - ✅ **Fixed Command Formats**: Claude uses `$ARGUMENTS`, Gemini uses `{{args}}`
|
28
|
+
> - ✅ **Enhanced Documentation**: Clearer examples and usage instructions
|
25
29
|
|
26
30
|
### Why SpecPulse?
|
27
31
|
|
@@ -69,25 +73,21 @@ specpulse init --ai gemini
|
|
69
73
|
|
70
74
|
```bash
|
71
75
|
# Initialize a new feature
|
72
|
-
/pulse
|
76
|
+
/pulse user-authentication
|
77
|
+
# Creates structure for 001-user-authentication feature
|
73
78
|
|
74
|
-
# Create the specification
|
75
|
-
/spec create
|
76
|
-
|
77
|
-
# Validate the specification
|
78
|
-
/spec validate
|
79
|
+
# Create the specification
|
80
|
+
/spec create user login with OAuth2 and email/password
|
81
|
+
# Or just: /spec (for interactive mode)
|
79
82
|
|
80
83
|
# Generate implementation plan
|
81
84
|
/plan generate
|
82
|
-
|
83
|
-
# Validate plan against constitution
|
84
|
-
/plan validate
|
85
|
+
# Or: /plan validate (to check existing plan)
|
85
86
|
|
86
87
|
# Break down into tasks
|
87
88
|
/task breakdown
|
88
|
-
|
89
|
-
#
|
90
|
-
/task status
|
89
|
+
# Or: /task update (to update task status)
|
90
|
+
# Or: /task status (to see progress)
|
91
91
|
```
|
92
92
|
|
93
93
|
### Step 4: Validate & Ship
|
@@ -199,28 +199,41 @@ Stop guessing what users want:
|
|
199
199
|
|
200
200
|
### 🤖 Deep AI Integration
|
201
201
|
|
202
|
-
**
|
202
|
+
**How AI Commands Work:**
|
203
|
+
|
204
|
+
Claude and Gemini use slash commands that accept arguments via `$ARGUMENTS`:
|
205
|
+
|
203
206
|
```bash
|
204
|
-
#
|
205
|
-
/
|
206
|
-
|
207
|
-
#
|
208
|
-
/
|
209
|
-
/
|
210
|
-
/
|
211
|
-
|
212
|
-
#
|
213
|
-
/plan generate # Create implementation plan from spec
|
214
|
-
/plan validate # Validate plan against constitution
|
215
|
-
|
216
|
-
# Task management
|
217
|
-
/task breakdown # Generate tasks from plan
|
218
|
-
/task update # Update task status
|
219
|
-
/task status # Show task progress
|
207
|
+
/pulse user-authentication # Start new feature with name
|
208
|
+
/spec create OAuth2 login # Create specification with description
|
209
|
+
/spec update # Update existing specification
|
210
|
+
/spec validate # Validate specification completeness
|
211
|
+
/plan generate # Generate plan from specification
|
212
|
+
/plan validate # Validate plan against constitution
|
213
|
+
/task breakdown # Create task list from plan
|
214
|
+
/task update # Update task statuses
|
215
|
+
/task status # Show current progress
|
220
216
|
```
|
221
217
|
|
222
|
-
**
|
223
|
-
|
218
|
+
**Behind the Scenes:**
|
219
|
+
- Commands capture arguments using `$ARGUMENTS` variable
|
220
|
+
- Shell scripts in `scripts/` folder process the arguments
|
221
|
+
- AI reads templates from `templates/` folder
|
222
|
+
- Results are saved in `specs/`, `plans/`, `tasks/` folders
|
223
|
+
- Memory system tracks progress in `memory/` folder
|
224
|
+
|
225
|
+
**Claude vs Gemini:**
|
226
|
+
- **Claude**: Uses Markdown command files (`.claude/commands/*.md`) with YAML frontmatter
|
227
|
+
- Arguments passed via `$ARGUMENTS` variable to shell scripts
|
228
|
+
- **Gemini**: Uses TOML command files (`.gemini/commands/*.toml`) with simple format
|
229
|
+
- Arguments handled via `{{args}}` placeholder in prompts
|
230
|
+
- Both support arguments and work the same way from user perspective
|
231
|
+
|
232
|
+
**Command Arguments:**
|
233
|
+
- Commands can accept arguments: `/command arg1 arg2`
|
234
|
+
- Claude: Arguments passed to scripts via `$ARGUMENTS`
|
235
|
+
- Gemini: Arguments injected via `{{args}}` placeholder
|
236
|
+
- Commands can be used without arguments for interactive mode
|
224
237
|
|
225
238
|
## 📊 Real-World Impact
|
226
239
|
|
@@ -380,7 +393,8 @@ Built with inspiration from:
|
|
380
393
|
## 🚦 Project Status
|
381
394
|
|
382
395
|
[](https://github.com/specpulse/specpulse)
|
383
|
-
[](https://github.com/specpulse/specpulse)
|
397
|
+
[](https://github.com/specpulse/specpulse)
|
384
398
|
[](https://github.com/specpulse/specpulse)
|
385
399
|
|
386
400
|
---
|
@@ -0,0 +1,73 @@
|
|
1
|
+
---
|
2
|
+
name: plan
|
3
|
+
description: Generate or validate implementation plans
|
4
|
+
allowed_tools:
|
5
|
+
- Read
|
6
|
+
- Write
|
7
|
+
- Edit
|
8
|
+
- Bash
|
9
|
+
---
|
10
|
+
|
11
|
+
# /plan Command
|
12
|
+
|
13
|
+
Generate implementation plans from specifications following SpecPulse methodology.
|
14
|
+
|
15
|
+
## Usage
|
16
|
+
```
|
17
|
+
/plan [action]
|
18
|
+
```
|
19
|
+
|
20
|
+
Actions: `generate`, `validate` (defaults to `generate`)
|
21
|
+
|
22
|
+
## Implementation
|
23
|
+
|
24
|
+
When called with `/plan $ARGUMENTS`, I will:
|
25
|
+
|
26
|
+
1. **Parse arguments** to determine action:
|
27
|
+
- If `$ARGUMENTS` is `validate`: Check plan against constitution
|
28
|
+
- Otherwise: Generate new plan
|
29
|
+
|
30
|
+
2. **For `/plan generate` or `/plan`:**
|
31
|
+
a. **Read current specification** from `specs/XXX-feature/spec.md`
|
32
|
+
|
33
|
+
b. **Run Phase Gates checks**:
|
34
|
+
- Constitutional compliance
|
35
|
+
- Simplicity check (≤3 modules)
|
36
|
+
- Test-first strategy defined
|
37
|
+
- Framework selection complete
|
38
|
+
- Research completed
|
39
|
+
|
40
|
+
c. **Generate plan sections**:
|
41
|
+
- Technology stack
|
42
|
+
- Architecture overview
|
43
|
+
- Implementation phases
|
44
|
+
- API contracts
|
45
|
+
- Data models
|
46
|
+
- Testing strategy
|
47
|
+
|
48
|
+
d. **Track complexity**:
|
49
|
+
- If >3 modules, document justification
|
50
|
+
- Create simplification roadmap
|
51
|
+
|
52
|
+
e. **Write plan** to `plans/XXX-feature/plan.md`
|
53
|
+
|
54
|
+
3. **For `/plan validate`:**
|
55
|
+
- Read existing plan from `plans/XXX-feature/plan.md`
|
56
|
+
- Verify Phase Gates compliance
|
57
|
+
- Check complexity tracking
|
58
|
+
- Ensure test-first approach
|
59
|
+
- Validate framework choices
|
60
|
+
- Report validation results
|
61
|
+
|
62
|
+
## Phase Gates (Phase -1)
|
63
|
+
Must pass before implementation:
|
64
|
+
- ✅ Using ≤3 projects/modules
|
65
|
+
- ✅ Tests defined before code
|
66
|
+
- ✅ Using framework features directly
|
67
|
+
- ✅ No premature abstractions
|
68
|
+
- ✅ Research completed
|
69
|
+
|
70
|
+
## Example
|
71
|
+
```
|
72
|
+
/plan generate
|
73
|
+
```
|
@@ -0,0 +1,52 @@
|
|
1
|
+
---
|
2
|
+
name: pulse
|
3
|
+
description: Initialize a new feature with SpecPulse framework
|
4
|
+
allowed_tools:
|
5
|
+
- Bash
|
6
|
+
- Read
|
7
|
+
- Write
|
8
|
+
- Edit
|
9
|
+
---
|
10
|
+
|
11
|
+
# /pulse Command
|
12
|
+
|
13
|
+
Initialize a new feature following SpecPulse methodology.
|
14
|
+
|
15
|
+
## Usage
|
16
|
+
```
|
17
|
+
/pulse <feature-name>
|
18
|
+
```
|
19
|
+
|
20
|
+
## Implementation
|
21
|
+
|
22
|
+
When called with `/pulse $ARGUMENTS`, I will:
|
23
|
+
|
24
|
+
1. **Extract feature name** from `$ARGUMENTS`
|
25
|
+
2. **Run initialization script**: `bash scripts/pulse-init.sh "$ARGUMENTS"`
|
26
|
+
3. **Create feature structure**:
|
27
|
+
- Generate feature ID (001, 002, etc.)
|
28
|
+
- Create directories: `specs/XXX-feature/`, `plans/XXX-feature/`, `tasks/XXX-feature/`
|
29
|
+
- Copy templates to feature directories
|
30
|
+
- Update `memory/context.md` with current feature
|
31
|
+
- Create git branch if in git repository
|
32
|
+
|
33
|
+
4. **Report results** to user with created structure
|
34
|
+
|
35
|
+
## Example
|
36
|
+
```
|
37
|
+
User: /pulse user-authentication
|
38
|
+
```
|
39
|
+
|
40
|
+
I will:
|
41
|
+
- Run: `bash scripts/pulse-init.sh "user-authentication"`
|
42
|
+
- Create: `specs/001-user-authentication/spec.md`
|
43
|
+
- Create: `plans/001-user-authentication/plan.md`
|
44
|
+
- Create: `tasks/001-user-authentication/tasks.md`
|
45
|
+
- Switch to branch: `001-user-authentication` (if git)
|
46
|
+
- Report success and next steps
|
47
|
+
|
48
|
+
## Next Steps
|
49
|
+
After initialization:
|
50
|
+
- Use `/spec` to create the specification
|
51
|
+
- Use `/plan` to generate implementation plan
|
52
|
+
- Use `/task` to break down into tasks
|
@@ -0,0 +1,81 @@
|
|
1
|
+
---
|
2
|
+
name: spec
|
3
|
+
description: Create or manage feature specifications
|
4
|
+
allowed_tools:
|
5
|
+
- Read
|
6
|
+
- Write
|
7
|
+
- Edit
|
8
|
+
- Bash
|
9
|
+
---
|
10
|
+
|
11
|
+
# /spec Command
|
12
|
+
|
13
|
+
Create, update, or validate feature specifications using SpecPulse methodology.
|
14
|
+
|
15
|
+
## Usage
|
16
|
+
```
|
17
|
+
/spec [action] [description]
|
18
|
+
```
|
19
|
+
|
20
|
+
Actions: `create`, `update`, `validate` (defaults to `create`)
|
21
|
+
|
22
|
+
## Implementation
|
23
|
+
|
24
|
+
When called with `/spec $ARGUMENTS`, I will:
|
25
|
+
|
26
|
+
1. **Parse arguments** to determine action:
|
27
|
+
- If starts with `create`: Generate new specification
|
28
|
+
- If starts with `update`: Modify existing specification
|
29
|
+
- If starts with `validate`: Check specification completeness
|
30
|
+
- If no action specified: Default to `create` with full arguments as description
|
31
|
+
|
32
|
+
2. **For `/spec create [description]` or `/spec [description]`:**
|
33
|
+
- Read template from `templates/spec.md`
|
34
|
+
- Parse the description to identify:
|
35
|
+
- Functional requirements (Must/Should/Could have)
|
36
|
+
- User stories and acceptance criteria
|
37
|
+
- Technical requirements
|
38
|
+
- Mark any uncertainties with `[NEEDS CLARIFICATION: detail]`
|
39
|
+
- Find current feature directory (latest in specs/)
|
40
|
+
- Write specification to `specs/XXX-feature/spec.md`
|
41
|
+
|
42
|
+
3. **For `/spec update`:**
|
43
|
+
- Read existing specification
|
44
|
+
- Ask user for clarifications or changes
|
45
|
+
- Update content while preserving structure
|
46
|
+
- Remove resolved `[NEEDS CLARIFICATION]` markers
|
47
|
+
|
48
|
+
4. **For `/spec validate`:**
|
49
|
+
- Check all required sections are filled
|
50
|
+
- Count `[NEEDS CLARIFICATION]` markers
|
51
|
+
- Verify acceptance criteria are testable
|
52
|
+
- Report validation results
|
53
|
+
|
54
|
+
## Examples
|
55
|
+
|
56
|
+
### Creating a new specification
|
57
|
+
```
|
58
|
+
User: /spec user authentication with OAuth2 and email/password
|
59
|
+
```
|
60
|
+
I will create a comprehensive specification with all requirements.
|
61
|
+
|
62
|
+
### Updating existing specification
|
63
|
+
```
|
64
|
+
User: /spec update
|
65
|
+
```
|
66
|
+
I will read the current spec and guide through updates.
|
67
|
+
|
68
|
+
### Validating specification
|
69
|
+
```
|
70
|
+
User: /spec validate
|
71
|
+
```
|
72
|
+
I will check completeness and report any issues.
|
73
|
+
|
74
|
+
## Template Structure
|
75
|
+
The specification follows this structure:
|
76
|
+
- Project Overview
|
77
|
+
- Functional Requirements (Must/Should/Could have)
|
78
|
+
- User Stories with Acceptance Criteria
|
79
|
+
- Technical Specifications
|
80
|
+
- Clarifications Needed
|
81
|
+
- Validation Checklist
|
@@ -0,0 +1,78 @@
|
|
1
|
+
---
|
2
|
+
name: task
|
3
|
+
description: Generate and manage task breakdowns
|
4
|
+
allowed_tools:
|
5
|
+
- Read
|
6
|
+
- Write
|
7
|
+
- Edit
|
8
|
+
- Bash
|
9
|
+
---
|
10
|
+
|
11
|
+
# /task Command
|
12
|
+
|
13
|
+
Generate task breakdowns from implementation plans using SpecPulse structure.
|
14
|
+
|
15
|
+
## Usage
|
16
|
+
```
|
17
|
+
/task [action]
|
18
|
+
```
|
19
|
+
|
20
|
+
Actions: `breakdown`, `update`, `status` (defaults to `breakdown`)
|
21
|
+
|
22
|
+
## Implementation
|
23
|
+
|
24
|
+
When called with `/task $ARGUMENTS`, I will:
|
25
|
+
|
26
|
+
1. **Parse arguments** to determine action:
|
27
|
+
- If `$ARGUMENTS` is `update`: Update task status
|
28
|
+
- If `$ARGUMENTS` is `status`: Show progress
|
29
|
+
- Otherwise: Generate task breakdown
|
30
|
+
|
31
|
+
2. **For `/task breakdown` or `/task`:**
|
32
|
+
|
33
|
+
a. **Read implementation plan** from `plans/XXX-feature/plan.md`
|
34
|
+
|
35
|
+
b. **Generate tasks from plan**:
|
36
|
+
- Create task categories:
|
37
|
+
- Critical Path (Phase 0)
|
38
|
+
- Phase 1: Foundation
|
39
|
+
- Phase 2: Core Features
|
40
|
+
- Phase 3: Polish
|
41
|
+
- Phase 4: Testing
|
42
|
+
|
43
|
+
- For each task:
|
44
|
+
- Use T[XXX] format (T001, T002)
|
45
|
+
- Include clear description
|
46
|
+
- Mark dependencies
|
47
|
+
- Estimate complexity (S/M/L/XL)
|
48
|
+
- Assign priority
|
49
|
+
|
50
|
+
c. **Write tasks** to `tasks/XXX-feature/tasks.md`
|
51
|
+
|
52
|
+
3. **For `/task update`:**
|
53
|
+
- Read current tasks from `tasks/XXX-feature/tasks.md`
|
54
|
+
- Ask which tasks to update
|
55
|
+
- Mark tasks as completed/in-progress
|
56
|
+
- Add newly discovered tasks
|
57
|
+
- Update dependencies and blockers
|
58
|
+
- Save updated task list
|
59
|
+
|
60
|
+
4. **For `/task status`:**
|
61
|
+
- Read current tasks
|
62
|
+
- Count completed vs total
|
63
|
+
- Show current phase progress
|
64
|
+
- List any blockers
|
65
|
+
- Estimate remaining work
|
66
|
+
- Display progress summary
|
67
|
+
|
68
|
+
## Task Format
|
69
|
+
```markdown
|
70
|
+
- [ ] T001: [S] Set up project structure
|
71
|
+
- [ ] T002: [M] Create database schema
|
72
|
+
- [x] T003: [L] Implement authentication
|
73
|
+
```
|
74
|
+
|
75
|
+
## Example
|
76
|
+
```
|
77
|
+
/task breakdown
|
78
|
+
```
|
@@ -0,0 +1,51 @@
|
|
1
|
+
description = "Generate or validate implementation plans"
|
2
|
+
prompt = """
|
3
|
+
Handle the /plan command with arguments: {{args}}
|
4
|
+
|
5
|
+
Parse arguments to determine action:
|
6
|
+
- If "validate": Check plan against constitution
|
7
|
+
- Otherwise: Generate new plan
|
8
|
+
|
9
|
+
## For /plan generate or /plan:
|
10
|
+
1. Read current specification from @{specs/*/spec.md}
|
11
|
+
|
12
|
+
2. Run Phase Gates checks:
|
13
|
+
- Constitutional compliance
|
14
|
+
- Simplicity check (≤3 modules)
|
15
|
+
- Test-first strategy defined
|
16
|
+
- Framework selection complete
|
17
|
+
- Research completed
|
18
|
+
|
19
|
+
3. Generate plan sections:
|
20
|
+
- Technology stack
|
21
|
+
- Architecture overview
|
22
|
+
- Implementation phases
|
23
|
+
- API contracts
|
24
|
+
- Data models
|
25
|
+
- Testing strategy
|
26
|
+
|
27
|
+
4. Track complexity:
|
28
|
+
- If >3 modules, document justification
|
29
|
+
- Create simplification roadmap
|
30
|
+
|
31
|
+
5. Write plan to plans/XXX-feature/plan.md
|
32
|
+
|
33
|
+
## For /plan validate:
|
34
|
+
1. Read existing plan from @{plans/*/plan.md}
|
35
|
+
2. Verify Phase Gates compliance
|
36
|
+
3. Check complexity tracking
|
37
|
+
4. Ensure test-first approach
|
38
|
+
5. Validate framework choices
|
39
|
+
6. Report validation results
|
40
|
+
|
41
|
+
Phase Gates (Phase -1) must pass before implementation:
|
42
|
+
- ✅ Using ≤3 projects/modules
|
43
|
+
- ✅ Tests defined before code
|
44
|
+
- ✅ Using framework features directly
|
45
|
+
- ✅ No premature abstractions
|
46
|
+
- ✅ Research completed
|
47
|
+
|
48
|
+
Examples:
|
49
|
+
- /plan generate
|
50
|
+
- /plan validate
|
51
|
+
"""
|
@@ -0,0 +1,24 @@
|
|
1
|
+
description = "Initialize a new feature with SpecPulse framework"
|
2
|
+
prompt = """
|
3
|
+
Initialize a new SpecPulse feature with the name: {{args}}
|
4
|
+
|
5
|
+
Please follow these steps:
|
6
|
+
|
7
|
+
1. Extract the feature name from the provided arguments
|
8
|
+
2. Run the initialization script: !{bash scripts/pulse-init.sh "{{args}}"}
|
9
|
+
3. Create the feature structure:
|
10
|
+
- Generate feature ID (001, 002, etc.)
|
11
|
+
- Create directories: specs/XXX-feature/, plans/XXX-feature/, tasks/XXX-feature/
|
12
|
+
- Copy templates to feature directories
|
13
|
+
- Update memory/context.md with current feature
|
14
|
+
- Create git branch if in git repository
|
15
|
+
|
16
|
+
4. Report the results showing:
|
17
|
+
- Created structure paths
|
18
|
+
- Feature ID and branch name
|
19
|
+
- Next steps for the user
|
20
|
+
|
21
|
+
If no feature name is provided, ask the user for the feature name first.
|
22
|
+
|
23
|
+
Example usage: /pulse user-authentication
|
24
|
+
"""
|
@@ -0,0 +1,37 @@
|
|
1
|
+
description = "Create or manage feature specifications"
|
2
|
+
prompt = """
|
3
|
+
Handle the /spec command with arguments: {{args}}
|
4
|
+
|
5
|
+
Parse the arguments to determine the action:
|
6
|
+
- If starts with "create": Generate new specification
|
7
|
+
- If starts with "update": Modify existing specification
|
8
|
+
- If starts with "validate": Check specification completeness
|
9
|
+
- If no action specified: Default to "create" with full arguments as description
|
10
|
+
|
11
|
+
## For /spec create [description] or /spec [description]:
|
12
|
+
1. Read template from @{templates/spec.md}
|
13
|
+
2. Parse the description to identify:
|
14
|
+
- Functional requirements (Must/Should/Could have)
|
15
|
+
- User stories and acceptance criteria
|
16
|
+
- Technical requirements
|
17
|
+
3. Mark any uncertainties with [NEEDS CLARIFICATION: detail]
|
18
|
+
4. Find current feature directory (latest in specs/)
|
19
|
+
5. Write specification to specs/XXX-feature/spec.md
|
20
|
+
|
21
|
+
## For /spec update:
|
22
|
+
1. Read existing specification from @{specs/*/spec.md}
|
23
|
+
2. Ask user for clarifications or changes
|
24
|
+
3. Update content while preserving structure
|
25
|
+
4. Remove resolved [NEEDS CLARIFICATION] markers
|
26
|
+
|
27
|
+
## For /spec validate:
|
28
|
+
1. Check all required sections are filled
|
29
|
+
2. Count [NEEDS CLARIFICATION] markers
|
30
|
+
3. Verify acceptance criteria are testable
|
31
|
+
4. Report validation results
|
32
|
+
|
33
|
+
Examples:
|
34
|
+
- /spec user authentication with OAuth2 and email/password
|
35
|
+
- /spec update
|
36
|
+
- /spec validate
|
37
|
+
"""
|