mcpField
P
python-code-review

python-code-review

github.com/existential-birdsテスト・品質85920 回インストール11 週間前に更新
リポジトリ

python-code-review について

スタイル、型、非同期処理、エラー処理を確認する Python コードレビュー用スキルです。報告前に対象範囲、根拠、検証を順に確認するゲートを備えています。

主な機能

  1. 01PEP 8 スタイルの確認
  2. 02型安全性の確認
  3. 03非同期処理とエラー処理のレビュー
  4. 04誤検出のスクリーニング
  5. 05根拠と検証のゲート

活用シーン

  1. 01Python の書式と命名の確認
  2. 02関数アノテーションと非同期コードの点検
  3. 03ファイルと行番号付きの指摘作成

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/existential-birds/beagle --skill python-code-review

インストール後、Claude Code で/python-code-reviewを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

references/
async-patterns.md
common-mistakes.md
error-handling.md
pep8-style.md
type-safety.md

詳細

Python コードレビュー

クイックリファレンス

問題の種類参照先
インデント、行の長さ、空白、命名references/pep8-style.md
型ヒントの欠落・誤り、Any の使用references/type-safety.md
非同期処理内のブロッキング呼び出し、await の欠落references/async-patterns.md
bare except、コンテキストの欠落、ログ記録references/error-handling.md
可変なデフォルト値、print 文references/common-mistakes.md

レビューチェックリスト

PEP8 スタイル
  • 4 スペースのインデント(タブは使用しない)
  • 行の長さは 79 文字以下(docstring/コメントは 72 文字以下)
  • トップレベル定義の前後には空行を 2 行、クラス内では 1 行入れる
  • インポートをグループ化する:標準ライブラリ → サードパーティ → ローカル(グループ間には空行を入れる)
  • 括弧内やコロン・カンマの前に空白を入れない
  • 命名:関数/変数には snake_case、クラスには CamelCase、定数には UPPER_CASE を使用する
  • インラインコメントの前には 2 つ以上の空白を入れる
型安全性
  • すべての関数パラメーターと戻り値に型ヒントを付ける
  • 必要な場合を除き Any を使わない(使用する場合は理由をコメントで説明する)
  • T | None の構文を正しく使用する(Python 3.10 以降)
非同期パターン
  • 非同期関数内でブロッキング呼び出し(time.sleep、requests)を使用しない
  • すべてのコルーチンに適切な await を付ける
エラー処理
  • bare except: 節を使用しない
  • コンテキストを伴う具体的な例外型を使用する
  • スタックトレースを保持するために raise ... from を使用する
よくある間違い
  • 可変なデフォルト引数を使用しない
  • 出力には print() ではなく logger を使用する
  • .format() や % より f-string を優先する

有効なパターン(問題として報告しない)

以下のパターンは意図的かつ適切です。問題として報告しないでください。

  • 型注釈と型アサーションの違い — 注釈は型を宣言するものであり、実行時のアサーションではありません。検証の欠落と混同しないでください
  • 型付けされていないライブラリとの連携での Any の使用 — 外部ライブラリに型スタブがない場合に必要です
  • 空の __init__.py ファイル — パッケージ構造として有効であり、コードは不要です
  • noqa コメント — 特定のケースにリンタールールが適用されない場合は有効です
  • 実行時の型チェック後の cast() の使用 — 型チェッカーに絞り込まれた型を知らせる適切なパターンです

コンテキスト依存のルール

以下の問題は、該当する条件が満たされる場合にのみ指摘してください。

問題指摘する条件
一般的な例外処理具体的な例外型が利用可能で、意味がある場合のみ
未使用の変数変数名に _ の接頭辞がなく、f-string、ログ記録、デバッグでも使用されていない場合のみ

ゲート(報告ワークフロー)

順番どおりに完了してください。各合格条件を満たすまで、次に進まないでください。

  1. 範囲 — 合格: 今回確認した .py のパス(または明示的な glob)をすべて列挙する。
  2. 誤検知の確認 — 合格: 報告する各問題について、上記の有効なパターンとコンテキスト依存のルールを確認する。それらの項目が指摘しないよう示している場合は、その指摘を取り下げるか範囲を絞る。
  3. 根拠 — 合格: 残る各指摘に [FILE:LINE](または範囲を限定した行番号の範囲)を含める。シンボル名や短い原文の抜粋を場所の目印に添えてもかまいませんが、目印の代わりにはなりません。
  4. 検証プロトコル — 合格: review-verification-protocol を読み込み、ユーザー向けの報告を作成する前に、報告する各問題について必須手順を完了する。
  5. 提出 — 合格: ユーザーに見せる出力が、そのプロトコルで指定された構成に従っている(チェックを省略した問題のみの一覧にしない)。

参照先を読み込むタイミング

  • コードのフォーマット/スタイルのレビュー → pep8-style.md
  • 関数シグネチャのレビュー → type-safety.md
  • async def 関数のレビュー → async-patterns.md
  • try/except ブロックのレビュー → error-handling.md
  • Python の一般的なレビュー → common-mistakes.md

レビューの質問

  1. コードは PEP8 の書式(インデント、行の長さ、空白)に従っていますか?
  2. インポートは適切にグループ化されていますか(標準ライブラリ → サードパーティ → ローカル)?
  3. 名前は命名規則(snake_case、CamelCase、UPPER_CASE)に従っていますか?
  4. すべての関数シグネチャに型注釈が付いていますか?
  5. 非同期関数は本当にノンブロッキングですか?
  6. 例外には意味のあるコンテキストが含まれていますか?
  7. 変更可能なデフォルト引数はありますか?

報告する前に、上記の**ゲート(報告ワークフロー)**を完了してください(特にゲート 4)。

コメント