Python品質チェックスキル (local-python-qa)
目的: Python実装における品質チェック(pytest, ruff, mypy)を実行し、高品質なコードを保証する
使用タイミング: /implementコマンドのステップ0(実装前)とステップ4(実装後)で自動的に読み込まれる
ステップ0: 実装前の品質チェック
目的: 既存コードのバグを事前に修正し、クリーンな状態で実装を開始
1. 型チェック実行
bash
.venv/bin/mypy src/
- •既存のバグや型エラーを発見
- •実装開始前に修正することで、後で混乱を避ける
- •実例:
social_proof_fetcher.pyの構文エラー発見(except句のバグ)
2. リントチェック実行
bash
.venv/bin/ruff check src/
- •コードスタイルの問題を事前に修正
- •既存の警告やエラーを解消
3. エラーが見つかった場合
- •実装開始前に既存バグを修正
- •修正後、再度チェックを実行して確認
- •クリーンな状態になってから実装開始
効果:
- •既存バグの早期発見・修正
- •実装中のエラーを最小化
- •デバッグ時間の削減
注意: このステップで見つかったエラーは、今回の実装タスクとは別にコミットすることを推奨
ステップ4: 自動テストと品質チェック
4-1. テスト実行
bash
.venv/bin/pytest tests/ -v
- •期待結果: 全テストがパス
- •エラーの場合: テストを修正してから次に進む
4-2. Ruff違反の修正(重要)
フロー:
1. エラー確認
bash
.venv/bin/ruff check src/
2. エラーがある場合、以下の手順で修正
a) 自動修正を実行:
bash
.venv/bin/ruff check src/ --fix
- •自動修正可能なエラー(import順序、不要な空白等)が修正される
- •修正内容を確認する
b) 残りのエラーを確認:
bash
.venv/bin/ruff check src/
- •手動修正が必要なエラーがリスト表示される
c) エラーの優先順位を判断:
- •高優先度: セキュリティ(S)、async誤用(ASYNC)、複雑度(C90)
- •中優先度: print文(T20)、命名規則(N)、pylint(PL)
- •低優先度: 簡素化(SIM)、不要コード(PIE)、return改善(RET)
d) 手動修正を実行:
- •エラーメッセージを確認し、該当箇所を修正
- •例:
- •
S(セキュリティ): ハードコードされた認証情報を環境変数に移行 - •
C90(複雑度): 関数を分割してシンプルにする - •
T20(print): print文をstructlog.loggerに置き換え - •
N(命名規則): 関数名・変数名をPEP8準拠に修正
- •
e) 再確認:
bash
.venv/bin/ruff check src/
- •期待結果:
All checks passed!が表示される
3. コードフォーマット
bash
.venv/bin/ruff format src/
- •コードスタイルを統一
- •ダブルクォート、インデント、行の折り返し等を自動調整
4. 🔄 修正後のテスト再実行(重要)
bash
.venv/bin/pytest tests/ -v
- •理由: ruff違反の修正でコードが変更されたため、テストが壊れていないか確認
- •期待結果: 全テストがパス
- •エラーの場合: 修正したコードを見直し、テストを修正してから次に進む
4-3. 型チェック
bash
.venv/bin/mypy src/
- •期待結果:
Success: no issues found - •エラーの場合: 型ヒントを追加・修正してから次に進む
4-4. 最終確認
全てのチェックがパスしたことを確認:
- •✅ pytest: 全テストパス
- •✅ ruff check:
All checks passed! - •✅ ruff format: フォーマット適用済み
- •✅ mypy:
Success: no issues found
重要な原則
品質チェックは必須
全てのチェックがパスするまで実装は完了とみなさない。
- •ruff:
All checks passed!を確認 - •mypy:
Success: no issues foundを確認 - •pytest: 今回の変更に関連するテストが全てパスすることを確認
リファクタリング後のテスト
Ruff違反の修正や型エラーの修正でコードを変更した場合、必ずテストを再実行してください。コード変更によって既存機能が壊れていないことを確認することが重要です。
コスト・リスク管理
外部API呼び出しを伴う動作確認
原則: ユーザーに確認を取る
以下の場合は、実行前に AskUserQuestion ツールで確認すること:
- •LLM API(Bedrock)の呼び出し
- •有料APIの呼び出し
- •メール送信(SES)
- •外部サービスへの書き込み操作
確認例:
code
質問: 「ローカル環境でLLM判定を実行しますか?」 header: "動作確認" 選択肢: - label: "スキップする(推奨)" description: "テストは全てパス済み。コストを避けるため、実行をスキップします。" - label: "実行する" description: "実際にLLM APIを呼び出して動作確認します。コスト: 約14円/30記事"
理由:
- •不要なコストを削減
- •ユーザーの意思決定を尊重
- •リスクの可視化
実装中の中間チェック
フェーズごとの軽量チェック:
各TDDサイクル(RED/GREEN/REFACTOR)完了時に、以下の軽量なチェックを実行すると効果的:
bash
# 関連するテストのみ実行(高速) .venv/bin/pytest tests/unit/services/test_buzz_scorer.py -v # 型チェック(変更ファイルのみ) .venv/bin/mypy src/services/buzz_scorer.py
効果:
- •早期にエラーを発見
- •デバッグコストを削減
- •実装の方向性を随時確認