write-ticket

チケットの作成

調査と判断を行ったのと同じチャットで、最終版のチケットを作成します。ユーザーが開始した場合に限ります。/task はチケットを読み込みます（チケットのコンテキスト）。このスキルがチケットを実装することはありません。

読むタイミング

• ユーザーフローに変更が入りますか？調査中にuser-experience.mdを開き、その内容をPlanの条件付きUX/UIセクションに反映します。バックエンドのみの作業では不要です。
• 分析や草案の作成を始める前ですか？code-quality.md、code-structure.md、doctrine.mdを開きます。読まずに進めると、ルールに反する構成をチケットで計画してしまいます。
• Featureについて詳しく確認したり、草案を作成したりする前ですか？strong-foundation.mdを開きます。読まずに進めると、Planに新しいバリアントを組み込む接点がなくなります。
• 質問する前ですか？ユーザーへの質問と、関連するreference.mdのガイダンスを開きます。読まずに進めると、リポジトリやトラッカーにすでにある情報を尋ねてしまいます。
• 草案を作成する、または執筆を始める前ですか？Planの本文、新しい実行者への引き継ぎ、最終版の説明を開きます。読まずに進めると、チケットの内容を理解するのに以前のチャットが必要になります。

プロセス

1. プロンプトと、名前が挙げられている既存のチケットを読みます。意図する成果と、ユーザーがチャット上のドラフトを求めているのか、トラッカーへの実際の書き込みを求めているのかを確認します。入手可能な場合は、リポジトリとトラッカーに関する情報を推測します。チケットのステージについて質問してはいけません。
2. /analyze を通じて問題とコードの根拠を集め、現在の分析を再利用して、不足分だけを更新します。理解を深めるうえで重要な場合は、対象を絞った /how と /why の調査も適用します。変更内容に応じて、分解の前に 公開境界の調査 を適用します。準備は同じチャット内で行います。途中でチケットを作成したり、調査結果を別途保存したりする必要はありません。
3. 判断ガイダンスに従って /grill-me を適用します。これには、本人の言葉での意図の行ごとの言い換えと準備状況の確認が含まれます。未解決で重要なユーザーの選択についてのみ質問します。依頼がすべて確定している場合は、質問する必要はありません。確定した回答は再利用します。不完全な回答や矛盾を明確にし、正確な契約、理由、依存関係、明示的なブロッカーを、それらを扱う作業項目に反映します。回答によって理解が変わった場合は、新たな事実を調査し、この場で作成中のチケットを修正します。面談を最初からやり直したり、不足がないのに分析パスを再度実施したりする必要はありません。
4. その根拠と確定したコンテキストからプラン本文を作成します。作業項目の契約に従い、依存関係の順に、各項目の「実施内容」「理由」「方法」「予定する検証」の詳細を含む、意義のある実装項目を記述します。項目ごとの理由を重複させず、共有コンテキストは他のセクションに記載します。作業の種類を割り当てます。有用でレビュー可能な PR の境界に分けられる場合は、PR サイズのサブイシューを適用します。同じコンテキストから子チケットの本文とスタックの引き継ぎを作成します。すべての本文を最終版として整えます。
5. 新規実行者への引き継ぎを適用します。重要なドラフトでは、新規コンテキストでの読み取り専用チェッカーと、条件に該当する場合のスタックチェックも含めます。具体的なブロッカーを解消したうえで、子チケットの本文とスタック順がある場合はそれらも含め、最終ドラフト全体を一度だけ「確定」メッセージとして提示します。このメッセージには質問を含めません（ドラフトのみを求められた場合は、これを最終回答とします）。不完全なドラフトや未確認のドラフトは、不足点を明示したままチャット内に留め、実装可能と称してはいけません。
6. ドラフトのみを求められた場合は、その最終ドラフトを提示して終了します。トラッカーへの書き込みが許可されている場合は、まだ不足している優先度、担当者、トラッカーの情報を一度にまとめて確認します。完全なドラフトを提示した後、冗長な許可確認をせずに書き込みます。トラッカーへの書き込みに従い、チケットの識別情報と更新前の重要な本文を保持します。修正後は最終版の整合性を再確認します。
7. 保存した本文と関連付けを読み返します。必要に応じて、実際の URL、種類、適用したメタデータ、スタック順を、未完了の書き込みやブロッカーとともに返します。本文全体を再掲せず、作業結果の出力に従います。作成時のステータスは Todo とし、更新時はユーザーが別のステータスを指定していない限り、既存のステータスを保持します。実装や公開は開始しません。