散らかったLinearバックログを10分でトリアージする方法
使うタイミング: 月曜の朝。バックログに未トリアージのイシューが200件以上あり、1時間後にプランニングが控えている場面。
前提条件
- Linearワークスペースへのアクセス —
mcp-remote経由のOAuth — 最初のツール呼び出し時にブラウザが開き権限を付与 - チームスラッグ(例:
ENG) — 任意のイシューIDを確認 — プレフィックスがチームスラッグです
フロー
-
チームの未トリアージイシューをすべて取得List all ENG issues in state 'Triage' or with no priority set, created in the last 30 days. Return id, title, reporter, and description length.✓ コピーしました→ 分類に十分なコンテキストを持つ候補の一覧表
-
テーマごとにクラスタリングGroup these into 4-6 themes (bug / infra / onboarding / perf / etc.). For each cluster, propose a priority and suggested project.✓ コピーしました→ 根拠付きのテーマ別クラスター
-
決定を適用For each cluster, update the issues: set priority, add the matching label, and move to 'Backlog' state. Do NOT assign anyone.✓ コピーしました→ N件のイシューが更新され、確認ログが記録される
結果: プランニングに使えるバックログが、グループ化・優先度付けされ、エージェントが行ったすべての変更の監査証跡付きで完成します。
注意点
- エージェントが「類似コードを書いた人」を根拠に誤った担当者へ一括アサインしてしまう — アサインしないよう明示的に指示してください — アサインは人間が判断すべきです
- Linear無料プランでは約1500リクエスト/時でレート制限がかかる —
issueBatchUpdateが利用可能であればバッチ更新を使用し、そうでなければトリアージを500件以下に抑えてください