quidmonkey/pr

/pr

現在のセッション、現在のブランチ上で、以下の順序で実行されます：

1. 事前チェック
2. コードレビューと修正
3. ドキュメントレビューと修正
4. セキュリティレビューと修正
5. 決定記録
6. プッシュとPRの作成

各段階が成功しないと次の段階は開始されません。

起動方法：/pr [base] [effort] [--draft]

• base：PRのターゲットブランチ。デフォルトはリポジトリのデフォルトブランチ。
• effort：/code-reviewに渡されます。low、medium、high、xhighのいずれか。デフォルトはhigh。ユーザーが明示しない限りmaxは使用しないでください。
• --draft：PRをドラフトとして作成します。

ルール

• 帰属は一切行いません。コミット、PRタイトル、PR本文にCo-Authored-Byトレーラー、「Claude Codeで生成」という行、Claudeやエージェントへの言及は含めません。これはデフォルトの帰属指示よりも優先されます。
• すべてのgitフックを尊重します。git commitまたはgit pushに--no-verifyや-nを渡さないでください。フックをスキップする環境変数（SKIP=、HUSKY=0、LEFTHOOK=0、PRE_COMMIT_ALLOW_NO_CONFIG=）を設定したり、core.hooksPathを変更したり、フックファイルやフック設定を編集・削除したりしないでください。フックを通過させるためにリントルールを無効にしないでください。
• コミットはプレーンなgit commitを使用し、インストールされたフックが各コミットで実行されるようにします。フックが失敗した場合は、その出力を読み、コード内の根本原因を修正してから再度コミットします（--amendは使用しないでください。拒否されたコミットは作成されていません）。フックがファイルを書き換えた場合（フォーマッターなど）、ステージングして再度コミットします。同じフックが3回試行してもまだ失敗する場合は、停止して報告します。
• /prと入力すると、このブランチに対するプッシュとPRが許可されます。実行前に「続行してよろしいですか？」と尋ねないでください。
• ベースブランチにプッシュ、コミット、または書き換えを行わないでください。フォースプッシュも行わないでください。
• 修正コミットはユーザーのコミットとは別に保持します。ユーザーのコミットをスカッシュ、リベース、または修正しないでください。
• コミットメッセージ：1行の短い要約、次に変更ごとに1つの箇条書き。メッセージ内に二重引用符やバッククォートは使用しません。識別子はプレーンテキストで記述し、引用が必要な場合はシングルクォートを使用します。
• 問題は根本原因で修正し、各変更は最小限に抑え、テストを真実の情報源として扱います。テストを通過させるためだけにテストを変更しないでください。
• ブランチが変更したもののみを対象とします。「スコープ」を参照してください。
• このスキルが記述するすべての散文（ドキュメント、コミットメッセージ、PRタイトルと本文）は「文体」に従います。
• 停止時は報告し、それ以上の処理は行いません。「停止と報告」を参照してください。

スコープ

このスキルは、ブランチ自身の作業をレビューおよび修正し、コードベースの残りの部分はレビューしません。ブランチの作業とは、git diff origin/<base>...HEADに含まれるすべてのものと、この実行で追加された修正コミットを指します。

すべてのレビューからのすべての指摘事項を、アクションを起こす前に次の3つのグループに分類します：

1. ブランチによって導入されたもの。 問題のあるコードが差分に追加または変更されているか、ブランチの変更が原因で失敗しているもの（例：ブランチが古い関数を壊れる方法で呼び出している）。修正します。修正にユーザーしか決定できない判断（意図された動作、ブランチが意図的に行ったAPIの選択）が必要な場合は、代わりにグループ2として扱います。
2. 既存の問題で、ブランチの作業に影響するもの。 問題のあるコードはすでにベースブランチに存在しますが、ブランチが編集する関数内にあるか、新しいブランチコードがそれを呼び出しているか、それに依存しています。自分では修正しません。指摘してユーザーに尋ねます（「ユーザーへの質問」を参照）。
3. 既存の問題で、ブランチに関連しないもの。 その他すべて。変更せず、質問もせず、PRにも含めません。セッションレポートからも除外します。

