smart-spec-kit-mcp 2.0.0 → 2.0.2

package/starter-kit/memory/constitution.md

@@ -0,0 +1,122 @@
+# Project Constitution
+
+> This document defines the core principles and guidelines that govern all development on this project.
+
+## Project Information
+
+- **Project Name**: [TO FILL: Your project name]
+- **Ratification Date**: [TO FILL: YYYY-MM-DD]
+- **Last Amended**: [TO FILL: YYYY-MM-DD]
+- **Version**: 1.0.0
+
+---
+
+## Core Principles
+
+### Principle 1: [TO FILL: Principle Name]
+
+[TO FILL: Description of this principle and what it means for the project]
+
+**Rationale**: [TO FILL: Why this principle matters and what problems it solves]
+
+**Examples**:
+- [TO FILL: Concrete example of applying this principle]
+
+---
+
+### Principle 2: Code Quality
+
+All code must be readable, maintainable, and follow established coding standards.
+
+**Rationale**: Consistent, high-quality code reduces bugs, speeds up onboarding, and makes the codebase easier to maintain over time.
+
+**Guidelines**:
+- Code must pass linting without warnings
+- All public functions must have documentation
+- Complex logic must include explanatory comments
+- Code review required for all changes
+
+---
+
+### Principle 3: Test Coverage
+
+All features must have appropriate test coverage before being considered complete.
+
+**Rationale**: Tests provide confidence that code works as intended and prevents regressions during future changes.
+
+**Guidelines**:
+- Unit tests for business logic (minimum 80% coverage)
+- Integration tests for API endpoints
+- E2E tests for critical user flows
+
+---
+
+### Principle 4: Documentation First
+
+Features must be specified before implementation begins.
+
+**Rationale**: Clear specifications reduce misunderstandings, prevent rework, and create a shared understanding among all stakeholders.
+
+**Guidelines**:
+- Use `/speckit.specify` before starting any new feature
+- Keep specifications updated as requirements evolve
+- Link implementation PRs to their specifications
+
+---
+
+### Principle 5: Security by Design
+
+Security considerations must be part of every feature from the start.
+
+**Rationale**: Retrofitting security is expensive and error-prone. Building it in from the start is more effective.
+
+**Guidelines**:
+- Validate all user inputs
+- Use parameterized queries for database access
+- Follow principle of least privilege
+- Document security considerations in specifications
+
+---
+
+## Tech Stack Guidelines
+
+### Preferred Technologies
+| Category | Technology | Notes |
+|----------|------------|-------|
+| Language | [TO FILL] | |
+| Framework | [TO FILL] | |
+| Database | [TO FILL] | |
+| Testing | [TO FILL] | |
+
+### Code Style
+- [TO FILL: Link to style guide or describe key conventions]
+
+### Dependencies
+- Prefer well-maintained, widely-used packages
+- Document the reason for adding new dependencies
+- Keep dependencies updated regularly
+
+---
+
+## Governance
+
+### Amendment Process
+1. Propose changes via pull request to this document
+2. Changes require approval from [TO FILL: who approves]
+3. Version number updated according to semantic versioning:
+   - **MAJOR**: Principle removed or fundamentally changed
+   - **MINOR**: New principle or section added
+   - **PATCH**: Clarifications and wording improvements
+
+### Enforcement
+- Code reviews should verify adherence to these principles
+- Automated checks where possible (linting, test coverage)
+- Regular retrospectives to assess principle effectiveness
+
+---
+
+## Version History
+
+| Version | Date | Changes |
+|---------|------|---------|
+| 1.0.0 | [TO FILL] | Initial constitution |

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

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

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

@@ -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