@k2works/claude-code-booster 0.7.0 → 0.9.0

package/lib/assets/.claude/commands/pr-feedback.md

@@ -1,143 +0,0 @@
-## PR Feedback
-
-Pull Request のレビューコメントを効率的に対応し、エラー分析 3 段階アプローチで根本解決を図ります。
-
-### 使い方
-
-```bash
-# レビューコメントの取得と分析
-gh pr view --comments
-「レビューコメントを優先度別に分類して対応計画を作成してください」
-
-# エラー関連コメントの詳細分析
-gh pr checks
-「CI エラーを 3 段階アプローチで分析して根本原因を特定してください」
-
-# 修正完了後の品質確認
-npm test && npm run lint
-「修正が完了したので回帰テストとコード品質をチェックしてください」
-```
-
-### 基本例
-
-```bash
-# コメント分類の実行
-gh pr view 123 --comments | head -20
-"レビューコメントを must/imo/nits/q に分類して対応順序を決めてください"
-
-# エラー情報の収集
-npm run build 2>&1 | tee error.log
-"ビルドエラーの根本原因を特定し、適切な修正方法を提案してください"
-
-# 修正実装の確認
-git diff HEAD~1
-"この修正がレビュー指摘事項を適切に解決しているか評価してください"
-```
-
-### コメント分類体系
-
-```
-🔴 must: 修正必須
-├─ セキュリティ問題
-├─ 機能バグ
-├─ 設計原則違反
-└─ 規約違反
-
-🟡 imo: 改善提案
-├─ より良い実装方法
-├─ パフォーマンス改善
-├─ 可読性向上
-└─ リファクタリング提案
-
-🟢 nits: 軽微な指摘
-├─ タイポ修正
-├─ インデント調整
-├─ コメント追加
-└─ 命名の微調整
-
-🔵 q: 質問・確認
-├─ 実装意図の確認
-├─ 仕様の明確化
-├─ 設計判断の背景
-└─ 代替案の検討
-```
-
-### エラー分析 3 段階アプローチ
-
-#### Stage 1: 情報収集
-
-**必須実行**
-
-- エラーメッセージの完全取得
-- スタックトレースの確認
-- 再現条件の特定
-
-**推奨実行**
-
-- 環境情報の収集
-- 最近の変更履歴
-- 関連ログの確認
-
-#### Stage 2: 根本原因分析
-
-- 5 Whys 分析の適用
-- 依存関係の追跡
-- 環境差異の確認
-- 最小再現コードの作成
-
-#### Stage 3: 解決策実装
-
-- 即座の対処（ホットフィックス）
-- 根本的解決（本質修正）
-- 予防策（再発防止）
-
-### 対応フロー
-
-1. **コメント分析**: 優先度別の分類
-2. **修正計画**: 対応順序の決定
-3. **段階的修正**: Critical → High → Medium → Low
-4. **品質確認**: テスト・リント・ビルド
-5. **進捗報告**: 具体的な修正内容の説明
-
-### 修正後の確認
-
-```bash
-# 基本チェック
-npm test
-npm run lint
-npm run build
-
-# 回帰テスト
-npm run test:e2e
-
-# コード品質
-npm run test:coverage
-```
-
-### 返信テンプレート
-
-**修正完了報告**
-
-```markdown
-@reviewer ご指摘ありがとうございます。
-修正完了いたしました：
-
-- [具体的修正内容]
-- [テスト結果]
-- [確認方法]
-```
-
-**技術判断説明**
-
-```markdown
-実装背景：[理由]
-検討した代替案：[選択肢と判断根拠]
-採用案の利点：[メリット]
-```
-
-### 注意事項
-
-- **優先度遵守**: Critical → High → Medium → Low の順で対応
-- **テストファースト**: 修正前に回帰テスト確認
-- **明確な報告**: 修正内容と確認方法を具体的に記述
-- **建設的対話**: 技術的根拠に基づく丁寧なコミュニケーション

package/lib/assets/.claude/commands/pr-issue.md

