send-to-linear

Linear に送信

構造化されていない入力を、適切に整理された Linear チケットに変換します。

セットアップ

設定の解決

次の順序でチーム設定を探します（最初に見つかったものを使用します）。

1. ~/.agents/configs/send-to-linear/config.json（ユーザーによる上書き）
2. references/config.json（このスキルファイルを基準とした同梱のデフォルト設定）

ユーザー設定が見つかった場合はそれを使用します。見つからない場合は、同梱の config.json を使用します。

ユーザー設定が存在せず、同梱設定の必須フィールド（team、default_assignee）が空の場合は、作業を中止してユーザーに確認します。

ローカル設定が見つかりません。同梱の references/config.json には空のデフォルト値が含まれており、このスキルの更新時に上書きされます。

ユーザー設定を次の場所に作成してください：~/.agents/configs/send-to-linear/config.json

同梱の references/config.json をひな形としてコピーし、チーム、プロジェクト、担当者、ラベル、規約を入力してください。

テンプレートの解決

チケットテンプレートにも同じ方法を適用します。

1. ~/.agents/configs/send-to-linear/ticket-template.md（ユーザーによる上書き）
2. references/ticket-template.md（同梱のデフォルト）

テンプレートをカスタマイズする必要はほとんどないため、同梱版しか存在しなくても確認は求めません。

フェーズ 1：入力の取り込み

次の入力を任意に組み合わせて受け付けます。

• Slack のダンプ — 貼り付けられたメッセージ、または Slack MCP ツールで取得したメッセージ
• 通話の文字起こし — Fireflies（mcp__fireflies__* ツール）から取得したテキスト、貼り付けられたテキスト、またはファイル
• スクリーンショット — Read ツールで画像ファイルを読み取ります
• 会議メモ／ドキュメント — Markdown、テキスト、ドキュメントの内容
• ユーザーの説明 — 自由形式の「X、Y、Z が必要です」

ユーザーの入力が曖昧または不完全な場合は、先に確認の質問を 1 つだけします。過度に質問を重ねないでください。

Fireflies の文字起こしの場合は、要約（fireflies_get_summary）と全文の文字起こし（fireflies_get_transcript）の両方を取得します。トピックの特定には要約を、詳細の抽出には全文の文字起こしを使用します。

フェーズ 2：トピックと実行可能な項目の抽出

短い入力（5K 文字未満）の場合は、メインコンテキストで直接抽出します。

長い入力（5K 文字超、たとえば通話の全文文字起こし）の場合は、主要なトピックまたは時間区間ごとに 1 つずつ、サブエージェントを並行して起動し、次の項目を抽出します。

1. 具体例とユースケース — 最も重要な出力です。具体的なシナリオ、企業名／ティッカー、KPI、正確な引用、タイムスタンプ、推論の流れを記録します。「解釈エラーを修正する」というチケットは役に立ちません。「解釈エラーを修正する — たとえば、Intel の CapEx について解説が『横ばいから減少』と述べている一方で、コンセンサス予想が『減少』の場合、上方修正として認識する」のようなチケットなら、すぐに作業に取りかかれます。
2. 機能要件 — 実装または変更が必要なもの
3. 制限／対象範囲 — 明示的に対象外とされたもの
4. 受け入れ基準 — テスト可能な条件

項目を次のように分類します。

• 実行可能なチケット — 範囲が明確で、すぐに着手できるもの
• アイデア／さらに検討が必要な項目 — 構想段階または探索的な内容で、追跡はするものの、すぐには実行できないもの

フェーズ 3：チケットをスクラッチパッドに下書きする

references/ticket-template.md の形式を使用して、.claude/scratchpad/linear-tickets-YYYY-MM-DD.md に書き込みます。

ソースに実例が含まれるチケットには、必ずその例を原文のまま含めてください。具体性を要約で削らないでください。

フェーズ 4：検証（長文の入力のみ）

短い／単純な入力の場合は省略します。通話の文字起こしや長い Slack スレッドの場合は、次の確認を行う検証用サブエージェントを起動します。サブエージェントはソース資料全体と下書きのチケットを読み、抜け漏れの一覧を作成します。

• チケットに含まれていないユースケース
• 担当者が割り当てられているのに記録されていないアクション項目
• 受け入れ基準に含まれていない、合意済みの設計上の決定事項
• どのチケットにも含まれていない「X を行う必要がある」という発言

見つかった抜け漏れを下書きに反映します。

フェーズ 5：ユーザーによる確認

ここで停止します。 ファイルの準備ができたことをユーザーに伝え、Linear に何かを作成する前に、明示的な指示を待ちます。

ユーザーは項目の再構成、統合、分割、名称変更、メモの追加、項目のスキップを依頼できます。先に進む前に、フィードバックをすべてスクラッチパッドのファイルに反映します。

フェーズ 6：Linear で作成する（明示的な承認があった場合のみ）

Setup の解決順序に従って設定を読み込み、次の手順を実行します。

1. mcp__linear__list_teams — チーム ID を解決します
2. mcp__linear__list_issue_labels — ラベル ID を解決します
3. mcp__linear__list_projects — プロジェクト ID を解決します（設定されている場合）
4. mcp__linear__list_cycles with type: "current" — 現在のサイクルを解決します（assign_to_current_cycle が true の場合）

承認されたチケットをそれぞれ mcp__linear__create_issue で作成します。

• team：設定の値
• project：設定の値
• assignee：設定の値
• cycle：現在のサイクル番号
• state：設定の default_status
• labels：チケットの Labels フィールドに基づいて照合したもの
• title：チケットのタイトル
• description：Markdown 形式のチケット本文全体
• links：利用可能な場合はソースリンク（例：Fireflies のトランスクリプト URL、Slack のパーマリンク）

作成したチケットの識別子をユーザーに報告します。

主なルール

1. 具体例は必須です。 エンジニアは抽象的な説明ではなく、具体的なシナリオから構築すべきものを把握します。推論の流れ全体、正確な引用、実際の状況を保持してください。
2. ユーザーの承認なしにチケットを作成してはいけません。 必ず最初にスクラッチパッドへ下書きしてください。
3. 設定は既定値であり、制約ではありません。 ユーザーは呼び出しごとに、チーム、担当者、ラベル、その他のフィールドを上書きできます。
4. 過度に統合しないでください。 2 つの項目が独立した作業であれば、別々のチケットにします。項目が本当に同じ成果物の一部である場合にのみ、まとめてください。
5. 会話の中に埋もれている独立した要件もチケットにします。 「日付も比較する必要があります」のような何気ない発言も、独立した作業項目です。