ops-fires

OPS ► FIRES

ランタイムコンテキスト

実行する前に、利用可能なコンテキストを読み込みます。

1. デーモンのヘルス：${CLAUDE_PLUGIN_DATA_DIR:-$HOME/.claude/plugins/data/ops-ops-marketplace}/daemon-health.json を読み込みます。

   • infra-monitor サービスの状態を確認します。稼働していない場合、事前収集されたインフラデータが古くなっている可能性があります。
   • action_needed が null でない場合は、潜在的な障害として直ちに提示します。

2. シークレット：ECS／CloudWatch のクエリには AWS 認証情報が必要です。

   シークレットの解決

   • 最初に、$AWS_ACCESS_KEY_ID／$AWS_PROFILE 環境変数を確認します。
   • 次に、設定で doppler が構成されている場合は、doppler secrets get AWS_ACCESS_KEY_ID --plain を実行します。
   • その次に、設定の password_manager_config.query_cmd を使用します。
   • Sentry トークン：$SENTRY_AUTH_TOKEN → Doppler の SENTRY_AUTH_TOKEN → Vault

3. 設定：${CLAUDE_PLUGIN_DATA_DIR}/preferences.json を読み込み、クエリする Vault を確認するために secrets_manager の設定を調べます。

CLI／API リファレンス

aws CLI

コマンド	用途	出力
aws ecs list-services --cluster <name> --query 'serviceArns'	ECS サービス	ARN のリスト
aws ecs describe-services --cluster <name> --services <arn> --query 'services[0].{status:status,running:runningCount,desired:desiredCount}'	サービスのヘルス	JSON
aws logs tail /ecs/<service> --since 1h --format short	ECS ログ	ログ行（ライブ監視には Monitor と併用）

gh CLI（GitHub）

コマンド	用途	出力
gh run list --limit 20 --json status,conclusion,name,headBranch,createdAt	最近の CI 実行	JSON 配列
gh run view <id> --repo <repo> --log-failed	失敗した CI のログ	ログ出力

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 配列

---

Agent Teams のサポート

CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 が設定されている場合、複数の修正エージェントを同時に割り当てる際は Agent Teams を使用します。これにより、次のことが可能になります。

• 修正エージェント間で調査結果を共有できます（例：API エージェントが DB を根本原因として特定した場合、インフラエージェントが DB の修正に切り替えます）。
• 「CRITICAL の ECS 問題を最優先し、その後 CI の失敗に対応する」のように優先順位を付けられます。
• 進捗をリアルタイムで確認できます。エージェントは根本原因を見つけ次第報告するため、最適な順序で修正を統合できます。

チームのセットアップ（フラグが有効な場合のみ。割り当てフェーズで実行）：

TeamCreate("fire-fixers")
Agent(team_name="fire-fixers", name="fix-[service]", ...)

フラグが設定されていない場合は、標準の並列サブエージェントを使用します。

事前収集されたインフラデータ

${CLAUDE_PLUGIN_ROOT}/bin/ops-infra 2>/dev/null || echo '{"clusters":[],"error":"infra check failed"}'

CI の失敗（過去 24 時間）

${CLAUDE_PLUGIN_ROOT}/bin/ops-ci 2>/dev/null || echo '[]'

外部プロジェクトのヘルス

${CLAUDE_PLUGIN_ROOT}/bin/ops-external 2>/dev/null || echo '[]'

タスク

外部プロジェクトも含め、事前収集されたデータを分析します。その後、並列で確認します。

1. ECS のヘルス — インフラデータを解析し、ヘルスに問題のあるサービス、停止したタスク、失敗したデプロイを特定します。
2. Sentry — Sentry MCP が接続されている場合は、最近の未解決エラーをクエリします。それ以外の場合は、利用できないことを記載します。
3. CI — CI データを解析し、失敗しているパイプラインや、壊れている main／dev ブランチを特定します。
4. GitHub Actions — gh run list --limit 20 --json status,conclusion,name,headBranch,createdAt 2>/dev/null
5. 外部プロジェクト — ops-external データを解析します。auth_expired は HIGH（認証情報のローテーションが必要）、unreachable／degraded は MEDIUM、not_configured は LOW として報告します。

各問題を重大度で分類します。

重大度	基準
CRITICAL	サービス停止、DB に到達できない、認証が機能しない
HIGH	エラー率の上昇、デプロイの停滞、CI の main が失敗
MEDIUM	重大ではないサービスの劣化、不安定なテスト
LOW	警告レベル、緊急性なし

---

出力形式

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 OPS ► FIRES DASHBOARD — [timestamp]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

CRITICAL
[service] — [issue] — [since]

HIGH
[service] — [issue] — [since]

MEDIUM
[service] — [issue] — [since]

ECS HEALTH
[cluster] [service] [desired/running] [status]

CI STATUS
[repo] [branch] [workflow] [status] [last run]

SENTRY (top errors, 24h)
[error] [count] [first seen] [project]

EXTERNAL PROJECTS
[alias] [source] [status] [details — e.g. auth_expired, unreachable]

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

バッチ化した AskUserQuestion 呼び出し（各呼び出し最大 4 つの選択肢）を使用します。関連するアクションのみを表示してください（例：問題が見つからなかった場合は、修正の振り分けオプションを省略します）。

AskUserQuestion 呼び出し 1：

  [Dispatch fix agent for [top critical issue]]
  [Dispatch fix agent for [second issue]]
  [View logs for [service]]
  [More...]

AskUserQuestion 呼び出し 2（「More...」の場合のみ）：

  [Open Sentry dashboard]
  [Open GitHub Actions]
  [All clear — nothing to do]

問題がない場合は、最終確認時刻とともに「ALL SYSTEMS OPERATIONAL」と表示します。

---

修正エージェントへの振り分け

ユーザーが問題の修正を選択した場合は、振り分けを行う前に AskUserQuestion を使用して対象範囲を確認します。

Dispatch fix agent for: [issue title]
  Severity: [CRITICAL/HIGH/MEDIUM]
  Repo: [repo]
  Error: [brief description]
  
  The agent will:
  - Investigate root cause in [repo]
  - Create feature branch with fix
  - Open PR for review

  [Dispatch agent]  [Show me the logs first]  [Skip — I'll fix manually]

確認後、以下を指定して Agent を起動します。

• エラーの詳細とログ
• 関連するリポジトリへのアクセス
• フィーチャーブランチを作成して修正し、PR を開くよう指示
• 完了または対応不能になった時点で報告するよう指示

インフラの問題には agents/infra-monitor.md のエージェント定義を使用します。

$ARGUMENTS にプロジェクトのエイリアスが含まれる場合は、そのプロジェクトのサービスのみを対象にします。

---

ネイティブツールの使用

Monitor — サービスの稼働状況をリアルタイムで確認

問題の調査時には、Monitor を使用して ECS タスクのログまたは GitHub Actions の実行状況をストリーミングします。

Monitor(command: "aws logs tail /ecs/<service> --follow --since 5m")

Tasks — インシデントの追跡

アクティブな問題ごとに TaskCreate を使用します。問題の調査、修正、エスカレーションに応じて TaskUpdate で更新します。

WebFetch — ステータスページ

問題の診断時には、WebFetch を使用して AWS ステータスページ（https://health.aws.amazon.com/health/status）、Vercel のステータスページ、またはサードパーティ API のステータスページを確認します。

WebSearch — 既知の障害パターン

WebSearch を使用して、エラーパターンが既知の AWS／インフラの問題に該当するかを調べます（例：「ECS task stopped CannotPullContainerError」→ 既知の ECR スロットリング）。