@lbruton/spec-workflow-mcp 2.2.4

package/dist/markdown/templates/structure-template.md

@@ -0,0 +1,145 @@
+# Project Structure
+
+## Directory Organization
+
+```
+[Define your project's directory structure. Examples below - adapt to your project type]
+
+Example for a library/package:
+project-root/
+├── src/                    # Source code
+├── tests/                  # Test files  
+├── docs/                   # Documentation
+├── examples/               # Usage examples
+└── [build/dist/out]        # Build output
+
+Example for an application:
+project-root/
+├── [src/app/lib]           # Main source code
+├── [assets/resources]      # Static resources
+├── [config/settings]       # Configuration
+├── [scripts/tools]         # Build/utility scripts
+└── [tests/spec]            # Test files
+
+Common patterns:
+- Group by feature/module
+- Group by layer (UI, business logic, data)
+- Group by type (models, controllers, views)
+- Flat structure for simple projects
+```
+
+## Naming Conventions
+
+### Files
+- **Components/Modules**: [e.g., `PascalCase`, `snake_case`, `kebab-case`]
+- **Services/Handlers**: [e.g., `UserService`, `user_service`, `user-service`]
+- **Utilities/Helpers**: [e.g., `dateUtils`, `date_utils`, `date-utils`]
+- **Tests**: [e.g., `[filename]_test`, `[filename].test`, `[filename]Test`]
+
+### Code
+- **Classes/Types**: [e.g., `PascalCase`, `CamelCase`, `snake_case`]
+- **Functions/Methods**: [e.g., `camelCase`, `snake_case`, `PascalCase`]
+- **Constants**: [e.g., `UPPER_SNAKE_CASE`, `SCREAMING_CASE`, `PascalCase`]
+- **Variables**: [e.g., `camelCase`, `snake_case`, `lowercase`]
+
+## Import Patterns
+
+### Import Order
+1. External dependencies
+2. Internal modules
+3. Relative imports
+4. Style imports
+
+### Module/Package Organization
+```
+[Describe your project's import/include patterns]
+Examples:
+- Absolute imports from project root
+- Relative imports within modules
+- Package/namespace organization
+- Dependency management approach
+```
+
+## Code Structure Patterns
+
+[Define common patterns for organizing code within files. Below are examples - choose what applies to your project]
+
+### Module/Class Organization
+```
+Example patterns:
+1. Imports/includes/dependencies
+2. Constants and configuration
+3. Type/interface definitions
+4. Main implementation
+5. Helper/utility functions
+6. Exports/public API
+```
+
+### Function/Method Organization
+```
+Example patterns:
+- Input validation first
+- Core logic in the middle
+- Error handling throughout
+- Clear return points
+```
+
+### File Organization Principles
+```
+Choose what works for your project:
+- One class/module per file
+- Related functionality grouped together
+- Public API at the top/bottom
+- Implementation details hidden
+```
+
+## Code Organization Principles
+
+1. **Single Responsibility**: Each file should have one clear purpose
+2. **Modularity**: Code should be organized into reusable modules
+3. **Testability**: Structure code to be easily testable
+4. **Consistency**: Follow patterns established in the codebase
+
+## Module Boundaries
+[Define how different parts of your project interact and maintain separation of concerns]
+
+Examples of boundary patterns:
+- **Core vs Plugins**: Core functionality vs extensible plugins
+- **Public API vs Internal**: What's exposed vs implementation details  
+- **Platform-specific vs Cross-platform**: OS-specific code isolation
+- **Stable vs Experimental**: Production code vs experimental features
+- **Dependencies direction**: Which modules can depend on which
+
+## Code Size Guidelines
+[Define your project's guidelines for file and function sizes]
+
+Suggested guidelines:
+- **File size**: [Define maximum lines per file]
+- **Function/Method size**: [Define maximum lines per function]
+- **Class/Module complexity**: [Define complexity limits]
+- **Nesting depth**: [Maximum nesting levels]
+
+## Dashboard/Monitoring Structure (if applicable)
+[How dashboard or monitoring components are organized]
+
+### Example Structure:
+```
+src/
+└── dashboard/          # Self-contained dashboard subsystem
+    ├── server/        # Backend server components
+    ├── client/        # Frontend assets
+    ├── shared/        # Shared types/utilities
+    └── public/        # Static assets
+```
+
+### Separation of Concerns
+- Dashboard isolated from core business logic
+- Own CLI entry point for independent operation
+- Minimal dependencies on main application
+- Can be disabled without affecting core functionality
+
+## Documentation Standards
+- All public APIs must have documentation
+- Complex logic should include inline comments
+- README files for major modules
+- Follow language-specific documentation conventions

package/dist/markdown/templates/tasks-template.md

@@ -0,0 +1,139 @@
+# Tasks Document
+
+- [ ] 1. Create core interfaces in src/types/feature.ts
+  - File: src/types/feature.ts
+  - Define TypeScript interfaces for feature data structures
+  - Extend existing base interfaces from base.ts
+  - Purpose: Establish type safety for feature implementation
+  - _Leverage: src/types/base.ts_
+  - _Requirements: 1.1_
+  - _Prompt: Role: TypeScript Developer specializing in type systems and interfaces | Task: Create comprehensive TypeScript interfaces for the feature data structures following requirements 1.1, extending existing base interfaces from src/types/base.ts | Restrictions: Do not modify existing base interfaces, maintain backward compatibility, follow project naming conventions | Success: All interfaces compile without errors, proper inheritance from base types, full type coverage for feature requirements_
+
+- [ ] 2. Create base model class in src/models/FeatureModel.ts
+  - File: src/models/FeatureModel.ts
+  - Implement base model extending BaseModel class
+  - Add validation methods using existing validation utilities
+  - Purpose: Provide data layer foundation for feature
+  - _Leverage: src/models/BaseModel.ts, src/utils/validation.ts_
+  - _Requirements: 2.1_
+  - _Prompt: Role: Backend Developer with expertise in Node.js and data modeling | Task: Create a base model class extending BaseModel and implementing validation following requirement 2.1, leveraging existing patterns from src/models/BaseModel.ts and src/utils/validation.ts | Restrictions: Must follow existing model patterns, do not bypass validation utilities, maintain consistent error handling | Success: Model extends BaseModel correctly, validation methods implemented and tested, follows project architecture patterns_
+
+- [ ] 3. Add specific model methods to FeatureModel.ts
+  - File: src/models/FeatureModel.ts (continue from task 2)
+  - Implement create, update, delete methods
+  - Add relationship handling for foreign keys
+  - Purpose: Complete model functionality for CRUD operations
+  - _Leverage: src/models/BaseModel.ts_
+  - _Requirements: 2.2, 2.3_
+  - _Prompt: Role: Backend Developer with expertise in ORM and database operations | Task: Implement CRUD methods and relationship handling in FeatureModel.ts following requirements 2.2 and 2.3, extending patterns from src/models/BaseModel.ts | Restrictions: Must maintain transaction integrity, follow existing relationship patterns, do not duplicate base model functionality | Success: All CRUD operations work correctly, relationships are properly handled, database operations are atomic and efficient_
+
+- [ ] 4. Create model unit tests in tests/models/FeatureModel.test.ts
+  - File: tests/models/FeatureModel.test.ts
+  - Write tests for model validation and CRUD methods
+  - Use existing test utilities and fixtures
+  - Purpose: Ensure model reliability and catch regressions
+  - _Leverage: tests/helpers/testUtils.ts, tests/fixtures/data.ts_
+  - _Requirements: 2.1, 2.2_
+  - _Prompt: Role: QA Engineer with expertise in unit testing and Jest/Mocha frameworks | Task: Create comprehensive unit tests for FeatureModel validation and CRUD methods covering requirements 2.1 and 2.2, using existing test utilities from tests/helpers/testUtils.ts and fixtures from tests/fixtures/data.ts | Restrictions: Must test both success and failure scenarios, do not test external dependencies directly, maintain test isolation | Success: All model methods are tested with good coverage, edge cases covered, tests run independently and consistently_
+
+- [ ] 5. Create service interface in src/services/IFeatureService.ts
+  - File: src/services/IFeatureService.ts
+  - Define service contract with method signatures
+  - Extend base service interface patterns
+  - Purpose: Establish service layer contract for dependency injection
+  - _Leverage: src/services/IBaseService.ts_
+  - _Requirements: 3.1_
+  - _Prompt: Role: Software Architect specializing in service-oriented architecture and TypeScript interfaces | Task: Design service interface contract following requirement 3.1, extending base service patterns from src/services/IBaseService.ts for dependency injection | Restrictions: Must maintain interface segregation principle, do not expose internal implementation details, ensure contract compatibility with DI container | Success: Interface is well-defined with clear method signatures, extends base service appropriately, supports all required service operations_
+
+- [ ] 6. Implement feature service in src/services/FeatureService.ts
+  - File: src/services/FeatureService.ts
+  - Create concrete service implementation using FeatureModel
+  - Add error handling with existing error utilities
+  - Purpose: Provide business logic layer for feature operations
+  - _Leverage: src/services/BaseService.ts, src/utils/errorHandler.ts, src/models/FeatureModel.ts_
+  - _Requirements: 3.2_
+  - _Prompt: Role: Backend Developer with expertise in service layer architecture and business logic | Task: Implement concrete FeatureService following requirement 3.2, using FeatureModel and extending BaseService patterns with proper error handling from src/utils/errorHandler.ts | Restrictions: Must implement interface contract exactly, do not bypass model validation, maintain separation of concerns from data layer | Success: Service implements all interface methods correctly, robust error handling implemented, business logic is well-encapsulated and testable_
+
+- [ ] 7. Add service dependency injection in src/utils/di.ts
+  - File: src/utils/di.ts (modify existing)
+  - Register FeatureService in dependency injection container
+  - Configure service lifetime and dependencies
+  - Purpose: Enable service injection throughout application
+  - _Leverage: existing DI configuration in src/utils/di.ts_
+  - _Requirements: 3.1_
+  - _Prompt: Role: DevOps Engineer with expertise in dependency injection and IoC containers | Task: Register FeatureService in DI container following requirement 3.1, configuring appropriate lifetime and dependencies using existing patterns from src/utils/di.ts | Restrictions: Must follow existing DI container patterns, do not create circular dependencies, maintain service resolution efficiency | Success: FeatureService is properly registered and resolvable, dependencies are correctly configured, service lifetime is appropriate for use case_
+
+- [ ] 8. Create service unit tests in tests/services/FeatureService.test.ts
+  - File: tests/services/FeatureService.test.ts
+  - Write tests for service methods with mocked dependencies
+  - Test error handling scenarios
+  - Purpose: Ensure service reliability and proper error handling
+  - _Leverage: tests/helpers/testUtils.ts, tests/mocks/modelMocks.ts_
+  - _Requirements: 3.2, 3.3_
+  - _Prompt: Role: QA Engineer with expertise in service testing and mocking frameworks | Task: Create comprehensive unit tests for FeatureService methods covering requirements 3.2 and 3.3, using mocked dependencies from tests/mocks/modelMocks.ts and test utilities | Restrictions: Must mock all external dependencies, test business logic in isolation, do not test framework code | Success: All service methods tested with proper mocking, error scenarios covered, tests verify business logic correctness and error handling_
+
+- [ ] 4. Create API endpoints
+  - Design API structure
+  - _Leverage: src/api/baseApi.ts, src/utils/apiUtils.ts_
+  - _Requirements: 4.0_
+  - _Prompt: Role: API Architect specializing in RESTful design and Express.js | Task: Design comprehensive API structure following requirement 4.0, leveraging existing patterns from src/api/baseApi.ts and utilities from src/utils/apiUtils.ts | Restrictions: Must follow REST conventions, maintain API versioning compatibility, do not expose internal data structures directly | Success: API structure is well-designed and documented, follows existing patterns, supports all required operations with proper HTTP methods and status codes_
+
+- [ ] 4.1 Set up routing and middleware
+  - Configure application routes
+  - Add authentication middleware
+  - Set up error handling middleware
+  - _Leverage: src/middleware/auth.ts, src/middleware/errorHandler.ts_
+  - _Requirements: 4.1_
+  - _Prompt: Role: Backend Developer with expertise in Express.js middleware and routing | Task: Configure application routes and middleware following requirement 4.1, integrating authentication from src/middleware/auth.ts and error handling from src/middleware/errorHandler.ts | Restrictions: Must maintain middleware order, do not bypass security middleware, ensure proper error propagation | Success: Routes are properly configured with correct middleware chain, authentication works correctly, errors are handled gracefully throughout the request lifecycle_
+
+- [ ] 4.2 Implement CRUD endpoints
+  - Create API endpoints
+  - Add request validation
+  - Write API integration tests
+  - _Leverage: src/controllers/BaseController.ts, src/utils/validation.ts_
+  - _Requirements: 4.2, 4.3_
+  - _Prompt: Role: Full-stack Developer with expertise in API development and validation | Task: Implement CRUD endpoints following requirements 4.2 and 4.3, extending BaseController patterns and using validation utilities from src/utils/validation.ts | Restrictions: Must validate all inputs, follow existing controller patterns, ensure proper HTTP status codes and responses | Success: All CRUD operations work correctly, request validation prevents invalid data, integration tests pass and cover all endpoints_
+
+- [ ] 5. Add frontend components
+  - Plan component architecture
+  - _Leverage: src/components/BaseComponent.tsx, src/styles/theme.ts_
+  - _Requirements: 5.0_
+  - _Prompt: Role: Frontend Architect with expertise in React component design and architecture | Task: Plan comprehensive component architecture following requirement 5.0, leveraging base patterns from src/components/BaseComponent.tsx and theme system from src/styles/theme.ts | Restrictions: Must follow existing component patterns, maintain design system consistency, ensure component reusability | Success: Architecture is well-planned and documented, components are properly organized, follows existing patterns and theme system_
+
+- [ ] 5.1 Create base UI components
+  - Set up component structure
+  - Implement reusable components
+  - Add styling and theming
+  - _Leverage: src/components/BaseComponent.tsx, src/styles/theme.ts_
+  - _Requirements: 5.1_
+  - _Prompt: Role: Frontend Developer specializing in React and component architecture | Task: Create reusable UI components following requirement 5.1, extending BaseComponent patterns and using existing theme system from src/styles/theme.ts | Restrictions: Must use existing theme variables, follow component composition patterns, ensure accessibility compliance | Success: Components are reusable and properly themed, follow existing architecture, accessible and responsive_
+
+- [ ] 5.2 Implement feature-specific components
+  - Create feature components
+  - Add state management
+  - Connect to API endpoints
+  - _Leverage: src/hooks/useApi.ts, src/components/BaseComponent.tsx_
+  - _Requirements: 5.2, 5.3_
+  - _Prompt: Role: React Developer with expertise in state management and API integration | Task: Implement feature-specific components following requirements 5.2 and 5.3, using API hooks from src/hooks/useApi.ts and extending BaseComponent patterns | Restrictions: Must use existing state management patterns, handle loading and error states properly, maintain component performance | Success: Components are fully functional with proper state management, API integration works smoothly, user experience is responsive and intuitive_
+
+- [ ] 6. Integration and testing
+  - Plan integration approach
+  - _Leverage: src/utils/integrationUtils.ts, tests/helpers/testUtils.ts_
+  - _Requirements: 6.0_
+  - _Prompt: Role: Integration Engineer with expertise in system integration and testing strategies | Task: Plan comprehensive integration approach following requirement 6.0, leveraging integration utilities from src/utils/integrationUtils.ts and test helpers | Restrictions: Must consider all system components, ensure proper test coverage, maintain integration test reliability | Success: Integration plan is comprehensive and feasible, all system components work together correctly, integration points are well-tested_
+
+- [ ] 6.1 Write end-to-end tests
+  - Set up E2E testing framework
+  - Write user journey tests
+  - Add test automation
+  - _Leverage: tests/helpers/testUtils.ts, tests/fixtures/data.ts_
+  - _Requirements: All_
+  - _Prompt: Role: QA Automation Engineer with expertise in E2E testing and test frameworks like Cypress or Playwright | Task: Implement comprehensive end-to-end tests covering all requirements, setting up testing framework and user journey tests using test utilities and fixtures | Restrictions: Must test real user workflows, ensure tests are maintainable and reliable, do not test implementation details | Success: E2E tests cover all critical user journeys, tests run reliably in CI/CD pipeline, user experience is validated from end-to-end_
+
+- [ ] 6.2 Final integration and cleanup
+  - Integrate all components
+  - Fix any integration issues
+  - Clean up code and documentation
+  - _Leverage: src/utils/cleanup.ts, docs/templates/_
+  - _Requirements: All_
+  - _Prompt: Role: Senior Developer with expertise in code quality and system integration | Task: Complete final integration of all components and perform comprehensive cleanup covering all requirements, using cleanup utilities and documentation templates | Restrictions: Must not break existing functionality, ensure code quality standards are met, maintain documentation consistency | Success: All components are fully integrated and working together, code is clean and well-documented, system meets all requirements and quality standards_

package/dist/markdown/templates/tech-template.md

@@ -0,0 +1,99 @@
+# Technology Stack
+
+## Project Type
+[Describe what kind of project this is: web application, CLI tool, desktop application, mobile app, library, API service, embedded system, game, etc.]
+
+## Core Technologies
+
+### Primary Language(s)
+- **Language**: [e.g., Python 3.11, Go 1.21, TypeScript, Rust, C++]
+- **Runtime/Compiler**: [if applicable]
+- **Language-specific tools**: [package managers, build tools, etc.]
+
+### Key Dependencies/Libraries
+[List the main libraries and frameworks your project depends on]
+- **[Library/Framework name]**: [Purpose and version]
+- **[Library/Framework name]**: [Purpose and version]
+
+### Application Architecture
+[Describe how your application is structured - this could be MVC, event-driven, plugin-based, client-server, standalone, microservices, monolithic, etc.]
+
+### Data Storage (if applicable)
+- **Primary storage**: [e.g., PostgreSQL, files, in-memory, cloud storage]
+- **Caching**: [e.g., Redis, in-memory, disk cache]
+- **Data formats**: [e.g., JSON, Protocol Buffers, XML, binary]
+
+### External Integrations (if applicable)
+- **APIs**: [External services you integrate with]
+- **Protocols**: [e.g., HTTP/REST, gRPC, WebSocket, TCP/IP]
+- **Authentication**: [e.g., OAuth, API keys, certificates]
+
+### Monitoring & Dashboard Technologies (if applicable)
+- **Dashboard Framework**: [e.g., React, Vue, vanilla JS, terminal UI]
+- **Real-time Communication**: [e.g., WebSocket, Server-Sent Events, polling]
+- **Visualization Libraries**: [e.g., Chart.js, D3, terminal graphs]
+- **State Management**: [e.g., Redux, Vuex, file system as source of truth]
+
+## Development Environment
+
+### Build & Development Tools
+- **Build System**: [e.g., Make, CMake, Gradle, npm scripts, cargo]
+- **Package Management**: [e.g., pip, npm, cargo, go mod, apt, brew]
+- **Development workflow**: [e.g., hot reload, watch mode, REPL]
+
+### Code Quality Tools
+- **Static Analysis**: [Tools for code quality and correctness]
+- **Formatting**: [Code style enforcement tools]
+- **Testing Framework**: [Unit, integration, and/or end-to-end testing tools]
+- **Documentation**: [Documentation generation tools]
+
+### Version Control & Collaboration
+- **VCS**: [e.g., Git, Mercurial, SVN]
+- **Branching Strategy**: [e.g., Git Flow, GitHub Flow, trunk-based]
+- **Code Review Process**: [How code reviews are conducted]
+
+### Dashboard Development (if applicable)
+- **Live Reload**: [e.g., Hot module replacement, file watchers]
+- **Port Management**: [e.g., Dynamic allocation, configurable ports]
+- **Multi-Instance Support**: [e.g., Running multiple dashboards simultaneously]
+
+## Deployment & Distribution (if applicable)
+- **Target Platform(s)**: [Where/how the project runs: cloud, on-premise, desktop, mobile, embedded]
+- **Distribution Method**: [How users get your software: download, package manager, app store, SaaS]
+- **Installation Requirements**: [Prerequisites, system requirements]
+- **Update Mechanism**: [How updates are delivered]
+
+## Technical Requirements & Constraints
+
+### Performance Requirements
+- [e.g., response time, throughput, memory usage, startup time]
+- [Specific benchmarks or targets]
+
+### Compatibility Requirements  
+- **Platform Support**: [Operating systems, architectures, versions]
+- **Dependency Versions**: [Minimum/maximum versions of dependencies]
+- **Standards Compliance**: [Industry standards, protocols, specifications]
+
+### Security & Compliance
+- **Security Requirements**: [Authentication, encryption, data protection]
+- **Compliance Standards**: [GDPR, HIPAA, SOC2, etc. if applicable]
+- **Threat Model**: [Key security considerations]
+
+### Scalability & Reliability
+- **Expected Load**: [Users, requests, data volume]
+- **Availability Requirements**: [Uptime targets, disaster recovery]
+- **Growth Projections**: [How the system needs to scale]
+
+## Technical Decisions & Rationale
+[Document key architectural and technology choices]
+
+### Decision Log
+1. **[Technology/Pattern Choice]**: [Why this was chosen, alternatives considered]
+2. **[Architecture Decision]**: [Rationale, trade-offs accepted]
+3. **[Tool/Library Selection]**: [Reasoning, evaluation criteria]
+
+## Known Limitations
+[Document any technical debt, limitations, or areas for improvement]
+
+- [Limitation 1]: [Impact and potential future solutions]
+- [Limitation 2]: [Why it exists and when it might be addressed]

package/dist/prompts/create-spec.d.ts

@@ -0,0 +1,3 @@
+import { PromptDefinition } from './types.js';
+export declare const createSpecPrompt: PromptDefinition;
+//# sourceMappingURL=create-spec.d.ts.map

package/dist/prompts/create-spec.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"create-spec.d.ts","sourceRoot":"","sources":["../../src/prompts/create-spec.ts"],"names":[],"mappings":"AACA,OAAO,EAAE,gBAAgB,EAAE,MAAM,YAAY,CAAC;AAiG9C,eAAO,MAAM,gBAAgB,EAAE,gBAG9B,CAAC"}

