musubix 2.1.0 → 2.2.0

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

@@ -1,210 +0,0 @@
----
-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>
-
-# Code Generation
-npx musubix codegen generate <file>
-
-# 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?

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

@@ -1,212 +0,0 @@
----
-name: musubix-test-generation
-description: Guide for generating test code from designs and requirements. Use this when asked to create unit tests, integration tests, or test coverage analysis following TDD/BDD practices.
-license: MIT
----
-
-# MUSUBIX Test Generation Skill
-
-This skill guides you through generating comprehensive test suites that maintain traceability.
-
-## Overview
-
-MUSUBIX follows **Article III - Test-First**: Red-Green-Blue TDD cycle.
-
-```mermaid
-flowchart LR
-    RED[🔴 Red<br/>Failing Test] --> GREEN[🟢 Green<br/>Minimal Code]
-    GREEN --> BLUE[🔵 Blue<br/>Refactor]
-    BLUE --> RED
-```
-
-## Test Structure
-
-### Unit Test Template
-
-```typescript
-/**
- * @requirement REQ-XXX-NNN
- * @design DES-XXX-NNN
- */
-import { describe, it, expect, beforeEach } from 'vitest';
-import { XxxService } from './xxx-service.js';
-import { resetXxxCounter } from './xxx-entity.js';
-
-describe('XxxService', () => {
-  let service: XxxService;
-  let repository: MockXxxRepository;
-
-  beforeEach(() => {
-    // BP-TEST-001: Reset counters before each test
-    resetXxxCounter();
-    repository = new MockXxxRepository();
-    service = new XxxService(repository);
-  });
-
-  describe('create', () => {
-    it('should create entity with valid input', async () => {
-      // Arrange
-      const input = { name: 'Test', value: 100 };
-      
-      // Act
-      const result = await service.create(input);
-      
-      // Assert
-      expect(result.isOk()).toBe(true);
-      if (result.isOk()) {
-        expect(result.value.name).toBe('Test');
-      }
-    });
-
-    it('should return error for invalid input', async () => {
-      // Arrange
-      const input = { name: '', value: -1 };
-      
-      // Act
-      const result = await service.create(input);
-      
-      // Assert
-      expect(result.isErr()).toBe(true);
-    });
-  });
-});
-```
-
-### Integration Test Template
-
-```typescript
-/**
- * @requirement REQ-XXX-NNN
- * @design DES-XXX-NNN
- */
-import { describe, it, expect, beforeAll, afterAll } from 'vitest';
-
-describe('XxxService Integration', () => {
-  beforeAll(async () => {
-    // Setup test environment
-  });
-
-  afterAll(async () => {
-    // Cleanup
-  });
-
-  it('should complete full workflow', async () => {
-    // Test full user journey
-  });
-});
-```
-
-## Best Practices for Testing
-
-### BP-TEST-001: Test Counter Reset
-
-```typescript
-beforeEach(() => {
-  resetPetCounter();  // Reset ID counters
-  resetReservationCounter();
-});
-```
-
-### BP-TEST-002: Verify API Before Test
-
-```typescript
-// ✅ Check actual API signature first
-const service = new PetService(repository);
-// Verify method exists and parameters match
-```
-
-### BP-TEST-004: Result Type Test Pattern
-
-```typescript
-// ✅ Test both success and failure cases
-it('should handle success', async () => {
-  const result = await service.create(validInput);
-  expect(result.isOk()).toBe(true);
-  if (result.isOk()) {
-    expect(result.value.id).toBeDefined();
-  }
-});
-
-it('should handle failure', async () => {
-  const result = await service.create(invalidInput);
-  expect(result.isErr()).toBe(true);
-  if (result.isErr()) {
-    expect(result.error.message).toContain('validation');
-  }
-});
-```
-
-### BP-TEST-005: Status Transition Testing
-
-```typescript
-describe('status transitions', () => {
-  // Valid transitions
-  it('should allow draft -> active', () => {
-    const result = workflow.transition('draft', 'activate');
-    expect(result).toBe('active');
-  });
-
-  // Invalid transitions
-  it('should reject completed -> draft', () => {
-    expect(() => workflow.transition('completed', 'revert'))
-      .toThrow('Invalid transition');
-  });
-});
-```
-
-## Test Categories
-
-| Category | Purpose | Location |
-|----------|---------|----------|
-| Unit | Single component | `__tests__/unit/` |
-| Integration | Multiple components | `__tests__/integration/` |
-| E2E | Full user flows | `__tests__/e2e/` |
-
-## CLI Commands
-
-```bash
-# Generate tests from design
-npx musubix test generate storage/design/DES-XXX.md
-
-# Run all tests
-npm test
-
-# Coverage report
-npx musubix test coverage src/
-
-# Run specific test file
-npm test -- xxx.test.ts
-```
-
-## Vitest Configuration
-
-```typescript
-// vitest.config.ts
-import { defineConfig } from 'vitest/config';
-
-export default defineConfig({
-  test: {
-    globals: true,
-    environment: 'node',
-    include: ['**/*.test.ts'],
-    coverage: {
-      provider: 'v8',
-      reporter: ['text', 'json', 'html'],
-    },
-  },
-});
-```
-
-## Coverage Targets
-
-| Metric | Target |
-|--------|--------|
-| Line Coverage | ≥80% |
-| Branch Coverage | ≥75% |
-| Function Coverage | ≥90% |
-
-## Related Skills
-
-- `musubix-sdd-workflow` - Full SDD workflow with TDD
-- `musubix-code-generation` - Generate code to test
-- `musubix-traceability` - Link tests to requirements

