create-ai-project 1.11.2 → 1.12.0

package/.claude/skills/task-analyzer/references/skills-index.yaml

@@ -0,0 +1,211 @@
+# スキルメタデータインデックス
+# rule-advisorがタスク分析に基づいて適切なスキルを選択するために使用
+
+skills:
+  coding-standards:
+    skill: "coding-standards"
+    tags: [anti-patterns, technical-judgment, debugging, rule-of-three, implementation, type-safety, refactoring, code-reading, best-practices, impact-analysis, unused-code, code-deletion, testing, tdd]
+    typical-use: "全ドメイン共通の技術的判断基準、アンチパターン検出、デバッグ手法、実装時のベストプラクティス、影響範囲調査、未使用コード削除、テスト設計原則"
+    size: large
+    key-references:
+      - "Rule of Three - Martin Fowler"
+      - "5 Whys - トヨタ生産方式"
+      - "DRY原則 - The Pragmatic Programmer"
+      - "単一責任原則（SRP） - Clean Code"
+      - "YAGNI原則 - Extreme Programming"
+      - "Avoiding fallback in distributed systems - AWS Builders' Library"
+      - "Test-Driven Development - Kent Beck"
+      - "Red-Green-Refactor - Kent Beck"
+      - "AAAパターン - Arrange-Act-Assert"
+    sections:
+      - "技術的アンチパターン（赤信号パターン）"
+      - "基本原則"
+      - "コメント記述ルール"
+      - "エラーハンドリングの基本原則"
+      - "Rule of Three - コード重複の判断基準"
+      - "よくある失敗パターンと回避方法"
+      - "デバッグ手法"
+      - "型安全性の基礎"
+      - "リファクタリング手法"
+      - "技術的判断が必要な場面"
+      - "継続的改善のマインドセット"
+      - "実装作業の完全性担保"
+      - "Red-Green-Refactorプロセス（テストファースト開発）"
+      - "テスト設計原則"
+      - "テストヘルパーの活用ルール"
+      - "テストの粒度原則"
+      - "継続性テストの範囲"
+
+  typescript-rules:
+    skill: "typescript-rules"
+    tags: [implementation, type-safety, async, coding-style, functional-programming, dependency-injection, backend]
+    typical-use: "バックエンドTypeScriptコードの作成・修正、クラス使用判断、DI実装"
+    size: small
+    key-references:
+      - "Dependency Injection - Martin Fowler"
+    sections:
+      - "Backend実装における型安全性"
+      - "コーディング規約"
+      - "エラーハンドリング"
+      - "パフォーマンス最適化"
+
+  typescript-testing:
+    skill: "typescript-testing"
+    tags: [quality, testing, coverage, vitest, backend, implementation]
+    typical-use: "バックエンドテスト作成、Vitest設定、70%カバレッジ要件、テスト品質基準"
+    size: small
+    key-references:
+      - "Vitest公式ドキュメント"
+    sections:
+      - "テストフレームワーク"
+      - "テストの基本方針"
+      - "テストの実装規約"
+      - "テスト品質基準"
+      - "モックの型安全性"
+      - "Vitestの基本例"
+
+  technical-spec:
+    skill: "technical-spec"
+    tags: [architecture, design, documentation, environment, data-flow, implementation, quality-commands, testing, build]
+    typical-use: "技術設計、環境設定、ドキュメント作成プロセス、実装方針決定、品質チェックコマンド、ビルドとテスト実行"
+    size: medium
+    key-references:
+      - "ADRフォーマット - Michael Nygard"
+      - "単一データソース原則 - Single Source of Truth"
+    sections:
+      - "技術スタックの基本方針"
+      - "環境変数管理とセキュリティ"
+      - "アーキテクチャ設計"
+      - "パターン適用の一貫性"
+      - "データフロー統一原則"
+      - "ビルドとテスト"
+
+  project-context:
+    skill: "project-context"
+    tags: [context, project-specific, implementation]
+    typical-use: "プロジェクト固有情報、実装原則の理解"
+    size: small
+    key-references:
+      - "プロジェクト固有（経験則）"
+    sections:
+      - "基本設定"
+      - "実装原則"
+      - "カスタマイズガイド"
+
+  documentation-criteria:
+    skill: "documentation-criteria"
+    tags: [documentation, decision-making, adr, prd, design-doc, planning, process]
+    typical-use: "実装開始時の規模判定、ドキュメント作成判定、ADR/PRD/Design Doc/作業計画書の作成基準"
+    size: medium
+    key-references:
+      - "ADR手法 - Michael Nygard"
+      - "Design Doc文化 - Google Engineering Practices"
+      - "Single Source of Truth"
+    sections:
+      - "作成判定マトリクス"
+      - "ADR作成条件（いずれか該当で必須）"
+      - "各ドキュメントの詳細定義"
+      - "作成プロセス"
+      - "保存場所"
+      - "ADRステータス"
+      - "AI自動化ルール"
+      - "図表作成要件"
+      - "共通ADRとの関係性"
+
+  implementation-approach:
+    skill: "implementation-approach"
+    tags: [architecture, implementation, task-decomposition, strategy-patterns, strangler-pattern, facade-pattern, design, planning, confirmation-levels]
+    typical-use: "実装戦略の選択、タスク分解、設計判断、大規模変更の計画"
+    size: medium
+    key-references:
+      - "Strangler Fig Pattern - Martin Fowler"
+      - "Feature Slicing - Martin Fowler"
+      - "Walking Skeleton - Alistair Cockburn"
+      - "Facade Pattern - Gang of Four"
+    sections:
+      - "メタ認知的戦略選択プロセス"
+      - "確認レベル定義"
+      - "統合ポイントの定義"
+      - "アンチパターン"
+      - "メタ認知的実行のための指針"
+
+  integration-e2e-testing:
+    skill: "integration-e2e-testing"
+    tags: [testing, integration-test, e2e-test, property-based-testing, fast-check, test-skeleton, test-review, quality]
+    typical-use: "統合テスト・E2Eテストのスケルトン生成、テスト実装、テストレビュー、Property-Based Test実装"
+    size: small
+    key-references:
+      - "fast-check - Property-based testing for TypeScript"
+      - "Node.js Testing Best Practices - Yoni Goldberg"
+      - "Property-Based Testing - 2025 Practices"
+    sections:
+      - "テスト種別と上限"
+      - "振る舞い優先の原則"
+      - "スケルトン仕様"
+      - "実装ルール"
+      - "レビュー基準"
+
+  subagents-orchestration-guide:
+    skill: "subagents-orchestration-guide"
+    tags: [orchestration, subagents, workflow, scale-determination, document-requirements, autonomous-execution]
+    typical-use: "サブエージェントのワークフロー調整、規模判定、ドキュメント要件"
+    size: medium
+    key-references:
+      - "ワークフロー調整パターン"
+      - "エージェント連携パターン"
+    sections:
+      - "規模判定"
+      - "ドキュメント要件"
+      - "停止ポイント"
+      - "自律実行モード"
+
+  # フロントエンド固有スキル
+  frontend/typescript-rules:
+    skill: "frontend/typescript-rules"
+    tags: [frontend, react, implementation, type-safety, props-driven, hooks, component-design, vite, error-boundary]
+    typical-use: "React/Viteでのフロントエンド開発、コンポーネント設計、Props設計、環境変数管理"
+    size: small
+    key-references:
+      - "React公式ドキュメント - Function Components"
+      - "Props-driven開発 - React Patterns"
+    sections:
+      - "フロントエンド固有のアンチパターン"
+      - "Frontend実装における型安全性"
+      - "コーディング規約"
+      - "エラーハンドリング"
+      - "パフォーマンス最適化"
+
+  frontend/typescript-testing:
+    skill: "frontend/typescript-testing"
+    tags: [frontend, react, quality, testing, coverage, vitest, react-testing-library, msw, component-testing, implementation]
+    typical-use: "Reactコンポーネントのテスト作成、React Testing Library、MSW、60%カバレッジ要件、Co-location"
+    size: small
+    key-references:
+      - "React Testing Library - Kent C. Dodds"
+      - "MSW (Mock Service Worker) - API Mocking"
+      - "ADR-0002 Co-location原則"
+    sections:
+      - "テストフレームワーク"
+      - "テストの基本方針"
+      - "テストの実装規約"
+      - "モックの型安全性の徹底"
+      - "React Testing Libraryの基本例"
+
+  frontend/technical-spec:
+    skill: "frontend/technical-spec"
+    tags: [frontend, react, architecture, design, documentation, environment, data-flow, implementation, vite, security, client-side, state-management, context-api, hooks, lighthouse, bundle-size, non-functional-requirements]
+    typical-use: "フロントエンド技術設計、環境変数管理（Vite）、セキュリティ制約、アーキテクチャ設計、状態管理パターン、実装方針決定、非機能要件の確認"
+    size: medium
+    key-references:
+      - "Vite公式ドキュメント - Environment Variables"
+      - "React公式ドキュメント - State Management"
+      - "Single Source of Truth - データフロー原則"
+      - "Immutable Update Patterns - React"
+      - "Lighthouse - Google Web Performance"
+      - "Web.dev - Performance Best Practices"
+    sections:
+      - "技術スタックの基本方針"
+      - "環境変数管理とセキュリティ"
+      - "アーキテクチャ設計"
+      - "データフロー統一原則"
+      - "ビルドとテスト"

