@madmatt112org/spec-workflow-mcp 3.0.0

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-decomposition.d.ts

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

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

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

package/dist/prompts/create-decomposition.js

@@ -0,0 +1,122 @@
+const prompt = {
+    name: 'create-decomposition',
+    title: 'Create Spec Decomposition',
+    description: 'Guide for decomposing steering documents into a complete set of specs. Reads product.md, tech.md, and structure.md, then produces a spec breakdown with dependency ordering, cross-spec conventions, and open questions.',
+    arguments: [
+        {
+            name: 'researchMode',
+            description: 'If "true", research current SDD literature instead of using baked-in principles. Default: false (use baked-in methodology).',
+            required: false
+        }
+    ]
+};
+async function handler(args, context) {
+    const researchMode = args.researchMode === 'true' || args.researchMode === true;
+    const methodologyInstruction = researchMode
+        ? `**Methodology — Research Mode:**
+Before decomposing, search the web for current best practices in spec-driven development
+decomposition (as of 2025-2026). Look for guidance on:
+- How to size specs / features for AI-assisted development
+- Vertical slicing vs. horizontal layering
+- INVEST criteria applied at the feature/spec level
+- The reviewability heuristic for spec sizing
+Synthesize what you find into principles, then apply them to the steering docs.`
+        : `**Methodology — Baked-in Principles:**
+Call the \`decomposition-guide\` tool to load the spec decomposition methodology. Read and
+follow the principles it provides.`;
+    const messages = [
+        {
+            role: 'user',
+            content: {
+                type: 'text',
+                text: `Create a spec decomposition for this project by analyzing the steering documents.
+
+**Context:**
+- Project: ${context.projectPath}
+${context.dashboardUrl ? `- Dashboard: ${context.dashboardUrl}` : ''}
+
+## Step 1: Load Inputs
+
+1. Read all steering docs from \`.spec-workflow/steering/\`:
+   - \`product.md\` — project vision, goals, features
+   - \`tech.md\` — technology decisions, architecture
+   - \`structure.md\` — codebase organization, conventions
+
+   If any steering doc is missing, inform the user and ask whether to proceed without it
+   or create it first.
+
+2. Ask the user: **"Is there existing code in this project that I should account for?"**
+   - If yes: scan the codebase to understand what is already built, what patterns exist,
+     and what functionality is in place. Factor this into the decomposition.
+   - If no: proceed assuming a greenfield project.
+
+## Step 2: Load Methodology
+
+${methodologyInstruction}
+
+## Step 3: Decompose
+
+Apply the methodology to the steering docs. Produce a decomposition that includes:
+
+- **Per-spec entries**: For each spec, describe:
+  - Name (kebab-case)
+  - What it delivers (concrete capabilities)
+  - End-to-end verification (how to prove the spec is complete)
+  - Dependencies on other specs
+  - Notes and design considerations specific to this spec
+
+- **Dependency graph**: A mermaid DAG showing spec ordering and relationships.
+
+- **Cross-spec conventions**: Shared patterns, schema evolution rules, API conventions,
+  or other project-wide decisions that apply across multiple specs.
+
+- **What is NOT a spec**: Items from the steering docs that lack independent deliverable
+  value. For each, document which spec absorbs it and why.
+
+- **Open questions**: Ambiguities, design decisions, or scope boundary questions that
+  surfaced during decomposition.
+
+Adapt the structure to fit the project — these sections are guidance, not a rigid schema.
+
+## Step 4: Open Questions
+
+**IMPORTANT**: Before finalizing the decomposition, present all open questions to the user.
+For each question:
+- Explain the question and why it matters for spec boundaries or ordering
+- Suggest options if possible
+- Ask the user for guidance: a specific answer, a directive to leave it unresolved,
+  or an indication that it should be resolved during a specific spec's design phase
+
+Wait for user input before finalizing.
+
+## Step 5: Save
+
+Save the completed decomposition to:
+\`.spec-workflow/spec-decomposition/decomposition.md\`
+
+## Step 6: Scaffold (Optional)
+
+Ask the user: **"Would you like me to create the spec directory structure?"**
+
+If yes, create \`.spec-workflow/specs/{spec-name}/\` for each spec in the decomposition,
+with a \`.gitkeep\` file in each.
+
+## Step 7: Next Steps
+
+Inform the user:
+- The decomposition is a living document — update it as individual specs are built and
+  design phases reveal new information.
+- To run an adversarial review of the decomposition, use the \`adversarial-review\` tool
+  with \`phase: 'decomposition'\`.
+- To start building specs, use the standard spec workflow: \`create-spec\` prompt with
+  the first spec from the dependency order.`
+            }
+        }
+    ];
+    return messages;
+}
+export const createDecompositionPrompt = {
+    prompt,
+    handler
+};
+//# sourceMappingURL=create-decomposition.js.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"create-decomposition.js","sourceRoot":"","sources":["../../src/prompts/create-decomposition.ts"],"names":[],"mappings":"AAIA,MAAM,MAAM,GAAW;IACrB,IAAI,EAAE,sBAAsB;IAC5B,KAAK,EAAE,2BAA2B;IAClC,WAAW,EAAE,0NAA0N;IACvO,SAAS,EAAE;QACT;YACE,IAAI,EAAE,cAAc;YACpB,WAAW,EAAE,6HAA6H;YAC1I,QAAQ,EAAE,KAAK;SAChB;KACF;CACF,CAAC;AAEF,KAAK,UAAU,OAAO,CAAC,IAAyB,EAAE,OAAoB;IACpE,MAAM,YAAY,GAAG,IAAI,CAAC,YAAY,KAAK,MAAM,IAAI,IAAI,CAAC,YAAY,KAAK,IAAI,CAAC;IAEhF,MAAM,sBAAsB,GAAG,YAAY;QACzC,CAAC,CAAC;;;;;;;gFAO0E;QAC5E,CAAC,CAAC;;mCAE6B,CAAC;IAElC,MAAM,QAAQ,GAAoB;QAChC;YACE,IAAI,EAAE,MAAM;YACZ,OAAO,EAAE;gBACP,IAAI,EAAE,MAAM;gBACZ,IAAI,EAAE;;;aAGD,OAAO,CAAC,WAAW;EAC9B,OAAO,CAAC,YAAY,CAAC,CAAC,CAAC,gBAAgB,OAAO,CAAC,YAAY,EAAE,CAAC,CAAC,CAAC,EAAE;;;;;;;;;;;;;;;;;;;EAmBlE,sBAAsB;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;4CAyDoB;aACrC;SACF;KACF,CAAC;IAEF,OAAO,QAAQ,CAAC;AAClB,CAAC;AAED,MAAM,CAAC,MAAM,yBAAyB,GAAqB;IACzD,MAAM;IACN,OAAO;CACR,CAAC"}

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"}