@k2works/claude-code-booster 0.8.0 → 0.9.0

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

@@ -1,571 +0,0 @@
-## Role Debate
-
-異なる専門性を持つロールが議論し、トレードオフを検討して最適解を導出するコマンド。
-
-### 使い方
-
-```bash
-/role-debate <ロール 1>,<ロール 2> [議題]
-/role-debate <ロール 1>,<ロール 2>,<ロール 3> [議題]
-```
-
-### 基本例
-
-```bash
-# セキュリティ vs パフォーマンスのトレードオフ
-/role-debate security,performance
-「JWT トークンの有効期限設定について」
-
-# ユーザビリティ vs セキュリティのバランス
-/role-debate frontend,security
-「2 段階認証の UX 最適化について」
-
-# 技術選定の議論
-/role-debate architect,mobile
-「React Native vs Flutter の選択について」
-
-# 3 者議論
-/role-debate architect,security,performance
-「マイクロサービス化の是非について」
-```
-
-### 議論の基本原則
-
-#### 建設的議論の心得
-
-- **相互尊重**: 他ロールの専門性と視点を尊重する
-- **事実ベース**: 感情的反論ではなく、データ・根拠に基づく議論
-- **解決志向**: 批判のための批判ではなく、より良い解決策を目指す
-- **実装重視**: 理想論ではなく実現可能性を考慮した提案
-
-#### 論拠の質的要件
-
-- **公式文書**: 標準・ガイドライン・公式ドキュメントへの言及
-- **実証事例**: 成功事例・失敗事例の具体的引用
-- **定量評価**: 可能な限り数値・指標での比較
-- **時系列考慮**: 短期・中期・長期での影響評価
-
-#### 議論倫理
-
-- **誠実性**: 自身の専門分野の限界も認める
-- **開放性**: 新しい情報・視点に対する柔軟性
-- **透明性**: 判断根拠・前提条件の明示
-- **責任性**: 提案の実装リスクも含めて言及
-
-### 議論プロセス
-
-### Phase 1: 初期立場表明
-
-各ロールが専門視点から独立して意見表明
-
-- 推奨案の提示
-- 根拠となる標準・文書の明示
-- 想定されるリスク・課題の説明
-- 成功指標の定義
-
-### Phase 2: 相互議論・反駁
-
-ロール間でのクロス議論
-
-- 他ロール提案への建設的反論
-- 見落とされた視点の指摘
-- トレードオフの明確化
-- 代替案の提示
-
-### Phase 3: 妥協点探索
-
-実装可能な解決策の模索
-
-- 各視点の重要度評価
-- Win-Win 解決策の検討
-- 段階的実装アプローチ
-- リスク軽減策の検討
-
-### Phase 4: 統合結論
-
-最終的な推奨事項の決定
-
-- 合意された解決策
-- 実装ロードマップ
-- 成功指標・測定方法
-- 将来の見直しポイント
-
-### 出力フォーマット例
-
-### 2 ロール議論の場合
-
-```
-ロール議論: Security vs Performance
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-議題: JWT トークンの有効期限設定
-
-Security ロールの主張:
-「15 分の短期有効期限を推奨します」
-
-根拠:
-- OWASP JWT Security Cheat Sheet 準拠
-- トークン漏洩時の被害時間窓を最小化
-- 攻撃者の利用可能時間を制限
-
-懸念事項:
-- 長期有効期限は攻撃リスクが指数関数的に増大
-- コンプライアンス要件（金融系）では短期が必須
-
-成功指標:
-- セキュリティインシデント発生率 < 0.1%
-- 平均攻撃検出時間 < 5 分
-
-Performance ロールの反論:
-「2 時間の有効期限を推奨します」
-
-根拠:
-- Google OAuth 2.0 Best Practices 参考
-- 頻繁な再認証によるサーバー負荷増大を回避
-- ユーザー体験（作業中断）の最小化
-
-懸念事項:
-- 15 分間隔の再認証は API 負荷 8 倍増
-- モバイル環境での接続断が頻発
-
-成功指標:
-- API レスポンス時間 < 200ms 維持
-- サーバー CPU 使用率 < 60%
-
-相互議論:
-Security → Performance:
-「サーバー負荷よりもセキュリティ侵害のビジネス損失の方が甚大。
-例: Equifax 事件では 7 億ドルの損失」
-
-Performance → Security:
-「リフレッシュトークン機構で両立可能。
-バックグラウンド更新により UX を損なわずセキュリティ確保」
-
-Security → Performance:
-「リフレッシュトークンも攻撃対象。適切な実装が前提」
-
-Performance → Security:
-「段階的アプローチを提案。通常操作 30 分、機密操作 15 分」
-
-妥協点探索:
-共通理解:
-- ユーザー体験とセキュリティの両立が必要
-- リスクレベルに応じた柔軟な対応
-- 実装・運用コストの現実的考慮
-
-Win-Win 要素:
-- リフレッシュトークン機構の活用
-- リスクベース認証の段階的導入
-- 自動ログアウト機能による補完
-
-統合結論:
-「30 分有効期限 + リフレッシュトークン + リスクベース認証」
-
-実装詳細:
-1. アクセストークン: 30 分有効期限
-2. リフレッシュトークン: 7 日有効期限
-3. 高リスク操作: 15 分で強制再認証
-4. 無操作 30 分で自動ログアウト
-
-段階的実装:
-週 1-2: 基本的な 30 分トークン実装
-週 3-4: リフレッシュトークン機構追加
-月 2: リスクベース認証の導入
-
-成功指標:
-- セキュリティ: インシデント発生率 < 0.1%
-- パフォーマンス: API 負荷増加率 < 20%
-- UX: ユーザー満足度 > 85%
-
-将来の見直し:
-- 3 ヶ月後: 実際の攻撃パターン・負荷状況を評価
-- 6 ヶ月後: より洗練されたリスクベース認証への移行検討
-```
-
-### 3 ロール議論の場合
-
-```
-ロール議論: Architect vs Security vs Performance
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-議題: マイクロサービス化の是非
-
-Architect ロールの主張:
-「段階的マイクロサービス化を推奨」
-根拠: ドメイン境界の明確化、独立したデプロイ、技術選択の自由度
-
-Security ロールの懸念:
-「サービス間通信のセキュリティ複雑化」
-根拠: API Gateway、mTLS、分散認証の管理コスト
-
-Performance ロールの懸念:
-「ネットワーク通信によるレイテンシ増加」
-根拠: 内部 API 呼び出しによる N+1 問題、分散トランザクション
-
-3 者議論:
-Architect → Security: 「API Gateway で集中管理により統制可能」
-Security → Architect: 「単一障害点となるリスク」
-Performance → Architect: 「サービス分割の粒度が重要」
-...（議論継続）
-
-統合結論:
-「ドメイン駆動設計による段階的分割 + セキュリティファースト設計」
-```
-
-### 効果的な議論パターン
-
-### 技術選定
-
-```bash
-/role-debate architect,performance
-「データベース選択: PostgreSQL vs MongoDB」
-
-/role-debate frontend,mobile
-「UI フレームワーク: React vs Vue」
-
-/role-debate security,architect
-「認証方式: JWT vs Session Cookie」
-```
-
-### 設計判断
-
-```bash
-/role-debate security,frontend
-「ユーザー認証の UX 設計」
-
-/role-debate performance,mobile
-「データ同期戦略の最適化」
-
-/role-debate architect,qa
-「テスト戦略とアーキテクチャ設計」
-```
-
-### トレードオフ問題
-
-```bash
-/role-debate security,performance
-「暗号化レベル vs 処理速度」
-
-/role-debate frontend,performance
-「リッチ UI vs ページ読み込み速度」
-
-/role-debate mobile,security
-「利便性 vs データ保護レベル」
-```
-
-### ロール別議論特性
-
-#### 🔒 Security ロール
-
-```yaml
-議論スタンス:
-  - 保守的アプローチ (リスク最小化)
-  - 規則準拠重視 (標準からの逸脱に慎重)
-  - 最悪ケース想定 (攻撃者視点)
-  - 長期的影響重視 (技術的負債としてのセキュリティ)
-
-典型的論点:
-  - "セキュリティ vs 利便性" のトレードオフ
-  - "コンプライアンス要件の必達"
-  - "攻撃コスト vs 防御コストの比較"
-  - "プライバシー保護の徹底"
-
-論拠ソース:
-  - OWASP ガイドライン
-  - NIST フレームワーク
-  - 業界標準 (ISO 27001, SOC 2)
-  - 実際の攻撃事例・統計
-
-議論での強み:
-  - リスク評価の精度
-  - 規制要件の知識
-  - 攻撃手法への理解
-
-注意すべき偏見:
-  - 過度な保守性 (イノベーション阻害)
-  - UX への配慮不足
-  - 実装コストの軽視
-```
-
-#### ⚡ Performance ロール
-
-```yaml
-議論スタンス:
-  - データ駆動判断 (測定ベース)
-  - 効率性重視 (コスト対効果の最適化)
-  - ユーザー体験優先 (体感速度重視)
-  - 継続的改善 (段階的最適化)
-
-典型的論点:
-  - "パフォーマンス vs セキュリティ"
-  - "最適化コスト vs 効果の投資対効果"
-  - "現在 vs 将来のスケーラビリティ"
-  - "ユーザー体験 vs システム効率"
-
-論拠ソース:
-  - Core Web Vitals メトリクス
-  - ベンチマーク結果・統計
-  - ユーザー行動への影響データ
-  - 業界パフォーマンス標準
-
-議論での強み:
-  - 定量的評価能力
-  - ボトルネック特定
-  - 最適化手法の知識
-
-注意すべき偏見:
-  - セキュリティの軽視
-  - 保守性への配慮不足
-  - プレマチュアオプティマイゼーション
-```
-
-#### 🏗️ Architect ロール
-
-```yaml
-議論スタンス:
-  - 長期視点重視 (システム進化への配慮)
-  - バランス追求 (全体最適)
-  - 段階的変更 (リスク管理)
-  - 標準準拠 (実証済みパターン優先)
-
-典型的論点:
-  - "短期効率 vs 長期保守性"
-  - "技術的負債 vs 開発速度"
-  - "マイクロサービス vs モノリス"
-  - "新技術採用 vs 安定性"
-
-論拠ソース:
-  - アーキテクチャパターン集
-  - 設計原則 (SOLID, DDD)
-  - 大規模システム事例
-  - 技術進化のトレンド
-
-議論での強み:
-  - 全体俯瞰能力
-  - 設計パターンの知識
-  - 長期影響の予測
-
-注意すべき偏見:
-  - 過度な一般化
-  - 新技術への保守性
-  - 実装詳細への理解不足
-```
-
-#### 🎨 Frontend ロール
-
-```yaml
-議論スタンス:
-  - ユーザー中心設計 (UX 最優先)
-  - 包摂的アプローチ (多様性配慮)
-  - 直感性重視 (学習コスト最小化)
-  - アクセシビリティ標準 (WCAG 準拠)
-
-典型的論点:
-  - "ユーザビリティ vs セキュリティ"
-  - "デザイン統一 vs プラットフォーム最適化"
-  - "機能性 vs シンプルさ"
-  - "パフォーマンス vs リッチな体験"
-
-論拠ソース:
-  - UX 研究・ユーザビリティテスト結果
-  - アクセシビリティガイドライン
-  - デザインシステム標準
-  - ユーザー行動データ
-
-議論での強み:
-  - ユーザー視点の代弁
-  - デザイン原則の知識
-  - アクセシビリティ要件
-
-注意すべき偏見:
-  - 技術制約への理解不足
-  - セキュリティ要件の軽視
-  - パフォーマンス影響の過小評価
-```
-
-#### 📱 Mobile ロール
-
-```yaml
-議論スタンス:
-  - プラットフォーム特化 (iOS/Android 差異考慮)
-  - コンテキスト適応 (移動中・片手操作)
-  - リソース制約 (バッテリー・メモリ・通信)
-  - ストア準拠 (審査ガイドライン)
-
-典型的論点:
-  - "ネイティブ vs クロスプラットフォーム"
-  - "オフライン対応 vs リアルタイム同期"
-  - "バッテリー効率 vs 機能性"
-  - "プラットフォーム統一 vs 最適化"
-
-論拠ソース:
-  - iOS HIG / Android Material Design
-  - App Store / Google Play ガイドライン
-  - モバイル UX 研究
-  - デバイス性能統計
-
-議論での強み:
-  - モバイル特有制約の理解
-  - プラットフォーム差異の知識
-  - タッチインターフェース設計
-
-注意すべき偏見:
-  - Web プラットフォームへの理解不足
-  - サーバーサイド制約の軽視
-  - デスクトップ環境への配慮不足
-```
-
-#### 🔍 Analyzer ロール
-
-```yaml
-議論スタンス:
-  - 証拠重視 (データファースト)
-  - 仮説検証 (科学的アプローチ)
-  - 構造的思考 (システム思考)
-  - バイアス除去 (客観性追求)
-
-典型的論点:
-  - "相関関係 vs 因果関係"
-  - "症状対症療法 vs 根本解決"
-  - "仮説 vs 事実の区別"
-  - "短期症状 vs 構造的問題"
-
-論拠ソース:
-  - 実測データ・ログ分析
-  - 統計的手法・分析結果
-  - システム思考理論
-  - 認知バイアス研究
-
-議論での強み:
-  - 論理的分析能力
-  - 証拠評価の客観性
-  - 構造的問題の発見
-
-注意すべき偏見:
-  - 分析麻痺 (行動力不足)
-  - 完璧主義 (実用性軽視)
-  - データ万能主義
-```
-
-### 議論進行テンプレート
-
-#### Phase 1: 立場表明テンプレート
-
-```
-【ロール名】の推奨案:
-「[具体的な提案]」
-
-根拠:
-- [公式文書・標準への言及]
-- [実証事例・データ]
-- [専門分野の原則]
-
-想定効果:
-- [短期的効果]
-- [中長期的効果]
-
-懸念・リスク:
-- [実装リスク]
-- [運用リスク]
-- [他分野への影響]
-
-成功指標:
-- [測定可能な指標 1]
-- [測定可能な指標 2]
-```
-
-#### Phase 2: 反駁テンプレート
-
-```
-[対象ロール] への反論:
-「[対象提案への具体的反論]」
-
-反論根拠:
-- [見落とされた視点]
-- [対立する証拠・事例]
-- [専門分野からの懸念]
-
-代替案:
-「[改良された提案]」
-
-妥協可能ポイント:
-- [受け入れ可能な条件]
-- [段階的実装の可能性]
-```
-
-#### Phase 3: 統合解決テンプレート
-
-```
-統合解決案:
-「[各ロールの懸念を考慮した最終提案]」
-
-各ロールへの配慮:
-- [Security]: [セキュリティ要件の満足方法]
-- [Performance]: [パフォーマンス要件の満足方法]
-- [その他]: [その他要件の満足方法]
-
-実装ロードマップ:
-- フェーズ 1 (即座): [緊急対応事項]
-- フェーズ 2 (短期): [基本実装]
-- フェーズ 3 (中期): [完全実装]
-
-成功指標・測定方法:
-- [統合的な成功指標]
-- [測定方法・頻度]
-- [見直しタイミング]
-```
-
-### 議論品質チェックリスト
-
-#### 論拠の質
-
-- [ ] 公式文書・標準への言及がある
-- [ ] 具体的な事例・データが提示されている
-- [ ] 推測と事実が明確に区別されている
-- [ ] 情報源が明示されている
-
-#### 議論の建設性
-
-- [ ] 相手の提案を正確に理解している
-- [ ] 感情的でなく論理的な反論
-- [ ] 代替案も提示している
-- [ ] Win-Win の可能性を探っている
-
-#### 実装可能性
-
-- [ ] 技術的実現可能性を考慮
-- [ ] 実装コスト・期間を見積もり
-- [ ] 段階的実装の可能性を検討
-- [ ] リスク軽減策を提示
-
-#### 統合性
-
-- [ ] 他分野への影響を考慮
-- [ ] 全体最適を追求
-- [ ] 長期的視点を含む
-- [ ] 測定可能な成功指標を設定
-
-### Claude との連携
-
-```bash
-# 設計文書を元にした議論
-cat system-design.md
-/role-debate architect,security
-「この設計のセキュリティ面での課題を議論して」
-
-# 問題を元にした解決策議論
-cat performance-issues.md
-/role-debate performance,architect
-「パフォーマンス問題の根本的解決策を議論して」
-
-# 要件を元にした技術選定議論
-/role-debate mobile,frontend
-「iOS ・ Android ・ Web の統一 UI 戦略について議論して」
-```
-
-### 注意事項
-
-- 議論は時間がかかる場合があります（複雑なトピックほど長時間）
-- 3 つ以上のロールでは議論が発散する可能性があります
-- 最終判断は議論結果を参考にユーザーが行ってください
-- 緊急性の高い問題では single role や multi-role を先に検討してください