create-issue

イシューを作成する

ユーザーの入力を、現在のリポジトリに基づいた実装可能なイシューにまとめてから作成します。イシューの登録依頼があった場合、以下のゲートを通過した時点で作成する権限が与えられます。

権限と確定した決定事項は、その適用範囲内で複数のターンにわたって再利用します。必須の一時停止に入る前に、独立して実行できる権限のある作業を完了してから、該当するスキルファイルへの正確なパスを Markdown リンクで示し、新たな決定または権限が必要であることを示すルールをブロック引用でそのまま引用してください。

ゲート

• 草案を作成する前に調査します。該当するプロジェクトの指示とビジョンを読み、結果と手段の両方について重複するイシューがないか、オープンとクローズ済みのイシューを検索し、影響を受けるコード、テスト、ドキュメントを確認します。
• 重要な要件が未確定の場合、またはユーザーがヒアリングを依頼した場合は、実際に登録されている grill-with-docs または grill-me のループを使用します。grill-with-docs を優先してください。確定した決定事項は再利用します。どちらも利用できない場合は、直接調査し、イシューに影響する不足情報だけを質問します。
• 依頼がプロジェクトのビジョンと矛盾する場合、重複する場合、または重要な事実を確認できない場合は、草案の作成前に停止します。重複する場合は既存のイシューを提示して停止し、同じ依頼を改めて登録するか、既存のイシューを変更するかは尋ねません。
• 投稿前に、現在の GitHub アカウントとエージェント環境から、認証済みの GitHub ユーザー名と正確なモデル名を特定します。どちらか一方でも確認できない場合は停止し、推測したり、汎用ラベルで代用したりしてはいけません。

草案のレビュー

プロジェクトの根拠に基づいてテンプレート、タイトル、ラベル、本文を決め、草案の承認を求めずにイシューを作成します。ユーザーが /create-issue draft や「まず草案を見せて」のように草案の提示を求めた場合は、その場合に限り、先に草案を提示して承認を求めます。後のターンでの依頼も含め、その依頼は明示された適用範囲内で有効です。automatic は受け付けますが、何も変更しません。重要な曖昧さは、上記のゲートに従って該当する点について質問し、代わりに草案全体のレビューを求めることはしません。

ワークフロー

1. リポジトリのイシューテンプレートと既存のラベル規則を確認します。

2. 依頼を調査し、上記のゲートを使って重要な未解決事項を解消します。進捗に関する主張は、この実行で収集した証拠に基づいて行います。

3. 該当するテンプレートに沿って下書きを作成します。テンプレートのすべての見出しを原文のまま、順序どおりに保ち、書くことがない見出しの下には1行で None またはその理由を記載します。見出しの下には、判断、実装、検証に関係する内容だけを記載します。

   • 具体的で平易なタイトル
   • 問題、現在と期待される動作、範囲、制約、必要な動作
   • バグの場合は再現手順とリグレッションに関する期待事項
   • 該当する場合は、ユーザーやテストへの影響、影響を受ける可能性の高い領域、関連作業

4. UI/UX 作業、またはローカルのスクリーンショットや動画については、references/ui-evidence.md を読みます。証拠となるメディアをリポジトリにコミットしてはいけません。プローブの出力など、メディア以外の証拠は折りたたみ可能な <details> ブロック内に記載します。

5. ユーザーから作成を求められない限り、既存のラベルのみを選びます。

6. 下書きのレビュー依頼が引き続き有効で、その下書きがまだ承認されていない場合は、提案するタイトル、ラベル、本文を提示し、ユーザーに承認または修正を求めて停止します。承認後にのみイシューを作成します。

7. イシュー本文の末尾に、次の GitHub Note を独立して目立つ形で追加します。両方の値を、この実行で特定した正確な ID に置き換えます。

   メモ

   @username に代わり ModelName を使用して作成しました。

8. 下書きに対して template-check を --kind issue --body FILE とともに実行します。対象リポジトリのチェックアウト外では --repo OWNER/REPO を追加し、リポジトリに複数のテンプレートがある場合は --template-name を追加します。報告された見出しの問題をすべて修正します。利用可能な GitHub ツールでイシューを作成し、返されたイシューのリポジトリと内容が意図したとおりであることを確認します。その後、ライブの本文に対して --issue N を指定して template-check を再実行し、問題があればイシューを編集して修正します。最後にイシューの URL を返します。書き込み応答が失われた、または中断された場合は、再試行する前にイシューを検索します。書き込みの結果が未解決の場合は不確実であると報告します。依頼が受け付けられた、または委任されたというだけでは、イシューが作成された証拠にはなりません。

結果から始めます。定型文、要約の繰り返し、ワークフローの説明は省きます。ただし、テンプレートの見出しと、その下に記載する1行の None は定型文ではありません。