Claude Code 疲れを軽減する 30+ 個のカスタムコマンド

git clone https://github.com/wasabeef/claude-code-cookbook.git ~/.claude

# 一部だけ使いたい場合はコピペしてね

$ /check-github-ci

PR #4517 の CI チェック状況を確認しました。

✅ 全チェック成功

総合状況: 🟢 All checks passed
- 成功: 11 項目
- スキップ: 6 項目
- 失敗: 0 項目

📋 成功チェック一覧

| チェック名                     | 状態   | 実行時間 | 説明                 |
|------------------------------|--------|--------|----------------------|
| android                      | ✅ pass | 10m57s | Android ビルド・テスト |
| ios                          | ✅ pass | 7m29s  | iOS ビルド・テスト     |
| TruffleHog                   | ✅ pass | 23s    | セキュリティスキャン    |
| commitlint                   | ✅ pass | 21s    | コミットメッセージ検証   |
| lint-and-test                | ✅ pass | 17s    | 静的解析・テスト        |
| Add labels                   | ✅ pass | 14s    | PR ラベル自動追加       |
| validate                     | ✅ pass | 9s     | 基本検証               |
| assign                       | ✅ pass | 7s     | 担当者自動割当          |
| require-labels               | ✅ pass | 7s     | 必須ラベル確認          |
| WIP                          | ✅ pass | 1s     | WIP 状態チェック        |
| action-semantic-pull-request | ✅ pass | 0s     | セマンティック PR 検証   |

$ git checkout -b feature/user-authentication
$ git add -A && git commit -m "feat: implement user authentication system"
$ /pr-create

🔍 変更内容を分析中...

📊 分析結果:
├─ 新規ファイル: 8 個
├─ 変更ファイル: 3 個
├─ 削除ファイル: 1 個
└─ 影響範囲: 認証システム全体

🚀 Pull Request を作成します

【タイトル】
feat: ユーザー認証システムの実装

【説明】
## Summary
- JWT ベースの認証システムを実装
- ログイン・ログアウト・パスワードリセット機能
- セキュリティ強化（bcrypt によるハッシュ化）

## Technical Changes
### 🆕 新規追加
- `src/auth/` - 認証関連のコアロジック
- `src/middleware/auth.ts` - 認証ミドルウェア
- `tests/auth/` - 認証機能のテストスイート

### 🔧 変更
- `src/routes/api.ts` - 認証ルートの追加
- `src/types/user.ts` - ユーザー型定義の拡張
- `package.json` - JWT, bcrypt 依存関係の追加

### 🗑️ 削除
- `src/legacy/simple-auth.ts` - 旧認証システム

## Test Plan
- [ ] 単体テスト (Jest): 15 test cases
- [ ] 統合テスト: ログインフロー
- [ ] セキュリティテスト: 認証バイパス検証
- [ ] パフォーマンステスト: JWT 生成速度

## Security Considerations
✅ OWASP 認証チートシート準拠
✅ Password strength validation
✅ Rate limiting 実装済み
✅ Secure cookie settings

PR URL: https://github.com/example/repo/pull/123

$ git add -A
$ /semantic-commit

⏺ 変更分析中...
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

検出された変更:
• src/auth/login.ts (新規)
• src/auth/register.ts (新規)
• src/types/user.ts (修正)
• src/utils/validation.ts (新規)
• src/components/LoginForm.tsx (新規)
• src/styles/auth.css (新規)
• tests/auth.test.ts (新規)
• tests/utils/auth-helpers.ts (新規)

提案されるコミット分割:

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
コミット 1/3
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
メッセージ: feat: ユーザー認証システムの基本実装
含まれるファイル:
  • src/auth/login.ts
  • src/auth/register.ts
  • src/types/user.ts
  • src/utils/validation.ts

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
コミット 2/3
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
メッセージ: style: ログインフォームの UI コンポーネント実装
含まれるファイル:
  • src/components/LoginForm.tsx
  • src/styles/auth.css

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
コミット 3/3
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
メッセージ: test: 認証機能のテストケース追加
含まれるファイル:
  • tests/auth.test.ts
  • tests/utils/auth-helpers.ts