@@ -1,78 +0,0 @@
-## Issue List
-
-現在のリポジトリのオープン Issue 一覧を優先順位付きで表示します。
-
-### 使い方
-
-```bash
-# Claude に依頼
-「オープン Issue 一覧を優先順位付きで表示して」
-```
-
-### 基本例
-
-```bash
-# リポジトリ情報を取得
-gh repo view --json nameWithOwner | jq -r '.nameWithOwner'
-
-# オープン Issue 情報を取得して Claude に依頼
-gh issue list --state open --json number,title,author,createdAt,updatedAt,labels,assignees,comments --limit 30
-
-「上記の Issue を優先度別に整理して、各 Issue の 2 行概要も含めて表示して。URL は上記で取得したリポジトリ名を使用して生成して」
-```
-
-### 表示形式
-
-```
-オープン Issue 一覧（優先順位順）
-
-### 高優先度
-#番号 タイトル [ラベル] | 作者 | オープンから経過時間 | コメント数 | 担当者
-      ├─ 概要 1 行目
-      └─ 概要 2 行目
-      https://github.com/owner/repo/issues/番号
-
-### 中優先度
-（同様の形式）
-
-### 低優先度
-（同様の形式）
-```
-
-### 優先度の判定基準
-
-**高優先度**
-
-- `bug` ラベルが付いている Issue
-- `critical` や `urgent` ラベルが付いている Issue
-- `security` ラベルが付いている Issue
-
-**中優先度**
-
-- `enhancement` ラベルが付いている Issue
-- `feature` ラベルが付いている Issue
-- 担当者が設定されている Issue
-
-**低優先度**
-
-- `documentation` ラベルが付いている Issue
-- `good first issue` ラベルが付いている Issue
-- `wontfix` や `duplicate` ラベルが付いている Issue
-
-### ラベルによるフィルタリング
-
-```bash
-# 特定のラベルの Issue のみ取得
-gh issue list --state open --label "bug" --json number,title,author,createdAt,labels,comments --limit 30
-
-# 複数ラベルでフィルタリング（AND 条件）
-gh issue list --state open --label "bug,high-priority" --json number,title,author,createdAt,labels,comments --limit 30
-```
-
-### 注意事項
-
-- GitHub CLI (`gh`) が必要です
-- オープン状態の Issue のみ表示します
-- 最大 30 件の Issue を表示します
-- 経過時間は Issue がオープンされてからの時間です
-- Issue の URL は実際のリポジトリ名から自動生成されます

package/lib/assets/.claude/commands/pr-list.md

@@ -1,66 +0,0 @@
-## PR List
-
-現在のリポジトリのオープン PR 一覧を優先順位付きで表示します。
-
-### 使い方
-
-```bash
-# Claude に依頼
-「オープン PR 一覧を優先順位付きで表示して」
-```
-
-### 基本例
-
-```bash
-# リポジトリ情報を取得
-gh repo view --json nameWithOwner | jq -r '.nameWithOwner'
-
-# オープン PR 情報を取得して Claude に依頼
-gh pr list --state open --draft=false --json number,title,author,createdAt,additions,deletions,reviews --limit 30
-
-「上記の PR を優先度別に整理して、各 PR の 2 行概要も含めて表示して。URL は上記で取得したリポジトリ名を使用して生成して」
-```
-
-### 表示形式
-
-```
-オープン PR 一覧（優先順位順）
-
-### 高優先度
-#番号 タイトル [Draft/DNM] | 作者 | オープンから経過時間 | Approved 数 | +追加/-削除
-      ├─ 概要 1 行目
-      └─ 概要 2 行目
-      https://github.com/owner/repo/pull/番号
-
-### 中優先度
-（同様の形式）
-
-### 低優先度
-（同様の形式）
-```
-
-### 優先度の判定基準
-
-**高優先度**
-
-- `fix:` バグ修正
-- `release:` リリース作業
-
-**中優先度**
-
-- `feat:` 新機能
-- `update:` 機能改善
-- その他通常の PR
-
-**低優先度**
-
-- DO NOT MERGE を含む PR
-- Draft で `test:`、`build:`、`perf:` の PR
-
-### 注意事項
-
-- GitHub CLI (`gh`) が必要です
-- オープン状態の PR のみ表示します（Draft は除外）
-- 最大 30 件の PR を表示します
-- 経過時間は PR がオープンされてからの時間です
-- PR の URL は実際のリポジトリ名から自動生成されます

package/lib/assets/.claude/commands/pr-review.md

