ops-triage

実行コンテキスト

トリアージの前に、以下を読み込みます。

1. 設定：cat ${CLAUDE_PLUGIN_DATA_DIR:-$HOME/.claude/plugins/data/ops-ops-marketplace}/preferences.json — リポジトリのパスを確認するため、プロジェクトレジストリを読み込みます
2. デーモンの健全性：cat ${CLAUDE_PLUGIN_DATA_DIR}/daemon-health.json — サービスが正常であることを確認します
3. シークレット：Doppler MCP（mcp__doppler__*）→ 環境変数 → Doppler CLI のフォールバック → パスワードマネージャーの順で解決します：SENTRY_AUTH_TOKEN、LINEAR_API_KEY、GITHUB_TOKEN
4. Ops の記憶：課題のコンテキストを確認するため、${CLAUDE_PLUGIN_DATA_DIR}/memories/topics_active.md を確認します

OPS ► クロスプラットフォームのトリアージ

CLI/API リファレンス

gh CLI（GitHub）

コマンド	用途	出力
gh issue list --state open --json number,title,body,labels,assignees,createdAt,url --limit 50	オープン中の課題	JSON 配列
gh issue list --repo <owner/repo> --state open --json number,title,labels,createdAt --limit 20	リポジトリの課題	JSON 配列
gh pr list --state merged --search "#<N>"	課題を参照する PR	JSON 配列
gh issue close <N> --comment "<msg>"	課題をクローズ	確認

sentry-cli / Sentry API

コマンド	用途	出力
sentry-cli issues list --project <slug> --status unresolved	未解決の課題	課題リスト
curl -H "Authorization: Bearer $SENTRY_AUTH_TOKEN" "https://sentry.io/api/0/projects/<org>/<proj>/issues/?query=is:unresolved"	MCP が利用できない場合の API フォールバック	JSON 配列

Linear GraphQL（MCP が利用できない場合のフォールバック）

コマンド	用途	出力
curl -X POST https://api.linear.app/graphql -H "Authorization: $LINEAR_API_KEY" -H "Content-Type: application/json" -d '{"query":"{ issues(filter: {state: {type: {in: [\"started\",\"unstarted\"]}}}) { nodes { id title state { name } priority assignee { name } } } }"}'	アクティブな課題	JSON

---

Agent Teams のサポート

CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 が設定されている場合、複数の課題に対する修正エージェントをディスパッチするときは Agent Teams を使用します。これにより、以下が可能になります。

• 修正エージェント間で調査結果を共有できます（例：Sentry のエラーを修正中のエージェントが、Linear の課題と同じ根本原因を発見する）
• 相互参照によって課題の重複が判明した場合、エージェントに別の課題を割り当てられます
• エージェントが進捗を報告するため、どの修正を先にマージするか優先順位を付けられます

チームのセットアップ（フラグが有効な場合のみ、フェーズ 4 のディスパッチ時）：

TeamCreate("triage-fixers")
Agent(team_name="triage-fixers", name="fix-[issue-id]", subagent_type="ops:triage-agent", ...)

broadcast(content="Root cause found: missing index on users.email — check if your issue is related") を使用して、発見した内容を共有します。

フラグが設定されていない場合は、標準の並列サブエージェントにフォールバックします。

フェーズ 1 — 課題を並行して収集する

以下をすべて同時に実行します。

GitHub の課題

gh issue list --state open --json number,title,body,labels,assignees,createdAt,url --limit 50 2>/dev/null

GitHub の課題（レジストリ主導）

REGISTRY="${CLAUDE_PLUGIN_ROOT}/scripts/registry.json"
[ -f "$REGISTRY" ] || REGISTRY="${CLAUDE_PLUGIN_ROOT}/scripts/registry.example.json"
for repo in $(jq -r '.projects[] | select(.gsd == true) | .repos[]' "$REGISTRY" 2>/dev/null); do
  echo "=== $repo ==="
  gh issue list --repo "$repo" --state open --json number,title,labels,createdAt --limit 20 2>/dev/null
done

Sentry

Sentry MCP が接続されている場合は、すべてのプロジェクトについて未解決の課題を取得します。 それ以外の場合は、echo "Sentry MCP not available" を実行します。

Linear

mcp__linear__list_teams を使用してチーム ID を取得し、各チームに対して filter: {state: {type: {in: ["unstarted", "started"]}}} を指定して mcp__linear__list_issues を実行します。

---

