create-ai-project 1.11.2 → 1.12.0

package/.claude/{commands/sync-rules.md → commands-ja/sync-skills.md}

@@ -1,28 +1,28 @@
 ---
-description: ルール修正後のメタデータ同期とrule-advisor精度最適化
+description: スキル修正後のメタデータ同期とrule-advisor精度最適化
 ---
 
-**コマンドコンテキスト**: ルールファイル編集後のメンテナンス作業
+**コマンドコンテキスト**: スキルファイル編集後のメンテナンス作業
 
 **Think deeply** rule-advisorの実行精度を最大化するための同期作業：
 
 ## 実行フロー
 
-### 1. ルールファイルのスキャン
+### 1. スキルファイルのスキャン
 ```bash
-# 実行時のルールディレクトリ
-RULES_DIR="docs/rules"
-INDEX_FILE="${RULES_DIR}/rules-index.yaml"
+# 実行時のスキルディレクトリ
+SKILLS_DIR=".claude/skills"
+INDEX_FILE=".claude/skills/task-analyzer/references/skills-index.yaml"
 
-# 全ルールファイルを解析
-find "${RULES_DIR}" -name "*.md" -type f | sort
+# 全スキルファイルを解析
+find "${SKILLS_DIR}" -name "SKILL.md" -type f | sort
 ```
 
 ### 2. メタデータ同期と最適化
 
 #### セクション自動同期
-- 各ファイルの`## `セクションを抽出
-- rules-index.yamlのsectionsを自動更新
+- 各SKILL.mdの`## `セクションを抽出
+- skills-index.yamlのsectionsを自動更新
 
 #### タグの最適化
 - ファイル内容からキーワードを分析
@@ -39,23 +39,23 @@ find "${RULES_DIR}" -name "*.md" -type f | sort
 
 ### 3. rule-advisor向け最適化
 
-メタデータの質を向上させ、rule-advisorが正確にルールを選択できるよう調整：
+メタデータの質を向上させ、rule-advisorが正確にスキルを選択できるよう調整：
 
 ```
-=== ルールメタデータ同期 ===
-対象: docs/rules
+=== スキルメタデータ同期 ===
+対象: .claude/skills
 
 実行した更新:
 ✅ sections同期
-  - typescript-testing.md: 2セクション追加
-  - ai-development-guide.md: 1セクション更新
+  - typescript-testing: 2セクション追加
+  - coding-standards: 1セクション更新
 
 ✅ tags最適化
-  - typescript.md: [functional-programming]タグ追加を提案
-  - technical-spec.md: [deprecated]タグ削除を提案
+  - typescript-rules: [functional-programming]タグ追加を提案
+  - technical-spec: [deprecated]タグ削除を提案
 
 ✅ typical-use改善
-  - 3ファイルの説明をより具体的に更新
+  - 3スキルの説明をより具体的に更新
 
 最終結果: rule-advisor精度向上のための最適化完了
 ```
@@ -64,7 +64,7 @@ find "${RULES_DIR}" -name "*.md" -type f | sort
 
 **本質的な目的**:
 - 単なる整合性維持ではなく、rule-advisorの選択精度向上
-- ルール編集作業の仕上げとしてのメタデータ最適化
+- スキル編集作業の仕上げとしてのメタデータ最適化
 
 **品質基準**:
 - sectionsは100%同期必須
@@ -83,23 +83,23 @@ find "${RULES_DIR}" -name "*.md" -type f | sort
 
 ## 実行タイミング
 
-- ルールファイル編集後（必須）
-- 新しいルールファイル追加時
-- 大規模なルール改訂後
+- スキルファイル編集後（必須）
+- 新しいスキルファイル追加時
+- 大規模なスキル改訂後
 - rule-advisorの選択精度が低下したと感じた時
 
 ## 出力例
 
 ```
-=== ルールメタデータ同期開始 ===
-対象: docs/rules (9ファイル)
+=== スキルメタデータ同期開始 ===
+対象: .claude/skills (13スキル)
 
-[1/9] typescript.md
+[1/13] typescript-rules
   ✅ sections: 7件同期完了
   💡 tags提案: +[functional-programming, dependency-injection]
   💡 typical-use: "TypeScript実装全般" → "型安全性重視の実装とモダンTypeScript機能活用"
 
-[2/9] typescript-testing.md
+[2/13] typescript-testing
   ✅ sections: 2件追加（テストの粒度、モックの型安全性）
   ✅ tags: 変更なし
   ✅ typical-use: 現状維持
@@ -107,10 +107,10 @@ find "${RULES_DIR}" -name "*.md" -type f | sort
 ...
 
 === 同期完了 ===
-更新: 3ファイル
+更新: 3スキル
 提案: 5件（承認してください）
 
 rule-advisor精度向上: 推定15%改善
 ```
 