package/.github/skills/musubix-traceability/SKILL.md

@@ -1,141 +0,0 @@
----
-name: musubix-traceability
-description: Guide for managing traceability between requirements, designs, code, and tests. Use this when asked to verify traceability, create traceability matrices, or perform impact analysis.
-license: MIT
----
-
-# MUSUBIX Traceability Skill
-
-This skill guides you through maintaining full traceability across the development lifecycle.
-
-## Overview
-
-MUSUBIX enforces **Article V - Traceability**: Complete bidirectional tracing between:
-
-```
-Requirements (REQ-*) ↔ Design (DES-*) ↔ Tasks (TSK-*) ↔ Code ↔ Tests
-```
-
-## Traceability Matrix
-
-### Creating a Traceability Matrix
-
-```markdown
-# Traceability Matrix
-
-| 要件ID | 設計ID | タスクID | コード | テスト |
-|--------|--------|---------|--------|--------|
-| REQ-AUTH-001 | DES-AUTH-001 | TSK-001 | src/auth/auth-service.ts | auth.test.ts |
-| REQ-AUTH-002 | DES-AUTH-001 | TSK-002 | src/auth/token-manager.ts | token.test.ts |
-```
-
-### CLI Commands
-
-```bash
-# Generate traceability matrix
-npx musubix trace matrix
-
-# Impact analysis for a specific requirement
-npx musubix trace impact REQ-AUTH-001
-
-# Validate all traceability links
-npx musubix trace validate
-```
-
-## Traceability in Code
-
-### Adding Traceability Comments
-
-```typescript
-/**
- * AuthService - 認証サービス
- * @requirement REQ-AUTH-001
- * @design DES-AUTH-001
- * @task TSK-001
- */
-export class AuthService {
-  /**
-   * ユーザー認証
-   * @requirement REQ-AUTH-001
-   */
-  async authenticate(credentials: Credentials): Promise<Result<Token, AuthError>> {
-    // Implementation
-  }
-}
-```
-
-### Test Traceability
-
-```typescript
-/**
- * @requirement REQ-AUTH-001
- * @design DES-AUTH-001
- */
-describe('AuthService', () => {
-  describe('authenticate', () => {
-    it('should return token for valid credentials', async () => {
-      // Test implementation
-    });
-  });
-});
-```
-
-## Impact Analysis
-
-When a requirement changes, identify all affected artifacts:
-
-```mermaid
-flowchart LR
-    REQ[REQ-AUTH-001<br/>変更] --> DES[DES-AUTH-001<br/>設計]
-    DES --> TSK1[TSK-001<br/>タスク]
-    DES --> TSK2[TSK-002<br/>タスク]
-    TSK1 --> CODE1[auth-service.ts]
-    TSK2 --> CODE2[token-manager.ts]
-    CODE1 --> TEST1[auth.test.ts]
-    CODE2 --> TEST2[token.test.ts]
-```
-
-### Impact Analysis Steps
-
-1. Identify changed requirement (REQ-*)
-2. Find linked designs (DES-*)
-3. Find linked tasks (TSK-*)
-4. Locate affected code files
-5. Identify tests to update
-6. Update all artifacts
-
-## Traceability Storage
-
-```
-storage/traceability/
-├── matrix.json           # Full traceability matrix
-├── requirements-map.json # REQ -> DES mappings
-├── design-map.json       # DES -> TSK mappings
-└── code-map.json         # TSK -> Code mappings
-```
-
-## Verification Checklist
-
-Before completing any feature:
-
-- [ ] All requirements have linked designs
-- [ ] All designs have linked tasks
-- [ ] All tasks have linked code
-- [ ] All code has linked tests
-- [ ] Traceability comments in code
-- [ ] Matrix updated
-
-## MCP Tool
-
-Use MCP tool for automated validation:
-
-```
-Tool: sdd_validate_traceability
-Description: Validates bidirectional traceability across all artifacts
-```
-
-## Related Skills
-
-- `musubix-sdd-workflow` - Full SDD workflow
-- `musubix-ears-validation` - Requirements validation
-- `musubix-test-generation` - Generate tests with traceability