create-ai-project 1.11.2 → 1.12.0

package/.claude/skills/documentation-criteria/references/design-template.md

@@ -0,0 +1,242 @@
+# [機能名] 設計書
+
+## 概要
+
+[この機能の目的と概要を2-3文で説明]
+
+## 設計サマリー（メタ）
+
+```yaml
+design_type: "新機能|拡張|リファクタリング"
+risk_level: "低|中|高"
+main_constraints:
+  - "[制約1]"
+  - "[制約2]"
+biggest_risks:
+  - "[リスク1]"
+  - "[リスク2]"
+unknowns:
+  - "[不確実性1]"
+  - "[不確実性2]"
+```
+
+## 背景と経緯
+
+### 前提となるADR
+
+- [ADRファイル名]: [関連する決定事項]
+- 共通技術ADRも該当する場合は参照
+
+### 合意事項チェックリスト
+
+#### スコープ
+- [ ] [変更対象の機能/コンポーネント]
+- [ ] [追加する機能]
+
+#### スコープ外（明示的に変更しないもの）
+- [ ] [変更しない機能/コンポーネント]
+- [ ] [維持する既存ロジック]
+
+#### 制約
+- [ ] 並行運用: [する/しない]
+- [ ] 後方互換性: [必要/不要]
+- [ ] パフォーマンス計測: [必要/不要]
+
+### 解決すべき課題
+
+[この機能が解決しようとする具体的な問題や課題]
+
+### 現状の課題
+
+[現在のシステムの問題点や制限事項]
+
+### 要件
+
+#### 機能要件
+
+- [必須の機能要件をリストアップ]
+
+#### 非機能要件
+
+- **パフォーマンス**: [レスポンス時間、スループットの要件]
+- **スケーラビリティ**: [負荷増大時の対応要件]
+- **信頼性**: [エラー率、可用性の要件]
+- **保守性**: [コードの可読性、変更容易性]
+
+## 受入条件（AC）- EARS形式
+
+各ACはEARS形式で記述。キーワードがテストタイプを決定。
+
+### [機能要件1]
+
+- [ ] **When** ユーザーが有効な認証情報でログインボタンをクリックすると、システムは認証を行いダッシュボードにリダイレクトする
+- [ ] **If** 認証情報が無効な場合、**then** システムはエラーメッセージ「認証情報が無効です」を表示する
+- [ ] **While** ユーザーがログインしている間、システムはセッションを60分間維持する
+
+### [機能要件2]
+
+- [ ] システムはデータリストを1ページ10件のページネーション付きで表示する
+- [ ] **When** 検索フィールドに入力すると、システムはリアルタイムでフィルタリングを適用する
+  - **Property**: `filtered.every(item => item.name.includes(query))`
+
+## 既存コードベース分析
+
+### 実装パスマッピング
+| 種別 | パス | 説明 |
+|-----|-----|-----|
+| 既存 | src/[実際のパス] | [現在の実装] |
+| 新規 | src/[計画パス] | [新規作成予定] |
+
+### 統合ポイント（新規実装でも記載）
+- **統合先**: [何と連携するか]
+- **呼び出し方式**: [どのように呼び出されるか]
+
+## 設計
+
+### 変更影響マップ
+
+```yaml
+変更対象: [変更するコンポーネント/機能]
+直接影響:
+  - [直接変更が必要なファイル/関数]
+  - [インターフェース変更箇所]
+間接影響:
+  - [データ形式の変更]
+  - [処理時間の変化]
+波及なし:
+  - [明示的に影響を受けない機能]
+```
+
+### アーキテクチャ概要
+
+[この機能がシステム全体の中でどのように位置づけられるか]
+
+### データフロー
+
+```
+[図やシュードコードでデータの流れを表現]
+```
+
+### 統合ポイント一覧
+
+| 統合ポイント | 箇所 | 旧実装 | 新実装 | 切替方式 |
+|------------|-----|-------|-------|---------|
+| 統合ポイント1 | [クラス/関数] | [既存処理] | [新処理] | [DI/Factoryなど] |
+| 統合ポイント2 | [別の箇所] | [既存] | [新規] | [方式] |
+
+### 主要コンポーネント
+
+#### コンポーネント1
+
+- **責務**: [このコンポーネントの責務範囲]
+- **インターフェース**: [提供するAPIや型定義]
+- **依存関係**: [他のコンポーネントとの関係]
+
+### 型定義
+
+```typescript
+// 主要な型定義をここに記載
+```
+
+### データ契約
+
+#### コンポーネント1
+
+```yaml
+入力:
+  型: [TypeScript型定義]
+  前提条件: [必須項目、形式の制約]
+  バリデーション: [検証方法]
+
+出力:
+  型: [TypeScript型定義]
+  保証: [常に満たされる条件]
+  エラー時: [例外/null/デフォルト値]
+
+不変条件:
+  - [処理前後で変わらない条件]
+```
+
+### エラーハンドリング
+
+[エラーの種類とその処理方法]
+
+### ロギングとモニタリング
+
+[ログに記録する内容とモニタリング方法]
+
+## 実装計画
+
+### 実装アプローチ
+
+**選択したアプローチ**: [アプローチ名または組み合わせ]
+**選択理由**: [プロジェクト制約と技術的依存関係を考慮した理由]
+
+### 技術的依存関係と実装順序
+
+#### 必要な実装順序
+1. **[コンポーネント/機能A]**
+   - 技術的理由: [なぜ先に実装する必要があるか]
+   - 依存要素: [これに依存する他のコンポーネント]
+
+2. **[コンポーネント/機能B]**
+   - 技術的理由: [Aの後に実装する技術的必要性]
+   - 前提条件: [事前に必要な実装]
+
+### 統合ポイント
+各統合ポイントでE2E確認が必要：
+
+**統合ポイント1: [名称]**
+- コンポーネント: [コンポーネントA] -> [コンポーネントB]
+- 確認方法: [統合が動作することの検証方法]
+
+### 移行戦略
+
+[技術的な移行アプローチ、後方互換性の確保方法]
+
+## テスト戦略
+
+### 単体テスト
+
+[単体テストの方針とカバレッジ目標]
+- 機能受入条件の個別要素を検証
+
+### 統合テスト
+
+[統合テストの方針と重要なテストケース]
+- 機能受入条件の組み合わせ動作を検証
+
+### E2Eテスト
+
+[E2Eテストの方針]
+- 受入条件のシナリオ全体を検証
+- ユーザー視点での機能動作を確認
+
+## セキュリティ考慮事項
+
+[セキュリティ上の懸念点と対策]
+
+## 代替案
+
+### 代替案1
+
+- **概要**: [代替案の説明]
+- **メリット**: [利点]
+- **デメリット**: [欠点]
+- **不採用理由**: [採用しなかった理由]
+
+## リスクと対策
+
+| リスク | 影響度 | 発生確率 | 対策 |
+|-------|-------|---------|-----|
+| [リスク1] | 高/中/低 | 高/中/低 | [対策] |
+
+## 参考資料
+
+- [関連するドキュメントやリンク]
+
+## 更新履歴
+
+| 日付 | バージョン | 変更内容 | 作成者 |
+|-----|-----------|---------|-------|
+| YYYY-MM-DD | 1.0 | 初版作成 | [名前] |

