create-ai-project 1.11.2 → 1.12.0

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

@@ -0,0 +1,261 @@
+# [機能名] 設計書
+
+## 概要
+
+[この機能の目的と概要を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や型定義]
+- **依存関係**: [他のコンポーネントとの関係]
+
+#### コンポーネント2
+
+- **責務**: [このコンポーネントの責務範囲]
+- **インターフェース**: [提供するAPIや型定義]
+- **依存関係**: [他のコンポーネントとの関係]
+
+### 型定義
+
+```typescript
+// 主要な型定義をここに記載
+```
+
+### データ契約
+
+#### コンポーネント1
+
+```yaml
+入力:
+  型: [TypeScript型定義]
+  前提条件: [必須項目、形式の制約]
+  バリデーション: [検証方法]
+
+出力:
+  型: [TypeScript型定義]
+  保証: [常に満たされる条件]
+  エラー時: [例外/null/デフォルト値]
+
+不変条件:
+  - [処理前後で変わらない条件]
+```
+
+### 状態遷移と不変条件
+
+[機能が状態管理を含む場合、状態遷移と不変条件をここに記述]
+
+```
+[状態A] ---(イベント1)---> [状態B]
+[状態B] ---(イベント2)---> [状態C]
+```
+
+**不変条件**:
+- [常に成立しなければならない条件]
+- [有効な状態遷移の制約]
+
+### エラーハンドリング
+
+[エラーの種類とその処理方法]
+
+### ロギングとモニタリング
+
+[ログに記録する内容とモニタリング方法]
+
+## 実装計画
+
+### 実装アプローチ
+
+**選択したアプローチ**: [アプローチ名または組み合わせ]
+**選択理由**: [プロジェクト制約と技術的依存関係を考慮した理由]
+
+### 技術的依存関係と実装順序
+
+#### 必要な実装順序
+1. **[コンポーネント/機能A]**
+   - 技術的理由: [なぜ先に実装する必要があるか]
+   - 依存要素: [これに依存する他のコンポーネント]
+
+2. **[コンポーネント/機能B]**
+   - 技術的理由: [Aの後に実装する技術的必要性]
+   - 前提条件: [事前に必要な実装]
+
+### 統合ポイント
+各統合ポイントでE2E確認が必要：
+
+**統合ポイント1: [名称]**
+- コンポーネント: [コンポーネントA] -> [コンポーネントB]
+- 確認方法: [統合が動作することの検証方法]
+
+### 移行戦略
+
+[技術的な移行アプローチ、後方互換性の確保方法]
+
+## テスト戦略
+
+### 単体テスト
+
+[単体テストの方針とカバレッジ目標]
+- 機能受入条件の個別要素を検証
+
+### 統合テスト
+
+[統合テストの方針と重要なテストケース]
+- 機能受入条件の組み合わせ動作を検証
+
+### E2Eテスト
+
+[E2Eテストの方針]
+- 受入条件のシナリオ全体を検証
+- ユーザー視点での機能動作を確認
+
+## セキュリティ考慮事項
+
+[セキュリティ上の懸念点と対策]
+
+## 代替案
+
+### 代替案1
+
+- **概要**: [代替案の説明]
+- **メリット**: [利点]
+- **デメリット**: [欠点]
+- **不採用理由**: [採用しなかった理由]
+
+## リスクと対策
+
+| リスク | 影響度 | 発生確率 | 対策 |
+|-------|-------|---------|-----|
+| [リスク1] | 高/中/低 | 高/中/低 | [対策] |
+
+## 参考資料
+
+- [関連するドキュメントやリンク]
+
+## 更新履歴
+
+| 日付 | バージョン | 変更内容 | 作成者 |
+|-----|-----------|---------|-------|
+| YYYY-MM-DD | 1.0 | 初版作成 | [名前] |

package/{docs/plans/template-ja.md → .claude/skills-ja/documentation-criteria/references/plan-template.md}

@@ -3,15 +3,15 @@
 作成日: YYYY-MM-DD
 種別: feature|fix|refactor
 想定影響範囲: Xファイル
-関連Issue/PR: #XXX（あれば）
+関連Issue/PR: #XXX（該当する場合）
 
 ## 関連ドキュメント
-- Design Doc: [docs/design/XXX.md]
-- ADR: [docs/adr/ADR-XXXX.md]（あれば）
-- PRD: [docs/prd/XXX.md]（あれば）
+- 設計書: [docs/design/XXX.md]
+- ADR: [docs/adr/ADR-XXXX.md]（該当する場合）
+- PRD: [docs/prd/XXX.md]（該当する場合）
 
 ## 目的
-[なぜこの変更が必要か、解決する問題は何か]
+[なぜこの変更が必要か、何を解決するか]
 
 ## 影響範囲
 ### 対象ファイル
@@ -26,8 +26,8 @@
 
 ### ドキュメント
 - [ ] ADR作成が必要（アーキテクチャ変更の場合）
-- [ ] Design Doc更新が必要
-- [ ] READMEの更新が必要
+- [ ] 設計書更新が必要
+- [ ] README更新が必要
 
 ## 実装計画
 
@@ -39,15 +39,15 @@
 #### タスク
 - [ ] タスク1: 具体的な作業内容
 - [ ] タスク2: 具体的な作業内容
-- [ ] 品質チェック: 段階的品質チェック実施（@docs/rules/technical-spec.md の「ビルドとテスト」参照）
-- [ ] 単体テスト: 関連するテストがすべてパス
+- [ ] 品質チェック: 段階的品質チェック実施（technical-specスキル参照）
+- [ ] 単体テスト: 関連する全テストがパス
 
 #### フェーズ完了条件
-- [ ] [機能的な完了条件]
-- [ ] [品質的な完了条件]
+- [ ] [機能完了条件]
+- [ ] [品質完了条件]
 
 #### 動作確認手順
-1. [動作確認手順]
+1. [動作確認ステップ]
 2. [期待結果の確認]
 3. [パフォーマンス確認（該当する場合）]
 
@@ -57,15 +57,15 @@
 #### タスク
 - [ ] タスク1: 具体的な作業内容
 - [ ] タスク2: 具体的な作業内容
-- [ ] 品質チェック: 段階的品質チェック実施（@docs/rules/technical-spec.md の「ビルドとテスト」参照）
+- [ ] 品質チェック: 段階的品質チェック実施（technical-specスキル参照）
 - [ ] 統合テスト: 機能全体の動作確認
 
 #### フェーズ完了条件
-- [ ] [機能的な完了条件]
-- [ ] [品質的な完了条件]
+- [ ] [機能完了条件]
+- [ ] [品質完了条件]
 
 #### 動作確認手順
-1. [動作確認手順]
+1. [動作確認ステップ]
 2. [期待結果の確認]
 3. [パフォーマンス確認（該当する場合）]
 
@@ -75,56 +75,56 @@
 #### タスク
 - [ ] タスク1: 具体的な作業内容
 - [ ] タスク2: 具体的な作業内容
-- [ ] 品質チェック: 段階的品質チェック実施（@docs/rules/technical-spec.md の「ビルドとテスト」参照）
-- [ ] 統合テスト: コンポーネント間の連携確認
+- [ ] 品質チェック: 段階的品質チェック実施（technical-specスキル参照）
+- [ ] 統合テスト: コンポーネント連携の検証
 
 #### フェーズ完了条件
-- [ ] [機能的な完了条件]
-- [ ] [品質的な完了条件]
+- [ ] [機能完了条件]
+- [ ] [品質完了条件]
 
 #### 動作確認手順
-[Design Docの該当統合ポイントのE2E確認を転記]
+[Design Docの該当する統合ポイントE2E確認をコピー]
 
 ### 最終Phase: 品質保証（必須）（想定コミット数: 1）
-**目的**: 全体品質の保証とDesign Doc整合性確認
+**目的**: 全体品質保証とDesign Doc整合性検証
 
 #### タスク
-- [ ] Design Doc全受入条件の達成確認
-- [ ] 品質チェック（型、lint、フォーマット）
+- [ ] Design Docの全受入条件達成を確認
+- [ ] 品質チェック（型、lint、format）
 - [ ] 全テスト実行
 - [ ] カバレッジ70%以上
 - [ ] ドキュメント更新
 
 #### 動作確認手順
-[Design DocのE2E確認手順を転記]
+[Design DocからE2E確認手順をコピー]
 
 ### 品質保証
-- [ ] 段階的品質チェック実施（詳細: @docs/rules/technical-spec.md の「ビルドとテスト」参照）
+- [ ] 段階的品質チェック実施（詳細: technical-specスキル参照）
 
 ## リスクと対策
 | リスク | 対策 |
-|--------|------|
-| [想定されるリスク] | [対策方法] |
+|-------|-----|
+| [想定されるリスク] | [対処方法] |
 
 ## 完了条件
-- [ ] すべてのフェーズが完了
-- [ ] 各フェーズの動作確認手順を実施済み
-- [ ] Design Docの受入条件を満たしている
-- [ ] 段階的品質チェック完了（エラーゼロ）
-- [ ] すべてのテストがパス
-- [ ] 必要なドキュメントが更新されている
-- [ ] ユーザーレビューで承認を得る
+- [ ] 全フェーズ完了
+- [ ] 各フェーズの動作確認手順を実施
+- [ ] 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/{docs/prd/template-ja.md → .claude/skills-ja/documentation-criteria/references/prd-template.md}

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

package/{docs/rules-ja/frontend/technical-spec.md → .claude/skills-ja/frontend/technical-spec/SKILL.md}

@@ -1,3 +1,8 @@
+---
+name: frontend/technical-spec
+description: 環境変数管理、アーキテクチャ設計、ビルド・テストコマンドを含むフロントエンド技術設計ルール。
+---
+
 # 技術設計ルール（フロントエンド）
 
 ## 技術スタックの基本方針
@@ -12,14 +17,14 @@ TypeScriptベースのReactアプリケーション実装。アーキテクチ
 - デフォルト値設定と必須チェックの適切な実装
 
 ```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
+// フロントエンドでは動作しない
+const apiUrl = process.env.API_URL // NG
 ```
 
 ### セキュリティ（クライアントサイド制約）
@@ -31,18 +36,17 @@ const apiUrl = process.env.API_URL
 
 **秘密情報の正しい取り扱い**:
 ```typescript
-// ❌ セキュリティリスク: APIキーがブラウザで露出
+// セキュリティリスク: 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キー認証を処理
 ```
 
 ## アーキテクチャ設計
 
 ### フロントエンドアーキテクチャパターン
-選択したプロジェクトパターンを厳格に遵守。プロジェクト固有の詳細は`docs/rules/architecture/`を参照。
 
 **Reactコンポーネントアーキテクチャ**:
 - **Function Components**: 必須、class componentsは非推奨
@@ -75,10 +79,10 @@ Reactアプリケーション全体で一貫したデータフローを維持：
 
 - **Immutable Updates**: State更新には不変パターンを使用
   ```typescript
-  // ✅ 不変なState更新
+  // 不変なState更新
   setUsers(prev => [...prev, newUser])
 
-  // ❌ 可変なState更新
+  // 可変なState更新（禁止）
   users.push(newUser)
   setUsers(users)
   ```
@@ -88,7 +92,7 @@ Reactアプリケーション全体で一貫したデータフローを維持：
 - **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()