musubix 3.5.1 → 3.6.1

package/.github/skills/musubix-domain-inference/SKILL.md

@@ -0,0 +1,196 @@
+---
+name: musubix-domain-inference
+description: Guide for automatic domain detection and component inference. Use this when asked to identify the domain of a project and get recommended components for that domain.
+license: MIT
+---
+
+# MUSUBIX Domain Inference Skill
+
+This skill guides you through automatic domain detection and component recommendations.
+
+## Overview
+
+MUSUBIX supports **62 domains** with **224 predefined components**. The domain inference system automatically:
+
+1. Detects project domain from requirements/descriptions
+2. Recommends optimal components for that domain
+3. Suggests architecture patterns
+
+## Supported Domains (62)
+
+### Business (8)
+| Domain | Description | Key Components |
+|--------|-------------|----------------|
+| ecommerce | EC・通販 | CartService, ProductCatalog, OrderProcessor |
+| finance | 金融 | AccountService, TransactionManager, LedgerService |
+| crm | 顧客管理 | CustomerService, LeadManager, OpportunityTracker |
+| hr | 人事 | EmployeeService, PayrollCalculator, AttendanceTracker |
+| marketing | マーケティング | CampaignManager, AudienceSegmenter, AnalyticsService |
+| inventory | 在庫管理 | StockManager, ReorderService, WarehouseController |
+| payment | 決済 | PaymentGateway, RefundProcessor, InvoiceGenerator |
+| subscription | サブスク | PlanManager, BillingService, RenewalProcessor |
+
+### Healthcare (3)
+| Domain | Description | Key Components |
+|--------|-------------|----------------|
+| healthcare | ヘルスケア | PatientService, DiagnosticService, AppointmentManager |
+| pharmacy | 薬局 | PrescriptionManager, MedicineInventory, DosageCalculator |
+| veterinary | 動物病院 | PetService, VetScheduleService, VaccinationTracker |
+
+### Service (20+)
+| Domain | Description | Key Components |
+|--------|-------------|----------------|
+| booking | 予約 | ReservationService, SlotManager, AvailabilityChecker |
+| hotel | ホテル | RoomService, CheckInManager, HousekeepingScheduler |
+| restaurant | 飲食店 | MenuManager, TableService, KitchenOrderSystem |
+| gym | フィットネス | MembershipService, ClassScheduler, TrainerAssignment |
+| delivery | 配送 | DeliveryService, RouteOptimizer, TrackingManager |
+| parking | 駐車場 | SpaceManager, EntryExitController, FeeCalculator |
+
+### Technology (8)
+| Domain | Description | Key Components |
+|--------|-------------|----------------|
+| iot | IoT | DeviceManager, TelemetryProcessor, AlertService |
+| security | セキュリティ | AuthService, PermissionManager, AuditLogger |
+| ai | AI | ModelService, InferenceEngine, TrainingPipeline |
+| analytics | 分析 | ReportGenerator, MetricsCollector, DashboardService |
+
+## Domain Detection
+
+### Automatic Detection
+
+MUSUBIX analyzes text for domain keywords:
+
+```typescript
+import { domainDetector } from '@nahisaho/musubix-core';
+
+const result = domainDetector.detect(`
+  ペットの予約管理システムを作りたい。
+  獣医師のスケジュール管理と、ワクチン接種記録も必要。
+`);
+
+// Result:
+// {
+//   primaryDomain: { id: 'veterinary', name: 'Veterinary', nameJa: '動物病院' },
+//   confidence: 0.92,
+//   matchedKeywords: ['ペット', '獣医', 'ワクチン', '予約'],
+//   suggestedComponents: ['PetService', 'ReservationService', 'VetScheduleService']
+// }
+```
+
+### CLI Usage
+
+```bash
+# Analyze requirements file
+npx musubix design patterns --detect-domain storage/specs/REQ-001.md
+
+# Get component recommendations
+npx musubix design generate storage/specs/REQ-001.md --infer-components
+```
+
+## Component Inference
+
+### Domain-Specific Components
+
+Each domain has predefined components with:
+- **Type**: Service, Repository, Controller, Factory, etc.
+- **Layer**: Presentation, Application, Domain, Infrastructure
+- **Dependencies**: Required collaborators
+- **Patterns**: Recommended design patterns
+- **Methods**: Domain-specific operations
+
+### Example: Veterinary Domain
+
+```typescript
+const veterinaryComponents = [
+  {
+    name: 'PetService',
+    type: 'service',
+    layer: 'application',
+    description: 'ペット管理のビジネスロジック',
+    dependencies: ['PetRepository', 'PetHistoryRepository'],
+    patterns: ['Service'],
+    methods: [
+      { name: 'register', returnType: 'Promise<Pet>' },
+      { name: 'update', returnType: 'Promise<Pet>' },
+      { name: 'getByOwner', returnType: 'Promise<Pet[]>' },
+      { name: 'getHistory', returnType: 'Promise<PetHistory[]>' },
+    ]
+  },
+  {
+    name: 'ReservationService',
+    type: 'service',
+    layer: 'application',
+    methods: [
+      { name: 'create', returnType: 'Promise<Reservation>' },
+      { name: 'confirm', returnType: 'Promise<Reservation>' },
+      { name: 'cancel', returnType: 'Promise<Reservation>' },
+      { name: 'getAvailableSlots', returnType: 'Promise<TimeSlot[]>' },
+    ]
+  },
+  // ...more components
+];
+```
+
+## Architecture Recommendations
+
+Based on domain, MUSUBIX recommends:
+
+| Domain Category | Architecture Style | Scaling Strategy |
+|-----------------|-------------------|------------------|
+| Business | Layered + DDD | Vertical with caching |
+| Technology | Microservices | Horizontal scaling |
+| Healthcare | Layered + Audit | Vertical with compliance |
+| Service | Layered | Vertical with caching |
+
+## Multi-Domain Projects
+
+For projects spanning multiple domains:
+
+```typescript
+const result = domainDetector.detect(`
+  ECサイトで商品を販売し、配送追跡も行いたい。
+  在庫管理とサブスクリプション機能も必要。
+`);
+
+// Result:
+// {
+//   primaryDomain: { id: 'ecommerce' },
+//   secondaryDomains: [
+//     { id: 'delivery' },
+//     { id: 'inventory' },
+//     { id: 'subscription' }
+//   ]
+// }
+```
+
+## Using in Design Documents
+
+```markdown
+# DES-SHOP-001: ECサイト設計
+
+## ドメイン分析
+- **主ドメイン**: ecommerce
+- **副ドメイン**: inventory, payment, delivery
+
+## 推奨コンポーネント
+
+### ecommerce ドメイン
+| コンポーネント | 種別 | 責務 |
+|---------------|------|------|
+| CartService | Service | カート管理 |
+| ProductCatalog | Service | 商品カタログ |
+| OrderProcessor | Service | 注文処理 |
+
+### inventory ドメイン
+| コンポーネント | 種別 | 責務 |
+|---------------|------|------|
+| StockManager | Service | 在庫管理 |
+| ReorderService | Service | 発注管理 |
+```
+
+## Related Skills
+
+- `musubix-c4-design` - Create architecture with inferred components
+- `musubix-code-generation` - Generate code for components
+- `musubix-sdd-workflow` - Full workflow with domain awareness

