bugfix-crate

このスキルは、厳格なレッド・グリーン・リファクタリングの修正ループです。

譲れないルール：

1. 一度に修正する指摘は1件だけです。
2. 動作上のバグについては、修正前に失敗する回帰テストを書いてください。
3. 修正ごとにクレートのテストと Clippy を実行してください。
4. 必要な検証を行わずに、指摘を修正済みにしてはいけません。
5. Rust コードを変更する前に、クレート固有のコーディング規約を確認するため rust スキルを使用してください。

bugfix-crate

入力

• $issues_file：クレートの指摘事項ファイルへのパス

目標

クレートの問題ファイルを順番に処理し、最終的に次の状態にします。

• 解決した各指摘に対する、検証済みの修正
• 動作に関する各修正の回帰テスト
• 合格するクレートのテストスイート
• 修正済み、保留、またはバグではないと判定した内容を示す、更新済みの問題ファイル

ステップ 0：ベースラインを確立する

編集を始める前に、次の作業を行います。

• 問題ファイル全体を読む
• 対象のクレート名とパスを特定する
• 関連する規約について rust を呼び出す
• クレート内に CLAUDE.md またはテストに関するガイダンスがあれば読む
• ベースラインの cargo test -p <crate> を実行する
• ベースラインの cargo clippy -p <crate> -- -D warnings を実行する

成功基準：最初の修正を行う前に、クレート、問題ファイル、ベースラインの状態が明確になっていること。

ステップ 1：指摘を1件ずつ処理する

未解決の指摘ごとに、次の作業を行います。

• 指摘に記載されたファイルとその前後のコンテキストを読む
• 動作、API、デッドコード、ドキュメントのみ、保留、またはバグではない、のいずれに該当するか判断する
• 動作または API の修正であれば、まず失敗するテストを書く
• 実装を変更する前に、テストが失敗することを確認する

指摘をまとめて処理してはいけません。

成功基準：修正を加える前に、各指摘に対する具体的な解決方針が決まっていること。

ステップ 2：必要最小限の修正を適用する

根本原因に対処する最小限のコード変更を行います。

ルール：

• 隣接するリファクタリングをまとめて行わない
• 既存のテストを弱めない
• #[allow(...)] で警告を隠さない
• 変更対象の領域で別の実際のバグが見つかった場合は、同じ作業中に修正し、問題ファイルに追加する

成功基準：広範な副作用を生じさせず、修正が根本原因に対処していること。

ステップ 3：検証してステータスを記録する

修正ごとに、次の作業を行います。

• cargo test -p <crate> を実行する
• cargo clippy -p <crate> -- -D warnings を実行する
• 問題ファイルを更新する：
  • 検証済みの修正には **[FIXED]**
  • 実際に存在する範囲外の修正には Deferred: <理由>
  • 妥当でない指摘には Not a bug: <理由>

検証が完了する前に、指摘を修正済みにしてはいけません。

成功基準：指摘を処理するたびに、問題ファイルとクレートの状態が一致していること。

ステップ 4：問題ファイルが解決されるまで完了しない

最後に、次の作業を行います。

• すべての指摘に最終ステータスが付いていることを確認する
• クレートのテストと Clippy が引き続き合格することを確認する
• 解決、保留、却下した指摘を要約する

成功基準：問題ファイルのトリアージが完了し、クレートが正常な状態であること。

ガードレール

• 同じクレートの修正にワークツリーエージェントを使用しないでください。
• ユーザーが明示的に求めた場合を除き、このスキルを先回りして実行しないでください。
• 回帰テストによるカバレッジなしに、動作上のバグを修正済みにしてはいけません。
• 実際の修正を、コメント、警告、ドキュメントで置き換えないでください。
• 1回の検証ループで複数の指摘をまとめて処理しないでください。

出力要件

次の内容を報告してください。

1. 処理したクレートと問題ファイル
2. ベースラインのテストと Clippy の状態
3. 指摘ごとの結果
4. 最終的なテストと Clippy の状態
5. 修正中に新たに見つかり、追加した指摘があればその内容