この分割案でコミットを実行しますか？ (y/n/edit):

$ /role-debate security,performance
「API レスポンスタイムを改善したいが、セキュリティも重要」

⏺ ロール議論: Security vs Performance
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

議題: API レスポンスタイムを改善したいが、セキュリティも重要

Phase 1: 初期立場表明

【Security Expert】の推奨案:
「全 API エンドポイントに Rate Limiting、暗号化、入力検証を必須化」

根拠:
- OWASP API Security Top 10 2023 準拠
- 2023 年の API 攻撃は前年比 681% 増加（Salt Security Report）
- ゼロトラストアーキテクチャの原則

懸念事項:
- パフォーマンス最適化による検証スキップは致命的
- キャッシュ実装時の認証バイパスリスク
- 並列処理による競合状態の脆弱性

成功指標:
- セキュリティインシデント発生率 < 0.01%
- 脆弱性スキャンで Critical/High: 0 件
- コンプライアンス監査 100% 合格

【Performance Expert】の推奨案:
「キャッシュ戦略とデータベース最適化でレスポンス 50% 改善」

根拠:
- Google の研究: 100ms 遅延で売上 1% 減少
- Core Web Vitals: LCP < 2.5 秒が必須
- 現状分析: DB クエリが全体の 70% を占める

懸念事項:
- 過度なセキュリティ検証で 3 倍のレイテンシ
- Rate Limiting による正当なトラフィック制限
- 暗号化/復号化の CPU オーバーヘッド

成功指標:
- P95 レスポンスタイム < 200ms
- スループット 10,000 req/s 達成
- CPU 使用率 < 70% 維持

Phase 2: 相互議論・反駁

Security → Performance:
「キャッシュによる情報漏洩事例多数。2022 年の Cloudflare 事件では 750 万ユーザーが影響」

Performance → Security:
「適切なキャッシュキー設計で回避可能。CDN エッジでの検証により両立できる」

Security → Performance:
「エッジセキュリティは複雑性を増し、設定ミスのリスクが上昇」

Performance → Security:
「段階的セキュリティレイヤーを提案。public API は軽量検証、sensitive API は完全検証」

Phase 3: 妥協点探索

共通理解:
- ビジネス継続にはセキュリティとパフォーマンス両方が必須
- リスクベースアプローチによる最適化が現実的
- 継続的な監視と改善が不可欠

Win-Win 要素:
- セキュリティヘッダーのキャッシュ（静的検証）
- 非同期セキュリティログ処理
- スマート Rate Limiting（AI 異常検知）

Phase 4: 統合結論

統合解決案:
「リスクベース 3 層セキュリティ + インテリジェントキャッシング」

実装詳細:
1. Public 層（低リスク）:
   - 30 秒キャッシュ + 基本 Rate Limiting
   - レスポンス目標: 50ms

2. Protected 層（中リスク）:
   - 5 秒キャッシュ + JWT 検証
   - レスポンス目標: 100ms

3. Sensitive 層（高リスク）:
   - キャッシュなし + 完全検証
   - レスポンス目標: 200ms

段階的実装:
- Week 1-2: リスク分類と API 仕分け
- Week 3-4: Public 層の最適化実装
- Month 2: Protected 層の実装と検証
- Month 3: 全体最適化と負荷テスト

成功指標:
- セキュリティ: ゼロブリーチ維持
- パフォーマンス: 平均レスポンス 40% 改善
- 可用性: 99.95% アップタイム

将来の見直し:
- 月次: セキュリティログとパフォーマンスメトリクス評価
- 四半期: 新たな脅威とパフォーマンス要件の再評価