package/dist/prompts/create-spec.js

@@ -0,0 +1,93 @@
+const prompt = {
+    name: 'create-spec',
+    title: 'Create Specification Document',
+    description: 'Guide for creating spec documents directly in the file system. Shows how to use templates and create requirements, design, or tasks documents at the correct paths.',
+    arguments: [
+        {
+            name: 'specName',
+            description: 'Feature name in kebab-case (e.g., user-authentication, data-export)',
+            required: true
+        },
+        {
+            name: 'documentType',
+            description: 'Type of document to create: requirements, design, or tasks',
+            required: true
+        },
+        {
+            name: 'description',
+            description: 'Brief description of what this spec should accomplish',
+            required: false
+        }
+    ]
+};
+async function handler(args, context) {
+    const { specName, documentType, description } = args;
+    if (!specName || !documentType) {
+        throw new Error('specName and documentType are required arguments');
+    }
+    const validDocTypes = ['requirements', 'design', 'tasks'];
+    if (!validDocTypes.includes(documentType)) {
+        throw new Error(`documentType must be one of: ${validDocTypes.join(', ')}`);
+    }
+    // Build context-aware messages
+    const messages = [
+        {
+            role: 'user',
+            content: {
+                type: 'text',
+                text: `Create a ${documentType} document for the "${specName}" feature using the spec-workflow methodology.
+
+**Context:**
+- Project: ${context.projectPath}
+- Feature: ${specName}
+- Document type: ${documentType}
+${description ? `- Description: ${description}` : ''}
+${context.dashboardUrl ? `- Dashboard: ${context.dashboardUrl}` : ''}
+
+**Instructions:**
+1. First, read the template at: .spec-workflow/templates/${documentType}-template.md
+2. Follow the template structure exactly - this ensures consistency across the project
+3. Create comprehensive content that follows spec-driven development best practices
+4. Include all required sections from the template
+5. Use clear, actionable language
+6. Create the document at: .spec-workflow/specs/${specName}/${documentType}.md
+7. After creating, use approvals tool with action:'request' to get user approval
+
+**File Paths:**
+- Template location: .spec-workflow/templates/${documentType}-template.md
+- Document destination: .spec-workflow/specs/${specName}/${documentType}.md
+
+**Workflow Guidelines:**
+- Requirements documents define WHAT needs to be built
+- Design documents define HOW it will be built  
+- Tasks documents break down implementation into actionable steps
+- Each document builds upon the previous one in sequence
+- Templates are automatically updated on server start
+
+${documentType === 'tasks' ? `
+**Special Instructions for Tasks Document:**
+- For each task, generate a _Prompt field with structured AI guidance
+- Format: _Prompt: Role: [role] | Task: [description] | Restrictions: [constraints] | Success: [criteria]
+- Make prompts specific to the project context and requirements
+- Include _Leverage fields pointing to existing code to reuse
+- Include _Requirements fields showing which requirements each task implements
+- Tasks should be atomic (1-3 files each) and in logical order
+
+**Implementation Logging:**
+- When implementing tasks, developers will use the log-implementation tool to record what was done
+- Implementation logs appear in the dashboard's "Logs" tab for easy reference
+- These logs prevent implementation details from being lost in chat history
+- Good task descriptions help developers write better implementation summaries
+` : ''}
+
+Please read the ${documentType} template and create the comprehensive document at the specified path.`
+            }
+        }
+    ];
+    return messages;
+}
+export const createSpecPrompt = {
+    prompt,
+    handler
+};
+//# sourceMappingURL=create-spec.js.map

package/dist/prompts/create-spec.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"create-spec.js","sourceRoot":"","sources":["../../src/prompts/create-spec.ts"],"names":[],"mappings":"AAIA,MAAM,MAAM,GAAW;IACrB,IAAI,EAAE,aAAa;IACnB,KAAK,EAAE,+BAA+B;IACtC,WAAW,EAAE,qKAAqK;IAClL,SAAS,EAAE;QACT;YACE,IAAI,EAAE,UAAU;YAChB,WAAW,EAAE,qEAAqE;YAClF,QAAQ,EAAE,IAAI;SACf;QACD;YACE,IAAI,EAAE,cAAc;YACpB,WAAW,EAAE,4DAA4D;YACzE,QAAQ,EAAE,IAAI;SACf;QACD;YACE,IAAI,EAAE,aAAa;YACnB,WAAW,EAAE,uDAAuD;YACpE,QAAQ,EAAE,KAAK;SAChB;KACF;CACF,CAAC;AAEF,KAAK,UAAU,OAAO,CAAC,IAAyB,EAAE,OAAoB;IACpE,MAAM,EAAE,QAAQ,EAAE,YAAY,EAAE,WAAW,EAAE,GAAG,IAAI,CAAC;IAErD,IAAI,CAAC,QAAQ,IAAI,CAAC,YAAY,EAAE,CAAC;QAC/B,MAAM,IAAI,KAAK,CAAC,kDAAkD,CAAC,CAAC;IACtE,CAAC;IAED,MAAM,aAAa,GAAG,CAAC,cAAc,EAAE,QAAQ,EAAE,OAAO,CAAC,CAAC;IAC1D,IAAI,CAAC,aAAa,CAAC,QAAQ,CAAC,YAAY,CAAC,EAAE,CAAC;QAC1C,MAAM,IAAI,KAAK,CAAC,gCAAgC,aAAa,CAAC,IAAI,CAAC,IAAI,CAAC,EAAE,CAAC,CAAC;IAC9E,CAAC;IAED,+BAA+B;IAC/B,MAAM,QAAQ,GAAoB;QAChC;YACE,IAAI,EAAE,MAAM;YACZ,OAAO,EAAE;gBACP,IAAI,EAAE,MAAM;gBACZ,IAAI,EAAE,YAAY,YAAY,sBAAsB,QAAQ;;;aAGvD,OAAO,CAAC,WAAW;aACnB,QAAQ;mBACF,YAAY;EAC7B,WAAW,CAAC,CAAC,CAAC,kBAAkB,WAAW,EAAE,CAAC,CAAC,CAAC,EAAE;EAClD,OAAO,CAAC,YAAY,CAAC,CAAC,CAAC,gBAAgB,OAAO,CAAC,YAAY,EAAE,CAAC,CAAC,CAAC,EAAE;;;2DAGT,YAAY;;;;;kDAKrB,QAAQ,IAAI,YAAY;;;;gDAI1B,YAAY;+CACb,QAAQ,IAAI,YAAY;;;;;;;;;EASrE,YAAY,KAAK,OAAO,CAAC,CAAC,CAAC;;;;;;;;;;;;;;CAc5B,CAAC,CAAC,CAAC,EAAE;;kBAEY,YAAY,wEAAwE;aAC/F;SACF;KACF,CAAC;IAEF,OAAO,QAAQ,CAAC;AAClB,CAAC;AAED,MAAM,CAAC,MAAM,gBAAgB,GAAqB;IAChD,MAAM;IACN,OAAO;CACR,CAAC"}

