ticket

チケット

自由形式の説明から Linear の課題を作成します。

このスキルは、ship／ship-autonomous スキルの上流側のペアです。作成した課題は、それらのスキルが取り込み、エンドツーエンドで実装するための入力となります。チケットはそれらのスキルへの入力として適切に読めるよう、スコープを明確にし、受け入れ条件を明示してください。また、ユーザーが実装前のプランレビューを ship-autonomous の必須条件にしたい場合は、プラン承認マーカー（ステップ 3 を参照）を記載してください。

必須ツール

• Linear MCP — ワークスペースのメタデータ（チーム、プロジェクト、ラベル、ステータス）の一覧表示と、課題の作成に使用します。接続できない場合は、ユーザーに再接続を依頼してください。

ワークフロー

1. 説明を読みます。 有用なチケットを作成するには説明が不十分な場合（問題の説明やスコープがない場合）は、簡潔な確認質問を 1 つしてください。それ以外の場合は続行します。

2. Linear MCP 経由でワークスペースを確認します。

   • 現在のプロジェクトディレクトリに一致するチームを選びます — チームの一覧を取得し、スキルが実行されているリポジトリに名前／キー／リンク済み GitHub リポジトリが一致するチームを選択します。一致するチームを特定できない場合は、ユーザーに一度確認し、その回答を記憶しておきます。
   • そのチームのプロジェクトとラベルを一覧表示します。
   • 現在のリポジトリに紐づくプロジェクトが明らかな場合は、あらかじめ選択します。

3. チケットの下書きを作成します。

   • タイトル — 短く、命令形にし、末尾にピリオドを付けません（例：「プロフィールグリッドでのハートのダブルタップを修正する」）。

   • 説明 — 次のテンプレートを使った Markdown（該当しないセクションは省略します）。

     ## Context
     
     <重要な理由／表示される場所>
     
     ## Current behavior
     
     <現在の動作（バグの場合）>
     
     ## Desired behavior
     
     <期待する動作>
     
     ## Acceptance criteria
     
     - [ ] ...
     
     ## Notes
     
     <リンク、エッジケース、フェンス付きブロック内のコードスニペット>
     

   • ラベル — 既存のラベルのみから選びます。新たに作成しないでください。

   • 優先度 — 表現から判断します（「urgent」「blocker」→ High、「nice to have」→ Low）。指定がない場合は Medium にします。

   • 担当者 — ユーザーが名前を挙げていない限り、未割り当てにします。

   • プラン承認マーカー — コードを書く前に実装プランの承認が必要だとユーザーが述べた場合は、説明に次の行を追加します。**Plan first: please post a plan and wait for approval before implementing.** ship-autonomous スキルは、プランレビューを必須にするかどうかを判断するため、チケット内にこのような文言があるかを確認します。

4. タイトル、本文、チーム、プロジェクト、ラベル、優先度を含む下書きをチャットに表示します。明示的な承認を待ってください。 変更を求められた場合は編集し、再度表示します。

5. Linear MCP 経由で課題を作成します。その後、ユーザーの元の依頼文をそのまま新しいチケットの最初のコメントとして投稿します。これにより、整えた説明とは別に、ユーザーが自分の言葉で依頼した内容を保持できます。言い換えたり、要約したり、削ったりせず、ユーザーが書いたとおりに依頼文をコピーしてください。Markdown が意図しない表示になる場合は、フェンス付き引用ブロックに入れてください。課題 ID と URL を報告します。

ルール

• 本文に AI による作成だと記載しないでください。
• ラベルと優先度は、ワークスペースに既存のものを使用してください。
• ファイルパス、エラー、スタックトレースは、そのまま ## Notes にフェンス付きコードブロックで記載します。
• 説明に親課題または重複課題が記載されている場合は、作成時に関連付けを設定します。