-**スコープ**: ルール修正作業後のメタデータ同期とrule-advisor精度最適化。
+**スコープ**: スキル修正作業後のメタデータ同期とrule-advisor精度最適化。

package/.claude/settings.local.json

@@ -65,7 +65,27 @@
       "Bash(npm pack:*)",
       "Bash(npm view:*)",
       "Bash(npx:*)",
-      "Bash(=20\" for compatibility\n\n🤖 Generated with [Claude Code](https://claude.com/claude-code)\n\nCo-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>\nEOF\n)\")"
+      "WebFetch(domain:zenn.dev)",
+      "Bash(npm version:*)",
+      "Bash(xargs -I {} sh -c 'echo \"\"\"\"=== {} ===\"\"\"\" && head -60 \"\"\"\"{}\"\"\"\"')",
+      "Bash(npm run lang:status:*)",
+      "Bash(npm run lang:en:*)",
+      "Bash(gh pr list:*)",
+      "Bash(xargs:*)",
+      "Bash(npm pkg:*)",
+      "Bash(head:*)",
+      "Bash(for agent in acceptance-test-generator code-reviewer design-sync document-reviewer integration-test-reviewer prd-creator quality-fixer quality-fixer-frontend requirement-analyzer rule-advisor task-decomposer task-executor task-executor-frontend technical-designer technical-designer-frontend work-planner)",
+      "Bash(do)",
+      "Bash(echo:*)",
+      "Bash(while read skill)",
+      "Bash(do if [ -f \".claude/skills-en/$skill/SKILL.md\" ])",
+      "Bash(then echo \"✅ $skill\" else echo \"❌ $skill \\(NOT FOUND\\)\" fi done)",
+      "Bash(for agent in acceptance-test-generator document-reviewer)",
+      "Bash(__NEW_LINE__ echo \"\")",
+      "WebFetch(domain:docs.anthropic.com)",
+      "Bash(git tag:*)",
+      "Bash(npm run build:*)",
+      "Bash(npm run check:*)"
     ],
     "deny": [],
     "ask": [],

package/{docs/rules/ai-development-guide.md → .claude/skills/coding-standards/SKILL.md}

@@ -1,4 +1,9 @@
-# AI開発者ガイド - 技術的判断基準とアンチパターン集
+---
+name: coding-standards
+description: 保守性、可読性、品質のための言語非依存コーディング原則。機能実装、リファクタリング、コードレビュー時に使用。
+---
+
+# 普遍的コーディング規約
 
 ## 技術的アンチパターン（赤信号パターン）
 
@@ -20,22 +25,24 @@
 - **対処療法的修正** - 根本原因を解決しない表面的な修正
 - **無計画な大規模変更** - 段階的アプローチの欠如
 
-## フォールバック処理に関する設計原則
+## 基本原則
+
+- **積極的なリファクタリング** - 技術的負債を防ぎ、健全性を維持
+- **使われない「念のため」のコード禁止** - YAGNI原則（Kent Beck）に反する
+
+## コメント記述ルール
 
-### 基本原則：Fail-Fast
-分散システムにおいて、フォールバック処理よりもプライマリコードの信頼性向上を優先する設計思想。
+- **機能説明重視**: コードが「何をするか」を記述
+- **履歴情報禁止**: 開発履歴は記載しない
+- **タイムレス**: いつ読んでも有効な内容のみ記述
+- **簡潔性**: 必要最小限の説明にとどめる
 
-### フォールバック実装の判断基準
-- **原則禁止**: エラー時の無条件フォールバックは実装しない
-- **例外的許可**: Design Docで明示的に定義された場合のみ実装
-- **レイヤー責務**:
-  - インフラ層: エラーを必ず上位に投げる（フォールバック判断なし）
-  - アプリケーション層: ビジネス要件に基づく判断を実装
+## エラーハンドリングの基本原則
 