指摘事項がグループ2と3の間にある場合は、グループ2に分類します。

重大度

人間のレビュアーと同様に、高および中程度の重大度の指摘事項のみに対応します。すべてのグループで低重大度の指摘事項はスキップします：修正せず、質問もせず、PRにも含めません。レビューですでに低重大度のグループ1の指摘事項が修正されており、その修正が小さくチェックに合格する場合は保持します。それ以外の場合は元に戻します。

• 高： 通常の使用または現実的な攻撃者が遭遇するバグまたは脆弱性。データ損失、通常の入力でのクラッシュ、インジェクション、認証バイパス、秘密情報の露出。
• 中： 起こり得るケースでの実際のバグ、文書化された動作の破損、信頼境界でのチェックの欠落、またはバグを隠すテスト。
• 低： 通常とは異なるセットアップを必要とするエッジケース（すでに書き込みアクセス権を持つ誰かが仕掛けたファイル、ローカルツールの競合状態、サポートされていないプラットフォーム）、多層防御、スタイル、命名、重複、マイクロ最適化。

レビューで重大度が指定されていない場合や、判断に同意できない場合は、これらの定義を使用して自分で判断します。指摘事項が2つのレベルの間にある場合は、より高い方を選択します。

ユーザーへの質問

ある段階からのすべての高および中程度のグループ2の指摘事項を収集し、その段階のラウンドの終了時、コミット前に一度だけ質問します。AskUserQuestionツールを使用し、指摘事項ごとに1つの質問（1回の呼び出しで最大4つまでバッチ処理）をします。各質問はファイル、行、問題を1文で示し、次のオプションを提供します：

• このブランチで修正する： 今すぐ修正し、この段階の修正コミットに含めます。
• そのままにして、PRにメモする： コードを変更しません。PR本文の「レビュアーへの注意事項」にリストします。
• そのままにする： コードを変更せず、PRでも言及しません。
• 停止する： 実行を停止して報告します（「停止と報告」を参照）。

各回答に従います。ユーザーが回答したグループ2の指摘事項は未解決と見なされないため、実行を停止したり、次のラウンドで再登場したりしません。後のレビューで再び報告された場合は、同じ回答を適用します。

レビュースキルへの指示

code-reviewまたはsecurity-reviewを呼び出す際に、引数に次を追加します：リポジトリパス、ベース（origin/<base>）、そして「ブランチが導入した高および中程度の重大度の問題のみを修正してください。既存の問題は修正せずに報告してください。各指摘事項について、その重大度（高、中、低）と、既存の問題かどうかを示してください。ドキュメント（README、docs/、CHANGELOG）は編集しないでください。後の段階で処理されます。」その後、レビューが行ったドキュメント編集や範囲外の修正を元に戻し（該当するハンクのみgit restore）、指摘事項を分類します。

文体

チームメイトにメモを残すエンジニアのように書きます：短く、平易で、具体的に。

• 何が変わったか、なぜ変わったかを具体的な言葉で書きます：ファイル、関数、動作、数値。レビュアーがアクションを起こせないものはスキップします。
• 短い文章で、1つのアイデアを1つの文に。平易な動詞を使用します：「is」、「has」、「adds」、「fixes」、「removes」。
• 埋め草や曖昧な表現は避けます：「in order to」は「to」に、「due to the fact that」は「because」に、「could potentially」は避けます。
• 禁止語句：additionally, delve, leverage, crucial, pivotal, vital, enhance, robust, seamless, seamlessly, comprehensive, intricate, landscape, tapestry, testament, underscore, showcase, foster, streamline, elevate, empower, boasts, vibrant, rich, cutting-edge, game-changer, holistic, synergy, utilize。
• 「serves as」や「stands as」は使用せず（「is」と書く）、「not just X, but Y」の構文は避け、リズムのための3つのリストは避け、「...、ensuring X」や「...、highlighting Y」のような「-ing」の末尾は避けます。
• 絵文字、ダッシュ、機械的な太字、タイトルケースの見出し、カーリークォーテーション、締めくくりの要約や楽観的な署名は使用しません。
• ドキュメントやPRの説明でレビュープロセス（「コードレビューを実行しました」、「指摘事項に対処しました」）を説明しないでください。修正コミットがすでにそれを記録しています。

