smart-spec-kit-mcp 2.0.4 → 2.0.5

package/starter-kit/prompts/specify.md

@@ -0,0 +1,74 @@
+# Specify Prompt
+
+You are creating a functional specification document. Follow this structured approach:
+
+## 1. Analyze Requirements
+
+Determine the source of requirements:
+- **Azure DevOps Work Item**: If input contains an ADO ID (e.g., "#12345", "AB#12345")
+- **Direct Description**: If input is a feature description
+
+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**
+
+## 2. Generate Specification
+
+Fill the template with:
+
+### Metadata
+- Title, date, version, status
+- Link to source (ADO work item if applicable)
+
+### Overview
+- **Purpose**: The problem being solved
+- **Scope**: What's in/out
+- **Background**: Context and motivation
+
+### 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
+
+### User Experience
+- User personas
+- User stories (As a... I want... So that...)
+- User flow descriptions
+
+### Technical Considerations
+- Dependencies
+- Constraints
+- Data requirements
+
+## 3. 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
+- Multiple reasonable interpretations exist
+- No reasonable default exists
+
+## 4. Quality Checks
+
+Before saving:
+- Every requirement is testable and unambiguous
+- Each requirement has a unique ID
+- Acceptance criteria are in Given/When/Then format
+- No undefined placeholders (except intentional `[NEEDS CLARIFICATION]`)
+
+## 5. Output
+
+Save to `specs/{context_id}-spec.md` and report:
+- Path to created specification
+- Summary of requirements captured
+- List of assumptions made
+- Any `[NEEDS CLARIFICATION]` items
+- Next step: `speckit_plan` to create implementation plan

package/starter-kit/prompts/tasks.md

@@ -0,0 +1,76 @@
+# Tasks Prompt
+
+You are generating a detailed task breakdown from an implementation plan. Follow this structured approach:
+
+## 1. Understand the Plan
+
+Read and analyze:
+- All phases and their objectives
+- Deliverables per phase
+- Dependencies between phases
+- Technical decisions made
+
+## 2. Task Decomposition Principles
+
+Create tasks that are:
+- **Atomic**: One clear deliverable
+- **Actionable**: Clear what to do
+- **Testable**: Has acceptance criteria
+- **Sized**: Completable in 1-4 hours
+
+## 3. Task Structure
+
+For each task include:
+
+```markdown
+### Task {ID}: {Short Title}
+
+**Phase**: {phase name}
+**Priority**: {P0-Critical / P1-High / P2-Medium / P3-Low}
+**Estimate**: {1h / 2h / 4h}
+**Dependencies**: {task IDs or "None"}
+
+**Description**:
+{What needs to be done}
+
+**Acceptance Criteria**:
+- [ ] {Criterion 1}
+- [ ] {Criterion 2}
+
+**Files to modify**:
+- `path/to/file.ts`
+
+**Status**: {Not Started / In Progress / Done}
+```
+
+## 4. Task Categories
+
+Group tasks by type:
+- 🏗️ **Setup/Infrastructure**
+- 📦 **Core Implementation**
+- 🔌 **Integration**
+- 🧪 **Testing**
+- 📚 **Documentation**
+- 🎨 **UI/UX** (if applicable)
+
+## 5. Dependency Graph
+
+Ensure:
+- No circular dependencies
+- Critical path is identified
+- Parallel work opportunities are marked
+
+## 6. Priority Guidelines
+
+- **P0-Critical**: Blocks all other work
+- **P1-High**: Core feature, must be done
+- **P2-Medium**: Important but not blocking
+- **P3-Low**: Nice to have, can defer
+
+## 7. Output
+
+Save to `specs/tasks.md` and report:
+- Total tasks count
+- Tasks per phase
+- Critical path summary
+- Next step: `speckit_implement` to start coding

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

