triage

# 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 に対して利用可能なツールの中から最適なものを選択し、データを取得する。

### 動作

1. URL を分析し、利用可能なツール（Bash 経由の CLI、WebFetch 等）の中から最適なデータ取得手段を判断する
2. 選択したツールでデータを取得する
3. 取得できない場合は WebFetch にフォールバックする
4. 取得した生データを保持し、Phase 2 に進む

### ツール選択の判断基準

- URL の内容を取得するのに **専用ツール**（CLI 等）が存在するなら、それを優先する
- 専用ツールがない、またはツールが失敗した場合は WebFetch でページ内容を取得する
- 特定サービスへのハードコーディングは行わない。ツールの追加で対応ソースは自然に拡張される

### エラー時

データを一切取得できなかった場合:
- 「URL からデータを取得できませんでした。URL が正しいか確認してください。」と報告して終了

## Phase 2: Context Exploration

**アナウンス:** 「Phase 2: Context Exploration — 周辺コンテキストを探索します」

Phase 1 で取得したデータを分析し、並列エージェントで探索を実行する。3 サブステップで構成される。

### Phase 2a: Exploration Planning

Phase 1 のデータから以下を抽出する:
1. 報告者（誰が報告しているか）
2. 対象（何についての報告か — 顧客名、機能名、エラー内容等）
3. 緊急度の手がかり（「至急」「本番障害」等のキーワード）

データ内容に応じて追加探索オプションを提案する。探索の種類と深さは 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 作成

1. Issue を作成する
   - title: Phase 3 のタイトル
   - project: 分析結果から判断
   - labels: 分析結果の分類 + ドメインラベル
   - priority: 分析結果の優先度（Urgent=1, High=2, Medium=3, Low=4）
   - description: 分析結果の要約 + 関連リソースのリンク
2. 分析が深い場合（原因仮説・影響範囲・関連コミット等がある場合）:
   - 詳細分析ドキュメントを作成し、Issue に紐付ける
3. 元 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 に含める
- 分析の根拠を明示する（「〜から判断」等）