スキル code-review-excellence
📦

code-review-excellence

安全

コードレビューの卓越性をマスターする

こちらからも入手できます: wshobson

コードレビューを門番から知識共有へと変革します。このスキルは、チームの士気を維持しながら早期にバグを発見するための体系的な分析フレームワーク、実用的なチェックリスト、協調的なフィードバック技法を提供します。

対応: Claude Codex Code(CC)
📊 71 十分
1

スキルZIPをダウンロード

2

Claudeでアップロード

設定 → 機能 → スキル → スキルをアップロードへ移動

3

オンにして利用開始

テストする

「code-review-excellence」を使用しています。 ユーザー入力を処理してデータベースに保存する関数

期待される結果:

## 要約
3 ファイルをレビュー、150 行変更。テストカバレッジは良好。

## 重要問題
🔴 [blocking] 42 行目で SQL インジェクションリスク - パラメータ化クエリを使用してください

## 提案
💡 検証ロジックを別の関数に抽出することを検討してください
🟢 包括的なエラーハンドリングは素晴らしい仕事です

## 判定
✅ SQL インジェクション問題の修正後承認

「code-review-excellence」を使用しています。 変更可能なデフォルト引数を持つ Python 関数

期待される結果:

## コードレビュー結果

### 🔴 [blocking] 変更可能なデフォルト引数
15 行目:`def add_item(item, items=[]):` - デフォルトリストは呼び出し間で共有されます

**修正:** `def add_item(item, items=None):` を使用し、関数内で初期化してください。

### 🟡 [important] 型ヒントの欠如
保守性向上のため型ヒントの追加を検討してください。

### 🟢 [praise] ドキュメント文字列とエラーハンドリングが良好

セキュリティ監査

安全
v1 • 2/25/2026

All 65 static findings are false positives. The skill is a code review education and guidance resource. Detected patterns (eval mentions, cryptographic references, backtick syntax) are all documentation and educational examples within the playbook, not executable malicious code.

2
スキャンされたファイル
559
解析された行数
4
検出結果
1
総監査数

高リスクの問題 (2)

Documentation Reference to eval()
Line 405 contains a security checklist item '- [ ] No eval() or similar dynamic execution?' - this is teaching reviewers what to look for in code, not actual eval usage.
Cryptographic Algorithm References
Lines 25, 66, 82, 92, 174, 337-339, 374-375 contain references to weak cryptographic algorithms in security checklists - these are educational items teaching reviewers what to check for.
中リスクの問題 (1)
Backtick Syntax in Code Examples
45 locations with backtick syntax detected - these are markdown code block delimiters in documentation examples, not shell command execution.
低リスクの問題 (1)
Fetch API Examples
Lines 297 and 304 contain fetch() calls in example code snippets - these are educational examples showing proper async error handling.
監査者: claude

品質スコア

38
アーキテクチャ
100
保守性
87
コンテンツ
50
コミュニティ
78
セキュリティ
100
仕様準拠

作れるもの

PR レビューの強化

構造化されたレビュー手法を使用して、バグを発見し作者に教育する、徹底的で一貫性のあるフィードバックをプルリクエストに提供します。

新規レビュアーのオンボーディング

チェックリスト、重大度フレームワーク、協調的な言語パターンを使用して、効果的なレビュー技法をジュニア開発者に教育します。

セキュリティ重視の監査

セキュリティチェックリストパターンを適用して、認証、入力検証、データ保護における一般的な脆弱性を特定します。

これらのプロンプトを試す

基本的な PR レビュー
以下のコード変更について、正確性、セキュリティ、保守性の観点からレビューしてください。フィードバックは重大度ごとにグループ化してください(blocking 問題、重要な提案、軽微な指摘)。うまくいっている点の要約も含めてください。
セキュリティ重視のレビュー
このコードのセキュリティレビューを実施してください。次の項目をチェックします:入力検証、SQL インジェクションリスク、XSS 脆弱性、認証の問題、機密データの露出。必須修正の問題には [blocking] を使用してください。
メンタリングレビュー
クイック確認
これらの変更を簡単にレビューしてください。最も重要な問題(最大 1-3 件の blocking アイテム)に焦点を当ててください。フィードバックは簡潔にしてください。

ベストプラクティス

  • PR サイクル時間を短くしチームの勢いを維持するため、24 時間以内にレビューを行う
  • 重大度ラベルを一貫して使用する:[blocking] は必須修正、[important] は修正すべき、[nit] はあれば良い
  • 人間によるレビューをロジックと設計に集中させるため、リンターを使用してスタイルとフォーマットチェックを自動化する

回避

  • 自動化されたフォーマッターを使用する代わりに、軽微なスタイルの好みで PR をブロックする
  • 協調的な質問ではなく「これは間違っている」のような判断的な言語を使用する
  • 対立を避けるために実際のレビューを行わずに承認を押し通す

よくある質問

コードレビューにはどのくらいの時間がかかるべきですか?
1 回のレビューあたり 20-30 分を目指してください。レビューは最大 60 分のセッションに分け、休憩を挟んでください。400 行を超える PR の場合は、より小さな変更への分割を依頼してください。
作者の回答に同意できない場合はどうすればよいですか?
まず彼らの推論を理解することに努めてください。彼らが立てた妥当な点を認めましょう。パフォーマンスが懸念事項の場合はデータやベンチマークを提供してください。重要でない場合は譲歩するタイミングも知ってください。
レビューを依頼する前に自分のコードをレビューすべきですか?
はい。このスキルのチェックリストを使用して自己レビューを行ってください。まず明らかな問題を確認してください。これによりレビューサイクルが減り、レビュアーの時間への敬意を示せます。
徹底的にレビューできない大きな PR はどのように扱えばよいですか?
作者に大きな PR を小さく焦点を絞った変更へ分割するよう依頼してください。レビューが必要な場合は、まず高レベルのアーキテクチャレビューを行い、その後の PR で詳細なレビューを実施してください。
blocking コメントと non-blocking コメントの違いは何ですか?
Blocking コメントはマージ前に解決する必要があります - これらはバグ、セキュリティ問題、または深刻な設計上の問題です。Non-blocking は提案、質問、またはあれば良い改善点です。
コードスタイルの好みについてどのようにフィードバックすべきですか?
スタイルの問題については、自動リンターとフォーマッターを使用するよう作者に指示してください。フォーマットについて手動でコメントせず、自動化できるものは自動化し、人間の努力をロジックと設計に集中させてください。

開発者の詳細

ファイル構成