review-crate

このスキルは、対象のクレート全体を実際に読み込んだ場合にのみ有効です。

譲れないルール：

1. 対象クレート内のすべてのファイルを列挙して読み込むこと。
2. 具体的な阻害要因がない限り、クレートのテストを実行すること。
3. すべての指摘について、正確な file:line の根拠を示すこと。
4. 新しい指摘を書く前に、現在のリポジトリにある正規の issue ファイルを確認すること。
5. 指摘は、このリポジトリ内の .ulpi/issues/<crate-name>.md にのみ記載すること。

review-crate

入力

• $crate_path：クレートディレクトリへのパス

目標

以下を実施し、クレートを完全に監査します。

• クレート全体を読み込む
• テストを実行する
• 実際のバグとカバレッジの不足を報告する
• 既存の指摘と重複しないように、正規のローカル issue ファイルを更新する

ステップ 0：クレートの識別情報を解決する

次の情報を特定します。

• クレートのパス
• Cargo.toml に記載されたクレート名
• 正規の issue ファイルのパス：.ulpi/issues/<crate-name>.md

クレートのパスが無効な場合は、処理を中止し、その旨を明確に伝えます。

成功基準：レビュー開始前に、クレートと issue ファイルの保存先が明確になっていること。

ステップ 1：クレート全体を列挙して読み込む

次のものを含め、クレート内のすべてのファイルを読み込みます。

• Cargo.toml
• ソースファイル
• テストファイル
• CLAUDE.md など、クレート内のドキュメント
• クレートディレクトリ内の補助ドキュメント

一部だけを確認して済ませてはいけません。「主要なファイル」を読んだ時点で終えてはいけません。

成功基準：クレート全体を読み込んだと正直に述べられること。

ステップ 2：クレートのテストを実行する

通常は、次のような、クレート全体を検証できる最小範囲の方法を実行します。

• cargo test -p <crate-name> -- --nocapture

テストを実行できない場合は、具体的な阻害要因を報告します。

成功基準：レビューに、実際のクレートテストの結果、または実行できない具体的な理由が含まれていること。

ステップ 3：既存の issue ファイルを確認する

.ulpi/issues/<crate-name>.md がすでに存在する場合：

• まずそのファイルを読む
• 既存の指摘との重複を避ける
• 真に新しい問題のみを追記する

存在しない場合：

• 記録に値する指摘があれば、そのファイルを作成する

成功基準：issue ファイルが正規の記録として保たれ、重複がないこと。

ステップ 4：分析して指摘を記載する

次の点を確認します。

• 正確性に関するバグ
• パニックやクラッシュのリスク
• 検証の不足
• 競合状態や状態管理の問題
• データ破損のリスク
• 明らかに実在するパフォーマンス上の問題
• リスクの高い動作に関するカバレッジの不足

指摘ごとに、次の内容を含めます。

• 重大度
• カテゴリー
• 正確な file:line
• 問題が実在する理由
• 修正の方向性

確実でない主張には INFERENCE とラベルを付け、不確実な理由を説明します。

成功基準：指摘に根拠があり、実行可能な内容であること。

ステップ 5：残存リスクをまとめる

次の内容を報告します。

• 読み込んだファイル
• テスト結果
• 記載または追記した指摘
• 残っている不確実性やカバレッジの不足

重大な指摘がなければ、その旨を明確に述べます。

成功基準：ユーザーが、レビューの範囲と残るリスクの両方を把握できること。

ガードレール

• このリポジトリの外にある外部の絶対パスへ指摘を書き込まないでください。
• ファイルを読み飛ばした場合、完全なレビューを行ったと主張しないでください。
• 直感だけで問題を作り出さないでください。
• disable-model-invocation を追加しないでください。これは有効な詳細監査ワークフローです。
• 複数クレートをまとめて確認する作業に変更しないでください。

出力形式

次の内容を報告します。

1. レビューしたクレート
2. ファイル数と、クレート全体を読み込んだ旨
3. テスト結果
4. 重大度別の指摘
5. 書き込みまたは追記した issue ファイル
6. 残存リスク、または問題がなかった旨