@k2works/claude-code-booster 0.7.0 → 0.9.0

package/lib/assets/.claude/commands/fix-error.md

@@ -1,258 +0,0 @@
-## Error Fix
-
-エラーメッセージから根本原因を特定し、実証済みの解決策を提案します。
-
-### 使い方
-
-```bash
-/fix-error [オプション]
-```
-
-### オプション
-
-- なし : 標準的なエラー分析
-- `--deep` : 深層分析モード（依存関係・環境要因を含む）
-- `--preventive` : 予防策重視の分析
-- `--quick` : 即座に適用可能な修正のみ提示
-
-### 基本例
-
-```bash
-# 標準的なエラー分析
-npm run build 2>&1
-/fix-error
-「ビルドエラーを分析して修正方法を提示して」
-
-# 深層分析モード
-python app.py 2>&1
-/fix-error --deep
-「エラーの根本原因を環境要因も含めて分析して」
-
-# 即座の修正重視
-cargo test 2>&1
-/fix-error --quick
-「すぐに適用できる修正方法を提示して」
-
-# 予防策重視
-./app 2>&1 | tail -50
-/fix-error --preventive
-「エラーの修正と今後の予防策を提示して」
-```
-
-### Claude との連携
-
-```bash
-# エラーログの分析
-cat error.log
-/fix-error
-「エラーの根本原因を特定し、修正方法を提案して」
-
-# テスト失敗の解決
-npm test 2>&1
-/fix-error --quick
-「失敗したテストを分析し、即座に適用できる修正案を提示して」
-
-# スタックトレースの解析
-python script.py 2>&1
-/fix-error --deep
-「このスタックトレースから問題箇所を特定して環境要因も含めて分析して」
-
-# 複数のエラーをまとめて解決
-grep -E "ERROR|WARN" app.log | tail -20
-/fix-error
-「これらのエラーと警告を優先度順に分類し、それぞれの解決方法を提案して」
-```
-
-### エラー分析の優先度
-
-#### 緊急度: 高（即座の対応必須）
-
-- **アプリケーション停止**: クラッシュ、無限ループ、デッドロック
-- **データ損失リスク**: データベースエラー、ファイル破損
-- **セキュリティ脆弱性**: 認証失敗、権限エラー、インジェクション
-- **本番環境影響**: デプロイ失敗、サービス停止
-
-#### 🟡 緊急度: 中（早期対応推奨）
-
-- **パフォーマンス問題**: メモリリーク、遅延、タイムアウト
-- **部分的機能不全**: 特定機能のエラー、UI の不具合
-- **開発効率低下**: ビルドエラー、テスト失敗
-
-#### 🟢 緊急度: 低（計画的対応）
-
-- **警告メッセージ**: deprecation、lint エラー
-- **開発環境限定**: ローカル環境のみの問題
-- **将来的リスク**: 技術的負債、保守性の問題
-
-### 分析プロセス
-
-#### Phase 1: エラー情報収集
-
-```bash
-🔴 必須実行:
-- エラーメッセージの完全な取得
-- スタックトレースの確認
-- 発生条件の特定（再現可能性）
-
-🟡 早期実行:
-- 環境情報の収集（OS、バージョン、依存関係）
-- 直前の変更履歴（git log、最近のコミット）
-- 関連ログの確認
-
-🟢 追加実行:
-- システムリソース状況
-- ネットワーク状態
-- 外部サービス状態
-```
-
-#### Phase 2: 根本原因分析
-
-1. **表面的症状の整理**
-   - エラーメッセージの正確な内容
-   - 発生タイミングとパターン
-   - 影響範囲の特定
-
-2. **深層原因の特定**
-   - 5 Whys 分析の適用
-   - 依存関係の追跡
-   - 環境差異の確認
-
-3. **仮説の検証**
-   - 最小再現コードの作成
-   - 分離テストの実行
-   - 原因の絞り込み
-
-#### Phase 3: 解決策の実装
-
-```bash
-🔴 即座の対処（ホットフィックス）:
-- 症状を抑える最小限の修正
-- 一時的な回避策の適用
-- 緊急デプロイの準備
-
-🟡 根本的解決:
-- 原因に対する本質的な修正
-- テストケースの追加
-- ドキュメントの更新
-
-🟢 予防策の実装:
-- エラーハンドリングの強化
-- 監視・アラートの設定
-- CI/CD パイプラインの改善
-```
-
-### 出力例
-
-```
-🚨 エラー分析レポート
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-📍 エラー概要
-├─ 種別: [コンパイル/実行時/論理/環境]
-├─ 緊急度: 🔴 高 / 🟡 中 / 🟢 低
-├─ 影響範囲: [機能名/コンポーネント]
-└─ 再現性: [100% / 断続的 / 特定条件]
-
-🔍 根本原因
-├─ 直接原因: [具体的な原因]
-├─ 背景要因: [環境/設定/依存関係]
-└─ トリガー: [発生条件]
-
-💡 解決策
-🔴 即座の対処:
-1. [具体的な修正コマンド/コード]
-2. [一時的な回避策]
-
-🟡 根本的解決:
-1. [本質的な修正方法]
-2. [必要なリファクタリング]
-
-🟢 予防策:
-1. [エラーハンドリング改善]
-2. [テスト追加]
-3. [監視設定]
-
-📝 検証手順
-1. [修正適用後の確認方法]
-2. [テスト実行コマンド]
-3. [動作確認項目]
-```
-
-### エラータイプ別の分析手法
-
-#### コンパイル/ビルドエラー
-
-```bash
-# TypeScript の型エラー
-必須確認（高）:
-- tsconfig.json の設定
-- 型定義ファイル（.d.ts）の存在
-- import 文の正確性
-
-# Rust のライフタイムエラー
-必須確認（高）:
-- 所有権の移動
-- 参照の有効期間
-- ミュータビリティの競合
-```
-
-#### 実行時エラー
-
-```bash
-# Null/Undefined 参照
-必須確認（高）:
-- オプショナルチェイニング不足
-- 初期化タイミング
-- 非同期処理の完了待機
-
-# メモリ関連エラー
-必須確認（高）:
-- ヒープダンプの取得
-- GC ログの分析
-- 循環参照の検出
-```
-
-#### 依存関係エラー
-
-```bash
-# バージョン競合
-必須確認（高）:
-- lock ファイルの整合性
-- peer dependencies の要件
-- 推移的依存関係
-
-# モジュール解決エラー
-必須確認（高）:
-- NODE_PATH 設定
-- パスエイリアス設定
-- シンボリックリンク
-```
-
-### 注意事項
-
-- **絶対禁止**: エラーメッセージの一部のみでの判断、検証なしでの Stack Overflow 解決策の適用
-- **例外条件**: 一時的な回避策は以下の 3 つの条件のみ許可
-  1. 本番環境の緊急対応（24 時間以内に根本解決必須）
-  2. 外部サービス障害（復旧待ちの間の代替手段）
-  3. 既知のフレームワークバグ（修正版リリース待ち）
-- **推奨事項**: 根本原因の特定を最優先し、表面的な修正を避ける
-
-### ベストプラクティス
-
-1. **完全な情報収集**: エラーメッセージの最初から最後まで確認
-2. **再現性の確認**: 最小再現コードの作成を最優先
-3. **段階的アプローチ**: 小さな修正から始めて検証
-4. **ドキュメント化**: 解決過程を記録して知識共有
-
-#### よくある落とし穴
-
-- **症状への対処**: 根本原因を見逃す表面的な修正
-- **過度な一般化**: 特定ケースの解決策を広範に適用
-- **検証の省略**: 修正後の副作用を確認しない
-- **知識の属人化**: 解決方法を文書化しない
-
-### 関連コマンド
-
-- `/design-patterns` : コード構造の問題を分析してパターン提案
-- `/tech-debt` : 技術的負債の観点からエラーの根本原因を分析
-- `/analyzer` : より深い根本原因分析が必要な場合

package/lib/assets/.claude/commands/multi-role.md

@@ -1,291 +0,0 @@
-## Multi Role
-
-複数のロールで同じ対象を並行分析し、統合レポートを生成するコマンド。
-
-### 使い方
-
-```bash
-/multi-role <ロール 1>,<ロール 2> [--agent|-a] [分析対象]
-/multi-role <ロール 1>,<ロール 2>,<ロール 3> [--agent|-a] [分析対象]
-```
-
-**重要**:
-
-- `--agent` オプションはロール指定の直後に配置してください
-- メッセージは `--agent` の後に記述してください
-- 正しい例: `/multi-role qa,architect --agent 計画を評価して`
-- 間違った例: `/multi-role qa,architect 計画を評価して --agent`
-
-### オプション
-
-- `--agent` または `-a` : 各ロールをサブエージェントとして並列実行（大規模分析時推奨）
-  - このオプションを使用すると、各ロールの description に自動委任促進フレーズ（"use PROACTIVELY" など）が含まれている場合、より積極的な自動委任が有効になります
-
-### 基本例
-
-```bash
-# セキュリティとパフォーマンスの両面分析（通常）
-/multi-role security,performance
-「この API エンドポイントを評価して」
-
-# 大規模システムの並列分析（サブエージェント）
-/multi-role security,performance --agent
-「システム全体のセキュリティとパフォーマンスを包括的に分析」
-
-# フロントエンド・モバイル・パフォーマンスの統合分析
-/multi-role frontend,mobile,performance
-「この画面の最適化案を検討して」
-
-# アーキテクチャ設計の多角的評価（サブエージェント）
-/multi-role architect,security,performance --agent
-「マイクロサービス化の設計を評価して」
-```
-
-### 分析プロセス
-
-### Phase 1: 並行分析
-
-各ロールが独立して同じ対象を分析
-
-- 専門視点からの評価実行
-- ロール固有の基準で判定
-- 独立した推奨事項の生成
-
-### Phase 2: 統合分析
-
-結果を構造化して統合
-
-- 各ロールの評価結果整理
-- 重複・矛盾点の特定
-- 補完関係の明確化
-
-### Phase 3: 統合レポート
-
-最終的な推奨事項の生成
-
-- 優先度付きアクションプラン
-- トレードオフの明示
-- 実装ロードマップ提示
-
-### 出力フォーマット例
-
-### 2 ロール分析の場合
-
-```
-マルチロール分析: Security + Performance
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-分析対象: API エンドポイント /api/users
-
-Security 分析結果:
-認証: JWT 検証が適切に実装
-認可: ロールベースアクセス制御が不完全
-暗号化: API キーが平文でログ出力
-
-評価スコア: 65/100
-重要度: High（機密データアクセスのため）
-
-Performance 分析結果:
-レスポンス時間: 平均 180ms（目標 200ms 以内）
-データベースクエリ: N+1 問題を検出
-キャッシュ: Redis キャッシュ未実装
-
-評価スコア: 70/100
-重要度: Medium（現状は許容範囲内）
-
-相互関連分析:
-相乗効果の機会:
-- Redis キャッシュ実装時に暗号化も同時考慮
-- ログ出力の改善でセキュリティ＋パフォーマンス向上
-
-トレードオフポイント:
-- 認可チェック強化 ↔ レスポンス時間への影響
-- ログ暗号化 ↔ デバッグ効率の低下
-
-統合優先度:
-Critical: API キー平文出力の修正
-High: N+1 クエリの解決
-Medium: Redis キャッシュ + 暗号化の実装
-Low: 認可制御の詳細化
-
-実装ロードマップ:
-週 1: API キーのマスキング実装
-週 2: データベースクエリ最適化
-週 3-4: キャッシュレイヤーの設計・実装
-月 2: 認可制御の段階的強化
-```
-
-### 3 ロール分析の場合
-
-```
-マルチロール分析: Frontend + Mobile + Performance
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-分析対象: ユーザープロフィール画面
-
-Frontend 分析結果:
-ユーザビリティ: 直感的なレイアウト
-アクセシビリティ: WCAG 2.1 準拠率 85%
-レスポンシブ: タブレット表示に課題
-
-Mobile 分析結果:
-タッチターゲット: 44pt 以上確保
-片手操作: 重要ボタンが上部に配置
-オフライン対応: 未実装
-
-Performance 分析結果:
-初期表示: LCP 2.1 秒（良好）
-画像最適化: WebP 未対応
-遅延読み込み: 未実装
-
-統合推奨事項:
-1. モバイル最適化（片手操作 + オフライン対応）
-2. 画像最適化（WebP + 遅延読み込み）
-3. タブレット UI の改善
-
-優先度: Mobile > Performance > Frontend
-実装期間: 3-4 週間
-```
-
-### 効果的な組み合わせパターン
-
-### セキュリティ重視
-
-```bash
-/multi-role security,architect
-「認証システムの設計」
-
-/multi-role security,frontend  
-「ログイン画面のセキュリティ」
-
-/multi-role security,mobile
-「モバイルアプリのデータ保護」
-```
-
-### パフォーマンス重視
-
-```bash
-/multi-role performance,architect
-「スケーラビリティ設計」
-
-/multi-role performance,frontend
-「Web ページの高速化」
-
-/multi-role performance,mobile
-「アプリの動作最適化」
-```
-
-### ユーザー体験重視
-
-```bash
-/multi-role frontend,mobile
-「クロスプラットフォーム UI」
-
-/multi-role frontend,performance
-「UX とパフォーマンスのバランス」
-
-/multi-role mobile,performance
-「モバイル UX の最適化」
-```
-
-### 包括的分析
-
-```bash
-/multi-role architect,security,performance
-「システム全体の評価」
-
-/multi-role frontend,mobile,performance
-「ユーザー体験の総合評価」
-
-/multi-role security,performance,mobile
-「モバイルアプリの総合診断」
-```
-
-### Claude との連携
-
-```bash
-# ファイル分析と組み合わせ
-cat src/components/UserProfile.tsx
-/multi-role frontend,mobile
-「このコンポーネントを複数の視点で評価して」
-
-# 設計ドキュメントの評価
-cat architecture-design.md
-/multi-role architect,security,performance
-「この設計を複数の専門分野で評価して」
-
-# エラー分析
-cat performance-issues.log
-/multi-role performance,analyzer
-「パフォーマンス問題を多角的に分析して」
-```
-
-### multi-role vs role-debate の使い分け
-
-### multi-role を使う場面
-
-- 各専門分野の独立した評価が欲しい
-- 統合的な改善計画を立てたい
-- 矛盾や重複を整理したい
-- 実装優先度を決めたい
-
-### role-debate を使う場面
-
-- 専門分野間でトレードオフがある
-- 技術選定で意見が分かれそう
-- 設計方針を議論で決めたい
-- 異なる視点での議論を聞きたい
-
-### サブエージェント並列実行（--agent）
-
-`--agent` オプションを使用すると、各ロールが独立したサブエージェントとして並列実行されます。
-
-#### 自動委任の促進
-
-ロールファイルの description フィールドに以下のようなフレーズが含まれている場合、`--agent` 使用時により積極的な自動委任が有効化されます：
-
-- "use PROACTIVELY"
-- "MUST BE USED"
-- その他の強調表現
-
-#### 実行フロー
-
-```
-通常実行:
-ロール 1 → ロール 2 → ロール 3 → 統合
-（順次実行、約 3-5 分）
-
---agent 実行:
-ロール 1 ─┐
-ロール 2 ─┼→ 統合
-ロール 3 ─┘
-（並列実行、約 1-2 分）
-```
-
-#### 効果的な使用例
-
-```bash
-# 大規模システムの総合評価
-/multi-role architect,security,performance,qa --agent
-「新システムの包括的評価」
-
-# 複数観点での詳細分析
-/multi-role frontend,mobile,performance --agent
-「全画面の UX 最適化分析」
-```
-
-#### パフォーマンス比較
-
-| ロール数 | 通常実行 | --agent 実行 | 短縮率 |
-|---------|----------|-------------|-------|
-| 2 ロール | 2-3 分 | 1 分 | 50% |
-| 3 ロール | 3-5 分 | 1-2 分 | 60% |
-| 4 ロール | 5-8 分 | 2-3 分 | 65% |
-
-### 注意事項
-
-- 3 つ以上のロールを同時実行すると出力が長くなります
-- 複雑な分析ほど実行時間が長くなる可能性があります
-- 相互矛盾する推奨事項が出た場合は、role-debate も検討してください
-- 最終的な判断は統合結果を参考にユーザーが行ってください
-- **--agent 使用時**: より多くのリソースを使用しますが、大規模分析では効率的です