package/dist/prompts/create-steering-doc.d.ts

@@ -0,0 +1,3 @@
+import { PromptDefinition } from './types.js';
+export declare const createSteeringDocPrompt: PromptDefinition;
+//# sourceMappingURL=create-steering-doc.d.ts.map

package/dist/prompts/create-steering-doc.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"create-steering-doc.d.ts","sourceRoot":"","sources":["../../src/prompts/create-steering-doc.ts"],"names":[],"mappings":"AACA,OAAO,EAAE,gBAAgB,EAAE,MAAM,YAAY,CAAC;AA6E9C,eAAO,MAAM,uBAAuB,EAAE,gBAGrC,CAAC"}

package/dist/prompts/create-steering-doc.js

@@ -0,0 +1,73 @@
+const prompt = {
+    name: 'create-steering-doc',
+    title: 'Create Steering Document',
+    description: 'Guide for creating project steering documents (product, tech, structure) directly in the file system. These provide high-level project guidance.',
+    arguments: [
+        {
+            name: 'docType',
+            description: 'Type of steering document: product, tech, or structure',
+            required: true
+        },
+        {
+            name: 'scope',
+            description: 'Scope of the steering document (e.g., frontend, backend, full-stack)',
+            required: false
+        }
+    ]
+};
+async function handler(args, context) {
+    const { docType, scope } = args;
+    if (!docType) {
+        throw new Error('docType is a required argument');
+    }
+    const validDocTypes = ['product', 'tech', 'structure'];
+    if (!validDocTypes.includes(docType)) {
+        throw new Error(`docType must be one of: ${validDocTypes.join(', ')}`);
+    }
+    const messages = [
+        {
+            role: 'user',
+            content: {
+                type: 'text',
+                text: `Create a ${docType} steering document for the project.
+
+**Context:**
+- Project: ${context.projectPath}
+- Steering document type: ${docType}
+${scope ? `- Scope: ${scope}` : ''}
+${context.dashboardUrl ? `- Dashboard: ${context.dashboardUrl}` : ''}
+
+**Instructions:**
+1. First, read the template at: .spec-workflow/templates/${docType}-template.md
+2. Check if steering docs exist at: .spec-workflow/steering/
+3. Create comprehensive content following the template structure
+4. Create the document at: .spec-workflow/steering/${docType}.md
+5. After creating, use approvals tool with action:'request' to get user approval
+
+**File Paths:**
+- Template location: .spec-workflow/templates/${docType}-template.md
+- Document destination: .spec-workflow/steering/${docType}.md
+
+**Steering Document Types:**
+- **product**: Defines project vision, goals, and user outcomes
+- **tech**: Documents technology decisions and architecture patterns
+- **structure**: Maps codebase organization and conventions
+
+**Key Principles:**
+- Be specific and actionable
+- Include examples where helpful
+- Consider both technical and business requirements
+- Provide clear guidance for future development
+- Templates are automatically updated on server start
+
+Please read the ${docType} template and create a comprehensive steering document at the specified path.`
+            }
+        }
+    ];
+    return messages;
+}
+export const createSteeringDocPrompt = {
+    prompt,
+    handler
+};
+//# sourceMappingURL=create-steering-doc.js.map

