specpulse 1.0.3__py3-none-any.whl → 1.0.4__py3-none-any.whl
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/__init__.py +1 -1
- specpulse/resources/commands/claude/plan.md +36 -17
- specpulse/resources/commands/claude/pulse.md +37 -21
- specpulse/resources/commands/claude/spec.md +67 -33
- specpulse/resources/commands/claude/task.md +47 -25
- specpulse/resources/commands/gemini/plan.toml +51 -48
- specpulse/resources/commands/gemini/pulse.toml +18 -39
- specpulse/resources/commands/gemini/spec.toml +32 -28
- specpulse/resources/commands/gemini/task.toml +57 -51
- {specpulse-1.0.3.dist-info → specpulse-1.0.4.dist-info}/METADATA +48 -34
- {specpulse-1.0.3.dist-info → specpulse-1.0.4.dist-info}/RECORD +15 -15
- {specpulse-1.0.3.dist-info → specpulse-1.0.4.dist-info}/WHEEL +0 -0
- {specpulse-1.0.3.dist-info → specpulse-1.0.4.dist-info}/entry_points.txt +0 -0
- {specpulse-1.0.3.dist-info → specpulse-1.0.4.dist-info}/licenses/LICENSE +0 -0
- {specpulse-1.0.3.dist-info → specpulse-1.0.4.dist-info}/top_level.txt +0 -0
specpulse/__init__.py
CHANGED
@@ -1,25 +1,43 @@
|
|
1
|
-
|
1
|
+
---
|
2
|
+
name: plan
|
3
|
+
description: Generate or validate implementation plans
|
4
|
+
allowed_tools:
|
5
|
+
- Read
|
6
|
+
- Write
|
7
|
+
- Edit
|
8
|
+
- Bash
|
9
|
+
---
|
2
10
|
|
3
|
-
|
11
|
+
# /plan Command
|
12
|
+
|
13
|
+
Generate implementation plans from specifications following SpecPulse methodology.
|
4
14
|
|
5
15
|
## Usage
|
6
16
|
```
|
7
|
-
/plan
|
8
|
-
/plan validate
|
17
|
+
/plan [action]
|
9
18
|
```
|
10
19
|
|
11
|
-
|
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
|
12
29
|
|
13
|
-
|
14
|
-
|
15
|
-
|
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**:
|
16
34
|
- Constitutional compliance
|
17
35
|
- Simplicity check (≤3 modules)
|
18
36
|
- Test-first strategy defined
|
19
37
|
- Framework selection complete
|
20
38
|
- Research completed
|
21
39
|
|
22
|
-
|
40
|
+
c. **Generate plan sections**:
|
23
41
|
- Technology stack
|
24
42
|
- Architecture overview
|
25
43
|
- Implementation phases
|
@@ -27,18 +45,19 @@ Create implementation plan from specification:
|
|
27
45
|
- Data models
|
28
46
|
- Testing strategy
|
29
47
|
|
30
|
-
|
48
|
+
d. **Track complexity**:
|
31
49
|
- If >3 modules, document justification
|
32
50
|
- Create simplification roadmap
|
33
51
|
|
34
|
-
|
52
|
+
e. **Write plan** to `plans/XXX-feature/plan.md`
|
35
53
|
|
36
|
-
|
37
|
-
|
38
|
-
|
39
|
-
|
40
|
-
|
41
|
-
|
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
|
42
61
|
|
43
62
|
## Phase Gates (Phase -1)
|
44
63
|
Must pass before implementation:
|
@@ -1,36 +1,52 @@
|
|
1
|
-
|
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
|
+
---
|
2
10
|
|
3
|
-
|
11
|
+
# /pulse Command
|
12
|
+
|
13
|
+
Initialize a new feature following SpecPulse methodology.
|
4
14
|
|
5
15
|
## Usage
|
6
16
|
```
|
7
|
-
/pulse
|
17
|
+
/pulse <feature-name>
|
8
18
|
```
|
9
19
|
|
10
|
-
##
|
11
|
-
|
12
|
-
|
13
|
-
|
14
|
-
|
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/`
|
15
29
|
- Copy templates to feature directories
|
16
|
-
- Update memory/context.md
|
17
|
-
- Create git branch if in git
|
30
|
+
- Update `memory/context.md` with current feature
|
31
|
+
- Create git branch if in git repository
|
18
32
|
|
19
|
-
|
33
|
+
4. **Report results** to user with created structure
|
20
34
|
|
21
35
|
## Example
|
22
36
|
```
|
23
|
-
/pulse
|
37
|
+
User: /pulse user-authentication
|
24
38
|
```
|
25
39
|
|
26
|
-
|
27
|
-
-
|
28
|
-
- specs/001-user-authentication/spec.md
|
29
|
-
- plans/001-user-authentication/plan.md
|
30
|
-
- tasks/001-user-authentication/tasks.md
|
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
|
31
47
|
|
32
48
|
## Next Steps
|
33
|
-
After initialization
|
34
|
-
- `/spec
|
35
|
-
- `/plan
|
36
|
-
- `/task
|
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
|
@@ -1,47 +1,81 @@
|
|
1
|
-
|
1
|
+
---
|
2
|
+
name: spec
|
3
|
+
description: Create or manage feature specifications
|
4
|
+
allowed_tools:
|
5
|
+
- Read
|
6
|
+
- Write
|
7
|
+
- Edit
|
8
|
+
- Bash
|
9
|
+
---
|
2
10
|
|
3
|
-
|
11
|
+
# /spec Command
|
12
|
+
|
13
|
+
Create, update, or validate feature specifications using SpecPulse methodology.
|
4
14
|
|
5
15
|
## Usage
|
6
16
|
```
|
7
|
-
/spec
|
8
|
-
/spec update
|
9
|
-
/spec validate
|
17
|
+
/spec [action] [description]
|
10
18
|
```
|
11
19
|
|
12
|
-
|
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
|
13
55
|
|
14
|
-
###
|
15
|
-
|
16
|
-
|
17
|
-
|
18
|
-
|
19
|
-
4. Mark uncertainties with [NEEDS CLARIFICATION]
|
20
|
-
5. Write to specs/[feature]/spec.md
|
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.
|
21
61
|
|
22
|
-
###
|
23
|
-
|
24
|
-
|
25
|
-
|
26
|
-
|
27
|
-
4. Update acceptance criteria
|
62
|
+
### Updating existing specification
|
63
|
+
```
|
64
|
+
User: /spec update
|
65
|
+
```
|
66
|
+
I will read the current spec and guide through updates.
|
28
67
|
|
29
|
-
###
|
30
|
-
|
31
|
-
|
32
|
-
|
33
|
-
|
34
|
-
4. Confirm technical specs are defined
|
68
|
+
### Validating specification
|
69
|
+
```
|
70
|
+
User: /spec validate
|
71
|
+
```
|
72
|
+
I will check completeness and report any issues.
|
35
73
|
|
36
74
|
## Template Structure
|
75
|
+
The specification follows this structure:
|
37
76
|
- Project Overview
|
38
|
-
- Functional Requirements (Must/Should/Could)
|
39
|
-
- User Stories with Acceptance Criteria
|
77
|
+
- Functional Requirements (Must/Should/Could have)
|
78
|
+
- User Stories with Acceptance Criteria
|
40
79
|
- Technical Specifications
|
41
80
|
- Clarifications Needed
|
42
|
-
- Validation Checklist
|
43
|
-
|
44
|
-
## Example
|
45
|
-
```
|
46
|
-
/spec create "Build a user authentication system with email/password and OAuth2"
|
47
|
-
```
|
81
|
+
- Validation Checklist
|
@@ -1,47 +1,69 @@
|
|
1
|
-
|
1
|
+
---
|
2
|
+
name: task
|
3
|
+
description: Generate and manage task breakdowns
|
4
|
+
allowed_tools:
|
5
|
+
- Read
|
6
|
+
- Write
|
7
|
+
- Edit
|
8
|
+
- Bash
|
9
|
+
---
|
2
10
|
|
3
|
-
|
11
|
+
# /task Command
|
12
|
+
|
13
|
+
Generate task breakdowns from implementation plans using SpecPulse structure.
|
4
14
|
|
5
15
|
## Usage
|
6
16
|
```
|
7
|
-
/task
|
8
|
-
/task update
|
9
|
-
/task status
|
17
|
+
/task [action]
|
10
18
|
```
|
11
19
|
|
12
|
-
|
20
|
+
Actions: `breakdown`, `update`, `status` (defaults to `breakdown`)
|
21
|
+
|
22
|
+
## Implementation
|
23
|
+
|
24
|
+
When called with `/task $ARGUMENTS`, I will:
|
13
25
|
|
14
|
-
|
15
|
-
|
16
|
-
|
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:
|
17
37
|
- Critical Path (Phase 0)
|
18
38
|
- Phase 1: Foundation
|
19
39
|
- Phase 2: Core Features
|
20
40
|
- Phase 3: Polish
|
21
41
|
- Phase 4: Testing
|
22
42
|
|
23
|
-
|
43
|
+
- For each task:
|
24
44
|
- Use T[XXX] format (T001, T002)
|
25
45
|
- Include clear description
|
26
46
|
- Mark dependencies
|
27
47
|
- Estimate complexity (S/M/L/XL)
|
28
48
|
- Assign priority
|
29
49
|
|
30
|
-
|
31
|
-
|
32
|
-
|
33
|
-
|
34
|
-
|
35
|
-
|
36
|
-
|
37
|
-
|
38
|
-
|
39
|
-
|
40
|
-
|
41
|
-
|
42
|
-
|
43
|
-
|
44
|
-
|
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
|
45
67
|
|
46
68
|
## Task Format
|
47
69
|
```markdown
|
@@ -1,48 +1,51 @@
|
|
1
|
-
|
2
|
-
|
3
|
-
|
4
|
-
|
5
|
-
|
6
|
-
|
7
|
-
|
8
|
-
|
9
|
-
|
10
|
-
|
11
|
-
|
12
|
-
|
13
|
-
|
14
|
-
|
15
|
-
|
16
|
-
|
17
|
-
|
18
|
-
|
19
|
-
|
20
|
-
|
21
|
-
|
22
|
-
|
23
|
-
|
24
|
-
|
25
|
-
|
26
|
-
|
27
|
-
|
28
|
-
|
29
|
-
|
30
|
-
|
31
|
-
|
32
|
-
|
33
|
-
|
34
|
-
|
35
|
-
|
36
|
-
|
37
|
-
|
38
|
-
|
39
|
-
|
40
|
-
|
41
|
-
|
42
|
-
|
43
|
-
|
44
|
-
|
45
|
-
|
46
|
-
|
47
|
-
|
48
|
-
|
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
|
+
"""
|
@@ -1,45 +1,24 @@
|
|
1
|
-
|
2
|
-
|
3
|
-
|
1
|
+
description = "Initialize a new feature with SpecPulse framework"
|
2
|
+
prompt = """
|
3
|
+
Initialize a new SpecPulse feature with the name: {{args}}
|
4
4
|
|
5
|
-
|
6
|
-
description = "Initialize a new feature with proper structure"
|
7
|
-
usage = "/pulse init <feature-name>"
|
5
|
+
Please follow these steps:
|
8
6
|
|
9
|
-
|
10
|
-
|
11
|
-
|
12
|
-
|
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
|
13
15
|
|
14
|
-
|
15
|
-
|
16
|
-
|
17
|
-
|
18
|
-
"plans/{{branch_name}}/plan.md",
|
19
|
-
"tasks/{{branch_name}}/tasks.md"
|
20
|
-
]
|
16
|
+
4. Report the results showing:
|
17
|
+
- Created structure paths
|
18
|
+
- Feature ID and branch name
|
19
|
+
- Next steps for the user
|
21
20
|
|
22
|
-
|
23
|
-
action = "update_context"
|
24
|
-
file = "memory/context.md"
|
25
|
-
content = """
|
26
|
-
## Active Feature: {{feature_name}}
|
27
|
-
- Feature ID: {{feature_id}}
|
28
|
-
- Branch: {{branch_name}}
|
29
|
-
- Started: {{timestamp}}
|
30
|
-
"""
|
21
|
+
If no feature name is provided, ask the user for the feature name first.
|
31
22
|
|
32
|
-
|
33
|
-
action = "git_branch"
|
34
|
-
branch = "{{branch_name}}"
|
35
|
-
|
36
|
-
[command.response]
|
37
|
-
template = """
|
38
|
-
✅ Feature initialized: {{feature_name}}
|
39
|
-
- Branch: {{branch_name}}
|
40
|
-
- Spec: specs/{{branch_name}}/spec.md
|
41
|
-
- Plan: plans/{{branch_name}}/plan.md
|
42
|
-
- Tasks: tasks/{{branch_name}}/tasks.md
|
43
|
-
|
44
|
-
Next: Use /spec create to define requirements
|
23
|
+
Example usage: /pulse user-authentication
|
45
24
|
"""
|
@@ -1,33 +1,37 @@
|
|
1
|
-
|
2
|
-
|
3
|
-
|
1
|
+
description = "Create or manage feature specifications"
|
2
|
+
prompt = """
|
3
|
+
Handle the /spec command with arguments: {{args}}
|
4
4
|
|
5
|
-
|
6
|
-
|
7
|
-
|
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
|
8
10
|
|
9
|
-
[[
|
10
|
-
|
11
|
-
|
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
|
12
20
|
|
13
|
-
|
14
|
-
|
15
|
-
|
16
|
-
|
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
|
17
26
|
|
18
|
-
|
19
|
-
|
20
|
-
|
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
|
21
32
|
|
22
|
-
|
23
|
-
|
24
|
-
|
25
|
-
|
26
|
-
|
27
|
-
"testable_criteria",
|
28
|
-
"technical_specs_defined"
|
29
|
-
]
|
30
|
-
|
31
|
-
[command.subcommands.update]
|
32
|
-
description = "Update existing specification"
|
33
|
-
usage = "/spec update"
|
33
|
+
Examples:
|
34
|
+
- /spec user authentication with OAuth2 and email/password
|
35
|
+
- /spec update
|
36
|
+
- /spec validate
|
37
|
+
"""
|
@@ -1,51 +1,57 @@
|
|
1
|
-
|
2
|
-
|
3
|
-
|
4
|
-
|
5
|
-
|
6
|
-
|
7
|
-
|
8
|
-
|
9
|
-
|
10
|
-
|
11
|
-
|
12
|
-
|
13
|
-
|
14
|
-
|
15
|
-
|
16
|
-
|
17
|
-
|
18
|
-
|
19
|
-
|
20
|
-
|
21
|
-
|
22
|
-
|
23
|
-
|
24
|
-
|
25
|
-
|
26
|
-
|
27
|
-
|
28
|
-
|
29
|
-
|
30
|
-
|
31
|
-
|
32
|
-
|
33
|
-
|
34
|
-
|
35
|
-
|
36
|
-
|
37
|
-
|
38
|
-
|
39
|
-
|
40
|
-
|
41
|
-
|
42
|
-
|
43
|
-
|
44
|
-
|
45
|
-
|
46
|
-
|
47
|
-
|
48
|
-
|
49
|
-
|
50
|
-
|
51
|
-
|
1
|
+
description = "Generate and manage task breakdowns"
|
2
|
+
prompt = """
|
3
|
+
Handle the /task command with arguments: {{args}}
|
4
|
+
|
5
|
+
Parse arguments to determine action:
|
6
|
+
- If "update": Update task status
|
7
|
+
- If "status": Show progress
|
8
|
+
- Otherwise: Generate task breakdown
|
9
|
+
|
10
|
+
## For /task breakdown or /task:
|
11
|
+
1. Read implementation plan from @{plans/*/plan.md}
|
12
|
+
|
13
|
+
2. Generate tasks from plan:
|
14
|
+
- Create task categories:
|
15
|
+
• Critical Path (Phase 0)
|
16
|
+
• Phase 1: Foundation
|
17
|
+
• Phase 2: Core Features
|
18
|
+
• Phase 3: Polish
|
19
|
+
• Phase 4: Testing
|
20
|
+
|
21
|
+
- For each task:
|
22
|
+
• Use T[XXX] format (T001, T002)
|
23
|
+
• Include clear description
|
24
|
+
• Mark dependencies
|
25
|
+
• Estimate complexity (S/M/L/XL)
|
26
|
+
• Assign priority
|
27
|
+
|
28
|
+
3. Write tasks to tasks/XXX-feature/tasks.md
|
29
|
+
|
30
|
+
## For /task update:
|
31
|
+
1. Read current tasks from @{tasks/*/tasks.md}
|
32
|
+
2. Ask which tasks to update
|
33
|
+
3. Mark tasks as completed/in-progress
|
34
|
+
4. Add newly discovered tasks
|
35
|
+
5. Update dependencies and blockers
|
36
|
+
6. Save updated task list
|
37
|
+
|
38
|
+
## For /task status:
|
39
|
+
1. Read current tasks
|
40
|
+
2. Count completed vs total
|
41
|
+
3. Show current phase progress
|
42
|
+
4. List any blockers
|
43
|
+
5. Estimate remaining work
|
44
|
+
6. Display progress summary
|
45
|
+
|
46
|
+
Task Format:
|
47
|
+
```markdown
|
48
|
+
- [ ] T001: [S] Set up project structure
|
49
|
+
- [ ] T002: [M] Create database schema
|
50
|
+
- [x] T003: [L] Implement authentication
|
51
|
+
```
|
52
|
+
|
53
|
+
Examples:
|
54
|
+
- /task breakdown
|
55
|
+
- /task update
|
56
|
+
- /task status
|
57
|
+
"""
|
@@ -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
|
---
|
@@ -1,17 +1,17 @@
|
|
1
|
-
specpulse/__init__.py,sha256=
|
1
|
+
specpulse/__init__.py,sha256=af-q2jbt5GBQQ_WYRCFUC-vRvvxW5Yqi97Sd11wMTOg,270
|
2
2
|
specpulse/cli/__init__.py,sha256=DpX6FoRJtSNjudsmZ3mTih_RIaWyiIgxew4-f8mOmFY,70
|
3
3
|
specpulse/cli/main.py,sha256=bnf9xka3AIAyhkjCXGKI-T45eTKyzx0bwE68TOkTfU0,24486
|
4
4
|
specpulse/core/__init__.py,sha256=VKHGdPDM38QM9yDIq05jxol4q8WFlFAeltOzYLsPuto,132
|
5
5
|
specpulse/core/specpulse.py,sha256=YVqZMDO3AIbCsAHY32wIuUV1cH-hIKAcFkqR5WrInVw,29962
|
6
6
|
specpulse/core/validator.py,sha256=dnaNUx7tj8V2K1TE6WPwrNWEiCpqC_b_DKryq6-A7Hk,12057
|
7
|
-
specpulse/resources/commands/claude/plan.md,sha256=
|
8
|
-
specpulse/resources/commands/claude/pulse.md,sha256=
|
9
|
-
specpulse/resources/commands/claude/spec.md,sha256=
|
10
|
-
specpulse/resources/commands/claude/task.md,sha256=
|
11
|
-
specpulse/resources/commands/gemini/plan.toml,sha256=
|
12
|
-
specpulse/resources/commands/gemini/pulse.toml,sha256
|
13
|
-
specpulse/resources/commands/gemini/spec.toml,sha256=
|
14
|
-
specpulse/resources/commands/gemini/task.toml,sha256=
|
7
|
+
specpulse/resources/commands/claude/plan.md,sha256=QAr9kmue7dtj7uWBMTL4xd9NWClUTNEPdErEWmYJHSs,1672
|
8
|
+
specpulse/resources/commands/claude/pulse.md,sha256=liq46kHS4SfKvnmzclti3-Z2DsyYydHLn_4XmQC05zk,1323
|
9
|
+
specpulse/resources/commands/claude/spec.md,sha256=1jWELtO02M6WnhUQ2QwBZjEUyKVqgfTdn5XtkNVVxV0,2227
|
10
|
+
specpulse/resources/commands/claude/task.md,sha256=lpgdzyqEKfDP-c6CzAUMTFzcVegrSFLl7_QtYx-3rGc,1748
|
11
|
+
specpulse/resources/commands/gemini/plan.toml,sha256=cQAIrFZZarJxzCc8BJp22ot0livEAHXNxqsJaRHenps,1308
|
12
|
+
specpulse/resources/commands/gemini/pulse.toml,sha256=-OpmaMIZd9AASp00onGH5t4-CCKaoQvNYLSxfv3ztdw,837
|
13
|
+
specpulse/resources/commands/gemini/spec.toml,sha256=OJhrcFRgnSyaqPOKg-3NhWzOZw1XiDYj3zg_XmQ79po,1346
|
14
|
+
specpulse/resources/commands/gemini/task.toml,sha256=wed7v0XL0QPGysr1dMKF-Q5M7qeT-cbpf94l7vae1CY,1398
|
15
15
|
specpulse/resources/memory/constitution.md,sha256=MUrX9a6inWAa58Oas-Ff_s1sIs04ehr7sSGOYjdAFv4,8286
|
16
16
|
specpulse/resources/memory/context.md,sha256=6021CJIJNTMOIB6xTxc3ehEGOUglIfl_IyJQXwzjw3U,562
|
17
17
|
specpulse/resources/memory/decisions.md,sha256=ZwzVyOPB2mIzwveWpGmedej7ncI81GALg8WVy6AeZA4,686
|
@@ -25,9 +25,9 @@ specpulse/resources/templates/task.md,sha256=TBR0BSbQFWKwFZBx1NU6wmzeRVdzrydS4X4
|
|
25
25
|
specpulse/utils/__init__.py,sha256=VTGRDsVLl2JIXYyHB9Sidxj5acY_W-LJI2MMtY1pwb0,122
|
26
26
|
specpulse/utils/console.py,sha256=xn4Koc1_ph61bvBTlvPOwAbqZ5ac7TZ51xTWJbwG0sc,12973
|
27
27
|
specpulse/utils/git_utils.py,sha256=RzJBZoyWp5on1_wq2lY1bs__UJsGKSDpAUeDKFdRYlQ,6095
|
28
|
-
specpulse-1.0.
|
29
|
-
specpulse-1.0.
|
30
|
-
specpulse-1.0.
|
31
|
-
specpulse-1.0.
|
32
|
-
specpulse-1.0.
|
33
|
-
specpulse-1.0.
|
28
|
+
specpulse-1.0.4.dist-info/licenses/LICENSE,sha256=ImSFezK-Phy0oTBqZipcajsJfPZT8mmg8m3jkgNdNhA,1066
|
29
|
+
specpulse-1.0.4.dist-info/METADATA,sha256=txplotk_lJ4sSQp7Or2PQ78RFOfIhalB_MQHCGCjVh4,15612
|
30
|
+
specpulse-1.0.4.dist-info/WHEEL,sha256=_zCd3N1l69ArxyTb8rzEoP9TpbYXkqRFSNOD5OuxnTs,91
|
31
|
+
specpulse-1.0.4.dist-info/entry_points.txt,sha256=GwMaCKWSCFZlJMrTNavEYrnREynIS6dM3B0ILxnaouA,83
|
32
|
+
specpulse-1.0.4.dist-info/top_level.txt,sha256=pEfkFil5xe38J00OHrBrJ07xpbm6bRnGhI8B07O9KeI,10
|
33
|
+
specpulse-1.0.4.dist-info/RECORD,,
|
File without changes
|
File without changes
|
File without changes
|
File without changes
|