create-ai-project 1.12.0 → 1.13.0

package/.claude/commands/review.md

@@ -1,78 +0,0 @@
----
-description: Design Doc準拠検証と必要に応じた自動修正
----
-
-**コマンドコンテキスト**: 実装完了後の品質保証専用コマンド
-
-Design Doc（省略時は直近のもの）: $ARGUMENTS
-
-**Think deeply** 準拠検証の本質を理解し、以下のステップで実行：
-
-## 実行フロー
-
-### 1. 前提確認
-```bash
-# Design Docの特定
-ls docs/design/*.md | grep -v template | tail -1
-
-# 実装ファイル確認
-git diff --name-only main...HEAD
-```
-
-### 2. code-reviewer実行
-Design Doc準拠率を検証：
-- 受入条件の充足確認
-- コード品質チェック
-- 実装完全性の評価
-
-### 3. 判定と対応
-
-**判定基準（プロジェクト段階を考慮）**:
-- プロトタイプ: 70%以上で合格
-- 本番実装: 90%以上推奨
-- 重要項目（セキュリティ等）: 準拠率に関わらず必須
-
-**準拠率に基づく対応**:
-
-準拠率が低い場合（本番で90%未満）:
-```
-検証結果: 準拠率 [X]%
-未充足項目:
-- [項目リスト]
-
-修正を実行しますか？ (y/n): 
-```
-
-ユーザーが `y` を選択した場合:
-
-## 🧠 修正実行前のメタ認知
-**必須**: `rule-advisor → TodoWrite → task-executor → quality-fixer`
-
-1. **rule-advisor実行**: 修正の本質を理解（表面的な対症療法 vs 根本解決）
-2. **TodoWrite更新**: 修正タスクを構造化 → `docs/plans/tasks/review-fixes-YYYYMMDD.md`
-3. **task-executor実行**: 自動修正を段階的実行（5ファイル超過で停止）
-4. **quality-fixer実行**: 品質ゲート通過を確認
-5. **再検証**: code-reviewerで改善度を測定
-
-### 4. 最終レポート
-```
-初回準拠率: [X]%
-最終準拠率: [Y]%（修正実行時）
-改善度: [Y-X]%
-
-残存課題:
-- [手動対応が必要な項目]
-```
-
-## 自動修正可能な項目
-- 単純な未実装の受入条件
-- エラーハンドリング追加
-- 型定義の修正
-- 関数分割（長さ・複雑度の改善）
-
-## 自動修正不可能な項目
-- ビジネスロジックの根本的変更
-- アーキテクチャレベルの修正
-- Design Doc自体の不備
-
-**スコープ**: Design Doc準拠検証と自動修正まで。

package/.claude/commands/sync-skills.md