package/.github/skills/musubix-ears-validation/SKILL.md

@@ -0,0 +1,161 @@
+---
+name: musubix-ears-validation
+description: Guide for validating and creating EARS-format requirements. Use this when asked to write requirements, validate requirement syntax, or convert natural language to EARS format.
+license: MIT
+---
+
+# MUSUBIX EARS Validation Skill
+
+This skill helps you create and validate requirements using EARS (Easy Approach to Requirements Syntax) format.
+
+## EARS Pattern Reference
+
+### 1. Ubiquitous Pattern
+**Use for**: Requirements that must always be satisfied.
+
+**Syntax**:
+```
+THE [system name] SHALL [requirement]
+```
+
+**Example**:
+```markdown
+THE AuthService SHALL authenticate users with valid credentials.
+```
+
+### 2. Event-Driven Pattern
+**Use for**: Requirements triggered by specific events.
+
+**Syntax**:
+```
+WHEN [trigger event], THE [system name] SHALL [response]
+```
+
+**Example**:
+```markdown
+WHEN a user submits login credentials, THE AuthService SHALL validate the credentials within 2 seconds.
+```
+
+### 3. State-Driven Pattern
+**Use for**: Requirements that apply while in a specific state.
+
+**Syntax**:
+```
+WHILE [system state], THE [system name] SHALL [behavior]
+```
+
+**Example**:
+```markdown
+WHILE the system is in maintenance mode, THE API SHALL return 503 Service Unavailable.
+```
+
+### 4. Unwanted Behavior Pattern
+**Use for**: Behaviors that must be prevented.
+
+**Syntax**:
+```
+THE [system name] SHALL NOT [unwanted behavior]
+```
+
+**Example**:
+```markdown
+THE AuthService SHALL NOT store passwords in plain text.
+```
+
+### 5. Optional Pattern
+**Use for**: Conditional requirements.
+
+**Syntax**:
+```
+IF [condition], THEN THE [system name] SHALL [response]
+```
+
+**Example**:
+```markdown
+IF two-factor authentication is enabled, THEN THE AuthService SHALL require a verification code.
+```
+
+## Validation Checklist
+
+When validating EARS requirements, check:
+
+- [ ] **Pattern Compliance**: Does it follow one of the 5 EARS patterns?
+- [ ] **System Name**: Is the system/component clearly identified?
+- [ ] **SHALL Keyword**: Is "SHALL" used for mandatory requirements?
+- [ ] **Measurable**: Is the requirement testable and measurable?
+- [ ] **Atomic**: Does it describe a single requirement?
+- [ ] **No Ambiguity**: Is the language clear and unambiguous?
+
+## CLI Commands
+
+```bash
+# Validate EARS syntax
+npx musubix requirements validate <file>
+
+# Convert natural language to EARS
+npx musubix requirements analyze <file>
+
+# Map to ontology
+npx musubix requirements map <file>
+```
+
+## Conversion Examples
+
+### Natural Language → EARS
+
+**Input**: "Users should be able to login"
+
+**Output**:
+```markdown
+THE AuthenticationModule SHALL authenticate users with valid credentials.
+```
+
+**Input**: "Show error when password is wrong"
+
+**Output**:
+```markdown
+WHEN invalid credentials are provided, THE AuthenticationModule SHALL display an error message.
+```
+
+**Input**: "Don't allow SQL injection"
+
+**Output**:
+```markdown
+THE InputValidator SHALL NOT accept input containing SQL injection patterns.
+```
+
+## Priority Levels
+
+| Priority | Description | Usage |
+|----------|-------------|-------|
+| **P0** | 必須 (Must Have) | Release blocker |
+| **P1** | 重要 (Should Have) | Implement if possible |
+| **P2** | 任意 (Nice to Have) | Time permitting |
+
+## Requirement Document Template
+
+```markdown
+### REQ-[CATEGORY]-[NUMBER]: [Title]
+
+**種別**: [UBIQUITOUS|EVENT-DRIVEN|STATE-DRIVEN|UNWANTED|OPTIONAL]
+**優先度**: [P0|P1|P2]
+
+**要件**:
+[EARS形式の要件文]
+
+**検証方法**: [Unit Test|Integration Test|E2E Test|Manual]
+**受入基準**:
+- [ ] Criterion 1
+- [ ] Criterion 2
+
+**トレーサビリティ**: DES-XXX, TEST-XXX
+**憲法準拠**: Article IV (EARS Format)
+```
+
+## Common Mistakes to Avoid
+
+1. ❌ Using "should" instead of "SHALL"
+2. ❌ Combining multiple requirements in one statement
+3. ❌ Vague or unmeasurable criteria
+4. ❌ Missing system name
+5. ❌ Using implementation details in requirements

