specpulse 1.0.4__py3-none-any.whl → 1.0.5__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 +156 -45
- specpulse/resources/commands/claude/pulse.md +63 -24
- specpulse/resources/commands/claude/spec.md +110 -31
- specpulse/resources/commands/claude/task.md +202 -43
- specpulse/resources/commands/gemini/plan.toml +13 -5
- specpulse/resources/commands/gemini/pulse.toml +4 -1
- specpulse/resources/commands/gemini/spec.toml +12 -4
- specpulse/resources/commands/gemini/task.toml +17 -5
- specpulse/resources/memory/constitution.md +2 -2
- specpulse/resources/scripts/pulse-init.ps1 +186 -0
- specpulse/resources/scripts/pulse-init.py +171 -0
- specpulse/resources/scripts/pulse-init.sh +80 -21
- specpulse/resources/scripts/pulse-plan.ps1 +251 -0
- specpulse/resources/scripts/pulse-plan.py +191 -0
- specpulse/resources/scripts/pulse-plan.sh +113 -12
- specpulse/resources/scripts/pulse-spec.ps1 +185 -0
- specpulse/resources/scripts/pulse-spec.py +167 -0
- specpulse/resources/scripts/pulse-spec.sh +86 -11
- specpulse/resources/scripts/pulse-task.ps1 +263 -0
- specpulse/resources/scripts/pulse-task.py +237 -0
- specpulse/resources/scripts/pulse-task.sh +123 -9
- specpulse/resources/templates/plan.md +142 -287
- specpulse/resources/templates/spec.md +80 -246
- specpulse/resources/templates/task.md +114 -93
- {specpulse-1.0.4.dist-info → specpulse-1.0.5.dist-info}/METADATA +29 -10
- specpulse-1.0.5.dist-info/RECORD +41 -0
- specpulse-1.0.4.dist-info/RECORD +0 -33
- {specpulse-1.0.4.dist-info → specpulse-1.0.5.dist-info}/WHEEL +0 -0
- {specpulse-1.0.4.dist-info → specpulse-1.0.5.dist-info}/entry_points.txt +0 -0
- {specpulse-1.0.4.dist-info → specpulse-1.0.5.dist-info}/licenses/LICENSE +0 -0
- {specpulse-1.0.4.dist-info → specpulse-1.0.5.dist-info}/top_level.txt +0 -0
specpulse/__init__.py
CHANGED
@@ -1,73 +1,184 @@
|
|
1
1
|
---
|
2
2
|
name: plan
|
3
|
-
description: Generate or validate implementation plans
|
3
|
+
description: Generate or validate implementation plans using AI-optimized templates
|
4
4
|
allowed_tools:
|
5
5
|
- Read
|
6
6
|
- Write
|
7
7
|
- Edit
|
8
8
|
- Bash
|
9
|
+
- TodoWrite
|
9
10
|
---
|
10
11
|
|
11
12
|
# /plan Command
|
12
13
|
|
13
|
-
Generate implementation plans from specifications following SpecPulse methodology.
|
14
|
+
Generate implementation plans from specifications following SpecPulse methodology with constitutional compliance and AI-optimized templates.
|
14
15
|
|
15
16
|
## Usage
|
16
17
|
```
|
17
|
-
/plan [action]
|
18
|
+
/plan [action] [feature-directory]
|
18
19
|
```
|
19
20
|
|
20
|
-
Actions: `generate`, `validate` (defaults to `generate`)
|
21
|
+
Actions: `generate`, `validate`, `optimize` (defaults to `generate`)
|
21
22
|
|
22
23
|
## Implementation
|
23
24
|
|
24
25
|
When called with `/plan $ARGUMENTS`, I will:
|
25
26
|
|
26
|
-
1. **Parse arguments**
|
27
|
-
- If
|
27
|
+
1. **Parse arguments** and determine action:
|
28
|
+
- If `validate`: Check plan against constitutional gates
|
29
|
+
- If `optimize`: Improve existing plan complexity
|
28
30
|
- Otherwise: Generate new plan
|
29
31
|
|
30
32
|
2. **For `/plan generate` or `/plan`:**
|
31
|
-
a. **
|
33
|
+
a. **Find and validate specification** from current context or provided directory
|
32
34
|
|
33
|
-
b. **
|
34
|
-
|
35
|
-
|
36
|
-
|
37
|
-
|
38
|
-
|
39
|
-
|
40
|
-
|
41
|
-
|
42
|
-
|
43
|
-
|
44
|
-
|
45
|
-
|
46
|
-
|
47
|
-
|
48
|
-
|
49
|
-
|
50
|
-
-
|
51
|
-
|
52
|
-
|
35
|
+
b. **Enhanced validation** using cross-platform script:
|
36
|
+
```bash
|
37
|
+
# Cross-platform detection
|
38
|
+
if [[ "$OSTYPE" == "msys" || "$OSTYPE" == "win32" ]]; then
|
39
|
+
powershell scripts/pulse-plan.ps1 "$FEATURE_DIR"
|
40
|
+
else
|
41
|
+
bash scripts/pulse-plan.sh "$FEATURE_DIR" || python scripts/pulse-plan.py "$FEATURE_DIR"
|
42
|
+
fi
|
43
|
+
```
|
44
|
+
|
45
|
+
c. **Run Constitutional Phase Gates** (Article VII):
|
46
|
+
- Simplicity Gate: ≤3 modules justification
|
47
|
+
- Anti-Abstraction Gate: Direct framework usage
|
48
|
+
- Test-First Gate: Tests before implementation
|
49
|
+
- Integration-First Gate: Real services over mocks
|
50
|
+
- Research Gate: Technology choices documented
|
51
|
+
|
52
|
+
d. **Generate AI-optimized plan** using template variables:
|
53
|
+
```markdown
|
54
|
+
# Implementation Plan: {{ feature_name }}
|
55
|
+
## Specification Reference
|
56
|
+
- **Spec ID**: SPEC-{{ feature_id }}
|
57
|
+
- **Generated**: {{ date }}
|
58
|
+
```
|
59
|
+
|
60
|
+
e. **Generate comprehensive sections**:
|
61
|
+
- Technology stack with performance implications
|
62
|
+
- Architecture overview with component relationships
|
63
|
+
- Implementation phases with timeline estimates
|
64
|
+
- API contracts with authentication requirements
|
65
|
+
- Data models with validation rules
|
66
|
+
- Testing strategy with coverage targets
|
67
|
+
- Security considerations with compliance requirements
|
68
|
+
- Deployment strategy with rollback plans
|
69
|
+
|
70
|
+
f. **Complexity tracking** (Article VII):
|
71
|
+
- Document all complexity exceptions with justifications
|
72
|
+
- Create mitigation strategies for each exception
|
73
|
+
- Track optimization opportunities
|
74
|
+
|
75
|
+
g. **Write optimized plan** to `plans/XXX-feature/plan.md`
|
53
76
|
|
54
77
|
3. **For `/plan validate`:**
|
55
|
-
-
|
56
|
-
|
57
|
-
|
58
|
-
|
59
|
-
|
60
|
-
|
61
|
-
|
62
|
-
|
63
|
-
|
64
|
-
-
|
65
|
-
-
|
66
|
-
-
|
67
|
-
-
|
68
|
-
-
|
69
|
-
|
70
|
-
|
78
|
+
- **Enhanced validation** using cross-platform script:
|
79
|
+
```bash
|
80
|
+
# Cross-platform detection
|
81
|
+
if [[ "$OSTYPE" == "msys" || "$OSTYPE" == "win32" ]]; then
|
82
|
+
powershell scripts/pulse-plan.ps1 "$FEATURE_DIR"
|
83
|
+
else
|
84
|
+
bash scripts/pulse-plan.sh "$FEATURE_DIR" || python scripts/pulse-plan.py "$FEATURE_DIR"
|
85
|
+
fi
|
86
|
+
```
|
87
|
+
- Verify all constitutional gates are addressed
|
88
|
+
- Check complexity exceptions have proper justifications
|
89
|
+
- Validate test-first approach is documented
|
90
|
+
- Ensure integration strategy uses real services
|
91
|
+
- Report detailed validation results
|
92
|
+
|
93
|
+
4. **For `/plan optimize`:**
|
94
|
+
- **Read existing plan** and analyze complexity
|
95
|
+
- **Identify optimization opportunities**:
|
96
|
+
- Module consolidation opportunities
|
97
|
+
- Abstraction layer removal candidates
|
98
|
+
- Simplification strategies
|
99
|
+
- **Generate optimization recommendations**
|
100
|
+
- **Update plan** with reduced complexity
|
101
|
+
|
102
|
+
## Constitutional Phase Gates (Phase -1)
|
103
|
+
|
104
|
+
**Must pass before implementation:**
|
105
|
+
|
106
|
+
### Article VII: Simplicity Gate
|
107
|
+
- [ ] Using ≤3 projects/modules for initial implementation
|
108
|
+
- [ ] No future-proofing without documented need
|
109
|
+
- [ ] Direct framework usage (no unnecessary wrappers)
|
110
|
+
- [ ] Single model representation per concept
|
111
|
+
|
112
|
+
### Article VII: Anti-Abstraction Gate
|
113
|
+
- [ ] Using framework features directly
|
114
|
+
- [ ] No unnecessary abstraction layers
|
115
|
+
- [ ] Clear, simple interfaces
|
116
|
+
- [ ] Avoiding premature optimization
|
117
|
+
|
118
|
+
### Article III: Test-First Gate
|
119
|
+
- [ ] Test specifications written
|
120
|
+
- [ ] Tests reviewed and approved
|
121
|
+
- [ ] Tests confirmed to FAIL before implementation
|
122
|
+
- [ ] TDD cycle planned (Red-Green-Refactor)
|
123
|
+
|
124
|
+
### Article VIII: Integration-First Gate
|
125
|
+
- [ ] Contract tests defined
|
126
|
+
- [ ] Using real services over mocks
|
127
|
+
- [ ] Production-like test environment planned
|
128
|
+
- [ ] End-to-end test scenarios identified
|
129
|
+
|
130
|
+
### Article VI: Research Gate
|
131
|
+
- [ ] Library options researched
|
132
|
+
- [ ] Performance implications documented
|
133
|
+
- [ ] Security considerations analyzed
|
134
|
+
- [ ] Trade-offs documented
|
135
|
+
|
136
|
+
## Examples
|
137
|
+
|
138
|
+
### Generate plan with validation
|
139
|
+
```
|
140
|
+
User: /plan generate
|
141
|
+
```
|
142
|
+
I will:
|
143
|
+
- Run: `bash scripts/pulse-plan.sh "$FEATURE_DIR"`
|
144
|
+
- Validate: Constitutional gates compliance
|
145
|
+
- Create: AI-optimized plan with template variables
|
146
|
+
- Output: `CONSTITUTIONAL_GATES_STATUS=PENDING`
|
147
|
+
|
148
|
+
### Validate existing plan
|
149
|
+
```
|
150
|
+
User: /plan validate
|
151
|
+
```
|
152
|
+
I will run comprehensive validation:
|
153
|
+
```
|
154
|
+
PLAN_FILE=plans/001-user-authentication/plan.md
|
155
|
+
CONSTITUTIONAL_GATES_STATUS=COMPLETED
|
156
|
+
MISSING_SECTIONS=0
|
157
|
+
STATUS=validation_complete
|
71
158
|
```
|
72
|
-
|
73
|
-
|
159
|
+
|
160
|
+
### Optimize plan complexity
|
161
|
+
```
|
162
|
+
User: /plan optimize
|
163
|
+
```
|
164
|
+
I will analyze and recommend complexity reductions.
|
165
|
+
|
166
|
+
## Enhanced Features
|
167
|
+
|
168
|
+
- **AI-optimized templates** with Jinja2-style variables
|
169
|
+
- **Cross-platform script execution** with automatic detection
|
170
|
+
- **Enhanced script integration** for Bash, PowerShell, and Python
|
171
|
+
- **Constitutional compliance tracking** with gate status
|
172
|
+
- **Complexity exception management** with justifications
|
173
|
+
- **Performance and security considerations** integrated
|
174
|
+
- **Integration-first approach** with real service usage
|
175
|
+
- **Detailed validation reporting** with specific recommendations
|
176
|
+
- **Platform-agnostic operation** for any development environment
|
177
|
+
|
178
|
+
## Error Handling
|
179
|
+
|
180
|
+
- Specification existence validation
|
181
|
+
- Constitutional gate compliance checking
|
182
|
+
- Template structure validation
|
183
|
+
- Directory structure verification
|
184
|
+
- Feature context auto-discovery
|
@@ -6,47 +6,86 @@ allowed_tools:
|
|
6
6
|
- Read
|
7
7
|
- Write
|
8
8
|
- Edit
|
9
|
+
- TodoWrite
|
9
10
|
---
|
10
11
|
|
11
12
|
# /pulse Command
|
12
13
|
|
13
|
-
Initialize a new feature following SpecPulse methodology.
|
14
|
+
Initialize a new feature following SpecPulse methodology with constitutional compliance.
|
14
15
|
|
15
16
|
## Usage
|
16
17
|
```
|
17
|
-
/pulse <feature-name>
|
18
|
+
/pulse <feature-name> [feature-id]
|
18
19
|
```
|
19
20
|
|
20
21
|
## Implementation
|
21
22
|
|
22
23
|
When called with `/pulse $ARGUMENTS`, I will:
|
23
24
|
|
24
|
-
1. **
|
25
|
-
2. **Run initialization script
|
26
|
-
|
27
|
-
-
|
28
|
-
-
|
29
|
-
|
30
|
-
-
|
31
|
-
- Create
|
25
|
+
1. **Validate arguments** and extract feature name + optional ID
|
26
|
+
2. **Run initialization script** with cross-platform detection:
|
27
|
+
- **Windows**: `powershell scripts/pulse-init.ps1 "$FEATURE_NAME" "$OPTIONAL_ID"`
|
28
|
+
- **Linux/macOS**: `bash scripts/pulse-init.sh "$FEATURE_NAME" "$OPTIONAL_ID"`
|
29
|
+
- **Python Fallback**: `python scripts/pulse-init.py "$FEATURE_NAME" "$OPTIONAL_ID"`
|
30
|
+
3. **Create complete feature structure**:
|
31
|
+
- Generate feature ID (001, 002, etc.) or use provided ID
|
32
|
+
- Create sanitized branch name: `ID-feature-name`
|
33
|
+
- Create directories: `specs/ID-feature-name/`, `plans/ID-feature-name/`, `tasks/ID-feature-name/`
|
34
|
+
- Copy AI-optimized templates to feature directories
|
35
|
+
- Update `memory/context.md` with current feature metadata
|
36
|
+
- Create and switch to git branch if in git repository
|
32
37
|
|
33
|
-
4. **
|
38
|
+
4. **Validate structure** and report comprehensive status
|
39
|
+
5. **Create todo list** for tracking feature development progress
|
40
|
+
|
41
|
+
## Constitutional Compliance
|
42
|
+
|
43
|
+
**Article I: Simplicity**
|
44
|
+
- [ ] Feature name is clear and specific
|
45
|
+
- [ ] No unnecessary abstractions in initial structure
|
46
|
+
- [ ] Single responsibility per feature
|
47
|
+
|
48
|
+
**Article II: Anti-Abstraction**
|
49
|
+
- [ ] Direct template usage (no wrapper layers)
|
50
|
+
- [ ] Minimal initial structure
|
51
|
+
- [ ] Framework-ready files
|
34
52
|
|
35
53
|
## Example
|
36
54
|
```
|
37
|
-
User: /pulse user-authentication
|
55
|
+
User: /pulse user-authentication-oauth2
|
38
56
|
```
|
39
57
|
|
40
58
|
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
|
-
-
|
46
|
-
-
|
47
|
-
|
48
|
-
##
|
49
|
-
|
50
|
-
|
51
|
-
-
|
52
|
-
-
|
59
|
+
- Run: `bash scripts/pulse-init.sh "user-authentication-oauth2"`
|
60
|
+
- Create: `specs/001-user-authentication-oauth2/spec.md`
|
61
|
+
- Create: `plans/001-user-authentication-oauth2/plan.md`
|
62
|
+
- Create: `tasks/001-user-authentication-oauth2/tasks.md`
|
63
|
+
- Branch: `001-user-authentication-oauth2`
|
64
|
+
- Status: `STATUS=initialized, BRANCH_NAME=001-user-authentication-oauth2`
|
65
|
+
|
66
|
+
## Error Handling
|
67
|
+
|
68
|
+
Enhanced validation includes:
|
69
|
+
- Feature name sanitization (alphanumeric, hyphens only)
|
70
|
+
- Directory creation validation
|
71
|
+
- Template existence verification
|
72
|
+
- Git repository validation
|
73
|
+
- Context file management
|
74
|
+
|
75
|
+
## Next Steps (Constitutional Order)
|
76
|
+
|
77
|
+
1. **Phase -1**: Use `/spec` to create specification with constitutional gates
|
78
|
+
2. **Phase 0**: Use `/plan` to generate implementation plan with complexity tracking
|
79
|
+
3. **Phase 1**: Use `/task` to break down into executable tasks
|
80
|
+
4. **Implementation**: Begin development following constitutional principles
|
81
|
+
|
82
|
+
## Integration Features
|
83
|
+
|
84
|
+
- **Automatic context tracking** in `memory/context.md`
|
85
|
+
- **Enhanced error reporting** with specific failure reasons
|
86
|
+
- **Git integration** with branch management
|
87
|
+
- **Template validation** before copying
|
88
|
+
- **Todo list creation** for progress tracking
|
89
|
+
- **Cross-platform script execution** with automatic detection
|
90
|
+
- **Multiple language support**: Bash, PowerShell, Python
|
91
|
+
- **Platform-agnostic operation** for any development environment
|
@@ -1,23 +1,24 @@
|
|
1
1
|
---
|
2
2
|
name: spec
|
3
|
-
description: Create or manage feature specifications
|
3
|
+
description: Create or manage feature specifications using AI-optimized templates
|
4
4
|
allowed_tools:
|
5
5
|
- Read
|
6
6
|
- Write
|
7
7
|
- Edit
|
8
8
|
- Bash
|
9
|
+
- TodoWrite
|
9
10
|
---
|
10
11
|
|
11
12
|
# /spec Command
|
12
13
|
|
13
|
-
Create, update, or validate feature specifications using SpecPulse methodology.
|
14
|
+
Create, update, or validate feature specifications using SpecPulse methodology with AI-optimized templates.
|
14
15
|
|
15
16
|
## Usage
|
16
17
|
```
|
17
|
-
/spec [action] [description]
|
18
|
+
/spec [action] [description|feature-name]
|
18
19
|
```
|
19
20
|
|
20
|
-
Actions: `create`, `update`, `validate` (defaults to `create`)
|
21
|
+
Actions: `create`, `update`, `validate`, `clarify` (defaults to `create`)
|
21
22
|
|
22
23
|
## Implementation
|
23
24
|
|
@@ -27,55 +28,133 @@ When called with `/spec $ARGUMENTS`, I will:
|
|
27
28
|
- If starts with `create`: Generate new specification
|
28
29
|
- If starts with `update`: Modify existing specification
|
29
30
|
- If starts with `validate`: Check specification completeness
|
31
|
+
- If starts with `clarify`: Address [NEEDS CLARIFICATION] markers
|
30
32
|
- If no action specified: Default to `create` with full arguments as description
|
31
33
|
|
32
34
|
2. **For `/spec create [description]` or `/spec [description]`:**
|
33
|
-
- Read template from `templates/spec.md`
|
35
|
+
- Read AI-optimized template from `templates/spec.md`
|
34
36
|
- Parse the description to identify:
|
35
|
-
- Functional requirements (Must/Should/Could have)
|
36
|
-
- User stories
|
37
|
-
- Technical
|
38
|
-
|
39
|
-
-
|
40
|
-
|
37
|
+
- Functional requirements (Must/Should/Could/Won't have)
|
38
|
+
- User stories with testable acceptance criteria
|
39
|
+
- Technical specifications and constraints
|
40
|
+
- Success metrics and out-of-scope items
|
41
|
+
- Generate specification using Jinja2-style template variables:
|
42
|
+
```markdown
|
43
|
+
# Specification: {{ feature_name }}
|
44
|
+
## Metadata
|
45
|
+
- **ID**: SPEC-{{ feature_id }}
|
46
|
+
- **Created**: {{ date }}
|
47
|
+
```
|
48
|
+
- Mark any uncertainties with `[NEEDS CLARIFICATION: specific question]`
|
49
|
+
- Find current feature directory from context or create new
|
50
|
+
- Write specification to `specs/ID-feature-name/spec.md`
|
51
|
+
- Run enhanced validation with cross-platform detection:
|
52
|
+
- **Windows**: `powershell scripts/pulse-spec.ps1 "$FEATURE_DIR"`
|
53
|
+
- **Linux/macOS**: `bash scripts/pulse-spec.sh "$FEATURE_DIR"`
|
54
|
+
- **Python Fallback**: `python scripts/pulse-spec.py "$FEATURE_DIR"`
|
41
55
|
|
42
56
|
3. **For `/spec update`:**
|
43
|
-
- Read existing specification
|
44
|
-
-
|
45
|
-
- Update content while preserving structure
|
57
|
+
- Read existing specification from current context
|
58
|
+
- Parse update requests and identify sections to modify
|
59
|
+
- Update content while preserving AI-friendly template structure
|
46
60
|
- Remove resolved `[NEEDS CLARIFICATION]` markers
|
61
|
+
- Run validation to ensure completeness
|
47
62
|
|
48
63
|
4. **For `/spec validate`:**
|
49
|
-
-
|
64
|
+
- Read current specification
|
65
|
+
- Check all required sections using enhanced validation:
|
66
|
+
```bash
|
67
|
+
# Cross-platform detection
|
68
|
+
if [[ "$OSTYPE" == "msys" || "$OSTYPE" == "win32" ]]; then
|
69
|
+
powershell scripts/pulse-spec.ps1 "$FEATURE_DIR"
|
70
|
+
else
|
71
|
+
bash scripts/pulse-spec.sh "$FEATURE_DIR" || python scripts/pulse-spec.py "$FEATURE_DIR"
|
72
|
+
fi
|
73
|
+
```
|
50
74
|
- Count `[NEEDS CLARIFICATION]` markers
|
51
|
-
- Verify acceptance criteria
|
52
|
-
-
|
75
|
+
- Verify acceptance criteria follow Given-When-Then format
|
76
|
+
- Check constitutional compliance indicators
|
77
|
+
- Report detailed validation results
|
78
|
+
|
79
|
+
5. **For `/spec clarify`:**
|
80
|
+
- Find all `[NEEDS CLARIFICATION]` markers
|
81
|
+
- Address each uncertainty with user input
|
82
|
+
- Update specification with resolved information
|
83
|
+
- Remove clarification markers
|
84
|
+
- Re-run validation
|
53
85
|
|
54
86
|
## Examples
|
55
87
|
|
56
88
|
### Creating a new specification
|
57
89
|
```
|
58
|
-
User: /spec user authentication with OAuth2 and
|
90
|
+
User: /spec create user authentication system with OAuth2 and JWT tokens
|
59
91
|
```
|
60
|
-
I will create a comprehensive specification
|
92
|
+
I will create a comprehensive specification using AI-optimized templates with:
|
93
|
+
- Jinja2-style variables for AI processing
|
94
|
+
- Constitutional compliance sections
|
95
|
+
- Testable acceptance criteria
|
96
|
+
- Automated validation
|
61
97
|
|
62
98
|
### Updating existing specification
|
63
99
|
```
|
64
|
-
User: /spec update
|
100
|
+
User: /spec update add password complexity requirements
|
65
101
|
```
|
66
|
-
I will read the current spec and
|
102
|
+
I will read the current spec, update password requirements, and validate changes.
|
67
103
|
|
68
104
|
### Validating specification
|
69
105
|
```
|
70
106
|
User: /spec validate
|
71
107
|
```
|
72
|
-
I will
|
73
|
-
|
74
|
-
|
75
|
-
|
76
|
-
|
77
|
-
|
78
|
-
|
79
|
-
|
80
|
-
|
81
|
-
|
108
|
+
I will run enhanced validation with detailed reporting:
|
109
|
+
```
|
110
|
+
SPEC_FILE=specs/001-user-authentication/spec.md
|
111
|
+
CLARIFICATIONS_NEEDED=3
|
112
|
+
MISSING_SECTIONS=0
|
113
|
+
STATUS=validation_complete
|
114
|
+
```
|
115
|
+
|
116
|
+
### Addressing clarifications
|
117
|
+
```
|
118
|
+
User: /spec clarify
|
119
|
+
```
|
120
|
+
I will systematically address all [NEEDS CLARIFICATION] markers.
|
121
|
+
|
122
|
+
## Enhanced Template Structure
|
123
|
+
|
124
|
+
The AI-optimized specification template includes:
|
125
|
+
- **Metadata**: Template variables for AI processing
|
126
|
+
- **Constitutional Gates**: Pre-implementation validation
|
127
|
+
- **Functional Requirements**: Structured Must/Should/Could/Won't
|
128
|
+
- **User Stories**: Given-When-Then acceptance criteria
|
129
|
+
- **Validation Checklist**: Automated completeness checks
|
130
|
+
- **Integration Points**: AI command workflow guidance
|
131
|
+
|
132
|
+
## Constitutional Compliance
|
133
|
+
|
134
|
+
**Article III: Test-First**
|
135
|
+
- [ ] Acceptance criteria written before implementation
|
136
|
+
- [ ] Test scenarios clearly defined
|
137
|
+
- [ ] Integration points identified
|
138
|
+
|
139
|
+
**Article VI: Research**
|
140
|
+
- [ ] Technology choices documented
|
141
|
+
- [ ] Security considerations addressed
|
142
|
+
- [ ] Performance requirements specified
|
143
|
+
|
144
|
+
## Enhanced Error Handling
|
145
|
+
|
146
|
+
- Template existence validation
|
147
|
+
- Feature directory auto-discovery
|
148
|
+
- Required sections validation
|
149
|
+
- Acceptance criteria format checking
|
150
|
+
- Clarification marker tracking
|
151
|
+
|
152
|
+
## Integration Features
|
153
|
+
|
154
|
+
- **Cross-platform script execution** with automatic detection
|
155
|
+
- **Enhanced script integration** with Bash, PowerShell, and Python support
|
156
|
+
- **Template variable processing** for AI optimization
|
157
|
+
- **Automated validation** with detailed reporting
|
158
|
+
- **Context-aware operation** using memory/context.md
|
159
|
+
- **Progress tracking** with todo list integration
|
160
|
+
- **Platform-agnostic operation** for Windows, Linux, and macOS
|