package/.claude/skills/documentation-criteria/references/plan-template.md

@@ -0,0 +1,130 @@
+# 作業計画書: [タイトル]
+
+作成日: YYYY-MM-DD
+種別: feature|fix|refactor
+想定影響範囲: Xファイル
+関連Issue/PR: #XXX（該当する場合）
+
+## 関連ドキュメント
+- 設計書: [docs/design/XXX.md]
+- ADR: [docs/adr/ADR-XXXX.md]（該当する場合）
+- PRD: [docs/prd/XXX.md]（該当する場合）
+
+## 目的
+[なぜこの変更が必要か、何を解決するか]
+
+## 影響範囲
+### 対象ファイル
+- [ ] src/domain/xxx
+- [ ] src/application/xxx
+- [ ] src/infrastructure/xxx
+- [ ] src/presentation/xxx
+
+### テストファイル
+- [ ] __tests__/xxx.test.ts
+- [ ] __tests__/xxx.test.ts
+
+### ドキュメント
+- [ ] ADR作成が必要（アーキテクチャ変更の場合）
+- [ ] 設計書更新が必要
+- [ ] README更新が必要
+
+## 実装計画
+
+（注: フェーズ構成はDesign Docの技術的依存関係と実装アプローチに基づいて決定）
+
+### Phase 1: [フェーズ名]（想定コミット数: X）
+**目的**: [このフェーズで達成すること]
+
+#### タスク
+- [ ] タスク1: 具体的な作業内容
+- [ ] タスク2: 具体的な作業内容
+- [ ] 品質チェック: 段階的品質チェック実施（technical-specスキル参照）
+- [ ] 単体テスト: 関連する全テストがパス
+
+#### フェーズ完了条件
+- [ ] [機能完了条件]
+- [ ] [品質完了条件]
+
+#### 動作確認手順
+1. [動作確認ステップ]
+2. [期待結果の確認]
+3. [パフォーマンス確認（該当する場合）]
+
+### Phase 2: [フェーズ名]（想定コミット数: X）
+**目的**: [このフェーズで達成すること]
+
+#### タスク
+- [ ] タスク1: 具体的な作業内容
+- [ ] タスク2: 具体的な作業内容
+- [ ] 品質チェック: 段階的品質チェック実施（technical-specスキル参照）
+- [ ] 統合テスト: 機能全体の動作確認
+
+#### フェーズ完了条件
+- [ ] [機能完了条件]
+- [ ] [品質完了条件]
+
+#### 動作確認手順
+1. [動作確認ステップ]
+2. [期待結果の確認]
+3. [パフォーマンス確認（該当する場合）]
+
+### Phase 3: [フェーズ名]（想定コミット数: X）
+**目的**: [このフェーズで達成すること]
+
+#### タスク
+- [ ] タスク1: 具体的な作業内容
+- [ ] タスク2: 具体的な作業内容
+- [ ] 品質チェック: 段階的品質チェック実施（technical-specスキル参照）
+- [ ] 統合テスト: コンポーネント連携の検証
+
+#### フェーズ完了条件
+- [ ] [機能完了条件]
+- [ ] [品質完了条件]
+
+#### 動作確認手順
+[Design Docの該当する統合ポイントE2E確認をコピー]
+
+### 最終Phase: 品質保証（必須）（想定コミット数: 1）
+**目的**: 全体品質保証とDesign Doc整合性検証
+
+#### タスク
+- [ ] Design Docの全受入条件達成を確認
+- [ ] 品質チェック（型、lint、format）
+- [ ] 全テスト実行
+- [ ] カバレッジ70%以上
+- [ ] ドキュメント更新
+
+#### 動作確認手順
+[Design DocからE2E確認手順をコピー]
+
+### 品質保証
+- [ ] 段階的品質チェック実施（詳細: technical-specスキル参照）
+
+## リスクと対策
+| リスク | 対策 |
+|-------|-----|
+| [想定されるリスク] | [対処方法] |
+
+## 完了条件
+- [ ] 全フェーズ完了
+- [ ] 各フェーズの動作確認手順を実施
+- [ ] Design Docの受入条件を満たす
+- [ ] 段階的品質チェック完了（エラー0件）
+- [ ] 全テストパス
+- [ ] 必要なドキュメント更新
+- [ ] ユーザーレビュー承認取得
+
+## 進捗記録
+### Phase 1
+- 開始: YYYY-MM-DD HH:MM
+- 完了: YYYY-MM-DD HH:MM
+- 備考: [特記事項]
+
+### Phase 2
+- 開始: YYYY-MM-DD HH:MM
+- 完了: YYYY-MM-DD HH:MM
+- 備考: [特記事項]
+
+## 備考
+[特記事項、参考情報、注意点など]

