create-ai-project 1.11.2 → 1.12.1

package/.claude/commands-ja/refine-rule.md

@@ -1,206 +0,0 @@
----
-description: ユーザーのルール変更要求を精度最大化して実装
----
-
-変更要求: $ARGUMENTS
-
-**Think deeply** ユーザーの変更意図を汲み取り、LLMが迷わない形で実装：
-
-## 適用する9つの観点
-1. コンテキスト圧迫 vs 実行精度 - 最小記述で最大精度
-2. 重複排除 - ルールファイル内・ルールファイル間の一貫性
-3. 責務の適切な集約 - 関連内容は1ファイルにまとめる（読み込み回数最小化）
-4. 判断基準明確化 - 測定可能な基準
-5. NG→推奨変換 - 推奨形式（背景：NG例を含む）
-6. 表記統一 - 一貫した表現
-7. 前提条件の明示化 - 暗黙前提を言語化
-8. 記述順序最適化 - 冒頭：最重要、末尾：例外
-9. スコープ境界明示 - 扱う/扱わない範囲
-
-## 実行フロー
-
-### 1. 変更要求の理解
-
-未指定時の質問テンプレート：
-```
-1. どのルールファイルを変更しますか？
-   例: typescript.md / ai-development-guide.md / documentation-criteria.md
-
-2. 変更種別を選択：
-   a) 新ルール追加（新しい基準を追加）
-   b) 既存ルール修正（曖昧な記述を明確化）  
-   c) ルール削除（不要になった基準を削除）
-
-3. 具体的な変更内容：
-   例：「any型の使用を禁止するルールを追加」
-   例：「エラーハンドリングの基準を明確化」
-   [ユーザー入力]
-```
-
-### 2. 変更設計案の作成
-
-対象ファイル特定と現状確認：
-
-```
-# ツール選択基準（測定可能な判断）
-if ファイルパスが明示されている:
-  Read: 指定ファイルを直接読み込み（背景：Glob不要でコンテキスト節約）
-else if ファイル名の一部のみ判明:
-  Glob: docs/rules/*{キーワード}*.md で探索
-  Read: 特定したファイルの現状確認
-else:
-  Glob: docs/rules/*.md で全件確認（背景：対象不明時は網羅的探索）
-  ユーザーに対象ファイル選択を確認
-```
-
-変更設計テンプレート：
-```
-【現状】
-「エラーは適切に処理する」（曖昧：「適切」の基準不明）
-
-【ユーザー要求の理解】
-「エラーハンドリングを厳格化したい」→ 測定可能な基準を設定
-
-【変更案】
-「エラーハンドリング実装基準：
-1. try-catch必須条件：
-   - 外部API呼び出し（fetch, axios等）
-   - ファイルI/O操作（fs.readFile等）
-   - JSON.parse、parseInt等の変換処理
-2. エラーログ必須項目：
-   - error.name（エラー種別）
-   - error.stack（発生箇所）
-   - タイムスタンプ（ISO 8601形式）
-3. ユーザー通知基準：
-   - 技術詳細を含まない（NG例：スタックトレース表示）
-   - 対処法を明示（推奨：「再度お試しください」）」
-
-この設計で進めますか？ (y/n)
-```
-
-### 3. 3回見直しプロセス
-
-#### 第1回: 実行精度最大化の観点で追記【追記専用モード】
-開始宣言: 「第1回：追記モードで実行。削除は一切行わない」
-- 曖昧表現→測定可能基準に変換
-  例：「大きい」→「100行以上」「5ファイル以上」
-- 暗黙前提→明示的条件として記載
-  例：「TypeScript環境で」「async関数内で」
-- 例外ケース・エッジケースの定義
-  例：「null/undefinedの場合」「空配列の場合」
-報告: 追記項目数をカウント（最低5項目）
-
-#### 第2回: 批判的修正で冗長性を削減【実修正モード】
-開始宣言: 「第2回：批判的修正モードで実行。冗長と判断した箇所を実際に削除・統合」
-
-修正作業：
-1. 第1回の追記内容を批判的に検証
-2. 以下の観点で実際に修正を実施：
-   - 同一概念の重複 → 統合
-   - 過度に詳細な説明 → 簡潔化
-   - 他ルールとの重複 → 参照に置換
-3. 修正前後の差分を記録（削除理由も明記）
-
-報告フォーマット：
-```
-修正箇所数: X件
-削除・統合した内容:
-- [削除前]: 「詳細な記述」
-  [削除後]: 「簡潔な記述」
-  [理由]: 冗長性の排除
-```
-
-#### 第3回: 差分評価による精度確保【復元判定モード】
-開始宣言: 「第3回：差分評価モードで実行。第2回の修正を検証し、必要なら復元」
-
-検証作業：
-1. 第2回の各修正について評価：
-   - この削除で実装時に迷う可能性があるか？
-   - エッジケースの考慮が漏れていないか？
-2. 精度低下リスクがある削除 → 復元
-3. 妥当な削除 → 維持
-
-最終確認質問（必須回答）：
-「ユーザーの変更要求を正確に実装するための必要十分条件が揃っているか？」
-
-報告: 復元項目数と最終的な削減率
-
-### 4. 承認取得
-
-変更前後の比較を提示し、ユーザー承認を取得。
-
-### 5. 実装
-
-1. 適切なツールで変更適用（ユーザー承認後）
-2. git diffで変更内容を最終確認
-3. `/sync-rules` 実行提案
-
-## 判断基準チェックリスト
-- [ ] 「if-then」形式で表現可能（「～の場合は～する」）
-- [ ] 数値・個数・状態で判定可能（主観的判断を排除）
-- [ ] 関連内容は1ファイルに集約（読み込み回数最小化）
-- [ ] 他ルールとの関係明記（依存・参照・委譲）
-- [ ] NG例を背景情報として含む
-- [ ] 前提条件が全て明示されている
-
-## 削減パターン例
-| パターン | 変換前 | 変換後 |
-|---------|--------|--------|
-| 感情的表現 | 「必ずすべき」 | 「以下の場合に実行（背景：実行しないとビルドエラー）」 |
-| 時間表現 | 「すぐに実行」 | 「エラー検出後、最初に実行」 |
-| 暗黙前提 | 「エラーハンドリングを実装」 | 「TypeScript環境でasync関数のエラーハンドリング実装」 |
-| 順序不明確 | 「以下を考慮：A、B、C」 | 「優先順：1.A（必須）、2.B（推奨）、3.C（任意）」 |
-| 冗長説明 | 「型安全性を確保するため、型を定義し、型チェックを行い、型エラーを防ぐ」 | 「型安全性の確保（定義・チェック・エラー防止）」 |
-| スコープ曖昧 | 「テストを書く」 | 「単体テストを書く（E2Eテストはtest-guideルール参照）」 |
-
-## 出力例
-
-```
-=== 変更実装完了 ===
-
-【ユーザー要求】
-「TypeScriptのエラーハンドリングルールを厳格化したい」
-
-【変更内容】
-対象: docs/rules/typescript.md
-セクション: ## エラーハンドリング
-
-変更前: 
-「エラーは適切に処理する」
-
-変更後（3回見直しプロセス完了）:
-「エラーハンドリング実装基準：
-1. try-catchブロック必須条件：
-   - 外部API呼び出し（fetch, axios等）
-   - ファイルI/O操作（fs.readFile, fs.writeFile等）
-   - JSON.parse、parseInt等の例外発生可能な処理
-2. エラーログ必須項目：
-   - error.name（エラー種別）
-   - error.stack（発生箇所）
-   - new Date().toISOString()（タイムスタンプ）
-3. ユーザー向けメッセージ：
-   - 技術詳細を含まない（NG例：スタックトレース表示）
-   - 具体的な対処法を明示（推奨：「再度お試しください」）」
-
-【改善指標】
-- 判断基準明確度: 0% → 100%（全て測定可能）
-- 曖昧表現: 1箇所 → 0箇所
-- NG例を背景情報として含む
-
-メタデータ同期のため /sync-rules を実行してください。
-```
-
-## 実行順序
-1. ユーザー要求理解
-2. 現状分析
-3. 9観点を適用した変更設計
-4. 3回見直しプロセス
-5. ユーザー承認
-6. 変更適用
-7. sync-rules提案
-
-**スコープ**: ユーザー変更要求の理解と精度最大化実装
-
-## エラーハンドリング
-- **ファイル未発見**: 利用可能なルール一覧を表示
-- **大規模変更検出**: 変更量50%以上の場合、段階的実施を提案

package/.claude/commands-ja/sync-rules.md

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

package/.claude/settings.local.json

@@ -1,74 +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:*)",
-      "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)\")"
-    ],
-    "deny": [],
-    "ask": [],
-    "defaultMode": "acceptEdits"
-  }
-}

package/docs/adr/template-ja.md

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