mcpField
L
linear-batch-refine

linear-batch-refine

github.com/lkshrkエージェントワークフロー141 回インストール4 週間前に更新
リポジトリ

linear-batch-refine について

Linear AI の課題をまとめて処理するためのオーケストレーションスキルです。対象の検出と順序付けを行い、単一課題向けスキルを一件ずつ起動し、確認事項を中継して結果を集約します。

主な機能

  1. 01ワークフラーラベルによる課題検出
  2. 02優先度と更新日時による順序付け
  3. 03単一課題スキルの逐次起動
  4. 04質問と担当者回答の中継
  5. 05完了・保留・失敗状況の集約

活用シーン

  1. 01精査やブロッカー対応が必要な Linear 課題の抽出
  2. 02複数課題の処理順の決定
  3. 03起動前のキュー確認
  4. 04バッチ結果と未解決事項の集約

MCP 対応

Linear MCP の `list_issues`、`get_issue`、`list_comments` を使って課題を検出・確認します。課題ごとの精査とライフサイクル変更は `linear-refine` スキルに委ねます。

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/lkshrk/linear-ai --skill linear-batch-refine

インストール後、Claude Code で/linear-batch-refineを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

agents/
openai.yaml
docs/
agent-required-passes.md
superpowers-linear-persistence.md
workflow.md
schemas/
linear-ai.claim.v1.schema.yaml
linear-ai.dashboard.v1.schema.yaml
linear-ai.plan.v1.schema.yaml
linear-ai.review-ledger.v1.schema.yaml
linear-ai.status.v1.schema.yaml
scripts/
validate_marked_comments.ts

詳細

Linear Batch Refine

オペレーターが、リファインまたはブロッカーへの対応が必要な複数の Linear AI イシューを処理したい場合に、このスキルを使用します。

これはオーケストレーターです。linear-refine ワークフローを重複して実行しないでください。単一イシュー用のスキルが、イシューごとの永続的な Linear コメント、ワークフローラベル、プランの検証、イシュー固有の解釈を担当します。

ソース契約

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

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

キューの検出

Linear MCP を使用します。

  • list_issues で、llm-refine と llm-blocked が付いたイシューを検索します。
  • 任意のフィルター:チーム、プロジェクト、担当者、ラベル、ユーザーから明示されたイシュー ID。
  • イシュー ID が明示されておらず、対象のチームとプロジェクトがセッション内ですでに明確でない場合は、検出を始める前に、どのチームとプロジェクトのイシューを処理するか尋ねてください。
  • llm-* ワークフローラベルが付いたイシューのみをキューに追加します。ユーザーが明示的に指定しない限り、llm-* ラベルのないイシューは無視してください。
  • ディスパッチ前に、get_issue と list_comments を使って候補イシューごとの概要をまとめます。

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

明示的なドライランまたは一覧のみのモードに対応してください。ドライラン/一覧のみのモードでは、キューを表示して、サブエージェントをディスパッチしたり Linear を変更したりせずに終了します。

キューは、まず Linear の優先度順、次に更新日時が古い順に並べ替えます。優先度の順序は「緊急」、「高」、「中」、「低」、「優先度なし/未設定」です。同じ優先度の中では、updatedAt の昇順に並べ替えます。対象を絞ったキューの概要には、イシュー ID、タイトル、状態ラベル、ステータス、プロジェクト、更新日時、イシューが対象となる理由を表示します。

ディスパッチ前に確認を求めてください。リファインは一度に 1 件ずつ処理します。リファインでは、単一イシュー用の linear-refine のインタビュー契約を維持してください。イシューのリファイン中は、サブエージェントから質問ラウンドが届き次第、オーケストレーターがそれをオペレーターに中継します(各ラウンドは 4 件以内にまとめ、各質問にサブエージェントの推奨回答と根拠を添えます)。オペレーターの回答は実行中のサブエージェントに返し、重要な分岐がすべて解決されるか、明示的に受け入れられるまで反復させます。その後にのみ、プランを準備完了としてマークできます。現在のイシューが準備完了、ブロック中、またはオペレーターが未解決の質問を明示的に保留した場合にのみ、キュー内の次のイシューに進んでください。パス終了時の集約対象は、オペレーターが保留した質問のみです。

別のイシューにフォーカスを切り替える際は、docs/workflow.md のチケット参照ルールに従い、まず内容を簡潔に要約してください。イシュー ID と、内容を一文で説明したものを示します。

ディスパッチのルール

各イシューをディスパッチする直前に、get_issue と list_comments でイシューの状態を再確認します。現在のラベルに llm-refine または llm-blocked が含まれなくなった場合、またはイシューに in-use クレームラベルが付いた場合(別のエージェントがクレーム済み)は、そのイシューをスキップし、観測した Linear の状態変化を概要に記録します。

イシューごとのサブエージェントに、以下を渡してディスパッチします。

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

ディスパッチ用プロンプトで、サブエージェントに質問票をスキップしたり、設計上の分岐を自律的に解決したりするよう指示してはいけません。代わりに、中継経路を定義してください。サブエージェントは実行中に質問ラウンドをオーケストレーターに送り、プランを確定する前に、中継されたオペレーターの回答を待ちます。待機中、サブエージェントは in-use クレームを保持します。

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

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

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

詳細化の作業中、サブエージェントは最終結果を返す前に、中間の質問ラウンドをオーケストレーターに送信します。

type: question_round
issue: TEAM-123
round: 1
questions:
  - question: Concrete question for the operator.
    recommended_answer: Evidence-based recommendation.
    reason: Why this branch is material.
    blocks: [I2]

オーケストレーターは各ラウンドをオペレーターに中継し、回答を実行中のサブエージェントに返します。すべてのラウンドに回答するか、オペレーターが明示的に保留するまで、最終的な構造化結果は送信されません。

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

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:
      - I2
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:
  - Validation, comment, or Linear state evidence.
error: null

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

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

集約は、オペレーターが保留した質問に対するフォールバックであり、主要なフローではありません。主要なフローは上記のライブ中継です。つまり、サブエージェントの実行中に質問ラウンドをオペレーターに届けます。

質問には、question、recommended_answer、reason、および任意のblocksが含まれます。

フィードバックには、summary、severity、recommendation、および任意のfollow_upが含まれます。

キューを一巡した後、オペレーターが保留した質問とフィードバックを問題ごとにグループ化します。ブロックされている作業や曖昧な作業を続行する前に、必要な入力をユーザーに求めます。回答済みの問題は、新しいlinear-refineサブエージェントの実行に引き渡します。古いサブエージェントの状態は再開しないでください。

未回答の問題は、次の要約でもブロックまたはスキップされたままになります。

要約の形式

最終要約には、以下を含めます。

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

Linear MCPの契約

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

  • list_issues
  • get_issue
  • list_comments

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

停止条件

キューを一巡したとき、ユーザーの入力が必要なとき、キャンセルが要求されたとき、または対象となる問題が残っていないときに停止します。

コメント