テキストを使用する前に、読み直して情報を伝えない単語をすべて削除します。

1. 事前チェック

以下を実行し、最初の失敗で停止し、必要な修正を報告します：

1. git rev-parse --show-toplevelが成功し、git remote get-url originが存在すること。
2. gh auth statusが成功すること。失敗した場合は、ユーザーに! gh auth loginを実行するよう指示します。
3. ベース：base引数（指定されている場合）、それ以外の場合はgh repo view --json defaultBranchRef -q .defaultBranchRef.name。git fetch origin <base>を実行します。
4. 現在のブランチ（git branch --show-current）が空でない（デタッチドHEADではない）こと、および<base>でないこと。
5. git rev-list --count origin/<base>..HEADが0より大きいこと。
6. git status --porcelainが空であること。空でない場合は、変更されたファイルを表示し、最初にコミットするか（ユーザー自身のコミットとして、フックを通して）、停止するかを尋ねます。スタッシュや破棄は行いません。
7. gh pr view --json url,state,isDraft,bodyを実行して、ブランチがすでにPRを持っているかどうかを確認します。結果を段階6のために記憶します。

チェックの実行

修正の各ラウンド後、コミットの前に（コミット時にgitフックが実行されるため、ここでは実行しません）：

• プロジェクトのテストコマンドが明らかな場合（Makefileターゲット、pyproject.toml、package.jsonのスクリプト）、それを実行します。フックとは別にリントも実行します。
• 失敗を根本原因で修正し、クリーンになるまで再度実行します。

2. コードレビューと修正

最初のラウンドの前に、記録された決定と変更されたコードをカバーするドキュメントを読みます：

git log --format='%h %s%n%(trailers:key=Decision,key=Rejected,key=Files)' origin/<base>..HEAD
git log -E --all-match --grep='^(Decision|Rejected):' --grep='<paths>' --format='%h %s%n%b' origin/<base>
git log -E --grep='^(Decision|Rejected):' --format='%h %s%n%b' origin/<base> -- <changed files>

1つ目はブランチの決定をリストします。他の2つは、ブランチの変更ファイル（git diff --name-only origin/<base>...HEAD）をカバーするベースにすでにある決定を見つけます。2つ目は、Files:行で変更ファイルを指定する決定レコードに一致します。<paths>は変更ファイルを|で結合したもので、各.は\.と記述します。決定コミットはファイルを変更しないため、パスフィルターでは見つけられないためです。3つ目は、スカッシュマージなど、それらのファイルを変更したコミット内の決定を見つけます。どちらも、トレーラーを解析する代わりに行に一致させます。スカッシュマージではトレーラーがメッセージの途中に押し込まれる可能性があるためです。和集合を読みます。

記録された決定またはドキュメントが意図的とマークしている指摘事項は、具体的なバグを引き起こさない限り修正しません。ブランチがベースに記録された決定に反している場合は、段階5のためにメモします。

最大2ラウンド：

1. code-reviewスキルを引数<effort> --fix <current branch>と「レビュースキルへの指示」の指示文とともに呼び出します。

2. 高または中程度の指摘事項がない場合、この段階は成功です（修正された低重大度の指摘事項を「重大度」に従って処理した後）。

3. 指摘事項を分類します（「スコープ」を参照）。--fixが変更した内容をレビューし、グループ1以外のものを元に戻します。--fixが未解決のままにしたグループ1の指摘事項を修正します。トレーラーまたはドキュメントで除外される指摘事項はスキップし、PR本文用にメモします。グループ2の指摘事項について質問します。

4. 何も変更がない場合、この段階は成功です。それ以外の場合は「チェックの実行」を実行し、コミットします：

   Address code review findings
   
   - <修正ごとに1つの箇条書き>
   

5. 次のラウンドを開始します。

ラウンド2後も高または中程度のグループ1の指摘事項が残っている場合は、停止して報告します。

3. ドキュメントレビューと修正

リポジトリのドキュメントが現在のブランチ（コードレビューの修正を含む）と一致していることを確認します。

