Skill: terrycarter1985/ai-code-review-ops (version 1.1.0)

--- name: code-review description: | コードレビューを実施する際に使用。プルリクエストのレビュー、コード品質チェック、 セキュリティ検査、パフォーマンス分析を行う。「レビューして」「コードをチェック」 「品質を確認」などの指示で起動。 --- # Code Review Skill ## Purpose このスキルは、以下のガイドライン(`~/.claude/CLAUDE.md`)に基づいた体系的なコードレビューを提供します: - コード品質の向上 - セキュリティ脆弱性の検出 - パフォーマンス問題の特定 - 保守性の評価 - ベストプラクティスの適用 ## When to Use 以下の場合にこのスキルを使用: - プルリクエストのレビュー依頼時 - 「コードをレビューして」という明示的な指示 - コード品質チェックの要求 - セキュリティレビューの必要時 - リファクタリング前の評価 ## Instructions ### 1. Check CI/CD Status **プルリクエストの場合、最初にCI/CDステータスをチェックする:** ```bash # GitHubのPR番号が明示されている場合 gh pr view <PR番号> --json statusCheckRollup # または、現在のブランチのPRを確認 gh pr status gh pr checks ``` **CI/CDチェックの結果に応じた対応:** - ✅ **すべてパス**: 通常のコードレビューに進む - ❌ **失敗あり**: - **自分が作成したPR**: 失敗原因を分析し、修正を実施 - **他人のPRレビュー**: 失敗内容を確認し、レビューコメントに含める **CI失敗時の詳細確認:** ```bash # 失敗したチェックの詳細を確認 gh pr checks <PR番号> # ログの取得（GitHub Actionsの場合） gh run view <run-id> --log-failed ``` ### 2. Confirm Review Scope レビュー対象を明確にする: ```bash # 変更ファイルの確認 git status git diff --name-only # PRの場合は差分を確認 gh pr diff <PR番号> # または特定のファイルが指定されている場合はそれを対象とする ``` ### 3. Understand Context レビュー前に以下を確認: - プロジェクトの種類(プロトタイプ/MVP/本番) - 関連する既存コード - テストの存在 - ドキュメント ### 4. Handle CI Failures **自分のPRでCI失敗の場合:** 1. **失敗の原因を特定**: - テスト失敗: どのテストがなぜ失敗したか - ビルドエラー: コンパイルエラー、型エラー等 - Linter/Formatter: コーディングスタイル違反 - セキュリティスキャン: 脆弱性検出 2. **修正を実施**: - エラーログを読み、根本原因を修正 - 関連するテストケースも更新 - ローカルで同じチェックを実行して検証 3. **再プッシュ**: ```bash git add . git commit -m "fix: resolve CI failures" git push ``` **他人のPRレビューでCI失敗の場合:** レビューコメントの冒頭に以下を追加: ```markdown ## ⚠️ CI/CD Status ### 失敗しているチェック - [チェック名1]: [失敗理由の要約] - [チェック名2]: [失敗理由の要約] ### 修正が必要なアクション 1. [具体的な修正内容] 2. [具体的な修正内容] 詳細は以下のコードレビューを参照してください。 --- ``` ### 5. Conduct Systematic Review 以下の観点でコードを評価(詳細は[reference.md](reference.md)参照): #### A. コード品質 - 可読性(変数名、関数名の適切性) - DRY原則の遵守 - 適切な抽象化レベル - コメントの質(「なぜ」を説明) #### B. エラーハンドリング - エラーケースの適切な処理 - エラーの抑制ではなく根本原因の解決 - 明確なエラーメッセージ - 外部API呼び出しの失敗処理 #### C. セキュリティ - 認証情報のハードコード確認 - 入力検証の実装 - OWASP Top 10の脆弱性チェック - 最小権限の原則 #### D. テスト - テストカバレッジ - エッジケースのテスト - テストの独立性 - テストの可読性 #### E. パフォーマンス - N+1問題 - 不要なループや計算 - キャッシング戦略 - リソースリーク #### F. 保守性 - 適切なモジュール分割 - 依存関係の明確性 - 技術的負債の記録 - 一貫したコーディングスタイル ### 6. Provide Feedback レビュー結果を以下の形式で提供: ```markdown ## コードレビュー結果 ### ⚠️ CI/CD Status (該当する場合) [CI失敗情報をここに記載] ### 🔴 Critical Issues (即座に修正が必要) - [具体的な問題と場所] - [修正案] ### 🟡 Warnings (修正を推奨) - [改善提案] - [理由] ### 🟢 Good Practices (良い点) - [評価できる実装] ### 💡 Suggestions (任意の改善案) - [より良い実装の提案] ### 📝 Notes - [その他の気づき] ``` ### 7. Constructive Communication - 個人ではなくコードに焦点を当てる - 問題だけでなく、良い点も指摘 - 具体的な改善案を提示 - 「なぜ」その変更が必要かを説明 ## Key Principles 1. **プロジェクトコンテキストを考慮**: プロトタイプと本番環境では異なる基準を適用 2. **優先順位付け**: Critical > Warning > Suggestion の順で重要度を明示 3. **実用性**: 完璧を求めすぎず、適切なバランスを取る 4. **学習機会**: レビューを教育の機会として活用 ## Reference Documents - [詳細なレビュー基準](reference.md) - [レビュー実例](examples.md) ## Dependencies - Git (変更差分の確認用) - GitHub CLI (`gh`) - PR情報とCI/CDステータスの取得用 - プロジェクト固有のlinter/formatter(存在する場合) ## CI/CD Integration このスキルは以下のCI/CDシステムに対応: - GitHub Actions - CircleCI (GitHub統合経由) - その他GitHub Checksに統合されているCI/CD **注意**: PRのCI/CDステータス確認には`gh`コマンドが必要です。インストール方法: ```bash # macOS brew install gh # 認証 gh auth login ```


Security scan verdicts — ClawScan: suspicious | static analysis: suspicious | VirusTotal: clean | SkillSpector: clean (LOW)