-### フォールバック過多の検出
-- 同一機能で3つ目のcatch文を書く時点で設計見直しを必須とする
-- フォールバックを実装する前にDesign Docでの定義を確認
-- エラーは適切にログ出力し、失敗を明確にする
+### Fail-Fast原則
+エラー時は速やかに失敗させ、不正な状態での処理継続を防ぐ。エラーの握りつぶしは禁止。
+
+詳細な実装方法（Result型、カスタムエラークラス、層別エラー処理など）は各言語・フレームワークのルールを参照。
 
 ## Rule of Three - コード重複の判断基準
 
@@ -61,16 +68,6 @@ Martin Fowler「Refactoring」に基づく重複コードの扱い方：
 - 共通化により可読性が著しく低下
 - テストコード内の簡単なヘルパー
 
-### 実装例
-```typescript
-// ❌ 1回目の重複で即共通化
-function validateUserEmail(email: string) { /* ... */ }
-function validateContactEmail(email: string) { /* ... */ }
-
-// ✅ 3回目で共通化
-function validateEmail(email: string, context: 'user' | 'contact' | 'admin') { /* ... */ }
-```
-
 ## よくある失敗パターンと回避方法
 
 ### パターン1: エラー修正の連鎖
@@ -91,20 +88,14 @@ function validateEmail(email: string, context: 'user' | 'contact' | 'admin') { /
 ### パターン4: 技術的不確実性の無視
 **症状**: 新技術導入時の想定外エラー多発
 **原因**: 事前調査なしで「公式ドキュメント通りなら動くはず」
-**回避方法**: 
+**回避方法**:
 - タスクファイル冒頭に確実性評価を記載
-  ```
-  確実性: low（理由: MCP接続の実例がない）
-  探索的実装: true
-  フォールバック: 従来APIを使用
-  ```
 - 確実性lowの場合、最初に最小限の動作確認コードを作成
-- 動作確認できたら本実装、できなければフォールバック実行
 
 ### パターン5: 既存コード調査不足
 **症状**: 重複実装、アーキテクチャ不整合、結合時の障害
 **原因**: 実装前の既存コード理解不足
-**回避方法**: 
+**回避方法**:
 - 実装前に類似機能の存在を必ず検索（同じドメイン、責務、設定パターンをキーワードに）
 - 類似機能を発見 → その実装を使用する（新規実装は行わない）
 - 類似機能が技術的負債 → ADRで改善提案を作成してから実装
@@ -133,85 +124,40 @@ Why5: 破壊的変更を含むメジャーバージョンアップ
 - モックで外部依存を置き換え
 - 問題が再現する最小構成を作成
 
-### 4. デバッグログ出力
-```typescript
-console.log('DEBUG:', {
-  context: 'user-creation',
-  input: { email, name },
-  state: currentState,
-  timestamp: new Date().toISOString()
-})
-```
-
-## 品質チェックコマンドリファレンス
-
-### Phase 1-3: 基本チェック
-```bash
-# Biome総合チェック（lint + format）
-npm run check
-
-# 未使用エクスポートの検出
-npm run check:unused
-
-# TypeScriptビルド
-npm run build
-```
+## 型安全性の基礎
 
-### Phase 4-6: テストと最終確認
-```bash
-# テスト実行
-npm test
+**型安全の原則**: `unknown`型と型ガードを使用する。`any`型は型チェックを無効化し、実行時エラーの原因となる。
 
-# カバレッジ測定（キャッシュクリア）
-npm run test:coverage:fresh
+**any型の代替手段（優先順位順）**
+1. **unknown型 + 型ガード**: 外部入力の検証に使用
+2. **ジェネリクス**: 型の柔軟性が必要な場合
+3. **ユニオン型・インターセクション型**: 複数の型の組み合わせ
+4. **型アサーション（最終手段）**: 型が確実な場合のみ
 
-# 全体統合チェック
-npm run check:all
-```
-
-### 補助コマンド
-```bash
-# カバレッジレポート確認
-open coverage/index.html
-
-# Vitestプロセスのクリーンアップ（テスト後必須）
-npm run cleanup:processes
-
-# 安全なテスト実行（自動クリーンアップ付き）
-npm run test:safe
-
-# 自動修正
-npm run format        # フォーマット修正
-npm run lint:fix      # Lint修正
+**型ガードの実装パターン**
+```typescript
+function isUser(value: unknown): value is User {
+  return typeof value === 'object' && value !== null && 'id' in value && 'name' in value
+}
 ```
 
-### トラブルシューティング
-- **ポート使用中エラー**: `npm run cleanup:processes`
-- **キャッシュ問題**: `npm run test:coverage:fresh`
-- **依存関係エラー**: `npm ci`で再インストール
-
-## 技術的判断が必要な場面
+**型の複雑性管理**
+- フィールド数: 20個まで（超えたら責務で分割、外部API型は例外）
+- オプショナル率: 30%まで（超えたら必須/任意で分離）
+- ネスト深さ: 3階層まで（超えたらフラット化）
+- 型アサーション: 3回以上使用したら設計見直し
+- **外部API型の扱い**: 制約を緩和し、実態に合わせて定義（内部では適切に変換）
 
-### 抽象化のタイミング
-- 具体的な実装を3回書いてからパターンを抽出
-- YAGNIを意識し、現在必要な機能のみ実装
-- 将来の拡張性より現在のシンプルさを優先
+## リファクタリング手法
 
-### パフォーマンス vs 可読性
-- 明確なボトルネックがない限り可読性を優先
-- 計測してから最適化（推測するな、計測せよ）
-- 最適化する場合はコメントで理由を明記
+**基本方針**
+- 小さなステップ: 段階的改善により、常に動作する状態を維持
+- 安全な変更: 一度に変更する範囲を最小限に抑制
+- 動作保証: 既存の動作を変えないことを確認しながら進める
 
-### 型定義の粒度
-- 過度に細かい型は保守性を低下させる
-- ドメインを適切に表現する型を設計
-- ユーティリティ型を活用して重複を削減
+**実施手順**: 現状把握 → 段階的変更 → 動作確認 → 最終検証
 
-## 継続的改善のマインドセット
-
-- **謙虚**: 完璧なコードは存在しない、フィードバック歓迎
-- **勇気**: 必要なリファクタリングは大胆に実行
-- **透明性**: 技術的な判断理由を明確に記録
+**優先順位**: 重複コード削除 > 長大な関数分割 > 複雑な条件分岐簡素化 > 型安全性向上
 
 ## 実装作業の完全性担保
 
@@ -251,10 +197,50 @@ Grep -n "targetData\|SetData\|UpdateData" -o content
 
 対象: コード・ドキュメント・設定ファイル
 
-### 既存コード削除判断フロー
+## Red-Green-Refactorプロセス（テストファースト開発）
 
-```
-使用中？ No → 即削除（Git履歴に残る）
-      Yes → 動作？ No → 削除+再実装
-                  Yes → 修正
-```
+**推奨原則**: コード変更は必ずテストから始める
+
+**開発ステップ**:
+1. **Red**: 期待する動作のテストを書く（失敗する）
+2. **Green**: 最小限の実装でテストを通す
+3. **Refactor**: テストが通る状態を維持しながらコード改善
+
+**NGケース（テストファースト不要）**:
+- 純粋な設定ファイル変更（.env、config等）
+- ドキュメントのみの更新（README、コメント等）
+- 緊急本番障害対応（ただし事後テスト必須）
+
+## テスト設計原則
+
+### テストケースの構造
+- テストは「準備（Arrange）」「実行（Act）」「検証（Assert）」の3段階で構成
+- 各テストの目的が明確に分かる命名
+- 1つのテストケースでは1つの振る舞いのみを検証
+
+### テストデータ管理
+- テストデータは専用ディレクトリで管理
+- 環境変数はテスト用の値を定義
+- 機密情報は必ずモック化
+- テストデータは最小限に保ち、テストケースの検証目的に直接関連するデータのみ使用
+
+### モックとスタブの使用方針
+
+**推奨: 単体テストでの外部依存モック化**
+- メリット: テストの独立性と再現性を確保
+- 実践: DB、API、ファイルシステム等の外部依存をモック化
+
+**避けるべき: 単体テストでの実際の外部接続**
+- 理由: テスト速度が遅くなり、環境依存の問題が発生するため
+
+### テスト失敗時の対応判断基準
+
+**テストを修正**: 間違った期待値、存在しない機能参照、実装詳細への依存、テストのためだけの実装
+**実装を修正**: 妥当な仕様、ビジネスロジック、重要なエッジケース
+**判断に迷ったら**: ユーザーに確認
+
+## テストの粒度原則
+
+### 原則：観測可能な振る舞いのみ
+**テスト対象**：公開API、戻り値、例外、外部呼び出し、永続化された状態
+**テスト対象外**：privateメソッド、内部状態、アルゴリズム詳細

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

@@ -1,3 +1,8 @@
+---
+name: documentation-criteria
+description: PRD、ADR、Design Doc、作業計画書を含むドキュメント作成基準とテンプレート。
+---
+
 # ドキュメント作成基準
 
 ## 作成判定マトリクス
@@ -87,7 +92,7 @@
 - インターフェース定義と型定義
 - データフローとコンポーネント設計
 - **統合ポイントでのE2E確認手順**
-- **受入条件（測定可能な形式）**
+- **受入条件（EARS形式: When/While/If-then/無印）**
 - 変更影響マップ（直接影響/間接影響/波及なしを明記）
 - 統合点の完全な列挙
 - データ契約の明確化
@@ -147,10 +152,10 @@
 
 | ドキュメント | パス | 命名規則 | テンプレート |
 |------------|-----|---------|------------|
-| PRD | `docs/prd/` | `[機能名]-prd.md` | `template-ja.md` |
-| ADR | `docs/adr/` | `ADR-[4桁]-[タイトル].md` | `template-ja.md` |
-| Design Doc | `docs/design/` | `[機能名]-design.md` | `template-ja.md` |
-| 作業計画書 | `docs/plans/` | `YYYYMMDD-{type}-{description}.md` | `template-ja.md` |
+| PRD | `docs/prd/` | `[機能名]-prd.md` | `prd-template.md` |
+| ADR | `docs/adr/` | `ADR-[4桁]-[タイトル].md` | `adr-template.md` |
+| Design Doc | `docs/design/` | `[機能名]-design.md` | `design-template.md` |
+| 作業計画書 | `docs/plans/` | `YYYYMMDD-{type}-{description}.md` | `plan-template.md` |
 
 ※作業計画書は`.gitignore`で除外
 
@@ -177,4 +182,12 @@
 1. **作成時**: 共通技術領域（ログ、エラーハンドリング、非同期処理等）を特定し、既存共通ADRを参照
 2. **不足時**: 必要な共通ADRが存在しない場合は作成を検討
 3. **Design Doc**: 「前提となるADR」セクションで共通ADRを明記
-4. **準拠確認**: 設計が共通ADRの決定事項と整合しているかを検証
+4. **準拠確認**: 設計が共通ADRの決定事項と整合しているかを検証
+
+## テンプレート
+
+テンプレートは`references/`ディレクトリにあります：
+- [Design Documentテンプレート](references/design-template.md)
+- [PRDテンプレート](references/prd-template.md)
+- [作業計画書テンプレート](references/plan-template.md)
+- [ADRテンプレート](references/adr-template.md)

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

@@ -0,0 +1,64 @@
+# [ADR番号] [タイトル]
+
+## ステータス
+
+[Proposed | Accepted | Deprecated | Superseded]
+
+## 経緯
+
+[この決定が必要になった背景と理由を説明。問題の本質、現在の課題、制約を含む]
+
+## 決定事項
+
+[実際に行った決定を説明。具体的で明確な記述を心がける]
+
+### 決定の詳細
+
+| 項目 | 内容 |
+|-----|-----|
+| **決定** | [一文で決定内容] |
+| **なぜ今か** | [今このタイミングで必要な理由] |
+| **なぜこれか** | [代替案との比較理由（1-3行）] |
+| **既知の不確実性** | [現時点で少なくとも1つの不確実性] |
+| **撤回基準** | [この決定を見直すべきシグナル1つ] |
+
+## 根拠
+
+[なぜこの決定を行ったか、代替案と比較して最善である理由を説明]
+
+### 検討した選択肢
+
+1. **選択肢1**: [説明]
+   - メリット: [利点をリストアップ]
+   - デメリット: [欠点をリストアップ]
+
+2. **選択肢2**: [説明]
+   - メリット: [利点をリストアップ]
+   - デメリット: [欠点をリストアップ]
+
+3. **選択肢3（採用）**: [説明]
+   - メリット: [利点をリストアップ]
+   - デメリット: [欠点をリストアップ]
+
+## 影響
+
+### ポジティブな影響
+
+- [プロジェクトやシステムへの良い影響をリストアップ]
+
+### ネガティブな影響
+
+- [受け入れる必要のある負の影響やトレードオフをリストアップ]
+
+### 中立的な影響
+
+- [良くも悪くもない変化をリストアップ]
+
+## 実装指針
+
+[原則的な方向性のみ。実装手順はDesign Docへ]
+例: 「依存性注入を使用」○、「Phase 1で実装」×
+
+## 関連情報
+
+- [関連するADR、ドキュメント、Issue、PRなどへのリンク]