| name | triage |
| description | URL(Slack/GitHub/その他)から情報収集→周辺コンテキスト探索→分析→Linear Issue 登録を行う初動対応ワークフロー。 問い合わせやバグ報告のトリアージに使用する。 |
| user-invocable | true |
Triage — 初動対応ワークフロー
URL を受け取り、4フェーズのパイプラインで初動対応を完了する。
開始時アナウンス: 「Triage を開始します。Phase 1: Data Collection」
起動
/triage <URL> [補足テキスト]
- URL: 必須
- 補足テキスト: 任意。Phase 2 の探索判断に加味される
ARGUMENTS を <URL> と [補足テキスト] にパースする。URL が含まれない場合は AskUserQuestion で URL を要求する。
Phase 1: Data Collection
アナウンス: 「Phase 1: Data Collection — データソースから情報を取得します」
URL に対して利用可能なツールの中から最適なものを選択し、データを取得する。
動作
- URL を分析し、利用可能なツール(Bash 経由の CLI、WebFetch 等)の中から最適なデータ取得手段を判断する
- 選択したツールでデータを取得する
- 取得できない場合は WebFetch にフォールバックする
- 取得した生データを保持し、Phase 2 に進む
ツール選択の判断基準
- URL の内容を取得するのに 専用ツール(CLI 等)が存在するなら、それを優先する
- 専用ツールがない、またはツールが失敗した場合は WebFetch でページ内容を取得する
- 特定サービスへのハードコーディングは行わない。ツールの追加で対応ソースは自然に拡張される
エラー時
データを一切取得できなかった場合:
- 「URL からデータを取得できませんでした。URL が正しいか確認してください。」と報告して終了
Phase 2: Context Exploration
アナウンス: 「Phase 2: Context Exploration — 周辺コンテキストを探索します」
Phase 1 で取得したデータを分析し、並列エージェントで探索を実行する。3 サブステップで構成される。
Phase 2a: Exploration Planning
Phase 1 のデータから以下を抽出する:
- 報告者(誰が報告しているか)
- 対象(何についての報告か — 顧客名、機能名、エラー内容等)
- 緊急度の手がかり(「至急」「本番障害」等のキーワード)
データ内容に応じて追加探索オプションを提案する。探索の種類と深さは LLM がデータ内容に応じて判断する。固定リストではない。
典型的な探索候補:
- コミュニケーションツール内の関連メッセージ検索
- Issue/PR の類似報告・過去の対応履歴
- コードベースの関連箇所・最近の変更
- 実行環境・データストア・エラートラッキング等の外部システム確認
以下のフォーマットで提案し、AskUserQuestion で選択を取得する:
## データソース要約
- ソース: [ソース種別と概要]
- 報告者: [誰が]
- 内容: [何を報告しているか]
## 探索提案
以下の追加調査を提案します:
1. [推奨] ...
2. [推奨] ...
3. [任意] ...
実行する番号を選択してください(例: 1,2 / all / none)
受け付ける入力:
none → Phase 2b/2c をスキップし、Phase 1 のデータのみで Phase 3 に進む
all → 全探索を並列実行
- カンマ区切りの番号(例:
1,2) → 該当番号の探索を並列実行
ユーザーが番号選択と共に補足テキストを追加した場合、Phase 3 の分析に加味する。
Phase 2b: Parallel Execution
承認された探索を 1 候補 = 1 Agent として並列 dispatch する。
エージェント構成:
- 各エージェントには以下を渡す:
- Phase 1 の取得データ(コンテキスト共有)
- 探索の具体的な指示(例: 「Linear で [トピック] に関連するチケットを検索」)
- 利用するツールの指定(slackcli, Grep, linear CLI 等)
- エージェント数の上限なし(承認された探索数 = エージェント数)
エージェントの責務:
- 割り当てられた 1 つの探索を実行し、結果を返す。それ以外はやらない
- 探索失敗時は「取得できなかった」旨を返す(該当探索をスキップして続行)
オーケストレーターの責務:
- 全エージェントの完了を待つ
- 各エージェントの結果を自身で統合・要約する
- エージェントの生出力をそのまま Phase 3 に転送しない
Phase 2c: Findings Confirmation
全探索結果のサマリーを提示し、ユーザーに正確性を確認する。
以下のフォーマットで提示し、AskUserQuestion で承認を取得する:
## 探索結果サマリー
### 1. [探索名]
- 取得元: [URL or 検索クエリ]
- 要約: [2-3行の要約]
- 関連度: 高 / 中 / 低
### 2. [探索名]
- 取得元: ...
- 要約: ...
- 関連度: ...
---
この内容で分析に進みますか?(修正があれば指示してください)
受け付ける入力:
- 承認 → Phase 3 に進む
- 修正指示(例: 「1 のスレッドは違う、正しくは #channel の昨日のスレッド」)→ 該当探索のみ再実行し、再度確認ゲートを提示
none → 全探索結果を破棄し、Phase 1 のデータのみで Phase 3 に進む
再実行ルール:
- 修正対象の探索のみ再実行する(他の探索結果は保持)
- 再実行は並列ではなく単発(1 探索の修正のため)
- 再実行後、再度確認ゲートを全体提示する
Phase 3: Analysis
アナウンス: 「Phase 3: Analysis — 収集した情報を分析します」
Phase 1 + Phase 2 で収集した全情報を構造化する。
動作
収集した情報量に応じて、以下の項目を取捨選択して構造化する。全項目を常に出力するわけではない。
- タイトル: 1行要約(Linear Issue のタイトルになる)
- 分類: Bug / Feature / Improvement
- ドメインラベル: データ内容から判断(プロジェクトに存在するラベルから選択)
- 優先度提案: Urgent / High / Medium / Low + 根拠
- 要約: 何が起きているか(2-3文)
- 原因仮説: コードベース調査した場合のみ
- 影響範囲: 該当顧客・機能
- 関連リソース: 元 URL、関連 Issue/PR、コミット SHA 等
- 推奨アクション: 次のステップの提案
出力
構造化した分析結果を Phase 4 に渡す。この時点ではユーザーに提示しない(Phase 4 のプレビューで提示する)。
Phase 4: Linear Registration
アナウンス: 「Phase 4: Linear Registration — Linear Issue を作成します」
Phase 3 の分析結果をプレビューとしてユーザーに提示し、承認後に Linear Issue を作成する。
プレビュー
以下のフォーマットで提示し、AskUserQuestion で承認を取得する:
## Linear Issue プレビュー
- **Title**: [タイトル]
- **Project**: [プロジェクト名]
- **Labels**: [ラベル]
- **Priority**: [優先度] — [根拠]
- **Description**:
[要約 + 分析結果]
この内容で Linear Issue を作成しますか?(修正があれば指示してください)
受け付ける入力:
- 承認(
yes, ok, 作成して 等) → Issue を作成
- 修正指示(テキスト) → 指示に従い修正してから再プレビュー
cancel → 「Issue 作成をキャンセルしました。」と報告して終了
Issue 作成
- Issue を作成する
- title: Phase 3 のタイトル
- project: 分析結果から判断
- labels: 分析結果の分類 + ドメインラベル
- priority: 分析結果の優先度(Urgent=1, High=2, Medium=3, Low=4)
- description: 分析結果の要約 + 関連リソースのリンク
- 分析が深い場合(原因仮説・影響範囲・関連コミット等がある場合):
- 詳細分析ドキュメントを作成し、Issue に紐付ける
- 元 URL をアタッチメントとして添付する
完了報告
Triage 完了。
- Linear Issue: [Issue ID] [Issue URL]
- Title: [タイトル]
- Priority: [優先度]
エラーハンドリング
| Phase | エラー | 対応 |
|---|
| 1 | URL からデータ取得不可 | 報告して終了 |
| 2 | 探索ツールが失敗 | 該当探索をスキップし、取得済みデータで続行 |
| 4 | Linear API エラー | エラー内容を報告し、再試行するか確認 |
Red Flags
Never:
- ユーザー承認なしに Linear Issue を作成する
- Phase 2 の探索提案をスキップする(
none はユーザーの明示的選択)
- 取得できなかったデータを推測で補完する
- Phase 2b エージェントの生出力を統合・要約せずに Phase 3 に転送する
Always:
- Phase 遷移時にアナウンスする
- 元 URL を Issue の description または attachment に含める
- 分析の根拠を明示する(「〜から判断」等)