package/.claude/skills/technical-spec/SKILL.md

@@ -0,0 +1,86 @@
+---
+name: technical-spec
+description: 環境変数管理、アーキテクチャ設計、ビルド・テストコマンドを含む技術設計ルール。
+---
+
+# 技術設計ルール
+
+## 技術スタックの基本方針
+TypeScriptをベースとしたアプリケーション実装。アーキテクチャパターンはプロジェクトの要件と規模に応じて選択すること。
+
+## 環境変数管理とセキュリティ
+
+### 環境変数管理
+- 環境変数は一元管理し、型安全性を確保する仕組みを構築すること
+- `process.env` の直接参照は避け、設定管理層を通じて取得すること
+- デフォルト値の設定や必須チェックを適切に実装すること
+
+### セキュリティ
+- `.env`ファイルはGitに含めない
+- APIキーやシークレットは必ず環境変数として管理
+- 機密情報のログ出力は禁止
+- エラーメッセージに機密情報を含めない
+
+## アーキテクチャ設計
+
+### アーキテクチャ設計の原則
+プロジェクトごとに適切なアーキテクチャを選択し、明確に定義すること：
+
+- **責務の分離**: 各層やモジュールの責務を明確に定義し、境界を守ること
+
+## データフロー統一原則
+
+#### 基本原則
+1. **単一データソース**: 同じ情報は1箇所にのみ保存する
+2. **構造化データ優先**: JSON文字列ではなくパース済みオブジェクトを使用
+3. **明確な責務分離**: 各層の責務を明確に定義
+
+#### データフローのベストプラクティス
+- **入力時点での検証**: データは入力層で検証し、型安全な形で内部に渡す
+- **変換の一元化**: データ変換ロジックは専用のユーティリティに集約
+- **ログの構造化**: データフローの各段階で構造化ログを出力
+
+## ビルドとテスト
+package.jsonの`packageManager`フィールドに応じた実行コマンドを使用すること。
+
+### ビルドコマンド
+- `build` - TypeScriptビルド
+- `type-check` - 型チェック（emit なし）
+
+### テストコマンド
+- `test` - テスト実行
+- `test:coverage` - カバレッジ測定
+- `test:coverage:fresh` - カバレッジ測定（キャッシュクリア）
+- `test:safe` - 安全なテスト実行（自動クリーンアップ付き）
+- `cleanup:processes` - Vitestプロセスのクリーンアップ
+
+### 品質チェック要件
+
+品質チェックは実装完了時に必須：
+
+**Phase 1-3: コード品質チェック**
+- `check` - Biome（lint + format）
+- `check:unused` - 未使用エクスポートの検出
+- `check:deps` - 循環依存の検出
+- `build` - TypeScriptビルド
+
+**Phase 4: テスト**
+- `test` - テスト実行
+
+**Phase 5: コード品質再検証**
+- `check:code` - コード品質の再検証（Phase 4でのテスト修正による副作用を清掃）
+
+### 補助コマンド
+- `check:all` - 全体統合チェック（check:code + test）※手動一括確認用
+- `open coverage/index.html` - カバレッジレポート確認
+- `format` - フォーマット修正
+- `lint:fix` - Lint修正
+
+### トラブルシューティング
+- **ポート使用中エラー**: `cleanup:processes` スクリプトを実行
+- **キャッシュ問題**: `test:coverage:fresh` スクリプトを実行
+- **依存関係エラー**: 依存関係のクリーンインストールを実行
+
+### カバレッジ要件
+- **必須**: ユニットテストカバレッジは70%以上
+- **メトリクス**: Statements、Branches、Functions、Lines

