linear

Linear の課題管理

Linear のワークフローを使用する前に、延期されたツールを含む利用可能な Linear ツールを検出し、現在のスキーマを確認してください。固定の MCP プレフィックスや過去のツール名ではなく、機能（課題の検索、画像、サブ課題の取得、作成・更新、コメント）に基づいてツールを選択してください。不足している機能の報告は、検出後にのみ行ってください。

ワークフロー

1. 課題の詳細を取得する — 作業を始める前に、課題検索機能を使用してください。
2. 画像を確認する — 課題の説明には、重要な背景情報（モックアップ、エラー状態、変更前後など）を含むスクリーンショットが含まれていることがよくあります。利用可能な画像抽出または表示機能を使用してください。生の Markdown だけを読むと、報告者が見ていた内容を見落とします。
3. サブ課題を確認する — 利用可能な親課題フィルターまたは課題の関連フィールドを使用してください。
4. 着手時に「進行中」にする — 計画または実装を始めた時点で「進行中」に設定してください。これにより、チームメイトに担当者がいることが伝わり、作業の重複を防げます。
5. 次の課題に移る前に、課題ごとの完了手順に従ってください。

課題の作成

課題を作成する際は、claude code ラベルを追加してください。理由：このラベルによって、チームは AI が生成した課題をフィルタリングおよび監査できます。ラベルがないと、そのような課題は一般のバックログに埋もれ、AI による貢献の傾向をチームが把握できなくなります。

ユーザーが別の担当者を明示的に指定する場合、または課題を未割り当てのままにするよう求める場合を除き、assignee: "me" を渡して、認証済みの Linear ユーザーに課題を割り当ててください。明示的な割り当ての指示は、常にこのデフォルト設定より優先してください。

言語

課題の言語は、その課題につながった会話の言語に合わせてください。中文で話している場合は課題を中文で書き、英語で話している場合は英語で書いてください。理由：課題は会話の続きであり、言語を切り替えると、スレッドを始めた協力者に翻訳の負担が生じます。

具体的には：

• 中文での会話 → 本文は中文で記述します。ファイルパス、識別子、ライブラリ名、コマンド、エラーメッセージなどの技術用語は英語のままにします。
• 英語での会話 → 本文は英語で記述します。
• コードブロック、ファイルパス、引用文字列は、周囲の言語にかかわらず常に元の形式のままにします。
• 更新にも同じルールが適用されます。既存の課題を編集する際（説明とタイトルの両方）、編集のきっかけとなった会話の言語を保ってください。リファクタリングの途中で課題の言語を切り替えないでください。

サブ課題ツリーの作成

親課題をサブ課題ツリーに分割する場合（例：LOBE-xxx のタスク分解）、以下の規則に従い、利用可能なツール機能を確認してください。

1. タイトルに順序を示すインデックスを付ける

Linear はサブ課題の順序付けをサポートしていますが、ツールによってサポート状況が異なります。特定の MCP ツールで利用できると決めつけず、検出された作成・更新スキーマで順序付けフィールドを確認してください。

回避策：タイトル自体に実行順序を含めます。

[1]     [db]       add schema fields
[2]     [db]       new table + repository
[3]     [service]  business logic layer
[4]     [api]      REST endpoints
[4.1]   [sdk]      client SDK wrapper
[4.1.1] [app]      consumer integration
[4.1.2] [app]      UI surface
[4.2]   [ui]       dashboard page

パネル上で順序が入れ替わっても、読者は依存関係の構造をひと目で把握できます。ドット区切りの番号 [n.m.k] は親子の階層を反映し、インデックスとツリーが一致するようにしてください。

2. サブ課題はルート直下に並べず、論理的な親子関係に従ってネストする

Linear は無制限の深さのサブ課題をサポートしています。1 つのルートの下に 8 件以上の兄弟課題を並べると、全体を把握しにくくなります。主従関係に沿ってグループ化してください。

• コアサービス → その SDK → SDK の利用者
• 子課題のほうが適切な場合は、兄弟課題を作成しないでください

課題の作成時または移動時に、検出されたスキーマを使用して親課題との関連を設定してください（たとえば、サポートされている場合は parentId: "LOBE-xxxx" を指定します）。親課題を移動しても、blockedBy の関連を書き換える必要はありません。

3. サブイシューの作成順序は blockedBy によって決まります

blockedBy を指定するには、ブロッカーが先に存在している必要があります（その LOBE ID が必要です）。そのため、次のようにします。

1. DAG をトポロジカルソートします — 依存関係のないリーフを先に、ルートを最後にします
2. 依存関係がないイシューを最初のウェーブで作成します
3. 先行するレスポンスからブロッカー ID を収集してから、依存するイシューを作成します
4. blockedBy は追加専用です。再度渡しても上書きされないため、安全に再実行できます

4. 依存関係の順序を守る

依存するイシューを作成する前に、ブロッカー ID を収集してください。メッセージ内でツール呼び出しが表示される順序から、並列実行されると決めつけないでください。アクティブなツールがサポートする実行方法を使用してください。

5. 各サブイシューの説明を自己完結させる

各サブイシューには、次の内容を記載してください。

• 目標（1～2 行）
• 変更対象の主要なファイル
• 具体的な変更内容／受け入れ基準
• 依存関係（ブロッカーとなるイシューへのリンクを LOBE-xxxx 形式で記載）
• 検証手順

実装担当者はサブイシューだけを開き、親イシューは開かない場合があります。親イシューの説明にしかないコンテキストに依存しないでください。

イシューごとの完了

次のイシューを開始する前に、各イシューを完了させてください。Linear の更新をすべて最後まで先延ばしにしないでください。そのイシューのステータス更新とコメントには、既存の承認を再利用し、再度確認を求めないでください。

1. 実装と、関連テストを含むリポジトリで必須のチェックを完了します。リポジトリの AGENTS.md の「Quality Check」セクションに従ってください（LobeHub では bun run check）。
2. 必要に応じて pr スキルを使って PR を作成します。Linear が PR とイシューを関連付け、マージ時にイシューをクローズできるよう、PR の本文に Fixes LOBE-123（または Closes / Resolves）を含めてください。
3. PR のマージ待ちの間にイシューを In Review に更新し、マージ後に Done に更新します。PR が不要な作業は、成果と検証が完了した時点で Done にします。
4. 結果の挙動、重要な変更、検証内容、PR のリンクを含む簡潔な完了コメントを、積極的に追加または更新してください。PR との関連付けは、ユーザーが読める要約の代わりにはなりません。既存のコメントで同じ結果をすでに説明している場合は、重複して投稿しないでください。