フェーズ 2 — コードと相互参照する

Sentry の各課題について、すでに修正済みかどうかを確認します。

1. Sentry イベントからエラーメッセージ、ファイルパス、行番号を抽出します。
2. 影響を受けるリポジトリ内で、関連するコードを grep で検索します。
3. Git ログを確認します：git log --oneline --all -- [file] 2>/dev/null | head -20
4. 修正がマージされ、デプロイ済みの場合（ECS のデプロイ時刻を確認）、解決済みとしてマークします。

GitHub の各課題について：

• マージ済みの PR が課題番号を参照しているか確認します（gh pr list --state merged --search "#[N]"）
• 参照されていてマージ済みの場合は、解決済みの可能性ありとしてマークします

---

フェーズ 3 — 修正済みの問題を確認して解決する

コードで修正され、デプロイ済みであることが確認された問題については、全件を表示し、AskUserQuestion を使用します。

Found N issues confirmed fixed and deployed:

  [Sentry] [title] — fix in [commit], deployed [time ago]
  [Linear] [title] — fix in [commit], deployed [time ago]
  [GitHub] #[N] [title] — referenced in merged PR #[M]

  [Resolve all N]  [Review each one]  [Skip — don't auto-resolve]

ユーザーが「1件ずつ確認」を選択した場合は、各問題を個別に表示し、AskUserQuestion を通じて [Resolve] ／ [Skip] を提示します。

確認済みの問題については、次のとおり対応します。

• Sentry：Sentry MCP を使用して問題を解決します
• Linear：mcp__linear__update_issue を state: "Done" で使用します
• GitHub：gh issue close [N] --comment "Auto-closed: fix confirmed deployed" を実行します

解決した内容をすべて記録します。

---

フェーズ 4 — トリアージボードを提示する

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 OPS ► TRIAGE — [date]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

AUTO-RESOLVED (already fixed)
 ✓ [Sentry] [title] — fix in [commit]
 ✓ [Linear] [title] — closed
 ✓ [GitHub] #[N] [title] — closed

ACTIVE ISSUES (needs work)
 CRITICAL  [source] [title] [age] [assigned?]
 HIGH      [source] [title] [age] [assigned?]
 MEDIUM    [source] [title] [age] [assigned?]

──────────────────────────────────────────────────────

AskUserQuestion はバッチで呼び出します（各呼び出しにつき選択肢は最大 4 件）。

AskUserQuestion の呼び出し 1：

  [Dispatch agent for [top critical issue]]
  [Dispatch agent for [second issue]]
  [Assign issue to sprint (Linear)]
  [More...]

AskUserQuestion の呼び出し 2（「More...」が選択された場合のみ）：

  [Bulk-assign all HIGH to current sprint]
  [Done]

---

修正エージェントのディスパッチ

問題に対してエージェントをディスパッチする際は、agents/triage-agent.md を使用して Agent を起動し、次の内容を渡します。

• 問題の全コンテキスト（エラー、スタックトレース、影響を受けるコード）
• フィーチャーブランチの作成、修正、PR のオープンを指示します
• 完了時、または作業がブロックされた場合に報告するよう指示します

$ARGUMENTS でプロジェクト／ソースが指定されている場合は、それに絞り込みます。

---

ネイティブツールの使用

タスク — トリアージの進捗

調査中の問題ごとに TaskCreate を使用します。問題の解決、ディスパッチ、スキップに応じて TaskUpdate で更新します。これにより、ユーザーはトリアージのチェックリストをリアルタイムで確認できます。

WebFetch — Sentry／GitHub の情報補完

Sentry MCP がクォータ制限に達した場合は、https://sentry.io/api/0/projects/<org>/<project>/issues/?query=is:unresolved に対する WebFetch に切り替えます（SENTRY_AUTH_TOKEN ヘッダーを使用）。gh の応答が遅い場合も、GitHub の問題の詳細について同様に対応します。

WebSearch — エラーのコンテキスト

繰り返し発生するエラーの既知の解決策を見つけるには、WebSearch を使用します（例：「AWS RDS connection reset」、「ECS task stopped reason」）。見つかった情報は、コンテキストとしてトリアージボードに含めます。

LSP — 修正エージェントによるコードナビゲーション

修正エージェントをディスパッチする際は、LSP を使用してシンボル定義、参照、呼び出し階層を検索します。これにより、エージェントは grep よりも速く、慣れていないコードベースを把握できます。