package/{docs/rules/typescript.md → .claude/skills/typescript-rules/SKILL.md}

@@ -1,67 +1,33 @@
-# TypeScript 開発ルール
-
-## 基本原則
-
-✅ **積極的なリファクタリング** - 技術的負債を防ぎ、健全性を維持
-❌ **使われない「念のため」のコード** - YAGNI原則（Kent Beck）に反する
-
-## コメント記述ルール
-- **機能説明重視**: コードが「何をするか」を記述
-- **履歴情報禁止**: 開発履歴は記載しない
-- **タイムレス**: いつ読んでも有効な内容のみ記述
-- **簡潔性**: 必要最小限の説明にとどめる
-
-## 型安全性
-
-**絶対ルール**: any型は完全禁止。型チェックが無効化され、実行時エラーの温床となる。
-
-**any型の代替手段（優先順位順）**
-1. **unknown型 + 型ガード**: 外部入力の検証に使用
-2. **ジェネリクス**: 型の柔軟性が必要な場合
-3. **ユニオン型・インターセクション型**: 複数の型の組み合わせ
-4. **型アサーション（最終手段）**: 型が確実な場合のみ
-
-**型ガードの実装パターン**
-```typescript
-function isUser(value: unknown): value is User {
-  return typeof value === 'object' && value !== null && 'id' in value && 'name' in value
-}
-```
+---
+name: typescript-rules
+description: 型安全性とエラーハンドリングのためのTypeScript開発ルール。TypeScriptコード実装や型定義レビュー時に使用。
+---
 
