メニュー
URL（Slack/GitHub/その他）から情報収集→周辺コンテキスト探索→分析→Linear Issue 登録を行う初動対応ワークフロー。 問い合わせやバグ報告のトリアージに使用する。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
AI が実装した変更の「受け入れ判定」を1画面で行うためのレビューパックを生成する。 diff 要約・テスト/リンタ実行証跡・リスクフラグ・Verification Contract 準拠状況を 1つのレポートに集約し、APPROVE / REWORK の判断材料を揃える。 実装完了後・コミット前・PR 作成前のレビュー依頼時、または /review-pack で起動。
現在のセッションで行った作業・決定事項・アーキテクチャ変更を project-state.json に記録し、 handover.md を生成する。コンテキスト圧縮の直前、/handover の明示呼び出し、 ツール呼び出し累計 50 回超過時、または応答が遅延した時に使用する。
Linear チケットの棚卸し・構造整理・未登録ソース発見を Collect/Discover/Analyze/Approve/Execute の 5 ステップで一気通貫実行する。 既存の外部リンク探索に加え、Slack/GitHub のキーワード検索と逆引きで未紐付きの 外部ソースも発見する。定期的な Linear メンテナンス、または「棚卸し」「リフレッシュ」 「整理」の依頼時に使用する。
Slack CLI: Send messages, read conversations, search, and manage Slack workspaces from the terminal. Use when the user asks anything related to Slack — sending messages, checking unreads, searching conversations, or managing workspaces. Also trigger when a Slack URL is provided (e.g., https://*.slack.com/archives/*, app.slack.com/*) or when the conversation context mentions Slack threads, channels, or messages.
前セッションの project-state.json から未完了タスク（in_progress/blocked）を特定し、 ユーザー承認後に作業を再開する。/continue の明示呼び出し、"continue from handover" のような継続指示、handover.md への言及を検出した時に使用する。worktree 切り替えと Pipeline Detection も含む。
md ドキュメントの陳腐化・欠落・矛盾を 4 Layer 構造で検出し、ユーザー承認後に修正する。 depends-on 検証、coverage チェック、business-rule/architecture の未文書化知識検出、 readme/CLAUDE.md のメタ整合検査を行う。/doc-audit で起動、または大規模なコード変更後に ドキュメント整合性を確認したい時に使用する。
| name | triage |
| description | URL（Slack/GitHub/その他）から情報収集→周辺コンテキスト探索→分析→Linear Issue 登録を行う初動対応ワークフロー。 問い合わせやバグ報告のトリアージに使用する。 |
| user-invocable | true |
URL を受け取り、4フェーズのパイプラインで初動対応を完了する。
開始時アナウンス: 「Triage を開始します。Phase 1: Data Collection」
/triage <URL> [補足テキスト]
ARGUMENTS を <URL> と [補足テキスト] にパースする。URL が含まれない場合は AskUserQuestion で URL を要求する。
アナウンス: 「Phase 1: Data Collection — データソースから情報を取得します」
URL に対して利用可能なツールの中から最適なものを選択し、データを取得する。
データを一切取得できなかった場合:
アナウンス: 「Phase 2: Context Exploration — 周辺コンテキストを探索します」
Phase 1 で取得したデータを分析し、並列エージェントで探索を実行する。3 サブステップで構成される。
Phase 1 のデータから以下を抽出する:
データ内容に応じて追加探索オプションを提案する。探索の種類と深さは LLM がデータ内容に応じて判断する。固定リストではない。
典型的な探索候補:
以下のフォーマットで提案し、AskUserQuestion で選択を取得する:
## データソース要約
- ソース: [ソース種別と概要]
- 報告者: [誰が]
- 内容: [何を報告しているか]
## 探索提案
以下の追加調査を提案します:
1. [推奨] ...
2. [推奨] ...
3. [任意] ...
実行する番号を選択してください（例: 1,2 / all / none）
受け付ける入力:
none → Phase 2b/2c をスキップし、Phase 1 のデータのみで Phase 3 に進むall → 全探索を並列実行1,2） → 該当番号の探索を並列実行ユーザーが番号選択と共に補足テキストを追加した場合、Phase 3 の分析に加味する。
承認された探索を 1 候補 = 1 Agent として並列 dispatch する。
エージェント構成:
エージェントの責務:
オーケストレーターの責務:
全探索結果のサマリーを提示し、ユーザーに正確性を確認する。
以下のフォーマットで提示し、AskUserQuestion で承認を取得する:
## 探索結果サマリー
### 1. [探索名]
- 取得元: [URL or 検索クエリ]
- 要約: [2-3行の要約]
- 関連度: 高 / 中 / 低
### 2. [探索名]
- 取得元: ...
- 要約: ...
- 関連度: ...
---
この内容で分析に進みますか？（修正があれば指示してください）
受け付ける入力:
none → 全探索結果を破棄し、Phase 1 のデータのみで Phase 3 に進む再実行ルール:
アナウンス: 「Phase 3: Analysis — 収集した情報を分析します」
Phase 1 + Phase 2 で収集した全情報を構造化する。
収集した情報量に応じて、以下の項目を取捨選択して構造化する。全項目を常に出力するわけではない。
構造化した分析結果を Phase 4 に渡す。この時点ではユーザーに提示しない（Phase 4 のプレビューで提示する）。
アナウンス: 「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 作成をキャンセルしました。」と報告して終了Triage 完了。
- Linear Issue: [Issue ID] [Issue URL]
- Title: [タイトル]
- Priority: [優先度]
| Phase | エラー | 対応 |
|---|---|---|
| 1 | URL からデータ取得不可 | 報告して終了 |
| 2 | 探索ツールが失敗 | 該当探索をスキップし、取得済みデータで続行 |
| 4 | Linear API エラー | エラー内容を報告し、再試行するか確認 |
Never:
none はユーザーの明示的選択）Always: