@arimakouyou/spec-workflow-mcp 2.2.7

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,100 @@
+# Tasks Document
+
+## Phase 1: Core Domain Layer
+
+- [ ] 1.1 Create core interfaces and model in src/types/feature.ts, src/models/FeatureModel.ts
+  - File: src/types/feature.ts, src/models/FeatureModel.ts
+  - Define TypeScript interfaces and implement model with validation/CRUD
+  - Purpose: Establish type-safe data layer
+  - _Leverage: src/types/base.ts, src/models/BaseModel.ts, src/utils/validation.ts_
+  - _Requirements: 1.1, 2.1, 2.2_
+  - _TestFocus: Interface contract validation, CRUD success/failure, validation boundaries, relationship integrity_
+  - _Prompt: Role: TypeScript Developer specializing in type systems and data modeling | Task: Create comprehensive TypeScript interfaces and implement model with validation and CRUD operations following requirements 1.1, 2.1, 2.2, extending existing base interfaces and model from src/types/base.ts and src/models/BaseModel.ts | Restrictions: Do not modify existing base interfaces, maintain backward compatibility, follow project naming conventions | Success: All interfaces compile without errors, model extends BaseModel correctly, validation methods implemented, full type coverage for feature requirements_
+
+- [ ] 1.2 Create service interface and implementation in src/services/IFeatureService.ts, src/services/FeatureService.ts
+  - File: src/services/IFeatureService.ts, src/services/FeatureService.ts
+  - Define service contract and implement concrete service using FeatureModel
+  - Add error handling with existing error utilities
+  - Purpose: Provide business logic layer for feature operations
+  - _DependsOn: 1.1_
+  - _Leverage: src/services/IBaseService.ts, src/services/BaseService.ts, src/utils/errorHandler.ts, src/models/FeatureModel.ts_
+  - _Requirements: 3.1, 3.2_
+  - _TestFocus: Service contract compliance, error propagation, business logic edge cases, dependency injection_
+  - _Prompt: Role: Backend Developer with expertise in service layer architecture | Task: Design service interface and implement concrete FeatureService following requirements 3.1 and 3.2, using FeatureModel and extending BaseService patterns with proper error handling | Restrictions: Must implement interface contract exactly, do not bypass model validation, maintain separation of concerns | Success: Interface is well-defined, service implements all methods correctly, robust error handling, business logic is testable_
+
+- [ ] 1.3 Register service in dependency injection container
+  - File: src/utils/di.ts
+  - Register FeatureService in DI container with proper lifetime configuration
+  - Purpose: Enable service injection throughout application
+  - _DependsOn: 1.1, 1.2_
+  - _Leverage: existing DI configuration in src/utils/di.ts_
+  - _Requirements: 3.1_
+  - _TestFocus: Service resolution, dependency chain, lifetime management_
+  - _Prompt: Role: Backend Developer with expertise in dependency injection | Task: Register FeatureService in DI container following requirement 3.1, configuring appropriate lifetime and dependencies using existing patterns | Restrictions: Must follow existing DI patterns, do not create circular dependencies | Success: FeatureService is properly registered and resolvable, dependencies correctly configured_
+
+- [ ] 1.4 Review and commit Phase 1
+  - _PhaseReview: true_
+  - _Prompt: Role: Code reviewer | Task: Review all Phase 1 changes for code quality, consistency, and correctness. Run full test suite and verify all tests pass. Stage and commit with a summary of Phase 1 deliverables. | Success: All tests pass, code review complete, changes committed_
+
+## Phase 2: API Layer
+
+- [ ] 2.1 Create API routing and middleware configuration
+  - File: src/api/featureRoutes.ts, src/middleware/featureMiddleware.ts
+  - Set up routing with authentication and error handling middleware
+  - Purpose: Establish API infrastructure for feature
+  - _Leverage: src/api/baseApi.ts, src/middleware/auth.ts, src/middleware/errorHandler.ts_
+  - _Requirements: 4.1_
+  - _TestFocus: Route registration, middleware chain order, auth enforcement, error response format_
+  - _Prompt: Role: Backend API developer specializing in Express.js | Task: Configure API routes and middleware following requirement 4.1, integrating authentication and error handling from existing middleware | Restrictions: Must maintain middleware order, do not bypass security middleware | Success: Routes properly configured with correct middleware chain, authentication works correctly_
+
+- [ ] 2.2 Implement CRUD endpoints with request validation
+  - File: src/controllers/FeatureController.ts
+  - Create API endpoints with input validation
+  - Purpose: Expose feature operations via REST API
+  - _Leverage: src/controllers/BaseController.ts, src/utils/validation.ts_
+  - _Requirements: 4.2, 4.3_
+  - _TestFocus: CRUD endpoint responses, input validation rejection, HTTP status codes, error payloads_
+  - _Prompt: Role: Full-stack Developer with expertise in API development | Task: Implement CRUD endpoints following requirements 4.2 and 4.3, extending BaseController patterns with request validation | Restrictions: Must validate all inputs, follow existing controller patterns, ensure proper HTTP status codes | Success: All CRUD operations work correctly, request validation prevents invalid data_
+
+- [ ] 2.3 Review and commit Phase 2
+  - _PhaseReview: true_
+  - _Prompt: Role: Code reviewer | Task: Review all Phase 2 changes for API design quality, security, and correctness. Run full test suite. Stage and commit with a summary of Phase 2 deliverables. | Success: All tests pass, API endpoints reviewed, changes committed_
+
+## Phase 3: Frontend Components
+
+- [ ] 3.1 Create base UI components
+  - File: src/components/feature/FeatureList.tsx, src/components/feature/FeatureForm.tsx
+  - Implement reusable components with styling and theming
+  - Purpose: Build UI building blocks for feature
+  - _Leverage: src/components/BaseComponent.tsx, src/styles/theme.ts_
+  - _Requirements: 5.1_
+  - _TestFocus: Component rendering, prop handling, accessibility, theme integration_
+  - _Prompt: Role: Frontend Developer specializing in React | Task: Create reusable UI components following requirement 5.1, extending BaseComponent patterns and using existing theme system | Restrictions: Must use existing theme variables, follow component patterns, ensure accessibility | Success: Components are reusable, properly themed, accessible and responsive_
+
+- [ ] 3.2 Implement feature-specific components with state and API integration
+  - File: src/components/feature/FeaturePage.tsx, src/hooks/useFeature.ts
+  - Create feature page with state management connected to API
+  - Purpose: Complete frontend user experience
+  - _Leverage: src/hooks/useApi.ts, src/components/BaseComponent.tsx_
+  - _Requirements: 5.2, 5.3_
+  - _TestFocus: State transitions, API integration, loading/error states, user interactions_
+  - _Prompt: Role: React Developer with expertise in state management | Task: Implement feature page and custom hook following requirements 5.2 and 5.3, using API hooks and extending BaseComponent patterns | Restrictions: Must use existing state management patterns, handle loading and error states | Success: Components fully functional with proper state, API integration works smoothly_
+
+- [ ] 3.3 Review and commit Phase 3
+  - _PhaseReview: true_
+  - _Prompt: Role: Code reviewer | Task: Review all Phase 3 changes for component quality, accessibility, and UX. Run full test suite. Stage and commit with a summary of Phase 3 deliverables. | Success: All tests pass, UI reviewed, changes committed_
+
+## Phase 4: Integration
+
+- [ ] 4.1 End-to-end integration and verification
+  - File: tests/e2e/feature.e2e.ts
+  - Write E2E tests covering critical user journeys across all layers
+  - Purpose: Verify full-stack integration works correctly
+  - _Leverage: tests/helpers/testUtils.ts, tests/fixtures/data.ts_
+  - _Requirements: All_
+  - _TestFocus: User journey flows, cross-layer data integrity, error recovery paths_
+  - _Prompt: Role: QA Engineer with expertise in E2E testing | Task: Implement end-to-end tests covering all critical user journeys across all layers | Restrictions: Must test real user workflows, ensure tests are maintainable | Success: E2E tests cover critical journeys, tests run reliably_
+
+- [ ] 4.2 Final review and commit Phase 4
+  - _PhaseReview: true_
+  - _Prompt: Role: Code reviewer | Task: Final review of all integration work. Run full test suite including E2E. Stage and commit with a summary of all deliverables. Clean up any remaining issues. | Success: All tests pass, full integration verified, final commit made_

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/markdown/templates/test-design-template.md

