musubix 2.3.7 → 2.4.1

package/.github/skills/musubix-code-generation/SKILL.md

@@ -0,0 +1,229 @@
+---
+name: musubix-code-generation
+description: Guide for generating code from design specifications using MUSUBIX. Use this when asked to generate code, implement features, or create components following design documents.
+license: MIT
+---
+
+# MUSUBIX Code Generation Skill
+
+This skill guides you through generating code from design specifications following MUSUBIX methodology.
+
+## Prerequisites
+
+Before generating code:
+
+1. Verify design document exists (`DES-*`)
+2. Verify requirements are traceable (`REQ-*`)
+3. Check `steering/tech.ja.md` for technology stack
+
+## Supported Languages
+
+| Language | Extension | Features |
+|----------|-----------|----------|
+| TypeScript | `.ts` | Full support with types |
+| JavaScript | `.js` | ES6+ modules |
+| Python | `.py` | Type hints support |
+| Java | `.java` | Interface/Class generation |
+| Go | `.go` | Struct/Interface generation |
+| Rust | `.rs` | Trait/Struct generation |
+| C# | `.cs` | Interface/Class generation |
+
+## Code Generation Workflow
+
+### Step 1: Read Design Document
+
+```bash
+# Generate code from design
+npx musubix codegen generate <design-file>
+```
+
+### Step 2: Generate with Traceability
+
+Always include requirement references:
+
+```typescript
+/**
+ * UserService - Handles user operations
+ * 
+ * @see REQ-INT-001 - Neuro-Symbolic Integration
+ * @see DES-INT-001 - Integration Layer Design
+ */
+export class UserService {
+  // Implementation
+}
+```
+
+### Step 3: Follow Test-First (Article III)
+
+1. **Write test first**:
+```typescript
+describe('UserService', () => {
+  it('should create user', async () => {
+    const service = new UserService();
+    const user = await service.create({ name: 'Test' });
+    expect(user.id).toBeDefined();
+  });
+});
+```
+
+2. **Implement minimal code**:
+```typescript
+export class UserService {
+  async create(data: CreateUserDto): Promise<User> {
+    return { id: generateId(), ...data };
+  }
+}
+```
+
+3. **Refactor**
+
+## Design Pattern Templates
+
+### Singleton Pattern
+```typescript
+/**
+ * @see REQ-DES-001 - Pattern Detection
+ * @pattern Singleton
+ */
+export class ConfigManager {
+  private static instance: ConfigManager;
+  
+  private constructor() {}
+  
+  static getInstance(): ConfigManager {
+    if (!ConfigManager.instance) {
+      ConfigManager.instance = new ConfigManager();
+    }
+    return ConfigManager.instance;
+  }
+}
+```
+
+### Factory Pattern
+```typescript
+/**
+ * @see REQ-DES-001 - Pattern Detection
+ * @pattern Factory
+ */
+export interface ServiceFactory {
+  create(type: string): Service;
+}
+
+export class DefaultServiceFactory implements ServiceFactory {
+  create(type: string): Service {
+    switch (type) {
+      case 'auth': return new AuthService();
+      case 'user': return new UserService();
+      default: throw new Error(`Unknown service: ${type}`);
+    }
+  }
+}
+```
+
+### Repository Pattern
+```typescript
+/**
+ * @see REQ-COD-001 - Code Generation
+ * @pattern Repository
+ */
+export interface Repository<T> {
+  findById(id: string): Promise<T | null>;
+  findAll(): Promise<T[]>;
+  save(entity: T): Promise<T>;
+  delete(id: string): Promise<void>;
+}
+
+export class UserRepository implements Repository<User> {
+  async findById(id: string): Promise<User | null> {
+    // Implementation
+  }
+  // ... other methods
+}
+```
+
+## CLI Commands
+
+```bash
+# Generate code from design
+npx musubix codegen generate <design-file>
+
+# Analyze existing code
+npx musubix codegen analyze <file>
+
+# Security scan
+npx musubix codegen security <path>
+```
+
+## Quality Checks (Article IX)
+
+Before committing code:
+
+- [ ] **Type Safety**: No `any` types (TypeScript)
+- [ ] **Traceability**: All classes/functions have `@see` references
+- [ ] **Tests**: Test coverage ≥ 80%
+- [ ] **Linting**: `npm run lint` passes
+- [ ] **Build**: `npm run build` succeeds
+
+## Neuro-Symbolic Integration (REQ-INT-002)
+
+When generating code that involves decision-making:
+
+```typescript
+/**
+ * @see REQ-INT-002 - Confidence Evaluation
+ */
+async function integrateResults(
+  neuralResult: NeuralResult,
+  symbolicResult: SymbolicResult
+): Promise<FinalResult> {
+  // Decision rules from REQ-INT-002
+  if (symbolicResult.status === 'invalid') {
+    return rejectNeural(neuralResult);
+  }
+  
+  if (neuralResult.confidence >= 0.8) {
+    return adoptNeural(neuralResult);
+  }
+  
+  return prioritizeSymbolic(symbolicResult);
+}
+```
+
+## File Structure Convention
+
+```
+packages/
+├── core/
+│   └── src/
+│       ├── [feature]/
+│       │   ├── index.ts        # Public exports
+│       │   ├── [feature].ts    # Main implementation
+│       │   ├── types.ts        # Type definitions
+│       │   └── __tests__/      # Tests
+│       └── index.ts            # Package exports
+```
+
+## Error Handling Pattern
+
+```typescript
+/**
+ * @see REQ-ERR-001 - Graceful Degradation
+ */
+export class MuSubixError extends Error {
+  constructor(
+    message: string,
+    public code: string,
+    public recoverable: boolean = true
+  ) {
+    super(message);
+    this.name = 'MuSubixError';
+  }
+}
+
+// Usage
+throw new MuSubixError(
+  'Failed to connect to YATA',
+  'YATA_CONNECTION_ERROR',
+  true // Can retry
+);
+```

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