pythia-review

PL/SQL のレビュー

開始時に宣言: 「pythia-review を使用します。まずデータベースのシグナルを確認します。」

フェーズ: 学習 → 質問 — まずデータベース自身のシグナルを確認し、開発者に調査結果を返します

2 つのパスでレビューします。まずデータベースが「誤りだと把握している」ことを確認し、次にチェックリストから「誤りの可能性が高い」ことを確認します。機械のシグナルを先に確認します。無料で、正確だからです。

パス 1 — 機械による判定

0. pythia lint <file>（提案ファイルの場合）— 行番号に紐づけられた、組み込みの標準と conventions.json に記載された LEAD のルールです。エラーは調査結果として報告し、手作業で再導出しないでください。
1. pythia errors NAME — 行・列番号付きのコンパイルエラーと警告です。コンパイルできないオブジェクトは、まだスタイルレビューする必要はありません。
2. pythia src NAME — コンパイラーの行番号付きでソースを読み、調査結果を行番号に紐づけられるようにします（line 47: ...）。
3. pythia impact NAME --depth 2 — このオブジェクトがどれほど影響を受けるかを確認します。依存先が 40 個あるものの調査結果は、同じ調査結果でも末端のものより優先度が高くなります。
4. 提案ファイル（まだ適用されていないもの）の場合：コンパイル結果が得られるのは適用時です。コンパイルはまだ検証されていないことを明記してください。

パス 2 — アンチパターンのチェックリスト

reference/antipatterns.md を確認します。また、プロジェクト独自の .pythia/conventions.md がある場合は、汎用リストより優先して確認します。7 項目は、それぞれ誤り → 正しい方法 → 理由の順です。行ごとのカーソルループ、文字列連結による動的 SQL、WHEN OTHERS THEN NULL、ループ内の COMMIT、%TYPE／%ROWTYPE ではなく手作業でコピーした型、大きな OUT パラメーターでの NOCOPY の未使用、コードベースとの規約のずれ（プロジェクトのスタイルは pythia similar で確認できます）。

調査結果の報告

• すべての調査結果に根拠を示します。line N: <何が問題か> — <なぜ問題になるか> — <修正方法>。
• 重要度の順序：正確性を損なう問題 → 気づかれずにデータを失う、またはエラーを起こす問題 → 大規模時のパフォーマンス → スタイルのずれ。
• 報告する前に主張を検証します。実際の行を src で読み、差分の記憶だけを頼りに報告しないでください。
• 問題がないレビューでは、「問題なさそうです」とだけ述べず、確認した内容を報告します。コンパイルエラーなし、新たな INVALID なし、チェックリスト確認済み。

このスキルを使わない場合

• 変更を適用しても安全かどうかのレビュー — これは pythia-impact と pythia-apply のプレビューで確認します。このスキルではコード自体を評価します。
• PL/SQL 以外のアプリケーションコードのレビュー — このスキルの対象外です。