smart-spec-kit-mcp 2.0.1 → 2.0.3

package/starter-kit/prompts/speckit.init.md

@@ -0,0 +1,153 @@
+---
+description: Initialize Spec-Kit in the current project. Creates the .spec-kit folder structure with default workflows and templates.
+---
+
+# /speckit.init - Initialize Project
+
+## User Input
+
+```text
+$ARGUMENTS
+```
+
+## Outline
+
+You are initializing Spec-Kit in the current project. Follow this workflow:
+
+### 1. Check Existing Setup
+
+Check if `.spec-kit/` directory already exists:
+- If exists and `--force` not specified, ask user if they want to overwrite
+- If `--force` specified, proceed with overwrite
+
+### 2. Create Directory Structure
+
+Create the following structure:
+
+```
+.spec-kit/
+├── workflows/          # Custom workflow definitions
+├── templates/          # Specification templates
+└── memory/             # Project-specific context
+    └── constitution.md # Project principles
+
+specs/                  # Generated specifications go here
+```
+
+### 3. Copy Default Templates
+
+Create default templates in `.spec-kit/templates/`:
+
+**functional-spec.md** - Feature specification template
+**bugfix-report.md** - Bug fix specification template
+**plan-template.md** - Implementation plan template
+**tasks-template.md** - Task breakdown template
+
+### 4. Create Constitution
+
+Create `.spec-kit/memory/constitution.md` with project principles template:
+
+```markdown
+# Project Constitution
+
+## Project Name
+[TO FILL: Project name]
+
+## Core Principles
+
+### Principle 1: [TO FILL: Principle Name]
+[TO FILL: Description of this principle]
+
+**Rationale**: [TO FILL: Why this principle matters]
+
+### Principle 2: Code Quality
+All code must pass linting and have appropriate test coverage.
+
+**Rationale**: Maintains consistency and reduces bugs.
+
+### Principle 3: Documentation
+All features must be documented before implementation begins.
+
+**Rationale**: Ensures alignment and reduces rework.
+
+## Tech Stack Guidelines
+[TO FILL: Preferred technologies, frameworks, and patterns]
+
+## Governance
+- **Ratification Date**: [TO FILL]
+- **Last Amended**: [TO FILL]
+- **Version**: 1.0.0
+```
+
+### 5. Setup VS Code Configuration
+
+If the project uses VS Code, suggest adding to `.vscode/settings.json`:
+
+```json
+{
+  "mcp": {
+    "servers": {
+      "spec-kit": {
+        "command": "npx",
+        "args": ["-y", "spec-kit-mcp"]
+      }
+    }
+  }
+}
+```
+
+### 6. Create Starter Workflow (Optional)
+
+If user requests, create a custom workflow in `.spec-kit/workflows/`:
+
+```yaml
+name: custom-feature
+displayName: "Custom Feature Workflow"
+description: "Your custom workflow for this project"
+template: functional-spec.md
+
+steps:
+  - id: specify
+    name: "Create Specification"
+    action: call_agent
+    agent: SpecAgent
+    
+  - id: plan
+    name: "Create Plan"
+    action: call_agent
+    agent: PlanAgent
+    
+  - id: implement
+    name: "Implement"
+    action: call_agent
+    agent: SpecAgent
+```
+
+### 7. Report Completion
+
+Output:
+```
+✅ Spec-Kit initialized successfully!
+
+Created:
+  📁 .spec-kit/workflows/     - Custom workflows
+  📁 .spec-kit/templates/     - Specification templates  
+  📁 .spec-kit/memory/        - Project context
+  📁 specs/                   - Specifications output
+
+Next steps:
+  1. Edit .spec-kit/memory/constitution.md with your project principles
+  2. Run /speckit.specify to create your first specification
+```
+
+## Options
+
+- `--force`: Overwrite existing .spec-kit directory
+- `--minimal`: Create minimal structure without examples
+- `--with-vscode`: Also configure VS Code MCP settings
+
+## Handoffs
+
+After initialization:
+- **Set principles**: Edit `.spec-kit/memory/constitution.md`
+- **Create spec**: `/speckit.specify` - Start creating specifications

