linear-batch-implement

Linear Batch Implement

オペレーターが実装可能な状態の Linear AI イシューを複数実装したい場合に、このスキルを使用します。

これはオーケストレーターです。linear-implement ワークフローを複製しないでください。単一イシュー向けスキルが、イシューごとの永続的な Linear コメント、ワークフローラベル、ダッシュボードの更新、PR の引き継ぎ、イシュー固有の解釈を担います。

ソースの規約

以下を読み、従ってください。

• skills/linear-implement/SKILL.md
• docs/workflow.md
• docs/implementer.md
• docs/agent-required-passes.md
• docs/superpowers-linear-persistence.md
• scripts/validate_marked_comments.ts

キューの検出

Linear MCP を使用します。

• list_issues を使用して、llm-ready が付いたイシューを検索します。
• 任意のフィルター：チーム、プロジェクト、担当者、ラベル、ユーザーから指定された明示的なイシュー ID。
• 明示的なイシュー ID が指定されておらず、対象のチームとプロジェクトがセッション内でまだ明確でない場合は、検出を始める前に、どのチームとプロジェクトのイシューを対象にするか確認してください。
• llm-* ワークフローラベルが付いたイシューのみをキューに入れます。ユーザーが明示的に指定した場合を除き、llm-* ラベルのないイシューは無視します。
• get_issue と list_comments を使用して、候補ごとに最新の有効な ready プランに plan_status: ready が設定されていることを確認します。

in-use claim ラベルがすでに付いているイシューは除外します。別のエージェントが作業中です。

明示的な dry-run または list-only モードに対応します。dry-run／list-only モードでは、キューを表示して終了し、サブエージェントのディスパッチや Linear の変更は行いません。

まず Linear の優先度でキューを並べ、次に最終更新日時が古い順に並べます。優先度の順序は Urgent、High、Medium、Low、No priority／なしです。同じ優先度内では、updatedAt の昇順に並べます。対象範囲を明示したキューの概要を表示します。概要には、イシュー ID、タイトル、ステータス、プロジェクト、イシューの worktree または Git ref、ready プランのリビジョン、更新日時、イシューが対象となる理由を含めます。

ディスパッチする前に確認を求めます。キューの検出後、ディスパッチ前に、並列実行数の全体上限を 1 つ確認します。並列実行数は最大 6 に制限します。無制限または既定の実装並列数を選択しないでください。

別のイシューにフォーカスを移すときは、docs/workflow.md の Ticket Reference Rule に従い、先に内容を簡潔にまとめます。イシュー ID、正確なイシュータイトル、内容を説明する 1 行を含めます。

ディスパッチのルール

各イシューをディスパッチする直前に、get_issue と list_comments でイシューの状態を再確認します。llm-ready がなくなっている場合、最新の有効な ready プランがなくなっている場合、または in-use claim ラベルが新たに付いている場合（別のエージェントに claim されている場合）は、そのイシューをスキップし、観測された Linear の状態変化を概要に記録します。

イシューごとに分離してください。各 linear-implement サブエージェントは、イシューの Git ref または PR を連携手段として使用し、分離されたイシューの worktree で作業する必要があります。コードを変更する別のイシューと、変更可能な worktree を共有してはいけません。

各 linear-implement サブエージェントのディスパッチ前に、直接実行時と同じ必須の実装権限コンテキストを渡すか、利用可能であることを確認します。内容は、そのイシューの worktree へのワークスペース書き込みアクセス、パッケージマネージャーと検証コマンドの実行権限、ダッシュボード／ステータスの変更に必要な Linear MCP の読み書きツール、ブランチまたは PR の作業が対象となる場合の Git／GitHub ツール、必須のプロジェクト MCP ツールです。通常の安全な作業に、プロンプトごとの確認を必要とする実装者をディスパッチしないでください。必要な権限コンテキストを提供できない場合は、そのイシューをスキップするか、権限不足としてブロックします。

この権限コンテキストは包括的な承認ではありません。破壊的または不可逆的な操作、認証情報が必要な操作、本番環境など外部に影響を及ぼす操作、大幅にスコープを変更する操作、必要な権限が不足している操作については、引き続きサブエージェントが確認を求めるか、作業をブロックします。

次の内容で、イシューごとにサブエージェントをディスパッチします。

$linear-ai:linear-implement <ISSUE-ID>

影響を受けたイシューについて、ツールまたはランタイムの失敗を 1 回再試行します。再試行も失敗した場合は、バッチ概要でそのイシューのみを failed とします。

キャンセルされた場合は、新たなディスパッチを停止し、すでに開始した安全な作業からの報告を待って、完了、ブロック、失敗、スキップ、キャンセル、未開始の各イシューを含むキャンセル概要を返します。

構造化されたサブエージェントの結果

すべてのサブエージェントに、構造化されたサブエージェントの結果を報告させます。

issue: HCL-123
status: completed # completed | blocked | failed | skipped | cancelled
questions:
  - question: Concrete question for the user.
    recommended_answer: Recommended answer with rationale.
    reason: Why this answer is needed.
    blocks:
      - I4
feedback:
  - summary: Short feedback from the subagent.
    severity: info # info | warning | blocker
    recommendation: Recommended follow-up.
    follow_up: Optional next step.
linear_mutations:
  - REQUIRED_LINEAR_MUTATIONS emitted by the single-issue skill, if any.
evidence:
  - PR, commit, dashboard, status comment, or verification evidence.
error: null

契約違反の影響を受けるのは、該当する課題のみです。

質問とフィードバックの集約

質問には、question、recommended_answer、reason、および省略可能なblocksを含めます。

フィードバックには、summary、severity、recommendation、および省略可能なfollow_upを含めます。

各ウェーブの後に、未解決の質問とフィードバックを課題ごとにまとめます。ブロック中または曖昧な作業を続行する前に、必要な情報をユーザーに確認します。回答済みの課題は、新しいlinear-implementサブエージェントの実行に引き継ぎます。古いサブエージェントの状態は再開しません。

未回答の課題は、次のサマリーでもブロック中またはスキップとして扱います。

サマリーの形式

次の項目を含む最終サマリーを返します。

• 発見された課題
• 割り当てられた課題
• 完了した課題
• ブロック中の課題／質問
• 失敗した課題
• スキップされた課題
• キャンセルまたは未開始の課題
• 適用されたユーザーの回答
• 正規化された証拠
• 観測されたLinearの状態のドリフト
• サブエージェントからのREQUIRED_LINEAR_MUTATIONS
• 次に推奨されるアクション

Linear MCPの契約

利用可能な場合は、次のLinear MCPツールを使用します。

• list_issues
• get_issue
• list_comments

バッチオーケストレーターは、linear-implementが担当する課題ごとのライフサイクル変更を実行しないでください。Linear MCPの書き込みツールが利用できない場合、またはサブエージェントが書き込み指示を出力した場合は、正確なREQUIRED_LINEAR_MUTATIONSをバッチサマリーに記載します。

停止条件

確認済みのすべてのウェーブが完了したとき、ユーザーからの入力が必要なとき、キャンセルが要求されたとき、または対象となる課題が残っていないときに停止します。