package/.claude/skills/documentation-criteria/references/prd-template.md

@@ -0,0 +1,109 @@
+# PRD: [機能名]
+
+## 概要
+
+### 一言まとめ
+[この機能を一言で説明]
+
+### 背景
+[なぜこの機能が必要か？どのような問題を解決するか？]
+
+## ユーザーストーリー
+
+### 主要ユーザー
+[主なターゲットユーザーを定義]
+
+### ユーザーストーリー
+```
+[ユーザー種別]として
+[目標/願望]をしたい
+なぜなら[期待する価値/メリット]だから
+```
+
+### ユースケース
+1. [具体的な利用シナリオ1]
+2. [具体的な利用シナリオ2]
+3. [具体的な利用シナリオ3]
+
+## 機能要件
+
+### Must Have（MVP）
+- [ ] 要件1: [詳細説明]
+  - AC: [受入条件 - Given/When/Then形式または測定可能な基準]
+- [ ] 要件2: [詳細説明]
+  - AC: [受入条件]
+- [ ] 要件3: [詳細説明]
+  - AC: [受入条件]
+
+### Nice to Have
+- [ ] 要件1: [詳細説明]
+- [ ] 要件2: [詳細説明]
+
+### スコープ外
+- 項目1: [説明と理由]
+- 項目2: [説明と理由]
+
+## 非機能要件
+
+### パフォーマンス
+- レスポンス時間: [目標値]
+- スループット: [目標値]
+- 同時接続数: [目標値]
+
+### 信頼性
+- 可用性: [目標値]
+- エラー率: [目標値]
+
+### セキュリティ
+- [セキュリティ要件の詳細]
+
+### スケーラビリティ
+- [将来のスケーリングに関する考慮事項]
+
+## 成功基準
+
+### 定量的指標
+1. [測定可能な成功指標1]
+2. [測定可能な成功指標2]
+3. [測定可能な成功指標3]
+
+### 定性的指標
+1. [ユーザー体験の指標1]
+2. [ユーザー体験の指標2]
+
+## 技術的考慮事項
+
+### 依存関係
+- [既存システムへの依存]
+- [外部サービスへの依存]
+
+### 制約
+- [技術的な制約]
+- [リソースの制約]
+
+### 前提条件
+- [確認が必要な前提1]
+- [確認が必要な前提2]
+
+### リスクと対策
+| リスク | 影響度 | 発生確率 | 対策 |
+|-------|-------|---------|-----|
+| [リスク1] | 高/中/低 | 高/中/低 | [対策] |
+| [リスク2] | 高/中/低 | 高/中/低 | [対策] |
+
+## 未決定事項
+
+- [ ] [質問1]: [選択肢や影響の説明]
+- [ ] [質問2]: [選択肢や影響の説明]
+
+*このセクションが空になるまでユーザーと議論し、確認後に削除*
+
+## 付録
+
+### 参考資料
+- [関連ドキュメント1]
+- [関連ドキュメント2]
+
+### 用語集
+- **用語1**: [定義]
+- **用語2**: [定義]

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