package/starter-kit/prompts/speckit.plan.md

@@ -0,0 +1,145 @@
+---
+description: Create a technical implementation plan from a specification. Specify your tech stack and architecture choices.
+---
+
+# /speckit.plan - Create Implementation Plan
+
+## User Input
+
+```text
+$ARGUMENTS
+```
+
+You **MUST** consider the user input before proceeding (if not empty).
+
+## Outline
+
+You are creating a technical implementation plan. Follow this workflow:
+
+### 1. Setup Check
+
+First, locate the specification:
+- Check for recent spec files in `specs/` directory
+- If user provides a spec path, use that
+- If no spec found, inform user to run `/speckit.specify` first
+
+### 2. Parse Tech Stack from Input
+
+Extract technology choices from user input:
+- **Language/Runtime**: Python, Node.js, .NET, etc.
+- **Framework**: React, FastAPI, ASP.NET, etc.
+- **Database**: PostgreSQL, MongoDB, etc.
+- **Infrastructure**: Docker, Kubernetes, Azure, etc.
+- **Other tools**: Testing frameworks, CI/CD, etc.
+
+If tech stack not specified, ask the user to provide it.
+
+### 3. Load Specification
+
+Read the specification file and extract:
+- Functional requirements
+- Non-functional requirements
+- User stories
+- Dependencies
+- Constraints
+
+### 4. Generate Research Document (Phase 0)
+
+Create `specs/{feature}/research.md` covering:
+
+1. **Tech Stack Analysis**
+   - Evaluate chosen technologies against requirements
+   - Identify potential issues or limitations
+   - Research latest versions and best practices
+
+2. **Architecture Options**
+   - Propose 2-3 architecture approaches
+   - Pros/cons for each
+   - Recommendation with justification
+
+3. **Third-Party Dependencies**
+   - Required libraries and packages
+   - Version recommendations
+   - License considerations
+
+4. **Technical Decisions Log**
+   - Decision records for key choices
+   - Alternatives considered
+   - Rationale for decisions
+
+### 5. Generate Design Documents (Phase 1)
+
+Create these documents in `specs/{feature}/`:
+
+**data-model.md** (if applicable):
+- Entity definitions
+- Relationships
+- Database schema
+- Sample data
+
+**contracts/** (if applicable):
+- API specifications (OpenAPI/Swagger format)
+- Message formats
+- Interface definitions
+
+**quickstart.md**:
+- Development environment setup
+- Build and run instructions
+- Integration test scenarios
+
+### 6. Generate Implementation Plan
+
+Create `specs/{feature}/plan.md` with:
+
+1. **Summary**
+   - Feature overview
+   - Tech stack summary
+   - Estimated complexity
+
+2. **Technical Context**
+   - Architecture diagram (text-based)
+   - System components
+   - Integration points
+
+3. **Project Structure**
+   - Directory layout
+   - Key files and their purposes
+   - Module organization
+
+4. **Implementation Phases**
+   - Phase breakdown with dependencies
+   - Deliverables per phase
+   - Risk mitigation for each phase
+
+5. **Quality Gates**
+   - Code review requirements
+   - Testing requirements
+   - Performance benchmarks
+
+### 7. Report Completion
+
+Output:
+- Path to created plan files
+- Summary of technical decisions
+- List of any issues needing resolution
+- Next step: `/speckit.tasks` to break down into actionable tasks
+
+## Key Rules
+
+### Plan Quality Checks
+- Each phase should have clear entry/exit criteria
+- Dependencies between phases must be explicit
+- Estimates should account for testing and documentation
+- Risks should have mitigation strategies
+
+### Architecture Principles
+- Favor simplicity over complexity
+- Consider maintainability and testability
+- Plan for observability (logging, monitoring)
+- Document security considerations
+
+## Handoffs
+
+After completing the plan, suggest:
+- **Generate tasks**: `/speckit.tasks` - Break plan into actionable tasks
+- **Create checklist**: `/speckit.checklist` - Generate quality checklist

package/starter-kit/prompts/speckit.specify.md

@@ -0,0 +1,123 @@
+---
+description: Create a functional specification from requirements or an Azure DevOps work item. Focus on WHAT you want to build, not the tech stack.
+---
+
+# /speckit.specify - Create Specification
+
+## User Input
+
+```text
+$ARGUMENTS
+```
+
+You **MUST** consider the user input before proceeding (if not empty).
+
+## Outline
+
+You are creating a functional specification document. Follow this workflow:
+
+### 1. Setup Check
+
+First, verify the Spec-Kit environment:
+- Check if `.spec-kit/` directory exists
+- If not, inform the user to run `/speckit.init` first
+
+### 2. Parse Requirements Source
+
+Determine the source of requirements from user input:
+
+**Option A: Azure DevOps Work Item**
+- If input contains an ADO work item ID (e.g., "#12345", "AB#12345", "Feature 12345")
+- Use the `fetch_ado_workitem` MCP tool to retrieve work item data
+
+**Option B: Direct Description**
+- If input is a feature description
+- Parse the description for key concepts: actors, actions, data, constraints
+
+### 3. Analyze Requirements
+
+For the provided requirements, identify:
+1. **Core user need** and business value
+2. **Explicit requirements** - what was directly stated
+3. **Implicit requirements** - reasonable inferences from context
+4. **Assumptions** - things that need validation
+5. **Risks and dependencies**
+6. **Edge cases and error scenarios**
+
+### 4. Generate Specification
+
+Load the template from `.spec-kit/templates/functional-spec.md` and fill it with:
+
+1. **Metadata Section**
+   - Title, date, version, status
+   - Link to Azure DevOps work item (if applicable)
+
+2. **Overview**
+   - Purpose (the problem being solved)
+   - Scope (what's in/out)
+   - Background context
+
+3. **Requirements**
+   - Functional requirements with IDs and priorities (Must Have/Should Have/Could Have)
+   - Non-functional requirements (performance, security, etc.)
+   - Acceptance criteria in Given/When/Then format
+
+4. **User Experience**
+   - User personas
+   - User stories (As a... I want... So that...)
+   - User flow descriptions
+
+5. **Technical Considerations**
+   - Dependencies
+   - Constraints
+   - Data requirements
+
+### 5. Handle Ambiguity
+
+For unclear aspects:
+- **Make informed guesses** based on context and industry standards
+- **Document assumptions** in the Assumptions section
+- **Limit clarifications**: Maximum 3 `[NEEDS CLARIFICATION]` markers for critical decisions only
+
+Only use `[NEEDS CLARIFICATION]` when:
+- The choice significantly impacts feature scope or user experience
+- Multiple reasonable interpretations exist with different implications
+- No reasonable default exists
+
+### 6. Save Specification
+
+Save the specification to:
+```
+specs/{context_id}-spec.md
+```
+
+If no context ID is provided, create a timestamped filename or ask for a feature short-name.
+
+### 7. Report Completion
+
+Output:
+- Path to created specification file
+- Summary of requirements captured
+- List of assumptions made
+- Any `[NEEDS CLARIFICATION]` items that need user input
+- Next step suggestion: `/speckit.plan` to create implementation plan
+
+## Quick Guidelines
+
+### Writing Style
+- Use active voice and clear, concise language
+- Include concrete examples for complex requirements
+- Define all technical terms and acronyms
+- Use tables for structured data (requirements, test cases)
+
+### Quality Checks
+- Every requirement should be testable and unambiguous
+- Each requirement should have a unique ID
+- Acceptance criteria should be in Given/When/Then format
+- No undefined placeholders in final output (except intentional `[NEEDS CLARIFICATION]`)
+
+## Handoffs
+
+After completing the specification, suggest:
+- **Clarify requirements**: `/speckit.clarify` - If there are `[NEEDS CLARIFICATION]` items
+- **Create implementation plan**: `/speckit.plan` - Once specification is approved

package/starter-kit/prompts/speckit.tasks.md

@@ -0,0 +1,137 @@
+---
+description: Generate actionable task breakdown from the implementation plan. Creates a tasks.md file with ordered, dependency-aware tasks.
+---
+
+# /speckit.tasks - Generate Task Breakdown
+
+## User Input
+
+```text
+$ARGUMENTS
+```
+
+You **MUST** consider the user input before proceeding (if not empty).
+
+## Outline
+
+You are generating an actionable task list from the implementation plan. Follow this workflow:
+
+### 1. Load Design Documents
+
+Read from the feature's spec directory:
+- **Required**: `plan.md` (tech stack, libraries, structure)
+- **Required**: `spec.md` (user stories with priorities)
+- **Optional**: `data-model.md` (entities)
+- **Optional**: `contracts/` (API endpoints)
+- **Optional**: `research.md` (decisions)
+
+If required files are missing, inform user to run `/speckit.plan` first.
+
+### 2. Extract Implementation Context
+
+From the documents, identify:
+- User stories with their priorities (P1, P2, P3)
+- Tech stack and frameworks
+- Database entities and relationships
+- API endpoints
+- External dependencies
+
+### 3. Generate Task Breakdown
+
+Create `specs/{feature}/tasks.md` with this structure:
+
+```markdown
+# Tasks: {Feature Name}
+
+**Input**: Design documents from `/specs/{feature}/`
+**Generated**: {Date}
+
+## Task Format
+
+- [ ] T### [P?] [Story?] Description - `path/to/file.ext`
+
+Legend:
+- T###: Task ID (sequential)
+- [P]: Can be executed in parallel with other [P] tasks
+- [Story?]: Associated user story ID (if applicable)
+```
+
+### 4. Phase Structure
+
+Organize tasks into these phases:
+
+**Phase 1: Setup (Shared Infrastructure)**
+- Project initialization
+- Dependency installation
+- Configuration files
+- Development environment setup
+
+**Phase 2: Foundational (Blocking Prerequisites)**
+- Database schema and migrations
+- Base models/entities
+- Authentication/authorization framework
+- Core utilities and helpers
+- Error handling infrastructure
+
+⚠️ **CRITICAL**: No user story work begins until Phase 2 is complete.
+
+**Phase 3+: User Stories (One Phase per Story)**
+For each user story in priority order:
+- Tests (if requested) → Models → Services → Endpoints → Integration
+- Each phase should be independently testable
+- Include checkpoint validation
+
+**Final Phase: Polish & Cross-Cutting**
+- Code cleanup and refactoring
+- Documentation updates
+- Performance optimization
+- Security hardening
+
+### 5. Task Generation Rules
+
+Each task MUST:
+- Be completable in 1-3 days by a single developer
+- Have a clear verb + object title
+- Include the file path(s) affected
+- Have explicit dependencies noted
+
+Mark with `[P]` if the task can run in parallel with others at the same level.
+
+### 6. Generate Dependency Graph
+
+Add a section showing:
+- Task dependencies (which tasks must complete first)
+- Parallel execution opportunities
+- Critical path identification
+
+### 7. Report Completion
+
+Output:
+- Path to generated `tasks.md`
+- Total task count
+- Task count per user story
+- Parallel execution opportunities identified
+- Suggested MVP scope (typically User Story 1 only)
+
+## Task Template
+
+```markdown
+## Phase 3: User Story 1 - {Title} (Priority: P1) 🎯 MVP
+
+**Goal**: {User story goal}
+**Independent Test**: {How to verify this story works alone}
+
+- [ ] T010 [US-1] Create {model} entity - `src/models/{model}.ts`
+- [ ] T011 [P] [US-1] Create {model} repository - `src/repositories/{model}.ts`
+- [ ] T012 [P] [US-1] Create {model} service - `src/services/{model}.ts`
+- [ ] T013 [US-1] Create {endpoint} API endpoint - `src/api/{endpoint}.ts`
+- [ ] T014 [US-1] Add integration tests - `tests/integration/{feature}.test.ts`
+
+**Checkpoint**: Story 1 complete - run `npm test` and verify {criteria}
+```
+
+## Handoffs
+
+After completing the tasks, suggest:
+- **Analyze plan**: `/speckit.analyze` - Cross-check consistency
+- **Implement**: `/speckit.implement` - Start executing tasks

package/starter-kit/templates/bugfix-report.md

@@ -0,0 +1,127 @@
+---
+title: "[TO FILL: Bug Title]"
+workitem_id: "[TO FILL]"
+type: Bugfix Report
+version: "1.0"
+status: Draft
+author: "[TO FILL]"
+created: "[TO FILL: Date]"
+severity: "[Critical/High/Medium/Low]"
+---
+
+# Bug Fix Report: [TO FILL: Bug Title]
+
+## 1. Bug Summary
+
+### 1.1 Description
+[TO FILL: Clear, concise description of the bug]
+
+### 1.2 Impact
+- **Severity**: [Critical/High/Medium/Low]
+- **Affected Users**: [TO FILL: Who is affected]
+- **Business Impact**: [TO FILL: How this affects the business]
+
+---
+
+## 2. Reproduction
+
+### 2.1 Environment
+| Component | Value |
+|-----------|-------|
+| OS | [TO FILL] |
+| Browser/Runtime | [TO FILL] |
+| Version | [TO FILL] |
+
+### 2.2 Steps to Reproduce
+1. [TO FILL: Step 1]
+2. [TO FILL: Step 2]
+3. [TO FILL: Step 3]
+
+### 2.3 Expected Behavior
+[TO FILL: What should happen]
+
+### 2.4 Actual Behavior
+[TO FILL: What actually happens]
+
+### 2.5 Evidence
+```
+[TO FILL: Error messages, logs, screenshots]
+```
+
+---
+
+## 3. Root Cause Analysis
+
+### 3.1 Investigation
+[TO FILL: What was investigated and findings]
+
+### 3.2 Root Cause
+[TO FILL: The underlying cause of the bug]
+
+### 3.3 Related Code
+```
+File: [path/to/file]
+Line: [line numbers]
+```
+
+---
+
+## 4. Fix Proposal
+
+### 4.1 Solution
+[TO FILL: Proposed fix approach]
+
+### 4.2 Changes Required
+| File | Change |
+|------|--------|
+| [TO FILL] | [TO FILL] |
+
+### 4.3 Risks
+- [TO FILL: Any risks with the proposed fix]
+
+---
+
+## 5. Testing
+
+### 5.1 Test Cases
+| ID | Scenario | Expected Result |
+|----|----------|-----------------|
+| TC-001 | [TO FILL: Original bug scenario] | Bug no longer occurs |
+| TC-002 | [TO FILL: Regression test] | Existing functionality intact |
+
+### 5.2 Verification Steps
+1. [TO FILL: How to verify the fix]
+2. [TO FILL: Regression testing steps]
+
+---
+
+## 6. Deployment
+
+### 6.1 Deployment Plan
+- [ ] Code review completed
+- [ ] Tests passing
+- [ ] Staging verification
+- [ ] Production deployment
+
+### 6.2 Rollback Plan
+[TO FILL: How to rollback if issues occur]
+
+---
+
+## 7. Post-Mortem (Optional)
+
+### 7.1 Timeline
+| Time | Event |
+|------|-------|
+| [TO FILL] | Bug reported |
+| [TO FILL] | Investigation started |
+| [TO FILL] | Root cause identified |
+| [TO FILL] | Fix deployed |
+
+### 7.2 Lessons Learned
+- [TO FILL: What can we improve to prevent similar issues]
+
+### 7.3 Action Items
+| Item | Owner | Due Date |
+|------|-------|----------|
+| [TO FILL] | [TO FILL] | [TO FILL] |