package/lib/assets/.claude/commands/next.md

@@ -1,136 +0,0 @@
-## Next
-
-次のイテレーションやタスクを計画・実行する開発進捗管理コマンド。
-
-### 使い方
-
-```bash
-/next [オプション]
-```
-
-### オプション
-
-- なし : 現在の状況を分析して次のステップを提案
-- `--plan` : 詳細な実装計画を作成
-- `--execute` : 提案された次のタスクを即座に実行
-- `--iteration <番号>` : 特定のイテレーション番号を指定して計画
-- `--review` : 現在のイテレーション完了状況をレビュー
-
-### 基本例
-
-```bash
-# 基本的な使い方（次のステップを提案）
-/next
-「現在の進捗を分析し、次に進むべきタスクを3つのオプションで提案」
-
-# 詳細計画の作成
-/next --plan
-「次のイテレーションの詳細実装計画を作成」
-
-# 即座に実行
-/next --execute
-「提案された最優先タスクを即座に実行開始」
-
-# 特定のイテレーション計画
-/next --iteration 4
-「イテレーション4の計画を作成」
-
-# 完了状況レビュー
-/next --review
-「現在のイテレーション完了状況と品質評価」
-```
-
-### 詳細機能
-
-#### 自動進捗分析
-
-現在のプロジェクト状況を自動分析し、最適な次のステップを提案：
-
-```bash
-# プロジェクト状況の包括的分析
-git status && git log --oneline -5
-/next
-```
-
-- **コードベース分析**: 実装済み機能と未実装機能の特定
-- **品質評価**: テストカバレッジとコード品質の評価  
-- **技術的負債**: 改善が必要な箇所の特定
-- **優先度判定**: ビジネス価値と技術的重要度による優先順位付け
-
-#### イテレーション管理
-
-アジャイル開発のイテレーション管理を支援：
-
-- **計画策定**: 次イテレーションのユーザーストーリーと工数見積もり
-- **目標設定**: 明確な成功基準と受け入れ条件の定義
-- **リスク管理**: 潜在的な障害とその対策の特定
-- **リソース計画**: 必要なスキルセットと時間配分の算出
-
-#### 選択肢提示
-
-常に3つの具体的な選択肢を提供：
-
-- **オプション1**: 最優先の必須タスク
-- **オプション2**: 代替的なアプローチや改善タスク  
-- **オプション3**: 探索的・実験的タスク
-
-### 出力例
-
-```
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-📋 次のステップ分析結果
-
-現在の状況:
-├─ ✅ イテレーション3: 予約キャンセル機能 (100%完了)
-├─ 🛡️ セキュリティ: 企業レベル達成
-├─ ⚡ パフォーマンス: 要件満たす
-└─ 📚ドキュメント: 完備
-
-次のステップオプション:
-[1] イテレーション4: 通知機能実装
-[2] MVPリリース準備・本番環境構築
-[3] 技術的改善・リファクタリング
-
-推奨: オプション1 (ビジネス価値最大化)
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-```
-
-### Claude との連携
-
-```bash
-# 現在の状況確認後に次のステップ相談
-git log --oneline -10 && git status
-/next --review
-「完了した作業を踏まえて次の優先タスクを判定」
-
-# 特定機能の実装状況確認後の計画
-find . -name "*.ts" -o -name "*.cs" | head -10
-/next --plan  
-「実装済みファイルを確認して次の開発計画を策定」
-
-# テスト結果確認後の改善提案
-npm test
-/next
-「テスト結果を踏まえた品質改善の次のステップを提案」
-```
-
-### 注意事項
-
-- **前提条件**: Gitリポジトリでの作業を前提とする
-- **制限事項**: プロジェクトの文脈を理解するため、事前の情報収集が必要
-- **推奨事項**: 定期的な進捗確認（1日1-2回）で効果的な開発進行
-
-### ベストプラクティス
-
-1. **定期実行**: イテレーション完了時や大きな機能実装後に実行
-2. **状況共有**: チーム全体で次のステップを共有し合意形成
-3. **柔軟性**: 提案された選択肢から状況に応じて最適なものを選択
-4. **継続改善**: フィードバックを基に次回の計画精度を向上
-
-### 関連コマンド
-
-- `/plan` : より詳細な実装計画作成
-- `/review` : コードレビューと品質評価
-- `/test` : テスト実行と結果分析
-- `/deploy` : デプロイメント関連タスク
-- `/progress``: 進捗確認タスク