package/dist/prompts/create-steering-doc.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"create-steering-doc.js","sourceRoot":"","sources":["../../src/prompts/create-steering-doc.ts"],"names":[],"mappings":"AAIA,MAAM,MAAM,GAAW;IACrB,IAAI,EAAE,qBAAqB;IAC3B,KAAK,EAAE,0BAA0B;IACjC,WAAW,EAAE,kJAAkJ;IAC/J,SAAS,EAAE;QACT;YACE,IAAI,EAAE,SAAS;YACf,WAAW,EAAE,wDAAwD;YACrE,QAAQ,EAAE,IAAI;SACf;QACD;YACE,IAAI,EAAE,OAAO;YACb,WAAW,EAAE,sEAAsE;YACnF,QAAQ,EAAE,KAAK;SAChB;KACF;CACF,CAAC;AAEF,KAAK,UAAU,OAAO,CAAC,IAAyB,EAAE,OAAoB;IACpE,MAAM,EAAE,OAAO,EAAE,KAAK,EAAE,GAAG,IAAI,CAAC;IAEhC,IAAI,CAAC,OAAO,EAAE,CAAC;QACb,MAAM,IAAI,KAAK,CAAC,gCAAgC,CAAC,CAAC;IACpD,CAAC;IAED,MAAM,aAAa,GAAG,CAAC,SAAS,EAAE,MAAM,EAAE,WAAW,CAAC,CAAC;IACvD,IAAI,CAAC,aAAa,CAAC,QAAQ,CAAC,OAAO,CAAC,EAAE,CAAC;QACrC,MAAM,IAAI,KAAK,CAAC,2BAA2B,aAAa,CAAC,IAAI,CAAC,IAAI,CAAC,EAAE,CAAC,CAAC;IACzE,CAAC;IAED,MAAM,QAAQ,GAAoB;QAChC;YACE,IAAI,EAAE,MAAM;YACZ,OAAO,EAAE;gBACP,IAAI,EAAE,MAAM;gBACZ,IAAI,EAAE,YAAY,OAAO;;;aAGpB,OAAO,CAAC,WAAW;4BACJ,OAAO;EACjC,KAAK,CAAC,CAAC,CAAC,YAAY,KAAK,EAAE,CAAC,CAAC,CAAC,EAAE;EAChC,OAAO,CAAC,YAAY,CAAC,CAAC,CAAC,gBAAgB,OAAO,CAAC,YAAY,EAAE,CAAC,CAAC,CAAC,EAAE;;;2DAGT,OAAO;;;qDAGb,OAAO;;;;gDAIZ,OAAO;kDACL,OAAO;;;;;;;;;;;;;;kBAcvC,OAAO,+EAA+E;aACjG;SACF;KACF,CAAC;IAEF,OAAO,QAAQ,CAAC;AAClB,CAAC;AAED,MAAM,CAAC,MAAM,uBAAuB,GAAqB;IACvD,MAAM;IACN,OAAO;CACR,CAAC"}

package/dist/prompts/implement-task.d.ts

@@ -0,0 +1,3 @@
+import { PromptDefinition } from './types.js';
+export declare const implementTaskPrompt: PromptDefinition;
+//# sourceMappingURL=implement-task.d.ts.map

package/dist/prompts/implement-task.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"implement-task.d.ts","sourceRoot":"","sources":["../../src/prompts/implement-task.ts"],"names":[],"mappings":"AACA,OAAO,EAAE,gBAAgB,EAAE,MAAM,YAAY,CAAC;AAgL9C,eAAO,MAAM,mBAAmB,EAAE,gBAGjC,CAAC"}