pythia-write について
pythia-write は PL/SQL 作成向けのエージェントスキルです。類似プログラムやデータベースのメタデータから規約を確認してからファイルを作成・検査し、変更範囲を依頼内容に限定します。適用作業は pythia-apply に委ねます。
主な機能
- 01プロジェクト規約の先行確認
- 02類似プログラムの検索と踏襲
- 03プログラム引数とテーブル型の確認
- 04規則に沿った PL/SQL ファイル作成
- 05lint とパターンによる検査
活用シーン
- 01既存コードベース向け PL/SQL プログラムの作成
- 02データベースのシグネチャと列型に基づくオブジェクトの草案作成
- 03適用前の PL/SQL ファイルの確認
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/pythia-writeを入力して読み込まれたか確認します。
同梱ファイルreference/patterns.md
詳細
PL/SQL の作成
開始時にアナウンス：「pythia-write を使用します。まずコードベースの規約を調べます。」
フェーズ： 学習 → 実行 — まず近接するコードを調べてから作成します。反映は pythia-apply の担当です。
作業を始める前に： プロジェクトに .pythia/conventions.md がある場合は、それを読みます。そこに記載されたプロジェクト固有のルールは、以下の一般的なパターンより優先されます。また、pythia conventions では、apply のプレビューでチェックされる命名パターンを確認できます。プロジェクトにファイルがなく、開発者が独自のスタイルを説明した場合は、pythia conventions --init を提案します。一度記録すれば、以後のセッションで再説明する必要はありません。
何千ものプロシージャがあるコードベースでは、プロシージャの書き方がすでに決まっています。あなたの仕事は、保守担当者が既存のものと見分けられないプロシージャを作ることです。より良いスタイルを持ち込むことではありません。
ワークフロー
- 手本を見つけます。
pythia similar <NEW_NAME>は、名前のトークンが一致する既存のプログラムを順位付けします。MATCHED_TOKENS列に一致した理由が表示されます。上位 2、3 件をpythia srcで開き、命名、パラメータの接頭辞、カーソルのスタイル、エラー処理、コメントのスタイルをまねます。 - シグネチャを確認します。 呼び出すプログラムごとに、
pythia args NAMEを実行して、実際のパラメータ名、順序、型、デフォルト値を確認します。類似コードの記憶を頼りにシグネチャを推測してはいけません。 - 型を確認します。 変更するテーブルごとに、
pythia cols TABLEを実行します。手作業で現在の型をコピーするのではなく、列を基準に%TYPE／%ROWTYPEで変数を宣言します。こうすれば、列が変更されても宣言はそのまま使えます。 - ファイルを作成します。 書き込み時に適用されるルールです。必ず守ってください。
- ファイルごとにオブジェクトを 1 つにします。 パッケージ仕様部と本体部は別々のファイルにします。
- PL/SQL ブロックの
;でファイルを終え、最終行には/を置きます。 - オブジェクト名はスキーマ修飾なしにするか、接続先と完全に一致するスキーマで修飾します。一致しない場合、適用時に拒否されます。
- ASCII 以外の文字列リテラル（ベトナム語のメッセージや、アクセント付き文字を含むテキスト）は、直接貼り付けてはいけません。
pythia unistr "<text>"を実行し、出力されたunistr('...')を使うことで、どのクライアント／DB の文字セットでもテキストを正しく保持できます。（COMMENT ON ... ISは例外で、リテラルのみを受け付けます。）
- 引き渡す前に自分で確認します。 まず
pythia lint <file>を実行し、組み込みの規約と LEAD のルールをチェックします。エラーはプレビュー前に修正します。次にreference/patterns.mdと照らし合わせて読み直し、カーソルとバルク処理のパターン、例外処理の原則、バインド変数、コミットの責任範囲を確認します。作成または変更したコメントはすべてpythia-commentにかけます。
作業範囲を決めるのは開発者の指示であり、あなたではありません
開発者が指定したオブジェクトだけを変更します。影響分析で破損する依存先が見つかった場合は、その一覧と提案を報告します。依存先の修正は別の依頼であり、個別の明示的な承認が必要です。「ついでに」が、依頼されたテーブルの編集を、頼まれていない 7 つのプロシージャの書き換えに変えてしまいます。
好みより規約を優先します
コードベースで明示カーソルを使っているなら、FOR r IN を使いたくても明示カーソルを使います。パラメータの接頭辞が時代遅れに見えても、同じものを使います。スタイルが混在するコードベースは、古くても一貫したコードベースより悪いものです。スタイル変更は開発者に別途提案し、黙って変更してはいけません。
このスキルを使用しない場合
- 新しいパッケージ、API、トリガーの設計 → まず
pythia-packageで形を決めます。 - テーブル、列、コメント →
pythia-table。 - 既存コードの理解 →
pythia-explore。 - 変更による影響の測定 →
pythia-impact（事前に必ず実施してください）。 - データベースへのファイルの反映 → 必ず
pythia-applyを使います。run-sqlもsqlplusも使ってはいけません。