@@ -1,142 +0,0 @@
-## PR Review
-
-Pull Request の体系的レビューでコード品質とアーキテクチャの健全性を確保します。
-
-### 使い方
-
-```bash
-# PR の包括的レビュー
-gh pr view 123 --comments
-「この PR を体系的にレビューしてコード品質、セキュリティ、アーキテクチャの観点からフィードバックしてください」
-
-# セキュリティ特化レビュー
-gh pr diff 123
-「セキュリティリスクと脆弱性に焦点を当ててレビューしてください」
-
-# アーキテクチャ観点のレビュー
-gh pr checkout 123 && find . -name "*.js" | head -10
-「レイヤー分離、依存関係、SOLID 原則の観点からアーキテクチャを評価してください」
-```
-
-### 基本例
-
-```bash
-# コード品質の数値的評価
-find . -name "*.js" -exec wc -l {} + | sort -rn | head -5
-"コードの複雑度、関数サイズ、重複度を評価して改善点を指摘してください"
-
-# セキュリティ脆弱性チェック
-grep -r "password\|secret\|token" . --include="*.js" | head -10
-"機密情報の漏洩、ハードコーディング、認証バイパスのリスクをチェックしてください"
-
-# アーキテクチャ違反の検出
-grep -r "import.*from.*\.\./\.\." . --include="*.js"
-"レイヤー違反、循環依存、結合度の問題を評価してください"
-```
-
-### コメント分類体系
-
-```
-🔴 critical.must: 致命的問題
-├─ セキュリティ脆弱性
-├─ データ整合性問題
-└─ システム障害リスク
-
-🟡 high.imo: 高優先度改善
-├─ 機能不全のリスク
-├─ パフォーマンス問題
-└─ 保守性の大幅低下
-
-🟢 medium.imo: 中優先度改善
-├─ 可読性の向上
-├─ コード構造改善
-└─ テスト品質向上
-
-🟢 low.nits: 軽微な指摘
-├─ スタイル統一
-├─ タイポ修正
-└─ コメント追加
-
-🔵 info.q: 質問・情報提供
-├─ 実装意図の確認
-├─ 設計判断の背景
-└─ ベストプラクティスの共有
-```
-
-### レビュー観点
-
-#### 1. コード正確性
-
-- **ロジックエラー**: 境界値、Null チェック、例外処理
-- **データ整合性**: 型安全性、バリデーション
-- **エラーハンドリング**: 網羅性、適切な処理
-
-#### 2. セキュリティ
-
-- **認証・認可**: 適切なチェック、権限管理
-- **入力検証**: SQL インジェクション、XSS 対策
-- **機密情報**: ログ出力禁止、暗号化
-
-#### 3. パフォーマンス
-
-- **アルゴリズム**: 時間計算量、メモリ効率
-- **データベース**: N+1 クエリ、インデックス最適化
-- **リソース**: メモリリーク、キャッシュ活用
-
-#### 4. アーキテクチャ
-
-- **レイヤー分離**: 依存方向、適切な分離
-- **結合度**: 疑結合、インターフェース活用
-- **SOLID 原則**: 単一責任、開放閉鎖、依存性逆転
-
-### レビューフロー
-
-1. **事前確認**: PR 情報、変更差分、関連 Issue
-2. **体系的チェック**: セキュリティ → 正確性 → パフォーマンス → アーキテクチャ
-3. **建設的フィードバック**: 具体的な改善案とコード例
-4. **フォローアップ**: 修正確認、CI 状態、最終承認
-
-### 効果的なコメント例
-
-**セキュリティ問題**
-
-```markdown
-**critical.must.** パスワードが平文で保存されています
-
-```javascript
-// 修正案
-const bcrypt = require('bcrypt');
-const hashedPassword = await bcrypt.hash(password, 12);
-```
-
-セキュリティリスクを防ぐためハッシュ化が必須です。
-
-```
-
-**パフォーマンス改善**
-```markdown
-**high.imo.** N+1 クエリ問題が発生します
-
-```javascript
-// 改善案: Eager Loading
-const users = await User.findAll({ include: [Post] });
-```
-
-クエリ数を大幅に削減できます。
-
-```
-
-**アーキテクチャ違反**
-```markdown
-**high.must.** レイヤー違反が発生しています
-
-ドメイン層がインフラ層に直接依存しています。
-依存性逆転の原則でインターフェースを導入してください。
-```
-
-### 注意事項
-
-- **建設的トーン**: 攻撃的ではなく協調的なコミュニケーション
-- **具体的提案**: 問題の指摘だけでなく解決案を提示
-- **優先度付け**: Critical → High → Medium → Low の順で対応
-- **継続改善**: レビュー結果をナレッジベース化

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