@@ -0,0 +1,221 @@
+# Test Design Document
+
+## Test Strategy Overview
+
+### Testing Philosophy
+[このフィーチャーのテスト全体方針を記述する。TDD を前提とし、品質保証の考え方を明記]
+
+### Test Pyramid
+[UT / IT / E2E のバランスと優先順位を定義する]
+
+| Level | 目的 | 実行タイミング | 想定件数 |
+|-------|------|--------------|---------|
+| Unit Test (UT) | コンポーネント単体の契約検証 | TDD RED フェーズ | [N] |
+| Integration Test (IT) | コンポーネント間結合の検証 | Phase Review | [N] |
+| E2E Test | ユーザージャーニーの検証 | Final E2E Gate | [N] |
+
+### Test Environment Requirements
+
+- **Container Runtime:** Docker / Podman (必須)
+- **テストフレームワーク:** [例: cargo test + mockall, jest + testcontainers, pytest]
+- **テスト用コンテナ:**
+
+| Service | Image | Purpose |
+|---------|-------|---------|
+| DB | [例: postgres:16-alpine] | テスト用 DB (testcontainers) |
+| [Other] | [image] | [purpose] |
+
+---
+
+## Unit Test Specifications
+
+### Component: [ComponentName1]
+- **Target:** [テスト対象のモジュール/ファイルパス]
+- **Dependencies to Mock:** [モック対象の依存コンポーネント]
+
+#### UT-1.1: [テストケース名]
+- **Category:** Happy Path
+- **Preconditions:** [事前条件]
+- **Input:** [入力データ]
+- **Expected Output:** [期待結果]
+- **Verification:** [検証方法（assert 内容等）]
+
+#### UT-1.2: [テストケース名]
+- **Category:** Boundary Values
+- **Preconditions:** [事前条件]
+- **Input:** [入力データ（境界値）]
+- **Expected Output:** [期待結果]
+- **Verification:** [検証方法]
+
+#### UT-1.3: [テストケース名]
+- **Category:** Error Handling
+- **Preconditions:** [事前条件]
+- **Input:** [異常入力]
+- **Expected Output:** [エラー種別・メッセージ]
+- **Verification:** [検証方法]
+
+#### UT-1.4: [テストケース名]
+- **Category:** Edge Cases
+- **Preconditions:** [事前条件]
+- **Input:** [エッジケース入力]
+- **Expected Output:** [期待結果]
+- **Verification:** [検証方法]
+
+### Component: [ComponentName2]
+- **Target:** [テスト対象のモジュール/ファイルパス]
+- **Dependencies to Mock:** [モック対象の依存コンポーネント]
+
+#### UT-2.1: [テストケース名]
+- **Category:** Happy Path
+- **Preconditions:** [事前条件]
+- **Input:** [入力データ]
+- **Expected Output:** [期待結果]
+- **Verification:** [検証方法]
+
+[必要なコンポーネント分だけ繰り返す]
+
+---
+
+## Integration Test Specifications
+
+### IT-1: [統合テストシナリオ名]
+- **Components:** [関与するコンポーネント一覧]
+- **Interaction:** [テスト対象の相互作用の説明]
+- **Technology:**
+  - **DB:** testcontainers (PostgreSQL) | docker-compose.test.yml
+  - **External API:** wiremock container | trait-based DI | nock
+  - **Setup:** migration + seed data via container
+- **Preconditions:** [事前条件（DB状態、外部サービス状態等）]
+- **Steps:**
+  1. [操作手順1]
+  2. [操作手順2]
+  3. [操作手順3]
+- **Expected Result:** [期待される最終結果]
+- **Verification Points:**
+  - [検証ポイント1: 例 — DB にレコードが挿入されていること]
+  - [検証ポイント2: 例 — レスポンスの HTTP ステータスが 201 であること]
+
+### IT-2: [統合テストシナリオ名]
+- **Components:** [関与するコンポーネント一覧]
+- **Interaction:** [テスト対象の相互作用の説明]
+- **Technology:**
+  - **DB:** testcontainers (PostgreSQL) | docker-compose.test.yml
+  - **External API:** wiremock container | trait-based DI | nock
+  - **Setup:** migration + seed data via container
+- **Preconditions:** [事前条件]
+- **Steps:**
+  1. [操作手順1]
+  2. [操作手順2]
+- **Expected Result:** [期待される最終結果]
+- **Verification Points:**
+  - [検証ポイント1]
+  - [検証ポイント2]
+
+[必要なシナリオ分だけ繰り返す]
+
+---
+
+## E2E Test Specifications
+
+### E2E-1: [ユーザージャーニー名]
+- **User Story:** [対応するユーザーストーリー（REQ-N の参照）]
+- **Test Type:** API E2E | Browser E2E | Full-Stack E2E
+- **Technology:**
+  - **Runner:** Playwright | Cypress | reqwest | supertest
+  - **App Container:** docker-compose up で全サービス起動
+  - **DB Setup:** migration + seed via container
+  - **Browser:** Chromium | Firefox | WebKit (Browser E2E のみ)
+- **Preconditions:** [システム状態の前提条件]
+- **Scenario Steps:**
+  1. [ユーザー操作1] → [期待されるシステム応答]
+  2. [ユーザー操作2] → [期待されるシステム応答]
+  3. [ユーザー操作3] → [期待されるシステム応答]
+- **Success Criteria:** [最終的な成功判定条件]
+- **Failure Scenarios:**
+  - [想定される失敗パターン1 → 期待される挙動]
+  - [想定される失敗パターン2 → 期待される挙動]
+
+### E2E-2: [ユーザージャーニー名]
+- **User Story:** [対応するユーザーストーリー]
+- **Test Type:** API E2E | Browser E2E | Full-Stack E2E
+- **Technology:**
+  - **Runner:** Playwright | Cypress | reqwest | supertest
+  - **App Container:** docker-compose up で全サービス起動
+  - **DB Setup:** migration + seed via container
+  - **Browser:** Chromium | Firefox | WebKit (Browser E2E のみ)
+- **Preconditions:** [前提条件]
+- **Scenario Steps:**
+  1. [操作1] → [応答]
+  2. [操作2] → [応答]
+- **Success Criteria:** [成功判定条件]
+- **Failure Scenarios:**
+  - [失敗パターン → 期待される挙動]
+
+[必要なジャーニー分だけ繰り返す]
+
+---
+
+## Requirements-Test Traceability Matrix
+
+| Requirement ID | UT Specs | IT Specs | E2E Specs | Notes |
+|---------------|----------|----------|-----------|-------|
+| REQ-1 | UT-1.1, UT-1.2 | IT-1 | E2E-1 | |
+| REQ-2 | UT-2.1 | IT-2 | E2E-1, E2E-2 | |
+| REQ-N | | | | |
+
+**カバレッジ基準**: 全 Requirement ID に対して、最低1つの UT と、関連する IT または E2E が紐づいていること。
+
+---
+
+## Test Data Requirements
+
+### Shared Test Fixtures
+[テスト間で共有するテストデータの定義]
+
+| Fixture Name | Description | Used By |
+|-------------|-------------|---------|
+| [fixture1] | [説明] | UT-1.1, IT-1 |
+| [fixture2] | [説明] | UT-2.1, E2E-1 |
+
+### Test Data Generation Strategy
+[テストデータの生成方針: ファクトリパターン、ビルダーパターン、フィクスチャファイル等]
+
+- **ユニットテスト**: [例 — テスト内でインラインで生成、ビルダーパターン使用]
+- **統合テスト**: [例 — testcontainers で DB コンテナ起動 + マイグレーション + シードデータ]
+- **E2Eテスト**: [例 — docker-compose.test.yml で全サービス起動、API 経由でデータ投入]
+
+---
+
+## E2E Test Infrastructure
+
+### Project Type Detection
+
+| 検出条件 | テストランナー | DB 戦略 |
+|----------|-------------|---------|
+| `Cargo.toml` + `[package.metadata.leptos]` | Playwright + reqwest | testcontainers |
+| `Cargo.toml` + axum/actix-web | reqwest | testcontainers |
+| `package.json` + React/Next.js | Playwright | testcontainers / docker-compose |
+| `package.json` + Express/Fastify | supertest + Playwright | testcontainers |
+
+### Container Test Setup
+
+- **IT (統合テスト)**: testcontainers でテストプロセス内からコンテナを起動・破棄。テストごとにクリーンな状態を保証
+- **E2E**: docker-compose.test.yml で全サービスを起動後にテスト実行。終了後にコンテナ停止・クリーンアップ
+
+### docker-compose.test.yml
+[テスト専用の compose 定義]
+- ポート衝突回避: 本番用ポートからオフセット（例: 5432 → 15432）
+- DB 初期化: テスト用マイグレーション + シードデータ
+- ボリューム: tmpfs で永続化しない（テストごとにクリーン）
+
+### Test Server Setup
+[テスト時のアプリケーションサーバ起動方法]
+- `docker-compose -f docker-compose.test.yml up -d`
+- ヘルスチェック待機後にテスト開始
+
+### Browser Test Configuration (フロントエンドがある場合)
+[Playwright / Cypress の設定]
+- **baseURL:** [例: http://localhost:13000]
+- **viewport:** [例: 1280x720]
+- **timeout:** [例: 30000ms]
+- **screenshot:** on failure

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;AAqG9C,eAAO,MAAM,gBAAgB,EAAE,gBAG9B,CAAC"}

package/dist/prompts/create-spec.js

@@ -0,0 +1,97 @@
+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, test-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, test-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', 'test-design', 'tasks'];
+    // ダッシュボードのプレビュー用サンプルコンテキストではバリデーションをスキップ
+    const isPreviewContext = context.projectPath === '{{projectPath}}';
+    if (!isPreviewContext && !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
+- Test design documents define HOW TO TEST the feature (UT/IT/E2E specifications)
+- Tasks documents break down implementation into actionable steps
+- Sequence: Requirements → Design → Test Design → Tasks
+- 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,kLAAkL;IAC/L,SAAS,EAAE;QACT;YACE,IAAI,EAAE,UAAU;YAChB,WAAW,EAAE,qEAAqE;YAClF,QAAQ,EAAE,IAAI;SACf;QACD;YACE,IAAI,EAAE,cAAc;YACpB,WAAW,EAAE,yEAAyE;YACtF,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,aAAa,EAAE,OAAO,CAAC,CAAC;IACzE,yCAAyC;IACzC,MAAM,gBAAgB,GAAG,OAAO,CAAC,WAAW,KAAK,iBAAiB,CAAC;IACnE,IAAI,CAAC,gBAAgB,IAAI,CAAC,aAAa,CAAC,QAAQ,CAAC,YAAY,CAAC,EAAE,CAAC;QAC/D,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;;;;;;;;;;;EAWrE,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"}