This is page 2 of 2. Use http://codebase.md/kingkongshot/specs-workflow-mcp?lines=true&page={x} to view the full context.
# Directory Structure
```
├── .gitignore
├── .npmignore
├── api
│ └── spec-workflow.openapi.yaml
├── eslint.config.js
├── LICENSE
├── logo.png
├── package-lock.json
├── package.json
├── README-zh.md
├── README.md
├── scripts
│ ├── generateOpenApiWebUI.ts
│ ├── generateTypes.ts
│ ├── publish-npm.sh
│ ├── sync-package.sh
│ └── validateOpenApi.ts
├── src
│ ├── features
│ │ ├── check
│ │ │ ├── analyzeStage.ts
│ │ │ ├── checkWorkflow.ts
│ │ │ └── generateNextDocument.ts
│ │ ├── confirm
│ │ │ └── confirmStage.ts
│ │ ├── executeWorkflow.ts
│ │ ├── init
│ │ │ ├── createRequirementsDoc.ts
│ │ │ └── initWorkflow.ts
│ │ ├── shared
│ │ │ ├── confirmationStatus.ts
│ │ │ ├── documentAnalyzer.ts
│ │ │ ├── documentStatus.ts
│ │ │ ├── documentTemplates.ts
│ │ │ ├── documentUtils.ts
│ │ │ ├── mcpTypes.ts
│ │ │ ├── openApiLoader.ts
│ │ │ ├── openApiTypes.ts
│ │ │ ├── progressCalculator.ts
│ │ │ ├── responseBuilder.ts
│ │ │ ├── taskGuidanceTemplate.ts
│ │ │ ├── taskParser.ts
│ │ │ └── typeGuards.ts
│ │ ├── skip
│ │ │ └── skipStage.ts
│ │ └── task
│ │ └── completeTask.ts
│ ├── index.ts
│ └── tools
│ └── specWorkflowTool.ts
└── tsconfig.json
```
# Files
--------------------------------------------------------------------------------
/api/spec-workflow.openapi.yaml:
--------------------------------------------------------------------------------
```yaml
1 | openapi: 3.1.0
2 | info:
3 | title: Spec Workflow API
4 | version: 1.0.0
5 | description: Intelligent Requirements Document Workflow API Specification
6 |
7 | servers:
8 | - url: mcp://spec-workflow
9 |
10 | # All operation definitions
11 | paths:
12 | /spec:
13 | post:
14 | operationId: executeWorkflow
15 | summary: Execute workflow operation
16 | requestBody:
17 | required: true
18 | content:
19 | application/json:
20 | schema:
21 | $ref: '#/components/schemas/WorkflowRequest'
22 | responses:
23 | '200':
24 | description: Operation successful
25 | content:
26 | application/json:
27 | schema:
28 | $ref: '#/components/schemas/WorkflowResponse'
29 |
30 | # Data model definitions
31 | components:
32 | schemas:
33 | # Request definitions
34 | WorkflowRequest:
35 | type: object
36 | required: [action]
37 | properties:
38 | featureName:
39 | type: string
40 | description: |
41 | Feature name for the specification (e.g., "用户认证", "order-management").
42 |
43 | **Required for**: init, check, skip, confirm, complete_task operations.
44 |
45 | The system will automatically resolve this to: {specsPath}/{featureName}/
46 |
47 | **For setup_workspace**: Not required - the system uses current working directory as project root.
48 | action:
49 | $ref: '#/components/schemas/Action'
50 |
51 | Action:
52 | type: object
53 | required: [type]
54 | properties:
55 | type:
56 | type: string
57 | enum: [setup_workspace, init, check, skip, confirm, complete_task]
58 | description: |
59 | Operation type to perform:
60 |
61 | - **setup_workspace**: Initialize project workspace (usually not called directly - MCP will automatically guide model to use this when needed)
62 | - **init**: Initialize a new feature specification
63 | - **check**: Check current workflow status
64 | - **skip**: Skip current stage
65 | - **confirm**: Confirm current stage completion
66 | - **complete_task**: Mark task(s) as completed
67 |
68 | introduction:
69 | type: string
70 | description: Feature introduction (required for init)
71 | language:
72 | type: string
73 | description: User preferred language for documentation (required for setup_workspace)
74 | taskNumber:
75 | oneOf:
76 | - type: string
77 | description: Single task number to mark as completed
78 | - type: array
79 | items:
80 | type: string
81 | description: Multiple task numbers for batch completion
82 | description: Task number(s) to mark as completed (required for complete_task)
83 |
84 | # Response definitions
85 | WorkflowResponse:
86 | type: object
87 | required: [result]
88 | properties:
89 | result:
90 | oneOf:
91 | - $ref: '#/components/schemas/ProjectInitResponse'
92 | - $ref: '#/components/schemas/InitResponse'
93 | - $ref: '#/components/schemas/CheckResponse'
94 | - $ref: '#/components/schemas/SkipResponse'
95 | - $ref: '#/components/schemas/ConfirmResponse'
96 | - $ref: '#/components/schemas/BatchCompleteTaskResponse'
97 |
98 | # Project initialization response
99 | ProjectInitResponse:
100 | type: object
101 | required: [success, data, displayText]
102 | properties:
103 | success:
104 | type: boolean
105 | data:
106 | type: object
107 | properties:
108 | success:
109 | type: boolean
110 | needsUserInput:
111 | type: boolean
112 | missingParams:
113 | type: array
114 | items:
115 | type: string
116 | projectRoot:
117 | type: string
118 | language:
119 | type: string
120 | userGuidelinesCreated:
121 | type: boolean
122 | configPath:
123 | type: string
124 | error:
125 | type: string
126 | errorType:
127 | type: string
128 | suggestions:
129 | type: array
130 | items:
131 | type: string
132 | displayText:
133 | type: string
134 | x-dynamic-fields:
135 | displayText: ["projectRoot", "language", "configPath", "error", "suggestions"]
136 | x-example-selection:
137 | criteria:
138 | - field: "success"
139 | required: true
140 | - field: "data.needsUserInput"
141 | when: "data.needsUserInput === true"
142 | - field: "data.errorType"
143 | when: "data.errorType !== undefined"
144 | examples:
145 | - success: false
146 | data:
147 | success: false
148 | needsUserInput: true
149 | missingParams: ["language"]
150 | displayText: |
151 | 🔧 Project initialization requires more information
152 |
153 | Model: Please ask user for their language preference:
154 |
155 | **Language Preference**: I will use (user's preferred language) for document writing - do you agree?
156 | - User can respond with: "Chinese", "English", "zh-CN", etc.
157 |
158 | After getting the user's response, model please call setup_workspace again with the language parameter.
159 |
160 | 📁 Specification documents will be automatically stored in the .specs folder in the project root directory.
161 |
162 | - success: true
163 | data:
164 | success: true
165 | projectRoot: /project/root
166 | language: English
167 | userGuidelinesCreated: true
168 | configPath: /project/root/.specs/.specs-workflow.json
169 | displayText: |
170 | ✅ Project initialization successful!
171 |
172 | 📁 Project root path: ${projectRoot}
173 | 📝 Specification documents path: ${projectRoot}/.specs
174 | 🌐 Documentation language: ${language}
175 |
176 | 📋 Created User Guidelines files:
177 | - user-guidelines-requirements.md - User preference guide for requirements documents
178 | - user-guidelines-design.md - User preference guide for design documents
179 | - user-guidelines-tasks.md - User preference guide for task documents
180 |
181 | 💡 Model: Please ask user to edit these User Guidelines files to guide the model's behavior. These contents will be automatically displayed when showing the corresponding stage writing guides.
182 |
183 | Model: Please ask user to use the init operation to start creating specific feature specification documents.
184 |
185 | - success: false
186 | data:
187 | success: false
188 | error: "Project already initialized"
189 | errorType: "already_initialized"
190 | projectRoot: /project/root
191 | configPath: /project/root/.specs/.specs-workflow.json
192 | suggestions: ["Delete .specs directory and reinitialize", "Or use existing configuration directly"]
193 | displayText: |
194 | ❌ Project already initialized
195 |
196 | 📁 Project root path: ${projectRoot}
197 | 📝 Configuration file: ${configPath}
198 |
199 | If user needs to reconfigure, model please ask user to delete the .specs directory first, then run setup_workspace again.
200 |
201 | - success: false
202 | data:
203 | success: false
204 | error: "Initialization failed"
205 | errorType: "PermissionError"
206 | suggestions: ["Check directory permissions", "Run with appropriate privileges", "Contact system administrator"]
207 | displayText: |
208 | ❌ Project initialization failed
209 |
210 | ${error}
211 |
212 | Suggested solutions:
213 | ${suggestions}
214 |
215 | If the problem persists, model please ask user to check system permission settings or contact the system administrator.
216 |
217 |
218 | # Initialization response
219 | InitResponse:
220 | type: object
221 | required: [success, data, displayText]
222 | properties:
223 | success:
224 | type: boolean
225 | data:
226 | type: object
227 | properties:
228 | path:
229 | type: string
230 | featureName:
231 | type: string
232 | nextAction:
233 | type: string
234 | const: edit_requirements
235 | displayText:
236 | type: string
237 | x-dynamic-fields:
238 | displayText: ["featureName", "path", "progress"]
239 | x-example-selection:
240 | criteria:
241 | - field: "success"
242 | required: true
243 | examples:
244 | - success: true
245 | data:
246 | path: /specs/new-feature
247 | featureName: New Feature
248 | nextAction: edit_requirements
249 | displayText: |
250 | ✅ ${featureName} initialized successfully!
251 |
252 | 📁 File directory: ${path}
253 | 📝 Created: requirements.md
254 |
255 | 📊 Overall progress: ${progress}%
256 | 🔄 Current status: Initialization successful (current) → Next step: write requirements document
257 |
258 | Model please continue with the following actions:
259 | 1. Read the requirements-guide below
260 | 2. First read ${path}/requirements.md, then start writing the document
261 | 3. After completing the document, use specs-workflow tool with action.type="check" to check the document format
262 | 4. When check passes, the model must ask the user "Do the requirements look good?", and must not proceed to the design document until getting explicit approval (e.g., "yes", "approved", "looks good", etc.)
263 | 5. When the user approves, the model must use the specs-workflow tool with action.type="confirm" to enter the design phase
264 |
265 | Special case - Skip requirements phase:
266 | - Only consider skipping when user explicitly requests (e.g., "skip requirements document", "go directly to design")
267 | - Before executing skip operation, the model must:
268 | 1. Explain to user this is an unconventional operation, requirements document is the foundation of the entire development process
269 | 2. Clearly state the risks: design may deviate from actual requirements, increasing rework costs
270 | 3. Ask the user: "Understanding these risks, are you sure you want to skip the requirements phase?"
271 | 4. Only use action.type="skip" after user explicitly confirms
272 |
273 |
274 | # Check response
275 | CheckResponse:
276 | type: object
277 | required: [stage, progress, status, displayText]
278 | properties:
279 | stage:
280 | $ref: '#/components/schemas/Stage'
281 | progress:
282 | $ref: '#/components/schemas/Progress'
283 | status:
284 | $ref: '#/components/schemas/Status'
285 | displayText:
286 | type: string
287 | x-dynamic-fields:
288 | displayText: ["path", "progress", "featureName"]
289 | x-example-selection:
290 | criteria:
291 | - field: "stage"
292 | required: true
293 | - field: "status.type"
294 | required: true
295 | examples:
296 | - stage: requirements
297 | progress:
298 | overall: 0
299 | requirements: 0
300 | design: 0
301 | tasks: 0
302 | status:
303 | type: not_edited
304 | reason: Requirements document not edited
305 | readyToConfirm: false
306 | displayText: |
307 | 📝 requirements.md has not been written yet
308 |
309 | 📁 File directory: ${path}
310 | 📝 Created: requirements.md
311 |
312 | 📊 Overall progress: ${progress}%
313 | 🔄 Current status: Writing requirements document (current) → Next step: use check to verify format
314 |
315 | Model please continue with the following actions:
316 | 1. Read the requirements-guide below
317 | 2. First read ${path}/requirements.md, then start writing the document
318 | 3. After completing the document, use specs-workflow tool with action.type="check" to check the document format
319 | 4. When check passes, the model must ask the user "Do the requirements look good?", and must not proceed to the design document until getting explicit approval (e.g., "yes", "approved", "looks good", etc.)
320 | 5. When the user approves, the model must use the specs-workflow tool with action.type="confirm" to enter the design phase
321 |
322 | Special case - Skip requirements phase:
323 | - Only consider skipping when user explicitly requests (e.g., "skip requirements document", "go directly to design")
324 | - Before executing skip operation, the model must:
325 | 1. Explain to user this is an unconventional operation, requirements document is the foundation of the entire development process
326 | 2. Clearly state the risks: design may deviate from actual requirements, increasing rework costs
327 | 3. Ask the user: "Understanding these risks, are you sure you want to skip the requirements phase?"
328 | 4. Only use action.type="skip" after user explicitly confirms
329 |
330 |
331 | - stage: requirements
332 | progress:
333 | overall: 30
334 | requirements: 100
335 | design: 0
336 | tasks: 0
337 | status:
338 | type: ready_to_confirm
339 | readyToConfirm: true
340 | displayText: |
341 | ✅ Requirements document check passed!
342 |
343 | 📊 Overall progress: ${progress}%
344 | 🔄 Current status: Checking requirements document (current) → Next step: get user approval
345 |
346 | Model please continue with the following actions:
347 | 1. Ask the user "Do the requirements look good?"
348 | 2. Wait for explicit user approval (e.g., "yes", "approved", "looks good", etc.)
349 | 3. After approval, use the specs-workflow tool with action.type="confirm"
350 | 4. Enter the design phase
351 |
352 | - stage: design
353 | progress:
354 | overall: 30
355 | requirements: 100
356 | design: 0
357 | tasks: 0
358 | status:
359 | type: not_edited
360 | reason: Design document not edited
361 | displayText: |
362 | 📝 design.md has not been written yet
363 |
364 | 📁 File directory: ${path}
365 | 📝 Created: design.md
366 |
367 | 📊 Overall progress: ${progress}%
368 | 🔄 Current status: Writing design document (current) → Next step: use check to verify format
369 |
370 | Model please continue with the following actions:
371 | 1. Read the design-guide below
372 | 2. First read ${path}/design.md, then start writing the document
373 | 3. After completing the document, use specs-workflow tool with action.type="check" to check the document format
374 | 4. When check passes, the model must ask the user "Does the design look good?", and must not proceed to task writing until getting explicit approval (e.g., "yes", "approved", "looks good", etc.)
375 | 5. When the user approves, the model must use the specs-workflow tool with action.type="confirm" to enter the tasks phase
376 |
377 | Special case - Skip design phase:
378 | - Only consider skipping when user explicitly requests (e.g., "skip design document", "go directly to tasks")
379 | - Before executing skip operation, the model must:
380 | 1. Explain to user this is an unconventional operation, design document helps better plan implementation
381 | 2. Clearly state the risks:
382 | - May not fully utilize existing features and components
383 | - Implementation direction may deviate from best practices
384 | - Code structure may lack overall planning
385 | 3. Ask the user: "Understanding these risks, are you sure you want to skip the design phase?"
386 | 4. Only use action.type="skip" after user explicitly confirms
387 |
388 |
389 | - stage: design
390 | progress:
391 | overall: 60
392 | requirements: 100
393 | design: 100
394 | tasks: 0
395 | status:
396 | type: ready_to_confirm
397 | readyToConfirm: true
398 | displayText: |
399 | ✅ Design document check passed!
400 |
401 | 📊 Overall progress: ${progress}%
402 | 🔄 Current status: Checking design document (current) → Next step: get user approval
403 |
404 | Model please continue with the following actions:
405 | 1. Ask the user "Does the design look good?"
406 | 2. Wait for explicit user approval (e.g., "yes", "approved", "looks good", etc.)
407 | 3. Must not proceed to task writing until getting explicit approval
408 | 4. After approval, use the specs-workflow tool with action.type="confirm"
409 | 5. Enter the tasks phase
410 |
411 | - stage: tasks
412 | progress:
413 | overall: 60
414 | requirements: 100
415 | design: 100
416 | tasks: 0
417 | status:
418 | type: not_edited
419 | reason: Tasks document not edited
420 | displayText: |
421 | 📝 tasks.md has not been written yet
422 |
423 | 📁 File directory: ${path}
424 | 📝 Created: tasks.md
425 |
426 | 📊 Overall progress: ${progress}%
427 | 🔄 Current status: Writing tasks document (current) → Next step: use check to verify format
428 |
429 | Model please continue with the following actions:
430 | 1. Read the task writing guide below
431 | 2. First read ${path}/tasks.md, then start writing the document
432 | 3. After completing the document, use specs-workflow tool with action.type="check" to check the document format
433 | 4. When check passes, the model must ask the user "Does the task plan look good?", and continue after getting explicit approval
434 | 5. When the user approves, the model must use the specs-workflow tool with action.type="confirm" to complete the workflow
435 |
436 |
437 | - stage: tasks
438 | progress:
439 | overall: 90
440 | requirements: 100
441 | design: 100
442 | tasks: 100
443 | status:
444 | type: ready_to_confirm
445 | readyToConfirm: true
446 | displayText: |
447 | ✅ Tasks document check passed!
448 |
449 | 📊 Overall progress: ${progress}%
450 | 🔄 Current status: Checking tasks document (current) → Next step: get user approval
451 |
452 | The tasks document includes:
453 | - ✓ Implementation steps
454 | - ✓ Task breakdown
455 | - ✓ Dependencies
456 | - ✓ Acceptance criteria
457 |
458 | Model please continue with the following actions:
459 | 1. Ask the user "Does the task plan look good?"
460 | 2. Wait for explicit user approval (e.g., "yes", "approved", "looks good", etc.)
461 | 3. After approval, use the specs-workflow tool with action.type="confirm"
462 | 4. Complete the entire workflow
463 |
464 | - stage: completed
465 | progress:
466 | overall: 100
467 | requirements: 100
468 | design: 100
469 | tasks: 100
470 | status:
471 | type: completed
472 | readyToConfirm: false
473 | displayText: |
474 | ✅ All phases completed!
475 |
476 | 📊 Overall progress: ${progress}%
477 | 🔄 Current status: Workflow completed ✨
478 |
479 | You have successfully completed the entire specification writing process:
480 | - ✓ Requirements document confirmed
481 | - ✓ Design document confirmed
482 | - ✓ Tasks document confirmed
483 |
484 | All documents have been written and confirmed.
485 |
486 | # Skip response
487 | SkipResponse:
488 | type: object
489 | required: [stage, skipped, displayText, progress]
490 | properties:
491 | stage:
492 | type: string
493 | skipped:
494 | type: boolean
495 | progress:
496 | $ref: '#/components/schemas/Progress'
497 | displayText:
498 | type: string
499 | x-dynamic-fields:
500 | displayText: ["stage", "progress"]
501 | x-example-selection:
502 | criteria:
503 | - field: "stage"
504 | required: true
505 | examples:
506 | - stage: requirements
507 | skipped: true
508 | progress:
509 | overall: 30
510 | requirements: 100
511 | design: 0
512 | tasks: 0
513 | displayText: |
514 | ⏭️ Skipped requirements phase
515 |
516 | 📊 Overall progress: ${progress}%
517 |
518 | Note: Skipping requirements phase may cause design to deviate from expectations.
519 | It's recommended to supplement requirements documents later.
520 |
521 | Now entering design phase, model please edit design.md document.
522 |
523 |
524 | - stage: design
525 | skipped: true
526 | progress:
527 | overall: 60
528 | requirements: 100
529 | design: 100
530 | tasks: 0
531 | displayText: |
532 | ⏭️ Skipped design phase
533 |
534 | 📊 Overall progress: ${progress}%
535 |
536 | Model please inform the user of the following risks:
537 | ⚠️ Warning: Skipping design phase may cause the following problems:
538 | - Lack of architectural design may cause implementation direction to deviate
539 | - May not fully utilize existing features and components
540 | - Code structure may lack overall planning
541 |
542 | It's recommended to gradually supplement design thinking during implementation.
543 | Now entering tasks phase, model please edit tasks.md document.
544 |
545 |
546 | - stage: tasks
547 | skipped: true
548 | progress:
549 | overall: 60
550 | requirements: 100
551 | design: 100
552 | tasks: 0
553 | displayText: |
554 | ⏭️ Skipped tasks phase
555 |
556 | 📊 Overall progress: ${progress}%
557 |
558 | ⚠️ Important Note: Tasks document is essential for development
559 | - The tasks document defines the specific implementation steps
560 | - Without it, developers lack clear guidance on what to build
561 | - If user is not ready to develop now, user can skip temporarily
562 |
563 | To write the tasks document later:
564 | 1. Use action.type="check" to review current status
565 | 2. Edit the tasks.md document with implementation details
566 | 3. Confirm when ready to start development
567 |
568 | The workflow is now complete. User can return to write tasks when ready to begin development.
569 |
570 | # Confirm response
571 | ConfirmResponse:
572 | type: object
573 | required: [stage, confirmed, nextStage, displayText, progress]
574 | properties:
575 | stage:
576 | type: string
577 | confirmed:
578 | type: boolean
579 | nextStage:
580 | type: string
581 | nullable: true
582 | progress:
583 | $ref: '#/components/schemas/Progress'
584 | displayText:
585 | type: string
586 | x-dynamic-fields:
587 | displayText: ["stage", "nextStage", "progress", "path"]
588 | x-example-selection:
589 | criteria:
590 | - field: "stage"
591 | required: true
592 | examples:
593 | - stage: requirements
594 | confirmed: true
595 | nextStage: design
596 | progress:
597 | overall: 30
598 | requirements: 100
599 | design: 0
600 | tasks: 0
601 | displayText: |
602 | ✅ Requirements confirmed, entering design phase!
603 |
604 | 📁 File directory: ${path}
605 | 📝 Created: design.md
606 |
607 | 📊 Overall progress: ${progress}%
608 | 🔄 Current status: Writing design document (current) → Next step: use check to verify format
609 |
610 | Model please continue with the following actions:
611 | 1. Read the design-guide below
612 | 2. First read ${path}/design.md, then start writing the document
613 | 3. After completing the document, use specs-workflow tool with action.type="check" to check the document format
614 | 4. When check passes, the model must ask the user "Does the design look good?", and must not proceed to task writing until getting explicit approval (e.g., "yes", "approved", "looks good", etc.)
615 | 5. When the user approves, the model must use the specs-workflow tool with action.type="confirm" to enter the tasks phase
616 |
617 | Special case - Skip design phase:
618 | - Only consider skipping when user explicitly requests (e.g., "skip design document", "go directly to tasks")
619 | - Before executing skip operation, the model must:
620 | 1. Explain to user this is an unconventional operation, design document helps better plan implementation
621 | 2. Clearly state the risks:
622 | - May not fully utilize existing features and components
623 | - Implementation direction may deviate from best practices
624 | - Code structure may lack overall planning
625 | 3. Ask the user: "Understanding these risks, are you sure you want to skip the design phase?"
626 | 4. Only use action.type="skip" after user explicitly confirms
627 |
628 |
629 | - stage: design
630 | confirmed: true
631 | nextStage: tasks
632 | progress:
633 | overall: 60
634 | requirements: 100
635 | design: 100
636 | tasks: 0
637 | displayText: |
638 | ✅ Design confirmed, entering tasks phase!
639 |
640 | 📁 File directory: ${path}
641 | 📝 Created: tasks.md
642 |
643 | 📊 Overall progress: ${progress}%
644 | 🔄 Current status: Writing tasks document (current) → Next step: use check to verify format
645 |
646 | Model please continue with the following actions:
647 | 1. Read the task writing guide below
648 | 2. First read ${path}/tasks.md, then start writing the document
649 | 3. After completing the document, use specs-workflow tool with action.type="check" to check the document format
650 | 4. When check passes, the model must ask the user "Does the task plan look good?", and continue after getting explicit approval
651 | 5. When the user approves, the model must use the specs-workflow tool with action.type="confirm" to complete the workflow
652 |
653 |
654 | - stage: tasks
655 | confirmed: true
656 | nextStage: null
657 | progress:
658 | overall: 100
659 | requirements: 100
660 | design: 100
661 | tasks: 100
662 | displayText: |
663 | ✅ Tasks confirmed, workflow completed!
664 |
665 | 📊 Overall progress: ${progress}%
666 | 🔄 Current status: All documents completed ✨
667 |
668 | Congratulations! You have completed the entire specification writing process:
669 | - ✓ Requirements document confirmed
670 | - ✓ Design document confirmed
671 | - ✓ Tasks document confirmed
672 |
673 |
674 |
675 | # Batch complete tasks response
676 | BatchCompleteTaskResponse:
677 | type: object
678 | required: [success, displayText]
679 | properties:
680 | success:
681 | type: boolean
682 | description: Whether the batch operation succeeded
683 | completedTasks:
684 | type: array
685 | items:
686 | type: string
687 | description: Task numbers that were actually completed in this operation
688 | alreadyCompleted:
689 | type: array
690 | items:
691 | type: string
692 | description: Task numbers that were already completed before this operation
693 | failedTasks:
694 | type: array
695 | items:
696 | type: object
697 | required: [taskNumber, reason]
698 | properties:
699 | taskNumber:
700 | type: string
701 | description: The task number that failed
702 | reason:
703 | type: string
704 | description: The reason why the task could not be completed
705 | description: Tasks that could not be completed with reasons
706 | results:
707 | type: array
708 | items:
709 | type: object
710 | required: [taskNumber, success]
711 | properties:
712 | taskNumber:
713 | type: string
714 | success:
715 | type: boolean
716 | status:
717 | type: string
718 | enum: [completed, already_completed, failed]
719 | description: Detailed results for each task in the batch
720 | nextTask:
721 | type: object
722 | nullable: true
723 | properties:
724 | number:
725 | type: string
726 | description:
727 | type: string
728 | description: Information about the next uncompleted task
729 | hasNextTask:
730 | type: boolean
731 | description: Whether there are more tasks to complete
732 | displayText:
733 | type: string
734 | description: Human-readable message about the batch operation
735 | examples:
736 | - success: true
737 | completedTasks: ["1.1", "1.2", "2.1"]
738 | alreadyCompleted: ["1.3"]
739 | failedTasks: []
740 | results:
741 | - taskNumber: "1.1"
742 | success: true
743 | status: completed
744 | - taskNumber: "1.2"
745 | success: true
746 | status: completed
747 | - taskNumber: "1.3"
748 | success: true
749 | status: already_completed
750 | - taskNumber: "2.1"
751 | success: true
752 | status: completed
753 | nextTask:
754 | number: "2.2"
755 | description: "Implement error handling"
756 | hasNextTask: true
757 | displayText: |
758 | ✅ Batch task processing succeeded
759 |
760 | Completed tasks:
761 | - 1.1
762 | - 1.2
763 | - 1.3
764 | - 2.1
765 |
766 | ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
767 |
768 | 📋 Next task to implement:
769 | - [ ] 2.2. Implement error handling
770 | - *Goal*: Add comprehensive error handling to the authentication system
771 | - *Details*: Implement try-catch blocks, error logging, and user-friendly error messages
772 | - *Requirements*: 1.2, 2.3
773 |
774 | ⚠️ IMPORTANT INSTRUCTIONS FOR MODEL:
775 | 1. [TASK FOCUS] Model MUST follow the workflow instructions to complete the specified task, not plan tasks independently.
776 |
777 | 2. [PROGRESS TRACKING] After completing each subtask, model MUST use the specs-workflow tool with complete_task action to mark it complete. DO NOT edit task.md directly.
778 | 3. [WORKFLOW] Implement task → Call complete_task to mark complete → Get next task automatically → Continue implementation
779 |
780 | Model: Please confirm your preferred execution mode:
781 |
782 | **Confirmation Required**: The model will complete tasks one by one, requiring your confirmation before proceeding to the next task.
783 |
784 | **Automatic Mode**: The model will complete tasks sequentially until all tasks are finished without requiring confirmation for each step.
785 |
786 | After you confirm your preferred approach, I will execute the development work for ${firstSubtask} according to your chosen mode, and immediately use complete_task after completing this specified task to proceed to the next one.
787 | - success: false
788 | completedTasks: []
789 | alreadyCompleted: []
790 | failedTasks:
791 | - taskNumber: "2.1"
792 | reason: "Has uncompleted subtasks"
793 | - taskNumber: "99"
794 | reason: "Task does not exist"
795 | results: []
796 | nextTask: null
797 | hasNextTask: false
798 | displayText: |
799 | ❌ Batch task completion failed
800 |
801 | The following tasks cannot be completed:
802 | - 2.1: Has uncompleted subtasks
803 | - 99: Task does not exist
804 |
805 | Model: Please ask user to resolve these issues and try again.
806 |
807 | # Common type definitions
808 | Stage:
809 | type: string
810 | enum: [requirements, design, tasks, completed]
811 | description: Current stage
812 |
813 | Progress:
814 | type: object
815 | required: [overall, requirements, design, tasks]
816 | properties:
817 | overall:
818 | type: integer
819 | minimum: 0
820 | maximum: 100
821 | description: Overall progress percentage
822 | requirements:
823 | type: integer
824 | minimum: 0
825 | maximum: 100
826 | description: Requirements phase progress
827 | design:
828 | type: integer
829 | minimum: 0
830 | maximum: 100
831 | description: Design phase progress
832 | tasks:
833 | type: integer
834 | minimum: 0
835 | maximum: 100
836 | description: Tasks phase progress
837 | x-progress-rules:
838 | - description: Requirements phase accounts for 30%
839 | formula: requirements * 0.3
840 | - description: Design phase accounts for 30%
841 | formula: design * 0.3
842 | - description: Tasks phase accounts for 40%
843 | formula: tasks * 0.4
844 |
845 | Status:
846 | type: object
847 | required: [type]
848 | properties:
849 | type:
850 | type: string
851 | enum: [not_started, not_edited, in_progress, ready_to_confirm, confirmed, completed]
852 | reason:
853 | type: string
854 | readyToConfirm:
855 | type: boolean
856 |
857 | Resource:
858 | type: object
859 | required: [id, content]
860 | properties:
861 | id:
862 | type: string
863 | description: Resource identifier
864 | content:
865 | type: string
866 | description: Resource content (Markdown format)
867 |
868 | ResourceRef:
869 | type: object
870 | required: [uri, mimeType]
871 | properties:
872 | uri:
873 | type: string
874 | description: Resource URI
875 | title:
876 | type: string
877 | description: Optional resource title
878 | mimeType:
879 | type: string
880 | description: Resource MIME type
881 | text:
882 | type: string
883 | description: Optional resource text content
884 |
885 | # Error response definitions
886 | x-error-responses:
887 | invalidPath:
888 | displayText: |
889 | ❌ Error: Invalid specification directory
890 |
891 | Path ${path} does not exist or is not a valid specification directory.
892 | Model: Please ask user to ensure the path is correct and has been initialized.
893 |
894 | alreadyInitialized:
895 | displayText: |
896 | ❌ Project already exists
897 |
898 | 📁 Path: ${path}
899 | 📄 Existing files: ${existingFiles}
900 |
901 | Model: Please ask user to choose one of the following actions:
902 | 1. Delete existing files and reinitialize: rm -rf ${path}/*
903 | 2. Initialize in a new directory: use a different path parameter
904 | 3. Continue editing existing project: use action.type="check" to check project status and read existing documents to see if adjustments are needed
905 |
906 | missingParameters:
907 | displayText: |
908 | ❌ Error: Missing required parameters
909 |
910 | ${action} operation requires the following parameters:
911 | ${missingParams}
912 |
913 | Model: Please ask user to provide complete parameters and try again.
914 |
915 | documentNotEdited:
916 | displayText: |
917 | ❌ Error: Document not ready for confirmation
918 |
919 | 📄 ${documentName} still contains template markers and has not been edited.
920 |
921 | The document appears to be in its initial state with placeholder content.
922 | Before confirming, you must edit the document and then use action.type="check" to verify the document is ready.
923 |
924 | If you want to skip writing this document:
925 | - Use action.type="skip" to bypass this stage
926 | - Note: Skipping important documents may impact project quality
927 |
928 | taskAlreadyCompleted:
929 | displayText: |
930 | ℹ️ Task ${taskNumber} is already completed
931 |
932 | This task has already been marked as completed.
933 | No action needed.
934 |
935 | taskNotFound:
936 | displayText: |
937 | ❌ Error: Task ${taskNumber} not found
938 |
939 | Model: Please ask user to check if the task number is correct.
940 |
941 | projectNotInitialized:
942 | displayText: |
943 | 🔧 Project not yet initialized
944 |
945 | Before using other features, model please complete project initialization first:
946 |
947 | **Step 1: Call workspace setup**
948 | ```json
949 | {
950 | "path": "${path}",
951 | "action": {
952 | "type": "setup_workspace"
953 | }
954 | }
955 | ```
956 |
957 | The system will guide you through language preference setup.
958 |
959 | **Why initialization is needed?**
960 | - Establish a single configuration source to ensure team collaboration consistency
961 | - Create User Guidelines to let you guide model behavior with natural language
962 | - Create .specs folder in project root for easy management and maintenance
963 |
964 | After initialization is complete, model can use init, check, confirm and other features.
965 |
966 | invalidConfig:
967 | displayText: |
968 | ⚠️ Invalid project configuration
969 |
970 | Configuration file found but content is invalid or path is unavailable. Model please reinitialize:
971 |
972 | ```json
973 | {
974 | "path": "${path}",
975 | "action": {
976 | "type": "setup_workspace",
977 | "language": "your language preference"
978 | }
979 | }
980 | ```
981 |
982 | The system will automatically override invalid configuration, no need to delete manually.
983 |
984 |
985 | # Shared resource definitions
986 | x-shared-resources:
987 | # Template editing instructions
988 | template-edit-instruction:
989 | uri: template-edit-instruction
990 | title: Template Editing Instructions
991 | mimeType: text/plain
992 | text: |
993 | ⚠️ Important: Model please delete all content with <template-*> tags, then start writing formal content.
994 | These tags are used to detect whether the document has been edited. Keeping these tags will cause the document to be judged as "not edited" status.
995 |
996 | # Requirements document example (reuses existing requirements-guide)
997 | requirements-template-example:
998 | uri: requirements-template-example
999 | title: Requirements Document Example
1000 | mimeType: text/plain
1001 | text: |
1002 | Example requirements:
1003 | ### Core Features
1004 | - User authentication system
1005 | - As a user, I want to register an account to use system features
1006 | - As a user, I want to log in securely to access personal data
1007 |
1008 | ### Acceptance Criteria
1009 | - [ ] Users can register using email
1010 | - [ ] Password strength meets security requirements
1011 | - [ ] Account locks for 15 minutes after 3 failed login attempts
1012 |
1013 | # Design document example (reuses existing design-guide)
1014 | design-template-example:
1015 | uri: design-template-example
1016 | title: Design Document Example
1017 | mimeType: text/plain
1018 | text: |
1019 | Example design:
1020 | ### Technical Architecture
1021 | - Frontend: React + TypeScript
1022 | - Backend: Node.js + Express
1023 | - Database: PostgreSQL
1024 | - Cache: Redis
1025 |
1026 | ### Authentication Flow
1027 | ```mermaid
1028 | sequenceDiagram
1029 | User->>Frontend: Enter credentials
1030 | Frontend->>Backend: POST /auth/login
1031 | Backend->>Database: Verify user
1032 | Database->>Backend: Return user information
1033 | Backend->>Frontend: Return JWT Token
1034 | ```
1035 |
1036 | # Tasks document example (reuses existing tasks-guide)
1037 | tasks-template-example:
1038 | uri: tasks-template-example
1039 | title: Task List Example
1040 | mimeType: text/plain
1041 | text: |
1042 | Example tasks:
1043 | ### Phase 1: Foundation Setup
1044 | - [ ] Initialize project structure (2h)
1045 | - [ ] Configure development environment (1h)
1046 | - [ ] Set up database connection (2h)
1047 |
1048 | ### Phase 2: Core Features
1049 | - [ ] Implement user registration API (4h)
1050 | - Dependency: Database connection
1051 | - [ ] Implement login authentication (4h)
1052 | - Dependency: User registration API
1053 |
1054 | requirements-guide:
1055 | uri: requirements-guide
1056 | title: Requirements Document Writing Guide
1057 | mimeType: text/markdown
1058 | text: |
1059 | # Requirements Gathering Generation
1060 |
1061 | Workflow Stage: Requirements Gathering
1062 |
1063 | First, generate an initial set of requirements in EARS format based on the feature idea, then iterate with the user to refine them until they are complete and accurate.
1064 |
1065 | Don't focus on code exploration in this phase. Instead, just focus on writing requirements which will later be turned into a design.
1066 |
1067 | **Constraints:**
1068 |
1069 | - The model MUST write the requirements document in the user's preferred regional language
1070 | - The model MUST edit the existing requirements.md file by removing the SPEC-MARKER comment block
1071 | - The model MUST fill in the requirements document based on the user's rough idea WITHOUT asking sequential questions first
1072 | - The model MUST format the requirements.md document with:
1073 | - A clear introduction section that summarizes the feature
1074 | - A hierarchical numbered list of requirements where each contains:
1075 | - A user story in the format "As a [role], I want [feature], so that [benefit]"
1076 | - A numbered list of acceptance criteria in EARS format (Easy Approach to Requirements Syntax)
1077 | - The model SHOULD consider edge cases, user experience, technical constraints, and success criteria in the initial requirements
1078 | - After updating the requirement document, the model MUST ask the user "Do the requirements look good? If so, we can move on to the design."
1079 | - The model MUST make modifications to the requirements document if the user requests changes or does not explicitly approve
1080 | - The model MUST ask for explicit approval after every iteration of edits to the requirements document
1081 | - The model MUST NOT proceed to the design document until receiving clear approval (such as "yes", "approved", "looks good", etc.)
1082 | - The model MUST continue the feedback-revision cycle until explicit approval is received
1083 | - The model SHOULD suggest specific areas where the requirements might need clarification or expansion
1084 | - The model MAY ask targeted questions about specific aspects of the requirements that need clarification
1085 | - The model MAY suggest options when the user is unsure about a particular aspect
1086 | - The model MUST proceed to the design phase after the user accepts the requirements
1087 |
1088 | design-guide:
1089 | uri: design-guide
1090 | title: Design Document Writing Guide
1091 | mimeType: text/markdown
1092 | text: |
1093 | # Design Document Creation Generation
1094 |
1095 | Workflow Stage: Design Document Creation
1096 |
1097 | After the user approves the Requirements, you should develop a comprehensive design document based on the feature requirements, conducting necessary research during the design process.
1098 | The design document should be based on the requirements document, so ensure it exists first.
1099 |
1100 | **Constraints:**
1101 |
1102 | - The model MUST write the design document in the user's preferred regional language
1103 | - The model MUST edit the existing design.md file by removing the SPEC-MARKER comment block
1104 | - The model MUST identify areas where research is needed based on the feature requirements
1105 | - The model MUST conduct research and build up context in the conversation thread
1106 | - The model SHOULD NOT create separate research files, but instead use the research as context for the design and implementation plan
1107 | - The model MUST summarize key findings that will inform the feature design
1108 | - The model SHOULD cite sources and include relevant links in the conversation
1109 | - The model MUST fill in the detailed design document in the existing design.md file
1110 | - The model MUST incorporate research findings directly into the design process
1111 | - The model MUST include the following sections in the design document:
1112 | - Overview
1113 | - Architecture
1114 | - Components and Interfaces
1115 | - Data Models
1116 | - Error Handling
1117 | - Testing Strategy
1118 | - The model SHOULD include diagrams or visual representations when appropriate (use Mermaid for diagrams if applicable)
1119 | - The model MUST ensure the design addresses all feature requirements identified during the clarification process
1120 | - The model SHOULD highlight design decisions and their rationales
1121 | - The model MAY ask the user for input on specific technical decisions during the design process
1122 | - After updating the design document, the model MUST ask the user "Does the design look good? If so, we can move on to the implementation plan."
1123 | - The model MUST make modifications to the design document if the user requests changes or does not explicitly approve
1124 | - The model MUST ask for explicit approval after every iteration of edits to the design document
1125 | - The model MUST NOT proceed to the implementation plan until receiving clear approval (such as "yes", "approved", "looks good", etc.)
1126 | - The model MUST continue the feedback-revision cycle until explicit approval is received
1127 | - The model MUST incorporate all user feedback into the design document before proceeding
1128 | - The model MUST offer to return to feature requirements clarification if gaps are identified during design
1129 |
1130 | tasks-guide:
1131 | uri: tasks-guide
1132 | title: Task List Writing Guide
1133 | mimeType: text/markdown
1134 | text: |
1135 | # Implementation Planning Generation
1136 |
1137 | Workflow Stage: Implementation Planning
1138 |
1139 | After the user approves the Design, create an actionable implementation plan with a checklist of coding tasks based on the requirements and design.
1140 | The tasks document should be based on the design document, so ensure it exists first.
1141 |
1142 | **Constraints:**
1143 |
1144 | - The model MUST write the tasks document in the user's preferred regional language
1145 | - The model MUST edit the existing tasks.md file by removing the SPEC-MARKER comment block
1146 | - The model MUST return to the design step if the user indicates any changes are needed to the design
1147 | - The model MUST return to the requirement step if the user indicates that we need additional requirements
1148 | - The model MUST fill in the implementation plan in the existing tasks.md file
1149 | - The model MUST use the following specific instructions when creating the implementation plan: Convert the feature design into a series of prompts for a code-generation LLM that will implement each step in a test-driven manner. Prioritize best practices, incremental progress, and early testing, ensuring no big jumps in complexity at any stage. Make sure that each prompt builds on the previous prompts, and ends with wiring things together. There should be no hanging or orphaned code that isn't integrated into a previous step. Focus ONLY on tasks that involve writing, modifying, or testing code.
1150 | - The model MUST format the implementation plan as a numbered checkbox list with a maximum of two levels of hierarchy:
1151 | - Top-level items (like epics) should be used only when needed
1152 | - Sub-tasks should be numbered with decimal notation (e.g., 1.1, 1.2, 2.1)
1153 | - Each item must be a checkbox
1154 | - Simple structure is preferred
1155 | - The model MUST ensure each task item includes:
1156 | - A clear objective as the task description that involves writing, modifying, or testing code
1157 | - Additional information as sub-bullets under the task
1158 | - Specific references to requirements from the requirements document (referencing granular sub-requirements, not just user stories)
1159 | - The model MUST ensure that the implementation plan is a series of discrete, manageable coding steps
1160 | - The model MUST ensure each task references specific requirements from the requirement document
1161 | - The model MUST NOT include excessive implementation details that are already covered in the design document
1162 | - The model MUST assume that all context documents (feature requirements, design) will be available during implementation
1163 | - The model MUST ensure each step builds incrementally on previous steps
1164 | - The model SHOULD prioritize test-driven development where appropriate
1165 | - The model MUST ensure the plan covers all aspects of the design that can be implemented through code
1166 | - The model SHOULD sequence steps to validate core functionality early through code
1167 | - The model MUST ensure that all requirements are covered by the implementation tasks
1168 | - The model MUST offer to return to previous steps (requirements or design) if gaps are identified during implementation planning
1169 | - The model MUST ONLY include tasks that can be performed by a coding agent (writing code, creating tests, etc.)
1170 | - The model MUST NOT include tasks related to user testing, deployment, performance metrics gathering, or other non-coding activities
1171 | - The model MUST focus on code implementation tasks that can be executed within the development environment
1172 | - The model MUST ensure each task is actionable by a coding agent by following these guidelines:
1173 | - Tasks should involve writing, modifying, or testing specific code components
1174 | - Tasks should specify what files or components need to be created or modified
1175 | - Tasks should be concrete enough that a coding agent can execute them without additional clarification
1176 | - Tasks should focus on implementation details rather than high-level concepts
1177 | - Tasks should be scoped to specific coding activities (e.g., "Implement X function" rather than "Support X feature")
1178 | - The model MUST explicitly avoid including the following types of non-coding tasks in the implementation plan:
1179 | - User acceptance testing or user feedback gathering
1180 | - Deployment to production or staging environments
1181 | - Performance metrics gathering or analysis
1182 | - Running the application to test end to end flows. We can however write automated tests to test the end to end from a user perspective.
1183 | - User training or documentation creation
1184 | - Business process changes or organizational changes
1185 | - Marketing or communication activities
1186 | - Any task that cannot be completed through writing, modifying, or testing code
1187 | - After updating the tasks document, the model MUST ask the user "Do the tasks look good?"
1188 | - The model MUST make modifications to the tasks document if the user requests changes or does not explicitly approve.
1189 | - The model MUST ask for explicit approval after every iteration of edits to the tasks document.
1190 | - The model MUST NOT consider the workflow complete until receiving clear approval (such as "yes", "approved", "looks good", etc.).
1191 | - The model MUST continue the feedback-revision cycle until explicit approval is received.
1192 | - The model MUST stop once the task document has been approved.
1193 |
1194 | **This workflow is ONLY for creating design and planning artifacts. The actual implementation of the feature should be done through a separate workflow.**
1195 |
1196 | - The model MUST NOT attempt to implement the feature as part of this workflow
1197 | - The model MUST clearly communicate to the user that this workflow is complete once the design and planning artifacts are created
1198 | - When the model receives the confirmation response for tasks stage, it will include the first uncompleted task
1199 | - The model MUST present this task to the user and ask: "Ready to start the first task?"
1200 | - The model MUST begin implementation only after user confirmation
1201 |
1202 | # Global configuration
1203 | x-global-config:
1204 | icons:
1205 | exists: "✅"
1206 | not_exists: "❌"
1207 | edited: "(edited)"
1208 | not_edited: "(pending edit)"
1209 | not_created: "(not created)"
1210 | confirmed: "(confirmed)"
1211 | skipped: "(skipped)"
1212 |
1213 | status_text:
1214 | not_created: "Not created"
1215 | not_edited: "Waiting for edit"
1216 | has_format_issues: "Has format issues"
1217 | not_confirmed: "Pending confirmation"
1218 | completed: "Completed"
1219 | skipped: "Skipped"
1220 |
1221 | stage_names:
1222 | requirements: "Requirements Document"
1223 | design: "Design Document"
1224 | tasks: "Task List"
1225 | completed: "Completed"
1226 |
1227 | file_names:
1228 | requirements: "Requirements.md"
1229 | design: "Design.md"
1230 | tasks: "Tasks.md"
1231 |
1232 | # Document templates
1233 | x-document-templates:
1234 | requirements:
1235 | title: "${featureName} - Requirements Document"
1236 | sections:
1237 | - name: "Project Background"
1238 | content: "${introduction}"
1239 | - name: "Core Features"
1240 | placeholder: "## Core Features\n\n<template-requirements>\nDescribe the core functionality of the feature here.\n</template-requirements>"
1241 | - name: "User Stories"
1242 | placeholder: "## User Stories\n\n<template-requirements>\n- As a [user type], I want [feature], so that [benefit]\n</template-requirements>"
1243 | - name: "Acceptance Criteria"
1244 | placeholder: "## Acceptance Criteria\n\n<template-requirements>\n- [ ] Criterion 1\n- [ ] Criterion 2\n</template-requirements>"
1245 | - name: "Non-functional Requirements"
1246 | placeholder: "## Non-functional Requirements\n\n<template-requirements>\n- Performance requirements\n- Security requirements\n- Compatibility requirements\n</template-requirements>"
1247 |
1248 | design:
1249 | title: "${featureName} - Design Document"
1250 | sections:
1251 | - name: "Overview"
1252 | placeholder: "## Overview\n\n<template-design>\nProvide a high-level overview of the design approach.\n</template-design>"
1253 | - name: "Architecture"
1254 | placeholder: "## Architecture\n\n<template-design>\nDescribe the overall architecture and key components.\n</template-design>"
1255 | - name: "Components and Interfaces"
1256 | placeholder: "## Components and Interfaces\n\n<template-design>\nDetail the main components and their interfaces.\n</template-design>"
1257 | - name: "Data Models"
1258 | placeholder: "## Data Models\n\n<template-design>\nDefine the data structures and models.\n</template-design>"
1259 | - name: "Error Handling"
1260 | placeholder: "## Error Handling\n\n<template-design>\nExplain error handling strategies.\n</template-design>"
1261 | - name: "Testing Strategy"
1262 | placeholder: "## Testing Strategy\n\n<template-design>\nOutline the testing approach.\n</template-design>"
1263 |
1264 | tasks:
1265 | title: "${featureName} - Task List"
1266 | sections:
1267 | - name: "Implementation Tasks"
1268 | placeholder: "## Implementation Tasks\n\n<template-tasks>\n- [ ] 1. **Main Task 1**\n - [ ] 1.1. Subtask description\n - *Goal*: Describe what this task aims to achieve\n - *Details*: Implementation details and considerations\n - *Requirements*: Reference to requirement numbers\n - [ ] 1.2. Subtask description\n - *Goal*: Describe what this task aims to achieve\n - *Details*: Implementation details and considerations\n - *Requirements*: Reference to requirement numbers\n- [ ] 2. **Main Task 2**\n - [ ] 2.1. Subtask description\n - *Goal*: Describe what this task aims to achieve\n - *Details*: Implementation details and considerations\n - *Requirements*: Reference to requirement numbers\n</template-tasks>"
1269 | - name: "Task Dependencies"
1270 | placeholder: "## Task Dependencies\n\n<template-tasks>\n- Task 1 must be completed before Task 2\n- Tasks 2.1 and 2.2 can be executed in parallel\n- Task 3 depends on completion of Tasks 1 and 2\n</template-tasks>"
1271 | - name: "Estimated Timeline"
1272 | placeholder: "## Estimated Timeline\n\n<template-tasks>\n- Task 1: 8 hours\n- Task 2: 12 hours\n- Task 3: 6 hours\n- **Total: 26 hours**\n</template-tasks>"
1273 |
1274 | skipped:
1275 | title: "${featureName} - ${stageName}"
1276 | sections:
1277 | - name: "Status"
1278 | content: "[Skipped] - This stage has been skipped"
1279 | - name: "Reason"
1280 | content: "User chose to skip this stage and proceed directly to next step."
1281 | - name: "Note"
1282 | content: "To supplement this document, model please delete [Skipped] marker and fill in corresponding content."
1283 |
1284 | # Task guidance template
1285 | x-task-guidance-template:
1286 | separator: "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
1287 | header: "📋 Next task to implement:"
1288 | instructions:
1289 | prefix: "⚠️ IMPORTANT INSTRUCTIONS FOR MODEL:"
1290 | taskFocus: "1. [TASK FOCUS] Model MUST follow the workflow instructions to complete the specified task, not plan tasks independently."
1291 | progressTracking: "2. [PROGRESS TRACKING] After completing each subtask, model MUST use the specs-workflow tool with complete_task action to mark it complete. DO NOT edit task.md directly."
1292 | workflow: "3. [WORKFLOW] Implement task → Call complete_task to mark complete → Get next task automatically → Continue implementation"
1293 | prompts:
1294 | firstTask: "Model: Please ask user \"Would you prefer to complete tasks one by one and report progress for your confirmation, or complete tasks sequentially and mark them as done until all tasks are finished at once?\" After user confirms, execute the development work for ${firstSubtask} according to user's preferred approach, and immediately use complete_task after completing this specified task."
1295 | nextTask: "Model: Please execute the development work for ${firstSubtask} and immediately use complete_task after completing this specified task."
1296 | continueTask: "Model: Please execute the development work for ${firstSubtask} and immediately use complete_task after completing this specified task."
1297 | batchContinue: "Model: Please execute the development work for ${firstSubtask} and immediately use complete_task after completing this specified task."
1298 | completionMessages:
1299 | taskCompleted: "✅ Task ${taskNumber} marked as completed!"
1300 | allCompleted: "🎉 Congratulations! All tasks completed!\n\nYou have successfully completed all implementation tasks. Project implementation phase completed."
1301 | alreadyCompleted: "ℹ️ Task ${taskNumber} is already completed\n\nThis task has already been marked as completed."
1302 | batchSucceeded: "✅ Batch task processing succeeded"
1303 | batchCompleted: "ℹ️ Batch task processing completed"
1304 | batchLabels:
1305 | completedTasks: "Completed tasks"
1306 |
```