@@ -1,147 +0,0 @@
-## Refactor
-
-安全で段階的なコードリファクタリングを実施し、SOLID 原則の遵守状況を評価します。
-
-### 使い方
-
-```bash
-# 複雑なコードの特定とリファクタリング計画
-find . -name "*.js" -exec wc -l {} + | sort -rn | head -10
-「大きなファイルをリファクタリングして複雑度を削減してください」
-
-# 重複コードの検出と統合
-grep -r "function processUser" . --include="*.js"
-「重複した関数を Extract Method で共通化してください」
-
-# SOLID 原則違反の検出
-grep -r "class.*Service" . --include="*.js" | head -10
-「これらのクラスが単一責任の原則に従っているか評価してください」
-```
-
-### 基本例
-
-```bash
-# 長いメソッドの検出
-grep -A 50 "function" src/*.js | grep -B 50 -A 50 "return" | wc -l
-"50 行以上のメソッドを Extract Method で分割してください"
-
-# 条件分岐の複雑度
-grep -r "if.*if.*if" . --include="*.js"
-"ネストした条件文を Strategy パターンで改善してください"
-
-# コードの臭いの検出
-grep -r "TODO\|FIXME\|HACK" . --exclude-dir=node_modules
-"技術的負債となっているコメントを解決してください"
-```
-
-### リファクタリング技法
-
-#### Extract Method（メソッド抽出）
-
-```javascript
-// Before: 長大なメソッド
-function processOrder(order) {
-  // 50 行の複雑な処理
-}
-
-// After: 責任分離
-function processOrder(order) {
-  validateOrder(order);
-  calculateTotal(order);
-  saveOrder(order);
-}
-```
-
-#### Replace Conditional with Polymorphism
-
-```javascript
-// Before: switch 文
-function getPrice(user) {
-  switch (user.type) {
-    case 'premium': return basPrice * 0.8;
-    case 'regular': return basePrice;
-  }
-}
-
-// After: Strategy パターン
-class PremiumPricing {
-  calculate(basePrice) { return basePrice * 0.8; }
-}
-```
-
-### SOLID 原則チェック
-
-```
-S - Single Responsibility
-├─ 各クラスが単一の責任を持つ
-├─ 変更理由が 1 つに限定される
-└─ 責任の境界が明確
-
-O - Open/Closed
-├─ 拡張に対して開かれている
-├─ 修正に対して閉じている
-└─ 新機能追加時の既存コード保護
-
-L - Liskov Substitution
-├─ 派生クラスの置換可能性
-├─ 契約の遵守
-└─ 期待される動作の維持
-
-I - Interface Segregation
-├─ 適切な粒度のインターフェース
-├─ 使用しないメソッドへの依存回避
-└─ 役割別インターフェース定義
-
-D - Dependency Inversion
-├─ 抽象への依存
-├─ 具象実装からの分離
-└─ 依存性注入の活用
-```
-
-### リファクタリング手順
-
-1. **現状分析**
-   - 複雑度測定（循環的複雑度）
-   - 重複コード検出
-   - 依存関係の分析
-
-2. **段階的実行**
-   - 小さなステップ（15-30 分単位）
-   - 各変更後のテスト実行
-   - 頻繁なコミット
-
-3. **品質確認**
-   - テストカバレッジ維持
-   - パフォーマンス測定
-   - コードレビュー
-
-### よくあるコードの臭い
-
-- **God Object**: 過度に多くの責務を持つクラス
-- **Long Method**: 50 行を超える長いメソッド
-- **Duplicate Code**: 同じロジックの重複
-- **Large Class**: 300 行を超える大きなクラス
-- **Long Parameter List**: 4 個以上のパラメータ
-
-### 自動化支援
-
-```bash
-# 静的解析
-npx complexity-report src/
-sonar-scanner
-
-# コードフォーマット
-npm run lint:fix
-prettier --write src/
-
-# テスト実行
-npm test
-npm run test:coverage
-```
-
-### 注意事項
-
-- **機能変更の禁止**: 外部動作を変えない
-- **テストファースト**: リファクタリング前にテスト追加
-- **段階的アプローチ**: 一度に大きな変更をしない
-- **継続的検証**: 各ステップでのテスト実行