smart-spec-kit-mcp 2.1.1 → 2.1.3
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/README.md +21 -12
- package/dist/cli.js +6 -0
- package/dist/cli.js.map +1 -1
- package/dist/tools/promptTools.d.ts +1 -1
- package/dist/tools/promptTools.d.ts.map +1 -1
- package/dist/tools/promptTools.js +205 -3
- package/dist/tools/promptTools.js.map +1 -1
- package/dist/utils/starterKitInstaller.d.ts.map +1 -1
- package/dist/utils/starterKitInstaller.js +50 -7
- package/dist/utils/starterKitInstaller.js.map +1 -1
- package/docs/DOCUMENTATION.md +181 -10
- package/package.json +1 -1
- package/starter-kit/copilot-instructions.md +20 -2
- package/starter-kit/prompts/implement.md +42 -1
- package/starter-kit/prompts/validate.md +89 -0
- package/starter-kit/rules/rgpd-rules.md +187 -0
- package/starter-kit/rules/security-rules.md +138 -0
- package/starter-kit/workflows/bugfix.yaml +99 -0
- package/starter-kit/workflows/feature-full.yaml +344 -0
- package/starter-kit/workflows/feature-quick.yaml +69 -0
- package/starter-kit/workflows/feature-standard.yaml +92 -0
- package/workflows/feature-quick.yaml +69 -0
|
@@ -0,0 +1,344 @@
|
|
|
1
|
+
# Full Feature Workflow with Governance
|
|
2
|
+
# Complete workflow with all validation checkpoints
|
|
3
|
+
|
|
4
|
+
name: feature-full
|
|
5
|
+
displayName: "Feature with Full Governance"
|
|
6
|
+
description: "Complete feature workflow including RGPD, Security, Architecture, Design System, and Testing validations"
|
|
7
|
+
|
|
8
|
+
metadata:
|
|
9
|
+
version: "1.0"
|
|
10
|
+
author: "Spec-Kit"
|
|
11
|
+
tags:
|
|
12
|
+
- feature
|
|
13
|
+
- governance
|
|
14
|
+
- enterprise
|
|
15
|
+
|
|
16
|
+
template: functional-spec.md
|
|
17
|
+
defaultAgent: SpecAgent
|
|
18
|
+
|
|
19
|
+
steps:
|
|
20
|
+
# ═══════════════════════════════════════════════════════════════
|
|
21
|
+
# PHASE 1: SPECIFICATION
|
|
22
|
+
# ═══════════════════════════════════════════════════════════════
|
|
23
|
+
|
|
24
|
+
- id: fetch-requirements
|
|
25
|
+
name: "1.1 Fetch Requirements"
|
|
26
|
+
action: fetch_ado
|
|
27
|
+
description: |
|
|
28
|
+
Retrieve the Feature work item and all linked items from Azure DevOps.
|
|
29
|
+
|
|
30
|
+
Extract:
|
|
31
|
+
- Title and description
|
|
32
|
+
- Acceptance criteria
|
|
33
|
+
- Parent Epic context
|
|
34
|
+
- Linked User Stories
|
|
35
|
+
- Attachments (mockups, documents)
|
|
36
|
+
outputs:
|
|
37
|
+
- workitem_data
|
|
38
|
+
- linked_items
|
|
39
|
+
- attachments
|
|
40
|
+
|
|
41
|
+
- id: write-spec
|
|
42
|
+
name: "1.2 Write Functional Specification"
|
|
43
|
+
action: call_agent
|
|
44
|
+
agent: SpecAgent
|
|
45
|
+
description: |
|
|
46
|
+
Generate a comprehensive functional specification including:
|
|
47
|
+
|
|
48
|
+
**Functional Requirements**
|
|
49
|
+
- User stories with acceptance criteria
|
|
50
|
+
- Business rules
|
|
51
|
+
- Data requirements
|
|
52
|
+
|
|
53
|
+
**Non-Functional Requirements**
|
|
54
|
+
- Performance targets
|
|
55
|
+
- Availability requirements
|
|
56
|
+
- Scalability needs
|
|
57
|
+
|
|
58
|
+
Mark uncertain sections with [TO FILL] for human review.
|
|
59
|
+
inputs:
|
|
60
|
+
source: "workitem_data"
|
|
61
|
+
outputs:
|
|
62
|
+
- functional_spec
|
|
63
|
+
|
|
64
|
+
# ═══════════════════════════════════════════════════════════════
|
|
65
|
+
# PHASE 2: VALIDATION GATES
|
|
66
|
+
# ═══════════════════════════════════════════════════════════════
|
|
67
|
+
|
|
68
|
+
- id: rgpd-review
|
|
69
|
+
name: "2.1 🛡️ RGPD Compliance Review"
|
|
70
|
+
action: review
|
|
71
|
+
agent: GovAgent
|
|
72
|
+
description: |
|
|
73
|
+
Validate GDPR/RGPD compliance:
|
|
74
|
+
|
|
75
|
+
**Data Collection**
|
|
76
|
+
- [ ] Personal data identified and documented
|
|
77
|
+
- [ ] Legal basis for processing defined
|
|
78
|
+
- [ ] Data minimization principle applied
|
|
79
|
+
|
|
80
|
+
**User Rights**
|
|
81
|
+
- [ ] Right to access implemented
|
|
82
|
+
- [ ] Right to rectification supported
|
|
83
|
+
- [ ] Right to erasure (RTBF) supported
|
|
84
|
+
- [ ] Data portability considered
|
|
85
|
+
|
|
86
|
+
**Security & Governance**
|
|
87
|
+
- [ ] Data retention period defined
|
|
88
|
+
- [ ] Third-party processors identified
|
|
89
|
+
- [ ] Privacy by design applied
|
|
90
|
+
- [ ] DPIA required? (if high risk)
|
|
91
|
+
inputs:
|
|
92
|
+
spec: "functional_spec"
|
|
93
|
+
outputs:
|
|
94
|
+
- rgpd_report
|
|
95
|
+
- rgpd_status
|
|
96
|
+
|
|
97
|
+
- id: security-review
|
|
98
|
+
name: "2.2 🔒 Security Review"
|
|
99
|
+
action: review
|
|
100
|
+
agent: GovAgent
|
|
101
|
+
description: |
|
|
102
|
+
Security assessment checklist:
|
|
103
|
+
|
|
104
|
+
**Authentication & Authorization**
|
|
105
|
+
- [ ] Auth mechanism defined
|
|
106
|
+
- [ ] Role-based access control
|
|
107
|
+
- [ ] Session management
|
|
108
|
+
|
|
109
|
+
**Data Protection**
|
|
110
|
+
- [ ] Encryption at rest
|
|
111
|
+
- [ ] Encryption in transit (TLS)
|
|
112
|
+
- [ ] Sensitive data handling
|
|
113
|
+
|
|
114
|
+
**Input/Output Security**
|
|
115
|
+
- [ ] Input validation strategy
|
|
116
|
+
- [ ] Output encoding
|
|
117
|
+
- [ ] SQL injection prevention
|
|
118
|
+
- [ ] XSS prevention
|
|
119
|
+
- [ ] CSRF protection
|
|
120
|
+
|
|
121
|
+
**Infrastructure**
|
|
122
|
+
- [ ] Secrets management
|
|
123
|
+
- [ ] Logging (without PII)
|
|
124
|
+
- [ ] Rate limiting
|
|
125
|
+
- [ ] DDoS considerations
|
|
126
|
+
inputs:
|
|
127
|
+
spec: "functional_spec"
|
|
128
|
+
outputs:
|
|
129
|
+
- security_report
|
|
130
|
+
- security_status
|
|
131
|
+
|
|
132
|
+
- id: architecture-review
|
|
133
|
+
name: "2.3 🏗️ Architecture Review"
|
|
134
|
+
action: review
|
|
135
|
+
agent: GovAgent
|
|
136
|
+
description: |
|
|
137
|
+
Architecture validation:
|
|
138
|
+
|
|
139
|
+
**Consistency**
|
|
140
|
+
- [ ] Aligns with existing architecture
|
|
141
|
+
- [ ] Follows established patterns
|
|
142
|
+
- [ ] Uses approved technologies
|
|
143
|
+
|
|
144
|
+
**Quality Attributes**
|
|
145
|
+
- [ ] Scalability addressed
|
|
146
|
+
- [ ] Performance requirements met
|
|
147
|
+
- [ ] Reliability/Availability design
|
|
148
|
+
- [ ] Maintainability considered
|
|
149
|
+
|
|
150
|
+
**Technical Debt**
|
|
151
|
+
- [ ] No unnecessary complexity
|
|
152
|
+
- [ ] Reuses existing components
|
|
153
|
+
- [ ] Technical debt acceptable
|
|
154
|
+
|
|
155
|
+
**Integration**
|
|
156
|
+
- [ ] API contracts defined
|
|
157
|
+
- [ ] Event/message schemas
|
|
158
|
+
- [ ] Database changes documented
|
|
159
|
+
inputs:
|
|
160
|
+
spec: "functional_spec"
|
|
161
|
+
outputs:
|
|
162
|
+
- architecture_report
|
|
163
|
+
- architecture_status
|
|
164
|
+
|
|
165
|
+
- id: design-review
|
|
166
|
+
name: "2.4 🎨 Design System Review"
|
|
167
|
+
action: review
|
|
168
|
+
agent: GovAgent
|
|
169
|
+
description: |
|
|
170
|
+
Design System compliance (if UI involved):
|
|
171
|
+
|
|
172
|
+
**Components**
|
|
173
|
+
- [ ] Uses Design System components
|
|
174
|
+
- [ ] No unauthorized custom components
|
|
175
|
+
- [ ] Proper component composition
|
|
176
|
+
|
|
177
|
+
**Visual Consistency**
|
|
178
|
+
- [ ] Color tokens used correctly
|
|
179
|
+
- [ ] Typography follows guidelines
|
|
180
|
+
- [ ] Spacing uses standard scale
|
|
181
|
+
- [ ] Icons from approved library
|
|
182
|
+
|
|
183
|
+
**Accessibility (WCAG 2.1 AA)**
|
|
184
|
+
- [ ] Color contrast ratios
|
|
185
|
+
- [ ] Keyboard navigation
|
|
186
|
+
- [ ] Screen reader support
|
|
187
|
+
- [ ] Focus indicators
|
|
188
|
+
|
|
189
|
+
**Responsive Design**
|
|
190
|
+
- [ ] Mobile breakpoints defined
|
|
191
|
+
- [ ] Touch targets adequate
|
|
192
|
+
- [ ] Dark mode support (if applicable)
|
|
193
|
+
inputs:
|
|
194
|
+
spec: "functional_spec"
|
|
195
|
+
outputs:
|
|
196
|
+
- design_report
|
|
197
|
+
- design_status
|
|
198
|
+
|
|
199
|
+
# ═══════════════════════════════════════════════════════════════
|
|
200
|
+
# PHASE 3: TECHNICAL PLANNING
|
|
201
|
+
# ═══════════════════════════════════════════════════════════════
|
|
202
|
+
|
|
203
|
+
- id: technical-plan
|
|
204
|
+
name: "3.1 Technical Planning"
|
|
205
|
+
action: call_agent
|
|
206
|
+
agent: PlanAgent
|
|
207
|
+
description: |
|
|
208
|
+
Create detailed technical plan:
|
|
209
|
+
|
|
210
|
+
**Architecture Decisions**
|
|
211
|
+
- Components to create/modify
|
|
212
|
+
- Database schema changes
|
|
213
|
+
- API endpoints
|
|
214
|
+
- Integration points
|
|
215
|
+
|
|
216
|
+
**Task Breakdown**
|
|
217
|
+
- Granular tasks (1-3 days each)
|
|
218
|
+
- Clear acceptance criteria
|
|
219
|
+
- Dependencies mapped
|
|
220
|
+
- Effort estimates (S/M/L/XL)
|
|
221
|
+
|
|
222
|
+
**Risk Mitigation**
|
|
223
|
+
- Technical risks identified
|
|
224
|
+
- Mitigation strategies
|
|
225
|
+
- Spike tasks if needed
|
|
226
|
+
inputs:
|
|
227
|
+
spec: "functional_spec"
|
|
228
|
+
reviews: ["rgpd_report", "security_report", "architecture_report"]
|
|
229
|
+
outputs:
|
|
230
|
+
- technical_plan
|
|
231
|
+
- task_list
|
|
232
|
+
|
|
233
|
+
- id: test-strategy
|
|
234
|
+
name: "3.2 🧪 Test Strategy"
|
|
235
|
+
action: call_agent
|
|
236
|
+
agent: TestAgent
|
|
237
|
+
description: |
|
|
238
|
+
Define comprehensive test strategy:
|
|
239
|
+
|
|
240
|
+
**Unit Tests**
|
|
241
|
+
- Critical business logic
|
|
242
|
+
- Edge cases
|
|
243
|
+
- Error handling
|
|
244
|
+
- Target: >80% coverage
|
|
245
|
+
|
|
246
|
+
**Integration Tests**
|
|
247
|
+
- API contracts
|
|
248
|
+
- Database operations
|
|
249
|
+
- External service mocks
|
|
250
|
+
|
|
251
|
+
**E2E Tests**
|
|
252
|
+
- Critical user journeys
|
|
253
|
+
- Happy path scenarios
|
|
254
|
+
- Key error scenarios
|
|
255
|
+
|
|
256
|
+
**Non-Functional Tests**
|
|
257
|
+
- Performance benchmarks
|
|
258
|
+
- Load testing thresholds
|
|
259
|
+
- Security scan requirements
|
|
260
|
+
inputs:
|
|
261
|
+
spec: "functional_spec"
|
|
262
|
+
plan: "technical_plan"
|
|
263
|
+
outputs:
|
|
264
|
+
- test_strategy
|
|
265
|
+
- test_cases
|
|
266
|
+
|
|
267
|
+
# ═══════════════════════════════════════════════════════════════
|
|
268
|
+
# PHASE 4: DOCUMENTATION & FINALIZATION
|
|
269
|
+
# ═══════════════════════════════════════════════════════════════
|
|
270
|
+
|
|
271
|
+
- id: documentation
|
|
272
|
+
name: "4.1 📚 Documentation Plan"
|
|
273
|
+
action: generate_content
|
|
274
|
+
description: |
|
|
275
|
+
Identify documentation needs:
|
|
276
|
+
|
|
277
|
+
**User Documentation**
|
|
278
|
+
- [ ] User guide updates
|
|
279
|
+
- [ ] FAQ additions
|
|
280
|
+
- [ ] Tutorial/walkthrough
|
|
281
|
+
|
|
282
|
+
**Technical Documentation**
|
|
283
|
+
- [ ] API documentation
|
|
284
|
+
- [ ] Architecture Decision Record (ADR)
|
|
285
|
+
- [ ] Runbook updates
|
|
286
|
+
- [ ] README updates
|
|
287
|
+
|
|
288
|
+
**Release Documentation**
|
|
289
|
+
- [ ] Changelog entry
|
|
290
|
+
- [ ] Release notes
|
|
291
|
+
- [ ] Migration guide (if breaking changes)
|
|
292
|
+
inputs:
|
|
293
|
+
spec: "functional_spec"
|
|
294
|
+
plan: "technical_plan"
|
|
295
|
+
outputs:
|
|
296
|
+
- documentation_plan
|
|
297
|
+
|
|
298
|
+
- id: final-approval
|
|
299
|
+
name: "4.2 ✅ Final Approval Gate"
|
|
300
|
+
action: review
|
|
301
|
+
agent: GovAgent
|
|
302
|
+
description: |
|
|
303
|
+
Final checklist before development starts:
|
|
304
|
+
|
|
305
|
+
**Specification**
|
|
306
|
+
- [ ] Functional spec complete and approved
|
|
307
|
+
- [ ] All [TO FILL] sections resolved
|
|
308
|
+
- [ ] Stakeholder sign-off obtained
|
|
309
|
+
|
|
310
|
+
**Compliance**
|
|
311
|
+
- [ ] RGPD review: PASSED
|
|
312
|
+
- [ ] Security review: PASSED
|
|
313
|
+
- [ ] Architecture review: PASSED
|
|
314
|
+
- [ ] Design review: PASSED (if applicable)
|
|
315
|
+
|
|
316
|
+
**Planning**
|
|
317
|
+
- [ ] Technical plan approved
|
|
318
|
+
- [ ] Tasks created in ADO
|
|
319
|
+
- [ ] Test strategy defined
|
|
320
|
+
- [ ] Documentation plan ready
|
|
321
|
+
|
|
322
|
+
**Ready for Development** ✅
|
|
323
|
+
inputs:
|
|
324
|
+
all_artifacts: true
|
|
325
|
+
outputs:
|
|
326
|
+
- final_approval
|
|
327
|
+
- development_ready
|
|
328
|
+
|
|
329
|
+
- id: create-tasks
|
|
330
|
+
name: "4.3 Create ADO Work Items"
|
|
331
|
+
action: create_file
|
|
332
|
+
description: |
|
|
333
|
+
Generate Azure DevOps work items:
|
|
334
|
+
- Create Tasks from technical plan
|
|
335
|
+
- Link to parent Feature
|
|
336
|
+
- Set estimates and priorities
|
|
337
|
+
- Assign to sprint
|
|
338
|
+
|
|
339
|
+
Output format ready for ADO import or manual creation.
|
|
340
|
+
inputs:
|
|
341
|
+
tasks: "task_list"
|
|
342
|
+
feature_id: "context_id"
|
|
343
|
+
outputs:
|
|
344
|
+
- ado_work_items
|
|
@@ -0,0 +1,69 @@
|
|
|
1
|
+
# Feature Quick Workflow
|
|
2
|
+
# Lightweight workflow for simple features / quick wins
|
|
3
|
+
|
|
4
|
+
name: feature-quick
|
|
5
|
+
displayName: "Quick Feature (Quick Win)"
|
|
6
|
+
description: "Lightweight workflow for simple features that don't need full specification"
|
|
7
|
+
|
|
8
|
+
metadata:
|
|
9
|
+
version: "1.0"
|
|
10
|
+
author: "Spec-Kit"
|
|
11
|
+
tags:
|
|
12
|
+
- feature
|
|
13
|
+
- quick-win
|
|
14
|
+
- lightweight
|
|
15
|
+
|
|
16
|
+
template: functional-spec.md
|
|
17
|
+
defaultAgent: SpecAgent
|
|
18
|
+
|
|
19
|
+
steps:
|
|
20
|
+
- id: quick-spec
|
|
21
|
+
name: "Quick Specification"
|
|
22
|
+
action: call_agent
|
|
23
|
+
agent: SpecAgent
|
|
24
|
+
description: |
|
|
25
|
+
Create a minimal specification with:
|
|
26
|
+
- Feature summary (2-3 sentences)
|
|
27
|
+
- User story (As a... I want... So that...)
|
|
28
|
+
- Acceptance criteria (3-5 bullet points)
|
|
29
|
+
- Technical notes (if any)
|
|
30
|
+
|
|
31
|
+
Keep it simple and actionable. No lengthy documentation needed.
|
|
32
|
+
inputs:
|
|
33
|
+
- name: requirements
|
|
34
|
+
description: "Feature description from user"
|
|
35
|
+
required: true
|
|
36
|
+
outputs:
|
|
37
|
+
- quick_spec
|
|
38
|
+
|
|
39
|
+
- id: implement
|
|
40
|
+
name: "Implement"
|
|
41
|
+
action: call_agent
|
|
42
|
+
agent: SpecAgent
|
|
43
|
+
description: |
|
|
44
|
+
Implement the feature directly based on the quick spec.
|
|
45
|
+
|
|
46
|
+
Guidelines:
|
|
47
|
+
- Follow project conventions from constitution
|
|
48
|
+
- Write clean, tested code
|
|
49
|
+
- Keep changes minimal and focused
|
|
50
|
+
inputs:
|
|
51
|
+
source: "quick_spec"
|
|
52
|
+
outputs:
|
|
53
|
+
- implementation
|
|
54
|
+
|
|
55
|
+
- id: auto-memory
|
|
56
|
+
name: "Update Memory"
|
|
57
|
+
action: call_agent
|
|
58
|
+
agent: SpecAgent
|
|
59
|
+
description: |
|
|
60
|
+
Automatically enrich project memory with:
|
|
61
|
+
- What was implemented (brief summary)
|
|
62
|
+
- Any technical decisions made
|
|
63
|
+
- Patterns or conventions used
|
|
64
|
+
|
|
65
|
+
Save to .spec-kit/memory/learnings.md or appropriate category.
|
|
66
|
+
inputs:
|
|
67
|
+
source: "implementation"
|
|
68
|
+
outputs:
|
|
69
|
+
- memory_update
|
|
@@ -0,0 +1,92 @@
|
|
|
1
|
+
# Feature Standard Workflow
|
|
2
|
+
# Used for creating functional specifications from Azure DevOps Feature work items
|
|
3
|
+
|
|
4
|
+
name: feature-standard
|
|
5
|
+
displayName: "Feature Specification"
|
|
6
|
+
description: "Creates a complete functional specification document from an Azure DevOps Feature work item"
|
|
7
|
+
|
|
8
|
+
metadata:
|
|
9
|
+
version: "1.0"
|
|
10
|
+
author: "Spec-Kit"
|
|
11
|
+
tags:
|
|
12
|
+
- feature
|
|
13
|
+
- specification
|
|
14
|
+
- functional
|
|
15
|
+
|
|
16
|
+
template: functional-spec.md
|
|
17
|
+
defaultAgent: SpecAgent
|
|
18
|
+
|
|
19
|
+
steps:
|
|
20
|
+
- id: fetch-workitem
|
|
21
|
+
name: "Fetch Azure DevOps Work Item"
|
|
22
|
+
action: fetch_ado
|
|
23
|
+
description: |
|
|
24
|
+
Retrieve the Feature work item from Azure DevOps.
|
|
25
|
+
Extract: Title, Description, Acceptance Criteria, Tags, Links, and Parent/Child relationships.
|
|
26
|
+
outputs:
|
|
27
|
+
- workitem_data
|
|
28
|
+
- linked_items
|
|
29
|
+
|
|
30
|
+
- id: analyze-requirements
|
|
31
|
+
name: "Analyze Requirements"
|
|
32
|
+
action: call_agent
|
|
33
|
+
agent: SpecAgent
|
|
34
|
+
description: |
|
|
35
|
+
Analyze the work item data to identify:
|
|
36
|
+
- Core functional requirements
|
|
37
|
+
- Non-functional requirements (performance, security, etc.)
|
|
38
|
+
- User personas and use cases
|
|
39
|
+
- Dependencies and constraints
|
|
40
|
+
- Risks and assumptions
|
|
41
|
+
inputs:
|
|
42
|
+
source: "workitem_data"
|
|
43
|
+
outputs:
|
|
44
|
+
- requirements_analysis
|
|
45
|
+
|
|
46
|
+
- id: generate-spec
|
|
47
|
+
name: "Generate Specification Document"
|
|
48
|
+
action: generate_content
|
|
49
|
+
agent: SpecAgent
|
|
50
|
+
description: |
|
|
51
|
+
Using the template and analyzed requirements, generate the functional specification.
|
|
52
|
+
|
|
53
|
+
Guidelines:
|
|
54
|
+
- Fill all sections with available data
|
|
55
|
+
- Mark unclear sections with [TO FILL] for human review
|
|
56
|
+
- Include traceability links to Azure DevOps
|
|
57
|
+
- Follow the template structure strictly
|
|
58
|
+
inputs:
|
|
59
|
+
template: "functional-spec.md"
|
|
60
|
+
data: "requirements_analysis"
|
|
61
|
+
outputs:
|
|
62
|
+
- spec_document
|
|
63
|
+
|
|
64
|
+
- id: review-spec
|
|
65
|
+
name: "Review & Validate"
|
|
66
|
+
action: review
|
|
67
|
+
agent: GovAgent
|
|
68
|
+
description: |
|
|
69
|
+
Review the generated specification for:
|
|
70
|
+
- Completeness (all required sections filled)
|
|
71
|
+
- Consistency (no contradictions)
|
|
72
|
+
- Clarity (understandable by all stakeholders)
|
|
73
|
+
- Traceability (links to source requirements)
|
|
74
|
+
|
|
75
|
+
Suggest improvements if needed.
|
|
76
|
+
inputs:
|
|
77
|
+
document: "spec_document"
|
|
78
|
+
outputs:
|
|
79
|
+
- review_feedback
|
|
80
|
+
- validated_spec
|
|
81
|
+
|
|
82
|
+
- id: create-file
|
|
83
|
+
name: "Save Specification"
|
|
84
|
+
action: create_file
|
|
85
|
+
description: |
|
|
86
|
+
Save the validated specification as a Markdown file.
|
|
87
|
+
Suggested location: `specs/{workitem_id}-functional-spec.md`
|
|
88
|
+
inputs:
|
|
89
|
+
content: "validated_spec"
|
|
90
|
+
filename_pattern: "{context_id}-functional-spec.md"
|
|
91
|
+
outputs:
|
|
92
|
+
- file_path
|
|
@@ -0,0 +1,69 @@
|
|
|
1
|
+
# Feature Quick Workflow
|
|
2
|
+
# Lightweight workflow for simple features / quick wins
|
|
3
|
+
|
|
4
|
+
name: feature-quick
|
|
5
|
+
displayName: "Quick Feature (Quick Win)"
|
|
6
|
+
description: "Lightweight workflow for simple features that don't need full specification"
|
|
7
|
+
|
|
8
|
+
metadata:
|
|
9
|
+
version: "1.0"
|
|
10
|
+
author: "Spec-Kit"
|
|
11
|
+
tags:
|
|
12
|
+
- feature
|
|
13
|
+
- quick-win
|
|
14
|
+
- lightweight
|
|
15
|
+
|
|
16
|
+
template: functional-spec.md
|
|
17
|
+
defaultAgent: SpecAgent
|
|
18
|
+
|
|
19
|
+
steps:
|
|
20
|
+
- id: quick-spec
|
|
21
|
+
name: "Quick Specification"
|
|
22
|
+
action: call_agent
|
|
23
|
+
agent: SpecAgent
|
|
24
|
+
description: |
|
|
25
|
+
Create a minimal specification with:
|
|
26
|
+
- Feature summary (2-3 sentences)
|
|
27
|
+
- User story (As a... I want... So that...)
|
|
28
|
+
- Acceptance criteria (3-5 bullet points)
|
|
29
|
+
- Technical notes (if any)
|
|
30
|
+
|
|
31
|
+
Keep it simple and actionable. No lengthy documentation needed.
|
|
32
|
+
inputs:
|
|
33
|
+
- name: requirements
|
|
34
|
+
description: "Feature description from user"
|
|
35
|
+
required: true
|
|
36
|
+
outputs:
|
|
37
|
+
- quick_spec
|
|
38
|
+
|
|
39
|
+
- id: implement
|
|
40
|
+
name: "Implement"
|
|
41
|
+
action: call_agent
|
|
42
|
+
agent: SpecAgent
|
|
43
|
+
description: |
|
|
44
|
+
Implement the feature directly based on the quick spec.
|
|
45
|
+
|
|
46
|
+
Guidelines:
|
|
47
|
+
- Follow project conventions from constitution
|
|
48
|
+
- Write clean, tested code
|
|
49
|
+
- Keep changes minimal and focused
|
|
50
|
+
inputs:
|
|
51
|
+
source: "quick_spec"
|
|
52
|
+
outputs:
|
|
53
|
+
- implementation
|
|
54
|
+
|
|
55
|
+
- id: auto-memory
|
|
56
|
+
name: "Update Memory"
|
|
57
|
+
action: call_agent
|
|
58
|
+
agent: SpecAgent
|
|
59
|
+
description: |
|
|
60
|
+
Automatically enrich project memory with:
|
|
61
|
+
- What was implemented (brief summary)
|
|
62
|
+
- Any technical decisions made
|
|
63
|
+
- Patterns or conventions used
|
|
64
|
+
|
|
65
|
+
Save to .spec-kit/memory/learnings.md or appropriate category.
|
|
66
|
+
inputs:
|
|
67
|
+
source: "implementation"
|
|
68
|
+
outputs:
|
|
69
|
+
- memory_update
|