@@ -1,116 +0,0 @@
----
-description: スキル修正後のメタデータ同期とrule-advisor精度最適化
----
-
-**コマンドコンテキスト**: スキルファイル編集後のメンテナンス作業
-
-**Think deeply** rule-advisorの実行精度を最大化するための同期作業：
-
-## 実行フロー
-
-### 1. スキルファイルのスキャン
-```bash
-# 実行時のスキルディレクトリ
-SKILLS_DIR=".claude/skills"
-INDEX_FILE=".claude/skills/task-analyzer/references/skills-index.yaml"
-
-# 全スキルファイルを解析
-find "${SKILLS_DIR}" -name "SKILL.md" -type f | sort
-```
-
-### 2. メタデータ同期と最適化
-
-#### セクション自動同期
-- 各SKILL.mdの`## `セクションを抽出
-- skills-index.yamlのsectionsを自動更新
-
-#### タグの最適化
-- ファイル内容からキーワードを分析
-- 適切なタグの追加提案
-- 不要なタグの削除提案
-
-#### typical-useの更新
-- ファイルの変更内容から使用場面を推測
-- より具体的な利用シーンの記述を提案
-
-#### key-referencesの補完
-- 新しく追加された概念や手法を検出
-- 関連する参考文献の追加を提案
-
-### 3. rule-advisor向け最適化
-
-メタデータの質を向上させ、rule-advisorが正確にスキルを選択できるよう調整：
-
-```
-=== スキルメタデータ同期 ===
-対象: .claude/skills
-
-実行した更新:
-✅ sections同期
-  - typescript-testing: 2セクション追加
-  - coding-standards: 1セクション更新
-
-✅ tags最適化
-  - typescript-rules: [functional-programming]タグ追加を提案
-  - technical-spec: [deprecated]タグ削除を提案
-
-✅ typical-use改善
-  - 3スキルの説明をより具体的に更新
-
-最終結果: rule-advisor精度向上のための最適化完了
-```
-
-## 🧠 メタ認知ポイント
-
-**本質的な目的**:
-- 単なる整合性維持ではなく、rule-advisorの選択精度向上
-- スキル編集作業の仕上げとしてのメタデータ最適化
-
-**品質基準**:
-- sectionsは100%同期必須
-- tagsは内容を正確に反映
-- typical-useは具体的な利用場面を明示
-- key-referencesは最新の手法を網羅
-
-## 変更要否の判断
-
-以下の順序で評価：
-- sectionsが100%同期済み → 「同期確認完了、更新不要」と報告して終了
-- 内容とタグが適切に一致 → 更新不要と判断
-- 改善の余地がある場合のみ → 具体的な修正提案を提示
-
-**注意**: 毎回変更する必要はありません。変更不要な場合はその旨を明確に報告して終了してください。
-
-## 実行タイミング
-
-- スキルファイル編集後（必須）
-- 新しいスキルファイル追加時
-- 大規模なスキル改訂後
-- rule-advisorの選択精度が低下したと感じた時
-
-## 出力例
-
-```
-=== スキルメタデータ同期開始 ===
-対象: .claude/skills (13スキル)
-
-[1/13] typescript-rules
-  ✅ sections: 7件同期完了
-  💡 tags提案: +[functional-programming, dependency-injection]
-  💡 typical-use: "TypeScript実装全般" → "型安全性重視の実装とモダンTypeScript機能活用"
-
-[2/13] typescript-testing
-  ✅ sections: 2件追加（テストの粒度、モックの型安全性）
-  ✅ tags: 変更なし
-  ✅ typical-use: 現状維持
-
-...
-
-=== 同期完了 ===
-更新: 3スキル
-提案: 5件（承認してください）
-
-rule-advisor精度向上: 推定15%改善
-```
-
-**スコープ**: スキル修正作業後のメタデータ同期とrule-advisor精度最適化。

package/.claude/commands/task.md

@@ -1,13 +0,0 @@
----
-description: タスクを適切なルールに従って実行
----
-
-タスク: $ARGUMENTS
-
-実行前に、以下を明確にしてください：
-
-1. **適用ルール**: このタスクに該当する開発ルールは？
-2. **初動**: ルールに基づく最初のアクションは？  
-3. **スコープ境界**: このタスクの完了条件と責務範囲は？
-
-上記を明示してから作業を開始します。

package/.claude/settings.local.json

@@ -1,94 +0,0 @@
-{
-  "$schema": "https://json.schemastore.org/claude-code-settings.json",
-  "permissions": {
-    "allow": [
-      "Bash(npm run check:unused:*)",
-      "Read(/Users/kagawashinsuke/Documents/tacoms-ai-bot/scripts/**)",
-      "WebSearch",
-      "Bash(npx ts-prune:*)",
-      "Bash(git checkout:*)",
-      "Bash(git pull:*)",
-      "Bash(chmod:*)",
-      "Bash(git add:*)",
-      "Bash(git commit:*)",
-      "Bash(gh api:*)",
-      "Bash(git branch:*)",
-      "WebFetch(domain:github.com)",
-      "Bash(npm install:*)",
-      "Bash(git reset:*)",
-      "WebFetch(domain:qiita.com)",
-      "Bash(cat:*)",
-      "Bash(git push:*)",
-      "WebFetch(domain:mermaid.js.org)",
-      "Bash(gh pr view:*)",
-      "Bash(gh pr diff:*)",
-      "Read(//tmp/**)",
-      "Bash(gh repo clone:*)",
-      "Bash(git stash:*)",
-      "Bash(npm run lang:ja:*)",
-      "Bash(find:*)",
-      "Bash(awk:*)",
-      "Bash(grep:*)",
-      "Bash(xargs basename:*)",
-      "WebFetch(domain:dev.to)",
-      "Bash(gh pr checks:*)",
-      "WebFetch(domain:www.anthropic.com)",
-      "Read(//Users/kagawashinsuke/Documents/agentic-code/**)",
-      "Read(//Users/kagawashinsuke/Documents/claude-code-workflows/**)",
-      "Bash(git -C /Users/kagawashinsuke/Documents/claude-code-workflows diff agents/acceptance-test-generator.md)",
-      "Read(//Users/kagawashinsuke/Documents/project-qb/**)",
-      "Bash(git rm:*)",
-      "Bash(git ls-tree:*)",
-      "Bash(node bin/create-project.js:*)",
-      "Bash(node:*)",
-      "WebFetch(domain:martinfowler.com)",
-      "Bash(test:*)",
-      "WebFetch(domain:www.agileconnection.com)",
-      "Bash(git log:*)",
-      "Bash(git mv:*)",
-      "Bash(gh pr create:*)",
-      "Bash(xargs git branch -D)",
-      "Bash(ls:*)",
-      "Bash(git clone:*)",
-      "WebFetch(domain:support.atlassian.com)",
-      "WebFetch(domain:community.atlassian.com)",
-      "WebFetch(domain:www.velir.com)",
-      "WebFetch(domain:scottspence.com)",
-      "WebFetch(domain:arxiv.org)",
-      "WebFetch(domain:dl.acm.org)",
-      "Bash(gh issue create:*)",
-      "Bash(git fetch:*)",
-      "Bash(git diff:*)",
-      "Bash(fi)",
-      "Bash(done)",
-      "WebFetch(domain:www.npmjs.com)",
-      "Bash(npm pack:*)",
-      "Bash(npm view:*)",
-      "Bash(npx:*)",
-      "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": [],
-    "defaultMode": "acceptEdits"
-  }
-}

package/.claude/skills/coding-standards/SKILL.md

@@ -1,246 +0,0 @@
----
-name: coding-standards
-description: 保守性、可読性、品質のための言語非依存コーディング原則。機能実装、リファクタリング、コードレビュー時に使用。
----
-
-# 普遍的コーディング規約
-
-## 技術的アンチパターン（赤信号パターン）
-
-以下のパターンを検出したら即座に停止し、設計を見直すこと：
-
-### コード品質のアンチパターン
-1. **同じようなコードを3回以上書いた** - Rule of Threeに違反
-2. **単一ファイルに複数の責務が混在** - 単一責任原則（SRP）違反
-3. **同じ内容を複数ファイルで定義** - DRY原則違反
-4. **依存関係を確認せずに変更** - 予期しない影響の可能性
-5. **コメントアウトでコード無効化** - バージョン管理を活用すべき
-6. **エラーの握りつぶし** - 問題の隠蔽は技術的負債
-7. **型アサーション（as）の多用** - 型安全性の放棄
-
-### 設計のアンチパターン
-- **「一旦動くように」という思考** - 技術的負債の蓄積
-- **継ぎ足し実装** - 既存コードへの無計画な追加
-- **不確実技術の楽観的実装** - 未知要素を「たぶん動く」前提で設計
-- **対処療法的修正** - 根本原因を解決しない表面的な修正
-- **無計画な大規模変更** - 段階的アプローチの欠如
-
-## 基本原則
-
-- **積極的なリファクタリング** - 技術的負債を防ぎ、健全性を維持
-- **使われない「念のため」のコード禁止** - YAGNI原則（Kent Beck）に反する
-
-## コメント記述ルール
-
-- **機能説明重視**: コードが「何をするか」を記述
-- **履歴情報禁止**: 開発履歴は記載しない
-- **タイムレス**: いつ読んでも有効な内容のみ記述
-- **簡潔性**: 必要最小限の説明にとどめる
-
-## エラーハンドリングの基本原則
-
-### Fail-Fast原則
-エラー時は速やかに失敗させ、不正な状態での処理継続を防ぐ。エラーの握りつぶしは禁止。
-
-詳細な実装方法（Result型、カスタムエラークラス、層別エラー処理など）は各言語・フレームワークのルールを参照。
-
-## Rule of Three - コード重複の判断基準
-
-Martin Fowler「Refactoring」に基づく重複コードの扱い方：
-
-| 重複回数 | 対応 | 理由 |
-|---------|------|------|
-| 1回目 | インライン実装 | 将来の変化が予測できない |
-| 2回目 | 将来の統合を意識 | パターンが見え始める |
-| 3回目 | 共通化実施 | パターンが確立された |
-
-### 共通化の判断基準
-
-**共通化すべきケース**
-- ビジネスロジックの重複
-- 複雑な処理アルゴリズム
-- 一括変更が必要になる可能性が高い箇所
-- バリデーションルール
-
-**共通化を避けるべきケース**
-- 偶然の一致（たまたま同じコード）
-- 将来異なる方向に進化する可能性
-- 共通化により可読性が著しく低下
-- テストコード内の簡単なヘルパー
-
-## よくある失敗パターンと回避方法
-
-### パターン1: エラー修正の連鎖
-**症状**: エラーを修正すると新しいエラーが発生
-**原因**: 根本原因を理解せずに表面的な修正
-**回避方法**: 5 Whysで根本原因を特定してから修正
-
-### パターン2: 型安全性の放棄
-**症状**: any型やasの多用
-**原因**: 型エラーを回避したい衝動
-**回避方法**: unknown型と型ガードで安全に処理
-
-### パターン3: テスト不足での実装
-**症状**: 実装後にバグ多発
-**原因**: Red-Green-Refactorプロセスの無視
-**回避方法**: 必ず失敗するテストから開始
-
-### パターン4: 技術的不確実性の無視
-**症状**: 新技術導入時の想定外エラー多発
-**原因**: 事前調査なしで「公式ドキュメント通りなら動くはず」
-**回避方法**:
-- タスクファイル冒頭に確実性評価を記載
-- 確実性lowの場合、最初に最小限の動作確認コードを作成
-
-### パターン5: 既存コード調査不足
-**症状**: 重複実装、アーキテクチャ不整合、結合時の障害
-**原因**: 実装前の既存コード理解不足
-**回避方法**:
-- 実装前に類似機能の存在を必ず検索（同じドメイン、責務、設定パターンをキーワードに）
-- 類似機能を発見 → その実装を使用する（新規実装は行わない）
-- 類似機能が技術的負債 → ADRで改善提案を作成してから実装
-- 類似機能が存在しない → 既存の設計思想に沿って新規実装
-- すべての判断と根拠をDesign Docの「既存コードベース分析」セクションに記録
-
-## デバッグ手法
-
-### 1. エラー分析手順
-1. エラーメッセージ（最初の行）を正確に読む
-2. スタックトレースの最初と最後に注目
-3. 自分のコードが現れる最初の行を特定
-
-### 2. 5 Whys - 根本原因分析
-```
-症状: TypeScriptのビルドエラー
-Why1: 型定義が一致しない → Why2: インターフェースが更新された
-Why3: 依存関係の変更 → Why4: パッケージ更新の影響
-Why5: 破壊的変更を含むメジャーバージョンアップ
-根本原因: package.jsonでのバージョン指定が不適切
-```
-
-### 3. 最小再現コード
-問題を切り分けるため、最小限のコードで再現を試みる：
-- 関連のない部分を削除
-- モックで外部依存を置き換え
-- 問題が再現する最小構成を作成
-
-## 型安全性の基礎
-
-**型安全の原則**: `unknown`型と型ガードを使用する。`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
-}
-```
-
-**型の複雑性管理**
-- フィールド数: 20個まで（超えたら責務で分割、外部API型は例外）
-- オプショナル率: 30%まで（超えたら必須/任意で分離）
-- ネスト深さ: 3階層まで（超えたらフラット化）
-- 型アサーション: 3回以上使用したら設計見直し
-- **外部API型の扱い**: 制約を緩和し、実態に合わせて定義（内部では適切に変換）
-
-## リファクタリング手法
-
-**基本方針**
-- 小さなステップ: 段階的改善により、常に動作する状態を維持
-- 安全な変更: 一度に変更する範囲を最小限に抑制
-- 動作保証: 既存の動作を変えないことを確認しながら進める
-
-**実施手順**: 現状把握 → 段階的変更 → 動作確認 → 最終検証
-
-**優先順位**: 重複コード削除 > 長大な関数分割 > 複雑な条件分岐簡素化 > 型安全性向上
-
-## 実装作業の完全性担保
-
-### 影響範囲調査の必須手順
-
-**完了定義**: 以下3段階すべての完了
-
-#### 1. 検索（Discovery）
-```bash
-Grep -n "TargetClass\|TargetMethod" -o content
-Grep -n "DependencyClass" -o content
-Grep -n "targetData\|SetData\|UpdateData" -o content
-```
-
-#### 2. 読解（Understanding）
-**必須**: 発見した全ファイルを読み込み、作業に必要な部分をコンテキストに含める：
-- 呼び出し元の目的と文脈
-- 依存関係の方向
-- データフロー: 生成→変更→参照
-
-#### 3. 特定（Identification）
-影響範囲の構造化報告（必須）：
-```
-## 影響範囲分析
-### 直接影響: ClassA、ClassB（理由明記）
-### 間接影響: SystemX、PrefabY（連携経路明記）
-### 処理フロー: 入力→処理1→処理2→出力
-```
-
-**重要**: 検索のみで完了とせず、3段階すべてを実行すること
-
-### 未使用コード削除ルール
-
-未使用コード検出時 → 使用予定？
-- Yes → 即実装（保留禁止）
-- No → 即削除（Git履歴に残る）
-
-対象: コード・ドキュメント・設定ファイル
-
-## Red-Green-Refactorプロセス（テストファースト開発）
-
-**推奨原則**: コード変更は必ずテストから始める
-
-**開発ステップ**:
-1. **Red**: 期待する動作のテストを書く（失敗する）
-2. **Green**: 最小限の実装でテストを通す
-3. **Refactor**: テストが通る状態を維持しながらコード改善
-
-**NGケース（テストファースト不要）**:
-- 純粋な設定ファイル変更（.env、config等）
-- ドキュメントのみの更新（README、コメント等）
-- 緊急本番障害対応（ただし事後テスト必須）
-
-## テスト設計原則
-
-### テストケースの構造
-- テストは「準備（Arrange）」「実行（Act）」「検証（Assert）」の3段階で構成
-- 各テストの目的が明確に分かる命名
-- 1つのテストケースでは1つの振る舞いのみを検証
-
-### テストデータ管理
-- テストデータは専用ディレクトリで管理
-- 環境変数はテスト用の値を定義
-- 機密情報は必ずモック化
-- テストデータは最小限に保ち、テストケースの検証目的に直接関連するデータのみ使用
-
-### モックとスタブの使用方針
-
-**推奨: 単体テストでの外部依存モック化**
-- メリット: テストの独立性と再現性を確保
-- 実践: DB、API、ファイルシステム等の外部依存をモック化
-
-**避けるべき: 単体テストでの実際の外部接続**
-- 理由: テスト速度が遅くなり、環境依存の問題が発生するため
-
-### テスト失敗時の対応判断基準
-
-**テストを修正**: 間違った期待値、存在しない機能参照、実装詳細への依存、テストのためだけの実装
-**実装を修正**: 妥当な仕様、ビジネスロジック、重要なエッジケース
-**判断に迷ったら**: ユーザーに確認
-
-## テストの粒度原則
-
-### 原則：観測可能な振る舞いのみ
-**テスト対象**：公開API、戻り値、例外、外部呼び出し、永続化された状態
-**テスト対象外**：privateメソッド、内部状態、アルゴリズム詳細