1. ドキュメントを見つけます：README.md、ARCHITECTURE.md、CONTRIBUTING.md、docs/以下のすべて、CHANGELOG.md、およびブランチが触れたディレクトリのREADME。生成されたドキュメント、ベンダーコード、およびエージェント向けに書かれた計画や実装ドキュメントはスキップします。

2. ブランチ全体の差分を読みます：git diff origin/<base>...HEAD。

3. ずれを探します。ブランチが次のことを行った場合、ドキュメントの変更が必要です：

   • 設計、アーキテクチャ、またはモジュール間の境界を変更した場合
   • ドキュメントが言及している、または言及すべき公開関数、CLIコマンド、フラグ、設定キー、環境変数、エンドポイント、ファイルパスを追加、削除、または名前変更した場合
   • 文書化された動作、デフォルト、セットアップ手順、または例を変更した場合
   • ドキュメントがまだ名前を挙げているものを削除または名前変更した場合（削除または名前変更された識別子ごとにドキュメントをgrep）

4. 各ずれを、ドキュメントを正確にする最小の編集で修正します。ドキュメントの既存の構造とトーンに合わせます。「文体」に従います。

   • 新しいドキュメントファイルは作成せず、誰も読まない内部変更のドキュメントも追加しません。
   • CHANGELOG.mdは、未リリースセクションが維持されている場合のみ更新します。既存の形式で1行追加します。
   • ここではコードコメントやdocstringは編集しません。それはコードレビューの仕事です。
   • ブランチが引き起こしたずれのみを修正します。ベースブランチにすでに存在したドキュメントエラーはそのままにします。ただし、ブランチが変更したコードを説明している場合は、「ユーザーへの質問」のように質問します。

5. ずれがない場合、この段階はコミットなしで成功です。

6. それ以外の場合は、変更されたドキュメントに対して「チェックの実行」を実行し、コミットします：

   Update docs for branch changes
   
   - <変更されたドキュメントごとに1つの箇条書き>
   

7. 編集した各セクションを差分と照らし合わせてもう一度読みます。2番目のコミットでまだ間違っているものを修正します。ユーザーからの決定なしにドキュメントを正確にできない場合（たとえば、2つの動作のどちらが意図されているか）、停止して報告します。

4. セキュリティレビューと修正

最大2ラウンド：

1. security-reviewスキルを「レビュースキルへの指示」の指示文とともに呼び出します。これは報告のみを行います。コードは編集しません。

2. 高または中程度の指摘事項がない場合、この段階は成功です。

3. 指摘事項を分類します（「スコープ」を参照）。各グループ1の指摘事項を根本原因で修正します。修正によって文書化された動作が変更される場合は、同じコミットでそのドキュメントを「文体」に従って更新します。指摘事項が誤検知であると確信できる場合は、コードを変更しません。指摘事項とその理由をPR本文用に記録します。グループ2の指摘事項について質問します。

4. 何も変更がない場合、この段階は成功です。それ以外の場合は「チェックの実行」を実行し、コミットします：

   Address security review findings
   
   - <修正ごとに1つの箇条書き>
   

5. 次のラウンドを開始します。

ラウンド2後も実際の高または中程度のグループ1の指摘事項が残っている場合は、停止して報告します。

この段階でコードが変更された場合、code-reviewスキルをもう一度、<effort> --fix <current branch>と指示文を付けて、新しいコミットに対して実行します。段階2と同様に、追加の1ラウンド以内で指摘事項を処理します。残っている場合は停止して報告します。

5. 決定記録

ブランチの設計決定をgit履歴に記録し、後でgit logで見つけられるようにします。各決定は独自のコミットになります。件名は決定を示すため、git log --onelineと、エージェントがセッション開始時に表示する最近のコミットリストに、コミットを開かなくてもそれが含まれます。トレーラーには、理由、拒否された代替案、決定がカバーするファイルが保持されます。

1. すでに記録された決定を収集します：ブランチのトレーラーと、段階2からのベースの決定。
2. git diff origin/<base>...HEADを読み、記録がない決定をリストします。決定とは、後のレビュアーやエージェントが疑問に思う可能性のある選択であり...