@@ -0,0 +1,147 @@
+---
+name: frontend/technical-spec
+description: 環境変数管理、アーキテクチャ設計、ビルド・テストコマンドを含むフロントエンド技術設計ルール。
+---
+
+# 技術設計ルール（フロントエンド）
+
+## 技術スタックの基本方針
+TypeScriptベースのReactアプリケーション実装。アーキテクチャパターンはプロジェクトの要件と規模に応じて選択する。
+
+## 環境変数管理とセキュリティ
+
+### 環境変数管理
+- **ビルドツールの環境変数システムを使用**: `process.env`はブラウザ環境で動作しない
+- 設定レイヤーを通じて環境変数を一元管理
+- TypeScriptによる適切な型安全性の実装
+- デフォルト値設定と必須チェックの適切な実装
+
+```typescript
+// ビルドツールの環境変数（公開値のみ）
+const config = {
+  apiUrl: import.meta.env.API_URL || 'http://localhost:3000',
+  appName: import.meta.env.APP_NAME || 'My App'
+}
+
+// フロントエンドでは動作しない
+const apiUrl = process.env.API_URL // NG
+```
+
+### セキュリティ（クライアントサイド制約）
+- **重要**: すべてのフロントエンドコードは公開され、ブラウザで見える
+- **クライアントサイドに秘密情報を保存しない**: APIキー、トークン、シークレットを環境変数に含めない
+- `.env`ファイルをGitに含めない（バックエンドと同様）
+- 機密情報のログ出力を禁止（パスワード、トークン、個人情報）
+- エラーメッセージに機密情報を含めない
+
+**秘密情報の正しい取り扱い**:
+```typescript
+// セキュリティリスク: APIキーがブラウザで露出
+const apiKey = import.meta.env.VITE_API_KEY
+const response = await fetch(`https://api.example.com/data?key=${apiKey}`)
+
+// 正しい: バックエンドが秘密情報を管理、フロントエンドはプロキシ経由でアクセス
+const response = await fetch('/api/data') // バックエンドがAPIキー認証を処理
+```
+
+## アーキテクチャ設計
+
+### フロントエンドアーキテクチャパターン
+
+**Reactコンポーネントアーキテクチャ**:
+- **Function Components**: 必須、class componentsは非推奨
+- **Custom Hooks**: ロジック再利用と依存性注入のため
+- **コンポーネント階層**: Atoms → Molecules → Organisms → Templates → Pages
+- **Props-driven**: コンポーネントは必要なすべてのデータをPropsで受け取る
+- **Co-location**: テスト、スタイル、関連ファイルをコンポーネントと同じ場所に配置
+
+**状態管理パターン**:
+- **Local State**: コンポーネント固有の状態には`useState`
+- **Context API**: コンポーネントツリー全体で状態を共有（テーマ、認証等）
+- **Custom Hooks**: 状態ロジックと副作用をカプセル化
+- **Server State**: APIデータのキャッシュにはReact QueryまたはSWR
+
+## データフロー統一原則
+
+### クライアントサイドのデータフロー
+Reactアプリケーション全体で一貫したデータフローを維持：
+
+- **Single Source of Truth**: 各状態には1つの権威あるソースがある
+  - UI状態: コンポーネントStateまたはContext
+  - サーバーデータ: React Query/SWRでキャッシュされたAPIレスポンス
+  - フォームデータ: React Hook Formを使ったControlled Components
+
+- **単方向フロー**: データはPropsを通じて上から下へ流れる
+  ```
+  APIレスポンス → State → Props → Render → UI
+  ユーザー入力 → イベントハンドラ → State更新 → 再レンダリング
+  ```
+
+- **Immutable Updates**: State更新には不変パターンを使用
+  ```typescript
+  // 不変なState更新
+  setUsers(prev => [...prev, newUser])
+
+  // 可変なState更新（禁止）
+  users.push(newUser)
+  setUsers(users)
+  ```
+
+### データフローにおける型安全性
+- **Frontend → Backend**: Props/State（型保証済み） → APIリクエスト（シリアライゼーション）
+- **Backend → Frontend**: APIレスポンス（`unknown`） → 型ガード → State（型保証済み）
+
+```typescript
+// 型安全なデータフロー
+async function fetchUser(id: string): Promise<User> {
+  const response = await fetch(`/api/users/${id}`)
+  const data: unknown = await response.json()
+
+  if (!isUser(data)) {
+    throw new Error('Invalid user data')
+  }
+
+  return data // User型として保証
+}
+```
+
+## ビルドとテスト
+package.jsonの`packageManager`フィールドに応じた実行コマンドを使用すること。
+
+### ビルドコマンド
+- `dev` - 開発サーバー
+- `build` - 本番ビルド
+- `preview` - 本番ビルドのプレビュー
+- `type-check` - 型チェック（出力なし）
+
+### テストコマンド
+- `test` - テスト実行
+- `test:coverage` - カバレッジ付きテスト実行
+- `test:coverage:fresh` - カバレッジ付きテスト実行（キャッシュクリア）
+- `test:safe` - 安全なテスト実行（自動クリーンアップ付き）
+- `cleanup:processes` - Vitestプロセスのクリーンアップ
+
+### 品質チェック要件
+実装完了時に品質チェックは必須：
+
+**Phase 1-3: 基本チェック**
+- `check` - Biome（lint + format）
+- `build` - TypeScriptビルド
+
+**Phase 4-5: テストと最終確認**
+- `test` - テスト実行
+- `test:coverage:fresh` - カバレッジ測定
+- `check:all` - 全体統合チェック
+
+### カバレッジ要件
+- **必須**: 単体テストのカバレッジは60%以上
+- **コンポーネント別目標**:
+  - Atoms: 70%以上
+  - Molecules: 65%以上
+  - Organisms: 60%以上
+  - Custom Hooks: 65%以上
+  - Utils: 70%以上
+
+### 非機能要件
+- **ブラウザ互換性**: Chrome/Firefox/Safari/Edge（最新2バージョン）
+- **レンダリング時間**: 主要ページで5秒以内