smart-spec-kit-mcp 2.0.4 → 2.0.6
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 +128 -60
- package/dist/cli.js +51 -26
- package/dist/cli.js.map +1 -1
- package/dist/index.js +2 -0
- package/dist/index.js.map +1 -1
- package/dist/tools/promptTools.d.ts +12 -0
- package/dist/tools/promptTools.d.ts.map +1 -0
- package/dist/tools/promptTools.js +540 -0
- package/dist/tools/promptTools.js.map +1 -0
- package/dist/utils/starterKitInstaller.d.ts +2 -1
- package/dist/utils/starterKitInstaller.d.ts.map +1 -1
- package/dist/utils/starterKitInstaller.js +51 -29
- package/dist/utils/starterKitInstaller.js.map +1 -1
- package/docs/DOCUMENTATION.md +423 -0
- package/docs/PACKAGING.md +323 -0
- package/package.json +2 -1
- package/starter-kit/copilot-instructions.md +96 -0
- package/starter-kit/prompts/clarify.md +73 -0
- package/starter-kit/prompts/implement.md +79 -0
- package/starter-kit/prompts/plan.md +69 -0
- package/starter-kit/prompts/specify.md +74 -0
- package/starter-kit/prompts/tasks.md +76 -0
- package/starter-kit/prompts/speckit.clarify.md +0 -129
- package/starter-kit/prompts/speckit.implement.md +0 -122
- package/starter-kit/prompts/speckit.init.md +0 -153
- package/starter-kit/prompts/speckit.plan.md +0 -145
- package/starter-kit/prompts/speckit.specify.md +0 -123
- package/starter-kit/prompts/speckit.tasks.md +0 -137
|
@@ -1,123 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
description: Create a functional specification from requirements or an Azure DevOps work item. Focus on WHAT you want to build, not the tech stack.
|
|
3
|
-
---
|
|
4
|
-
|
|
5
|
-
# /speckit.specify - Create Specification
|
|
6
|
-
|
|
7
|
-
## User Input
|
|
8
|
-
|
|
9
|
-
```text
|
|
10
|
-
$ARGUMENTS
|
|
11
|
-
```
|
|
12
|
-
|
|
13
|
-
You **MUST** consider the user input before proceeding (if not empty).
|
|
14
|
-
|
|
15
|
-
## Outline
|
|
16
|
-
|
|
17
|
-
You are creating a functional specification document. Follow this workflow:
|
|
18
|
-
|
|
19
|
-
### 1. Setup Check
|
|
20
|
-
|
|
21
|
-
First, verify the Spec-Kit environment:
|
|
22
|
-
- Check if `.spec-kit/` directory exists
|
|
23
|
-
- If not, inform the user to run `/speckit.init` first
|
|
24
|
-
|
|
25
|
-
### 2. Parse Requirements Source
|
|
26
|
-
|
|
27
|
-
Determine the source of requirements from user input:
|
|
28
|
-
|
|
29
|
-
**Option A: Azure DevOps Work Item**
|
|
30
|
-
- If input contains an ADO work item ID (e.g., "#12345", "AB#12345", "Feature 12345")
|
|
31
|
-
- Use the `fetch_ado_workitem` MCP tool to retrieve work item data
|
|
32
|
-
|
|
33
|
-
**Option B: Direct Description**
|
|
34
|
-
- If input is a feature description
|
|
35
|
-
- Parse the description for key concepts: actors, actions, data, constraints
|
|
36
|
-
|
|
37
|
-
### 3. Analyze Requirements
|
|
38
|
-
|
|
39
|
-
For the provided requirements, identify:
|
|
40
|
-
1. **Core user need** and business value
|
|
41
|
-
2. **Explicit requirements** - what was directly stated
|
|
42
|
-
3. **Implicit requirements** - reasonable inferences from context
|
|
43
|
-
4. **Assumptions** - things that need validation
|
|
44
|
-
5. **Risks and dependencies**
|
|
45
|
-
6. **Edge cases and error scenarios**
|
|
46
|
-
|
|
47
|
-
### 4. Generate Specification
|
|
48
|
-
|
|
49
|
-
Load the template from `.spec-kit/templates/functional-spec.md` and fill it with:
|
|
50
|
-
|
|
51
|
-
1. **Metadata Section**
|
|
52
|
-
- Title, date, version, status
|
|
53
|
-
- Link to Azure DevOps work item (if applicable)
|
|
54
|
-
|
|
55
|
-
2. **Overview**
|
|
56
|
-
- Purpose (the problem being solved)
|
|
57
|
-
- Scope (what's in/out)
|
|
58
|
-
- Background context
|
|
59
|
-
|
|
60
|
-
3. **Requirements**
|
|
61
|
-
- Functional requirements with IDs and priorities (Must Have/Should Have/Could Have)
|
|
62
|
-
- Non-functional requirements (performance, security, etc.)
|
|
63
|
-
- Acceptance criteria in Given/When/Then format
|
|
64
|
-
|
|
65
|
-
4. **User Experience**
|
|
66
|
-
- User personas
|
|
67
|
-
- User stories (As a... I want... So that...)
|
|
68
|
-
- User flow descriptions
|
|
69
|
-
|
|
70
|
-
5. **Technical Considerations**
|
|
71
|
-
- Dependencies
|
|
72
|
-
- Constraints
|
|
73
|
-
- Data requirements
|
|
74
|
-
|
|
75
|
-
### 5. Handle Ambiguity
|
|
76
|
-
|
|
77
|
-
For unclear aspects:
|
|
78
|
-
- **Make informed guesses** based on context and industry standards
|
|
79
|
-
- **Document assumptions** in the Assumptions section
|
|
80
|
-
- **Limit clarifications**: Maximum 3 `[NEEDS CLARIFICATION]` markers for critical decisions only
|
|
81
|
-
|
|
82
|
-
Only use `[NEEDS CLARIFICATION]` when:
|
|
83
|
-
- The choice significantly impacts feature scope or user experience
|
|
84
|
-
- Multiple reasonable interpretations exist with different implications
|
|
85
|
-
- No reasonable default exists
|
|
86
|
-
|
|
87
|
-
### 6. Save Specification
|
|
88
|
-
|
|
89
|
-
Save the specification to:
|
|
90
|
-
```
|
|
91
|
-
specs/{context_id}-spec.md
|
|
92
|
-
```
|
|
93
|
-
|
|
94
|
-
If no context ID is provided, create a timestamped filename or ask for a feature short-name.
|
|
95
|
-
|
|
96
|
-
### 7. Report Completion
|
|
97
|
-
|
|
98
|
-
Output:
|
|
99
|
-
- Path to created specification file
|
|
100
|
-
- Summary of requirements captured
|
|
101
|
-
- List of assumptions made
|
|
102
|
-
- Any `[NEEDS CLARIFICATION]` items that need user input
|
|
103
|
-
- Next step suggestion: `/speckit.plan` to create implementation plan
|
|
104
|
-
|
|
105
|
-
## Quick Guidelines
|
|
106
|
-
|
|
107
|
-
### Writing Style
|
|
108
|
-
- Use active voice and clear, concise language
|
|
109
|
-
- Include concrete examples for complex requirements
|
|
110
|
-
- Define all technical terms and acronyms
|
|
111
|
-
- Use tables for structured data (requirements, test cases)
|
|
112
|
-
|
|
113
|
-
### Quality Checks
|
|
114
|
-
- Every requirement should be testable and unambiguous
|
|
115
|
-
- Each requirement should have a unique ID
|
|
116
|
-
- Acceptance criteria should be in Given/When/Then format
|
|
117
|
-
- No undefined placeholders in final output (except intentional `[NEEDS CLARIFICATION]`)
|
|
118
|
-
|
|
119
|
-
## Handoffs
|
|
120
|
-
|
|
121
|
-
After completing the specification, suggest:
|
|
122
|
-
- **Clarify requirements**: `/speckit.clarify` - If there are `[NEEDS CLARIFICATION]` items
|
|
123
|
-
- **Create implementation plan**: `/speckit.plan` - Once specification is approved
|
|
@@ -1,137 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
description: Generate actionable task breakdown from the implementation plan. Creates a tasks.md file with ordered, dependency-aware tasks.
|
|
3
|
-
---
|
|
4
|
-
|
|
5
|
-
# /speckit.tasks - Generate Task Breakdown
|
|
6
|
-
|
|
7
|
-
## User Input
|
|
8
|
-
|
|
9
|
-
```text
|
|
10
|
-
$ARGUMENTS
|
|
11
|
-
```
|
|
12
|
-
|
|
13
|
-
You **MUST** consider the user input before proceeding (if not empty).
|
|
14
|
-
|
|
15
|
-
## Outline
|
|
16
|
-
|
|
17
|
-
You are generating an actionable task list from the implementation plan. Follow this workflow:
|
|
18
|
-
|
|
19
|
-
### 1. Load Design Documents
|
|
20
|
-
|
|
21
|
-
Read from the feature's spec directory:
|
|
22
|
-
- **Required**: `plan.md` (tech stack, libraries, structure)
|
|
23
|
-
- **Required**: `spec.md` (user stories with priorities)
|
|
24
|
-
- **Optional**: `data-model.md` (entities)
|
|
25
|
-
- **Optional**: `contracts/` (API endpoints)
|
|
26
|
-
- **Optional**: `research.md` (decisions)
|
|
27
|
-
|
|
28
|
-
If required files are missing, inform user to run `/speckit.plan` first.
|
|
29
|
-
|
|
30
|
-
### 2. Extract Implementation Context
|
|
31
|
-
|
|
32
|
-
From the documents, identify:
|
|
33
|
-
- User stories with their priorities (P1, P2, P3)
|
|
34
|
-
- Tech stack and frameworks
|
|
35
|
-
- Database entities and relationships
|
|
36
|
-
- API endpoints
|
|
37
|
-
- External dependencies
|
|
38
|
-
|
|
39
|
-
### 3. Generate Task Breakdown
|
|
40
|
-
|
|
41
|
-
Create `specs/{feature}/tasks.md` with this structure:
|
|
42
|
-
|
|
43
|
-
```markdown
|
|
44
|
-
# Tasks: {Feature Name}
|
|
45
|
-
|
|
46
|
-
**Input**: Design documents from `/specs/{feature}/`
|
|
47
|
-
**Generated**: {Date}
|
|
48
|
-
|
|
49
|
-
## Task Format
|
|
50
|
-
|
|
51
|
-
- [ ] T### [P?] [Story?] Description - `path/to/file.ext`
|
|
52
|
-
|
|
53
|
-
Legend:
|
|
54
|
-
- T###: Task ID (sequential)
|
|
55
|
-
- [P]: Can be executed in parallel with other [P] tasks
|
|
56
|
-
- [Story?]: Associated user story ID (if applicable)
|
|
57
|
-
```
|
|
58
|
-
|
|
59
|
-
### 4. Phase Structure
|
|
60
|
-
|
|
61
|
-
Organize tasks into these phases:
|
|
62
|
-
|
|
63
|
-
**Phase 1: Setup (Shared Infrastructure)**
|
|
64
|
-
- Project initialization
|
|
65
|
-
- Dependency installation
|
|
66
|
-
- Configuration files
|
|
67
|
-
- Development environment setup
|
|
68
|
-
|
|
69
|
-
**Phase 2: Foundational (Blocking Prerequisites)**
|
|
70
|
-
- Database schema and migrations
|
|
71
|
-
- Base models/entities
|
|
72
|
-
- Authentication/authorization framework
|
|
73
|
-
- Core utilities and helpers
|
|
74
|
-
- Error handling infrastructure
|
|
75
|
-
|
|
76
|
-
⚠️ **CRITICAL**: No user story work begins until Phase 2 is complete.
|
|
77
|
-
|
|
78
|
-
**Phase 3+: User Stories (One Phase per Story)**
|
|
79
|
-
For each user story in priority order:
|
|
80
|
-
- Tests (if requested) → Models → Services → Endpoints → Integration
|
|
81
|
-
- Each phase should be independently testable
|
|
82
|
-
- Include checkpoint validation
|
|
83
|
-
|
|
84
|
-
**Final Phase: Polish & Cross-Cutting**
|
|
85
|
-
- Code cleanup and refactoring
|
|
86
|
-
- Documentation updates
|
|
87
|
-
- Performance optimization
|
|
88
|
-
- Security hardening
|
|
89
|
-
|
|
90
|
-
### 5. Task Generation Rules
|
|
91
|
-
|
|
92
|
-
Each task MUST:
|
|
93
|
-
- Be completable in 1-3 days by a single developer
|
|
94
|
-
- Have a clear verb + object title
|
|
95
|
-
- Include the file path(s) affected
|
|
96
|
-
- Have explicit dependencies noted
|
|
97
|
-
|
|
98
|
-
Mark with `[P]` if the task can run in parallel with others at the same level.
|
|
99
|
-
|
|
100
|
-
### 6. Generate Dependency Graph
|
|
101
|
-
|
|
102
|
-
Add a section showing:
|
|
103
|
-
- Task dependencies (which tasks must complete first)
|
|
104
|
-
- Parallel execution opportunities
|
|
105
|
-
- Critical path identification
|
|
106
|
-
|
|
107
|
-
### 7. Report Completion
|
|
108
|
-
|
|
109
|
-
Output:
|
|
110
|
-
- Path to generated `tasks.md`
|
|
111
|
-
- Total task count
|
|
112
|
-
- Task count per user story
|
|
113
|
-
- Parallel execution opportunities identified
|
|
114
|
-
- Suggested MVP scope (typically User Story 1 only)
|
|
115
|
-
|
|
116
|
-
## Task Template
|
|
117
|
-
|
|
118
|
-
```markdown
|
|
119
|
-
## Phase 3: User Story 1 - {Title} (Priority: P1) 🎯 MVP
|
|
120
|
-
|
|
121
|
-
**Goal**: {User story goal}
|
|
122
|
-
**Independent Test**: {How to verify this story works alone}
|
|
123
|
-
|
|
124
|
-
- [ ] T010 [US-1] Create {model} entity - `src/models/{model}.ts`
|
|
125
|
-
- [ ] T011 [P] [US-1] Create {model} repository - `src/repositories/{model}.ts`
|
|
126
|
-
- [ ] T012 [P] [US-1] Create {model} service - `src/services/{model}.ts`
|
|
127
|
-
- [ ] T013 [US-1] Create {endpoint} API endpoint - `src/api/{endpoint}.ts`
|
|
128
|
-
- [ ] T014 [US-1] Add integration tests - `tests/integration/{feature}.test.ts`
|
|
129
|
-
|
|
130
|
-
**Checkpoint**: Story 1 complete - run `npm test` and verify {criteria}
|
|
131
|
-
```
|
|
132
|
-
|
|
133
|
-
## Handoffs
|
|
134
|
-
|
|
135
|
-
After completing the tasks, suggest:
|
|
136
|
-
- **Analyze plan**: `/speckit.analyze` - Cross-check consistency
|
|
137
|
-
- **Implement**: `/speckit.implement` - Start executing tasks
|