-**モダンな型機能の活用**
-- **satisfies演算子**: `const config = { port: 3000 } satisfies Config` - 型推論維持
-- **const assertion**: `const ROUTES = { HOME: '/' } as const satisfies Routes` - 不変かつ型安全
-- **ブランド型**: `type UserId = string & { __brand: 'UserId' }` - 意味を区別
-- **テンプレートリテラル型**: `type Endpoint = \`\${HttpMethod} \${Route}\`` - 文字列パターンを型で表現
+# TypeScript 開発ルール
 
-**実装での型安全性**
-- API通信: レスポンスは必ず`unknown`で受け、型ガードで検証
-- フォーム入力: 外部入力は`unknown`、バリデーション後に型確定
-- レガシー統合: `window as unknown as LegacyWindow`のように段階的アサーション
-- テストコード: モックも必ず型定義、`Partial<T>`や`vi.fn<[Args], Return>()`活用
+## Backend実装における型安全性
 
 **データフローでの型安全性**
 入力層（`unknown`） → 型ガード → ビジネス層（型保証） → 出力層（シリアライズ）
 
-**型の複雑性管理**
-- フィールド数: 20個まで（超えたら責務で分割、外部API型は例外）
-- オプショナル率: 30%まで（超えたら必須/任意で分離）
-- ネスト深さ: 3階層まで（超えたらフラット化）
-- 型アサーション: 3回以上使用したら設計見直し
-- **外部API型の扱い**: 制約を緩和し、実態に合わせて定義（内部では適切に変換）
+**Backend固有の型シナリオ**:
+- **API通信**: レスポンスは必ず`unknown`で受け、型ガードで検証
+- **フォーム入力**: 外部入力は`unknown`、バリデーション後に型確定
+- **レガシー統合**: `window as unknown as LegacyWindow`のように段階的アサーション
+- **テストコード**: モックも必ず型定義、`Partial<T>`や`vi.fn<[Args], Return>()`活用
 
 ## コーディング規約
 
 **クラス使用の判断基準**
 - **推奨：関数とinterfaceでの実装**
   - 背景: テスタビリティと関数合成の柔軟性が向上
-- **クラス使用を許可**: 
+- **クラス使用を許可**:
   - フレームワーク要求時（NestJSのController/Service、TypeORMのEntity等）
   - カスタムエラークラス定義時
   - 状態とビジネスロジックが密結合している場合（例: ShoppingCart、Session、StateMachine）
 - **判断基準**: 「このデータは振る舞いを持つか？」がYesならクラス検討
   ```typescript
-  // ✅ 関数とinterface
+  // 関数とinterface
   interface UserService { create(data: UserData): User }
   const userService: UserService = { create: (data) => {...} }
   ```
