create-fix-pr

修正 PR を作成する

概要

問題を調査し、それを解決するプルリクエストを作成します。これは investigate スキルを基盤としています。まず調査を適切に行い、証拠なしに修正へ飛びつかないでください。

すべての GitHub 操作には gh CLI を使用し（認証は gh ログインから取得されます）、それ以外のすべてには標準の Bash / Edit / Read / Grep を使用します。

ワークフロー

1. 調査する。 investigate スキルを使用して根本原因を特定します。問題を突き止める正確なトレース ID、ログ行、エラーグループ、コードの場所を引用します。
2. すでに PR がオープンになっていないか確認する。 何かを作成する前に、同じ問題に対処する既存のオープン PR を GitHub で検索します — gh pr list --search "<keywords>" --state open。存在する場合は、ユーザーをそれへ誘導してください — 重複を作成しないでください。
3. PR が適切な手段かどうかを判断する。 修正に設定変更、フラグの切り替え、またはアクセスできるコードの外側での変更が必要な場合は、PR を作成する代わりに解決策を説明してください。
4. リポジトリを取得する。 ローカルにまだない場合はクローンします — gh repo clone <owner>/<repo>。
5. リポジトリの規約を確認する。 リポジトリのルートにある agents.md または CLAUDE.md を読みます — これらは修正が従う必要のあるリポジトリ固有のルールを記述しています。
6. 変更を加える。 最小限の差分。周囲のコードをリファクタリングしないでください。機能を追加しないでください。たまたま気づいた無関係なバグを修正しないでください。1 つの PR、1 つの修正。
7. コミットする前に git のアイデンティティを設定する — pr-conventions.md を参照してください。
8. コミット、プッシュ、PR の作成。 ブランチの命名と PR 本文のルールについては pr-conventions.md を参照してください。

良い修正とは

• 可能な限り最小の行数で変更する
• バグが現在の挙動そのものでない限り、現在の本番挙動を維持する
• 証拠から検証できない前提に依存しない
• code-review スキルが存在するなら、そのチェックを通過するだろう

そうでないもの

• 報告された問題と無関係な大規模なリファクタリング
• 「ついでに」追加された投機的な null チェックやエラー処理
• 根本的なバグを隠すテストの変更
• 症状を修正するための依存関係のバージョンアップ

制限されたツール

gh がインストールされていない場合、または gh auth status が認証なしを示す場合は、エラーをユーザーに提示して停止してください — 代替の認証スキームを試さないでください。

PR に絶対に含めないもの

• GitHub アクセストークン、その他のシークレット、認証情報。
• 調査中に追加したデバッグログや print 文。

それ以外のすべてについては、リポジトリ自身のコミットおよび PR の規約に従ってください。