package/.github/skills/musubix-sdd-workflow/SKILL.md

@@ -0,0 +1,217 @@
+---
+name: musubix-sdd-workflow
+description: Guide for MUSUBIX SDD (Specification-Driven Development) workflow. Use this when asked to develop features using MUSUBIX methodology, create requirements, designs, or implement code following the 9 constitutional articles.
+license: MIT
+---
+
+# MUSUBIX SDD Workflow Skill
+
+This skill guides you through the complete SDD workflow for MUSUBIX projects.
+
+## Prerequisites
+
+Before starting any development task:
+
+1. Read `steering/` directory for project context
+2. Check `steering/rules/constitution.md` for the 9 constitutional articles
+3. Review existing specs in `storage/specs/`
+
+## Complete Workflow
+
+### Phase 1: Requirements Definition
+
+#### Step 1: Create Requirements Document (Article IV - EARS Format)
+
+Create requirements using EARS patterns:
+
+```markdown
+# REQ-[CATEGORY]-[NUMBER]
+
+**種別**: [UBIQUITOUS|EVENT-DRIVEN|STATE-DRIVEN|UNWANTED|OPTIONAL]
+**優先度**: [P0|P1|P2]
+
+**要件**:
+[EARS形式の要件文]
+
+**トレーサビリティ**: DES-XXX, TEST-XXX
+```
+
+EARS Patterns:
+- **Ubiquitous**: `THE [system] SHALL [requirement]`
+- **Event-driven**: `WHEN [event], THE [system] SHALL [response]`
+- **State-driven**: `WHILE [state], THE [system] SHALL [response]`
+- **Unwanted**: `THE [system] SHALL NOT [behavior]`
+- **Optional**: `IF [condition], THEN THE [system] SHALL [response]`
+
+#### Step 2-3: Requirements Review Loop
+
+Review requirements for:
+- EARS format compliance
+- Completeness and clarity
+- Testability
+- Traceability readiness
+
+**Repeat until no issues remain.**
+
+### Phase 2: Design
+
+#### Step 4: Create Design Document (Article VII - Design Patterns)
+
+Create C4 model design documents:
+
+1. **Context Level**: System boundaries and external actors
+2. **Container Level**: Technology choices and container composition
+3. **Component Level**: Internal structure of containers
+4. **Code Level**: Implementation details
+
+Design document template:
+```markdown
+# DES-[CATEGORY]-[NUMBER]
+
+## トレーサビリティ
+- 要件: REQ-XXX
+
+## C4モデル
+### Level 2: Container
+[PlantUML diagram]
+
+## コンポーネント設計
+[Component details]
+```
+
+#### Step 5-6: Design Review Loop
+
+Review design for:
+- Requirement coverage
+- SOLID principles compliance
+- Design pattern appropriateness
+- Traceability to requirements
+
+**Repeat until no issues remain.**
+
+### Phase 3: Task Decomposition
+
+#### Step 7: Generate Tasks
+
+Generate implementation tasks from design:
+
+```markdown
+# TSK-[CATEGORY]-[NUMBER]
+
+## 関連設計: DES-XXX
+## 関連要件: REQ-XXX
+
+## タスク内容
+[Implementation task description]
+
+## 受入基準
+- [ ] Criterion 1
+- [ ] Criterion 2
+
+## 見積もり
+[4時間以内を推奨]
+```
+
+#### Step 8-9: Task Review Loop
+
+Review tasks for:
+- Appropriate granularity (≤4 hours)
+- Clear acceptance criteria
+- Complete traceability chain
+
+**Repeat until no issues remain.**
+
+### Phase 4: Implementation
+
+#### Step 10: Coding & Unit Testing (Article III - Test-First)
+
+For each task, follow Red-Green-Blue cycle:
+
+1. **Red**: Write failing test first
+2. **Green**: Write minimal code to pass
+3. **Blue**: Refactor while keeping tests green
+
+Add requirement IDs in code comments:
+```typescript
+/**
+ * @see REQ-INT-001 - Neuro-Symbolic Integration
+ */
+```
+
+#### Step 11: Integration Testing
+
+When required by the task:
+- Run integration tests
+- Verify component interactions
+- Ensure end-to-end flows work correctly
+
+### Phase 5: Documentation & Completion
+
+#### Step 12: Update CHANGELOG.md
+
+Document all changes:
+- New features
+- Bug fixes
+- Breaking changes
+- Migration notes
+
+#### Step 13: Update Other Documentation
+
+If necessary, update:
+- README.md
+- USER-GUIDE.md
+- API-REFERENCE.md
+- AGENTS.md
+
+#### Step 14: Git Commit & Push
+
+```bash
+git add .
+git commit -m "feat/fix/chore: description"
+git push
+```
+
+## Traceability Validation (Article V)
+
+Ensure 100% traceability throughout:
+```
+REQ-* → DES-* → TSK-* → Code → Test
+```
+
+## CLI Commands
+
+```bash
+# Requirements
+npx musubix requirements analyze <file>
+npx musubix requirements validate <file>
+
+# Design
+npx musubix design generate <file>
+npx musubix design patterns <context>
+npx musubix design traceability            # REQ↔DES traceability (v3.1.0)
+
+# Code Generation
+npx musubix codegen generate <file>
+npx musubix codegen status <spec>          # Status transition code (v3.1.0)
+
+# Scaffolding
+npx musubix scaffold domain-model <name>
+npx musubix scaffold domain-model <name> -v "Price,Email"  # Value Objects (v3.1.0)
+npx musubix scaffold domain-model <name> -s "Order,Task"   # Status machines (v3.1.0)
+
+# Traceability
+npx musubix trace matrix
+npx musubix trace validate
+```
+
+## Constitutional Articles Checklist
+
+- [ ] **Article I**: Library-First - Is this a standalone library?
+- [ ] **Article II**: CLI Interface - Does it expose CLI?
+- [ ] **Article III**: Test-First - Are tests written first?
+- [ ] **Article IV**: EARS Format - Are requirements in EARS?
+- [ ] **Article V**: Traceability - Is everything traceable?
+- [ ] **Article VI**: Project Memory - Did you check steering/?
+- [ ] **Article VII**: Design Patterns - Are patterns documented?
+- [ ] **Article VIII**: Decision Records - Is ADR created?
+- [ ] **Article IX**: Quality Gates - Are quality checks passed?