@@ -69,14 +35,14 @@ function isUser(value: unknown): value is User {
 **関数設計**
 - **引数は0-2個まで**: 3個以上はオブジェクト化
   ```typescript
-  // ✅ オブジェクト引数
+  // オブジェクト引数
   function createUser({ name, email, role }: CreateUserParams) {}
   ```
 
 **依存性注入**
 - **外部依存は引数で注入**: テスト可能性とモジュール性確保
   ```typescript
-  // ✅ 依存性を引数で受け取る
+  // 依存性を引数で受け取る
   function createService(repository: Repository) { return {...} }
   ```
 
@@ -91,10 +57,10 @@ function isUser(value: unknown): value is User {
 - インポートは絶対パス（`src/`）
 
 **クリーンコード原則**
-- ✅ 使用されていないコードは即座に削除
-- ✅ デバッグ用`console.log()`は削除
-- ❌ コメントアウトされたコード（バージョン管理で履歴管理）
-- ✅ コメントは「なぜ」を説明（「何」ではなく）
+- 使用されていないコードは即座に削除
+- デバッグ用`console.log()`は削除
+- コメントアウトされたコード禁止（バージョン管理で履歴管理）
+- コメントは「なぜ」を説明（「何」ではなく）
 
 ## エラーハンドリング
 
@@ -102,12 +68,12 @@ function isUser(value: unknown): value is User {
 
 **Fail-Fast原則**: エラー時は速やかに失敗させ、不正な状態での処理継続を防ぐ
 ```typescript
-// ❌ 禁止: 無条件フォールバック
+// 禁止: 無条件フォールバック
 catch (error) {
   return defaultValue // エラーを隠蔽
 }
 
-// ✅ 必須: 明示的な失敗
+// 必須: 明示的な失敗
 catch (error) {
   logger.error('処理失敗', error)
   throw error // 上位層で適切に処理
@@ -149,18 +115,7 @@ export class AppError extends Error {
 - すべてのasync/awaitでtry-catch使用
 - エラーは必ずログと再スロー
 
-## リファクタリング手法
-
-**基本方針**
-- 小さなステップ: 段階的改善により、常に動作する状態を維持
-- 安全な変更: 一度に変更する範囲を最小限に抑制
-- 動作保証: 既存の動作を変えないことを確認しながら進める
-
-**実施手順**: 現状把握 → 段階的変更 → 動作確認 → 最終検証
-
-**優先順位**: 重複コード削除 > 長大な関数分割 > 複雑な条件分岐簡素化 > 型安全性向上
-
 ## パフォーマンス最適化
 
 - ストリーミング処理: 大きなデータセットはストリームで処理
-- メモリリーク防止: 不要なオブジェクトは明示的に解放
+- メモリリーク防止: 不要なオブジェクトは明示的に解放

package/.claude/skills/typescript-testing/SKILL.md

@@ -0,0 +1,155 @@
+---
+name: typescript-testing
+description: Vitestを使用したTypeScriptテストルール。カバレッジ要件、テスト設計原則、品質基準を含む。
+---
+
+# TypeScript テストルール
+
+## テストフレームワーク
+
+- **Vitest**: このプロジェクトではVitestを使用
+- テストのインポート: `import { describe, it, expect, beforeEach, vi } from 'vitest'`
+- モックの作成: `vi.mock()` を使用
+
+## テストの基本方針
+
+### 品質要件
+- **カバレッジ**: 単体テストのカバレッジは70%以上を必須
+- **独立性**: 各テストは他のテストに依存せず実行可能
+- **再現性**: テストは環境に依存せず、常に同じ結果を返す
+- **可読性**: テストコードも製品コードと同様の品質を維持
+
+### カバレッジ要件
+**必須**: 単体テストのカバレッジは70%以上
+**指標**: Statements（文）、Branches（分岐）、Functions（関数）、Lines（行）
+
+### テストの種類と範囲
+1. **単体テスト（Unit Tests）**
+   - 個々の関数やクラスの動作を検証
+   - 外部依存はすべてモック化
+   - 最も数が多く、細かい粒度で実施
+
+2. **統合テスト（Integration Tests）**
+   - 複数のコンポーネントの連携を検証
+   - 実際の依存関係を使用（DBやAPI等）
+   - 主要な機能フローの検証
+
+3. **E2Eテストでの機能横断検証**
+   - 新機能追加時、既存機能への影響を必ず検証
+   - Design Docの「統合ポイントマップ」で影響度「高」「中」の箇所をカバー
+   - 検証パターン: 既存機能動作 → 新機能有効化 → 既存機能の継続性確認
+   - 判定基準: レスポンス内容の変化なし、処理時間5秒以内
+   - CI/CDでの自動実行を前提とした設計
+
+## テストの実装規約
+
+### ディレクトリ構造
+```
+src/
+└── application/
+    └── services/
+        ├── __tests__/
+        │   ├── service.test.ts      # 単体テスト
+        │   └── service.int.test.ts  # 統合テスト
+        └── service.ts
+```
+
+### 命名規則
+- テストファイル: `{対象ファイル名}.test.ts`
+- 統合テストファイル: `{対象ファイル名}.int.test.ts`
+- テストスイート: 対象の機能や状況を説明する名前
+- テストケース: 期待される動作を説明する名前
+
+### テストコードの品質ルール
+
+**推奨: すべてのテストを常に有効に保つ**
+- メリット: テストスイートの完全性を保証
+- 実践: 問題があるテストは修正して有効化
+
+**避けるべき: test.skip()やコメントアウト**
+- 理由: テストの穴が生まれ、品質チェックが不完全になる
+- 対処: 不要なテストは完全に削除する
+
+## テスト品質基準
+
+### 境界値・異常系の網羅
+正常系に加え、境界値と異常系を含める。
+```typescript
+it('returns 0 for empty array', () => expect(calc([])).toBe(0))
+it('throws on negative price', () => expect(() => calc([{price: -1}])).toThrow())
+```
+
+### 期待値の直接記述
+期待値はリテラルで記述。実装ロジックを再現しない。
+**有効なテスト**: 期待値 ≠ モック戻り値（実装による変換・処理がある）
+```typescript
+expect(calcTax(100)).toBe(10)  // not: 100 * TAX_RATE
+```
+
+### 結果ベースの検証
+呼び出し順序・回数ではなく結果を検証。
+```typescript
+expect(mock).toHaveBeenCalledWith('a')  // not: toHaveBeenNthCalledWith
+```
+
+### 意味あるアサーション
+各テストに最低1つの検証を含める。
+```typescript
+it('creates user', async () => {
+  const user = await createUser({name: 'test'})
+  expect(user.id).toBeDefined()
+})
+```
+
+### 適切なモック範囲
+直接依存の外部I/Oのみモック。間接依存は実物使用。
+```typescript
+vi.mock('./database')  // 外部I/Oのみ
+```
+
+### Property-based Testing（fast-check）
+不変条件やプロパティを検証する場合はfast-checkを使用。
+```typescript
+import fc from 'fast-check'
+
+it('reverses twice equals original', () => {
+  fc.assert(fc.property(fc.array(fc.integer()), (arr) => {
+    return JSON.stringify(arr.reverse().reverse()) === JSON.stringify(arr)
+  }))
+})
+```
+
+**使用条件**: Design DocのACにProperty注釈が付与されている場合に使用。
+
+## モックの型安全性
+
+### 必要最小限の型定義
+```typescript
+// 必要な部分のみ
+type TestRepo = Pick<Repository, 'find' | 'save'>
+const mock: TestRepo = { find: vi.fn(), save: vi.fn() }
+
+// やむを得ない場合のみ、理由明記
+const sdkMock = {
+  call: vi.fn()
+} as unknown as ExternalSDK // 外部SDKの複雑な型のため
+```
+
+## Vitestの基本例
+
+```typescript
+import { describe, it, expect, vi } from 'vitest'
+
+vi.mock('./userService', () => ({
+  getUserById: vi.fn(),
+  updateUser: vi.fn()
+}))
+
+describe('ComponentName', () => {
+  it('should follow AAA pattern', () => {
+    const input = 'test'
+    const result = someFunction(input)
+    expect(result).toBe('expected')
+  })
+})
+```