@@ -1,129 +0,0 @@
----
-description: Identify underspecified areas in the specification and ask targeted clarification questions. Run before /speckit.plan.
----
-
-# /speckit.clarify - Clarify Requirements
-
-## User Input
-
-```text
-$ARGUMENTS
-```
-
-You **MUST** consider the user input before proceeding (if not empty).
-
-## Outline
-
-You are clarifying underspecified areas in the specification. Follow this workflow:
-
-### 1. Load Specification
-
-Find and read the specification file:
-- Check `specs/` directory for recent spec files
-- If user provides a spec path, use that
-- If no spec found, inform user to run `/speckit.specify` first
-
-### 2. Analyze for Gaps
-
-Review the specification for:
-
-**Critical Gaps** (must clarify):
-- Ambiguous scope boundaries
-- Undefined user roles/permissions
-- Missing error handling behavior
-- Unclear data validation rules
-- Security requirements not addressed
-
-**Important Gaps** (should clarify):
-- Performance expectations
-- Edge cases not covered
-- Integration details
-- UI/UX specifics
-
-**Minor Gaps** (nice to clarify):
-- Naming conventions
-- Logging requirements
-- Documentation needs
-
-### 3. Generate Questions
-
-Create a maximum of 5 highly targeted questions:
-
-For each question:
-1. **Question**: Clear, specific question
-2. **Context**: Why this matters for implementation
-3. **Options**: Provide 2-3 reasonable options with recommendations
-4. **Default**: Suggest a default if no answer provided
-
-**Question Format**:
-```
-### Question {N}: {Topic}
-
-{Question text}
-
-**Why it matters**: {Impact on implementation}
-
-**Options**:
-| Option | Description |
-|--------|-------------|
-| A (Recommended) | {Description} |
-| B | {Description} |
-| C | {Description} |
-
-You can reply with the option letter, "recommended", or provide your own answer.
-```
-
-### 4. Interactive Clarification
-
-Present questions one at a time:
-1. Ask the question with options
-2. Wait for user response
-3. Record the answer
-4. Update the specification with the clarification
-
-For each answer:
-- If user says "yes", "recommended", or "A" → use the recommended option
-- If user provides a different answer → validate it fits the context
-- If user says "skip" → note as "Deferred" and continue
-
-### 5. Update Specification
-
-Add a **Clarifications** section to the specification:
-
-```markdown
-## Clarifications
-
-| # | Topic | Question | Answer | Date |
-|---|-------|----------|--------|------|
-| 1 | {Topic} | {Question summary} | {Answer} | {Date} |
-```
-
-Also update relevant sections with the clarified information.
-
-### 6. Report Completion
-
-Output:
-- Number of clarifications made
-- Summary of decisions
-- Any deferred items
-- Next step: `/speckit.plan` to create implementation plan
-
-## Question Generation Rules
-
-**DO ask about**:
-- Scope boundaries (what's explicitly in/out)
-- User roles and their permissions
-- Error states and recovery
-- Data retention and privacy
-- Performance requirements
-
-**DON'T ask about**:
-- Implementation details (that's for /speckit.plan)
-- Obvious defaults (pagination, sorting, etc.)
-- Tech stack choices (user provides in /speckit.plan)
-
-## Handoffs
-
-After completing clarifications:
-- **Create plan**: `/speckit.plan` - Now ready to plan implementation
-- **Re-specify**: `/speckit.specify` - If major changes needed

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

@@ -1,122 +0,0 @@
----
-description: Execute the implementation tasks from tasks.md. Implements the feature according to the plan.
----
-
-# /speckit.implement - Execute Implementation
-
-## User Input
-
-```text
-$ARGUMENTS
-```
-
-You **MUST** consider the user input before proceeding (if not empty).
-
-## Outline
-
-You are implementing the feature according to the task list. Follow this workflow:
-
-### 1. Validate Prerequisites
-
-Check that all required files exist:
-- `specs/{feature}/spec.md` - Specification
-- `specs/{feature}/plan.md` - Implementation plan
-- `specs/{feature}/tasks.md` - Task breakdown
-
-If any are missing, inform user which `/speckit.*` command to run.
-
-### 2. Load Implementation Context
-
-Read all design documents:
-- **tasks.md**: Complete task list with execution order
-- **plan.md**: Tech stack, architecture, file structure
-- **data-model.md**: Entity definitions (if exists)
-- **contracts/**: API specifications (if exists)
-- **research.md**: Technical decisions (if exists)
-
-### 3. Verify Project Setup
-
-Check or create essential project files:
-
-**Based on tech stack, verify:**
-- Package management files (`package.json`, `requirements.txt`, `*.csproj`)
-- Ignore files (`.gitignore`, `.dockerignore` if Docker used)
-- Linting/formatting config (`.eslintrc`, `prettier.config.js`, etc.)
-- TypeScript config if applicable
-
-**Create if missing** - only ask user if multiple valid options exist.
-
-### 4. Execute Tasks
-
-Process tasks from `tasks.md` in order:
-
-1. **Read the task** - Understand what needs to be done
-2. **Check dependencies** - Verify prerequisite tasks are complete
-3. **Implement** - Write the code following the plan
-4. **Mark complete** - Check off the task in tasks.md
-
-For each task:
-```
-📋 Task T{number}: {description}
-📁 File: {file_path}
-⏳ Status: In Progress...
-```
-
-### 5. Implementation Guidelines
-
-**Code Quality**:
-- Follow the code style specified in plan.md or project conventions
-- Include appropriate comments and documentation
-- Write tests if specified in the tasks
-- Handle errors appropriately
-
-**Progress Tracking**:
-- Update task checkboxes as you complete them
-- Note any blockers or issues encountered
-- Suggest adjustments if tasks need modification
-
-**Checkpoint Validation**:
-- At each phase checkpoint, run the specified validation
-- Report results before proceeding to next phase
-
-### 6. Handle Blockers
-
-If a task cannot be completed:
-1. Document the blocker in the task
-2. Check if it's a dependency issue
-3. Ask user for clarification if needed
-4. Skip and continue with non-blocked tasks
-
-### 7. Report Progress
-
-After each phase or upon request, report:
-- Tasks completed
-- Tasks remaining
-- Any blockers encountered
-- Code quality notes
-- Next steps
-
-## Execution Mode Options
-
-User can specify in `$ARGUMENTS`:
-
-- **Full implementation**: Complete all tasks
-- **Phase only**: `--phase 3` - Complete only specified phase
-- **Single task**: `--task T015` - Complete only specified task
-- **Dry run**: `--dry-run` - Show what would be done without making changes
-
-## Quality Checks
-
-Before marking implementation complete:
-- [ ] All tasks in tasks.md are checked off
-- [ ] Code compiles/runs without errors
-- [ ] Tests pass (if applicable)
-- [ ] No TODO comments left unaddressed
-- [ ] Documentation is updated
-
-## Handoffs
-
-After completing implementation:
-- **Test the feature** - Run tests and verify functionality
-- **Create PR** - Prepare pull request with summary
-- **Update spec** - Mark specification as implemented

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

@@ -1,153 +0,0 @@
----
-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

@@ -1,145 +0,0 @@
----
-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