Ops Fires

OPS ► FIRES

Load ops-rules before acting. Public repo (no personal data). Outbound: one draft → one approval → one send. If AskUserQuestion / Workflow are missing, follow Rule 10 in ops-rules (Hermes: numbered options / two-turn Telegram card; delegate_task).

Runtime Context

Before executing, load available context:

1. Daemon health: Read ${CLAUDE_PLUGIN_DATA_DIR:-$HOME/.claude/plugins/data/ops-ops-marketplace}/daemon-health.json

   • Check infra-monitor service status — if not running, pre-gathered infra data may be stale
   • If action_needed is not null → surface it immediately as a potential fire

2. Secrets: AWS credentials are required for ECS/CloudWatch queries.

   Secret Resolution

   • First: check $AWS_ACCESS_KEY_ID / $AWS_PROFILE env vars
   • Then: doppler secrets get AWS_ACCESS_KEY_ID --plain (if doppler configured in prefs)
   • Then: use password_manager_config.query_cmd from preferences
   • Sentry token: $SENTRY_AUTH_TOKEN → $SENTRY_TOKEN → Doppler claude-ops/prd/SENTRY_AUTH_TOKEN. Resolved by bin/ops-sentry; no action needed here.
   • Sentry org and region: preferences.json .partner_registry.sentry.{org,region_url}. Sentry is region-sharded — issues are served by the org's own region host (e.g. https://us.sentry.io), not sentry.io, and querying the wrong region returns an empty list rather than an error. Omit org and the script discovers the first org the token can see.

3. Preferences: Read ${CLAUDE_PLUGIN_DATA_DIR}/preferences.json for secrets_manager config to know which vault to query.

CLI/API Reference

aws CLI

gh CLI (GitHub)

sentry-cli / Sentry API

Agent Teams support

If CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 is set, use Agent Teams when dispatching multiple fix agents simultaneously. This enables:

• Fix agents share findings (e.g., API agent discovers DB is the root cause → infra agent pivots to DB fix)
• You can prioritize: "CRITICAL ECS issue first, then CI failures"
• Real-time progress: agents report as they find root causes, you can merge fixes in optimal order

Team setup (only when flag is enabled, dispatch phase):

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

If the flag is NOT set, use standard parallel subagents.

Pre-gathered infrastructure data

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

FinOps dashboard — open anomalies

Live anomaly feed from finops-dashboard (spend spikes, idle services, expired credits, drift detections). High-severity items belong in the FIRES table alongside infra outages. Falls open to [] if the dashboard isn't configured.

${CLAUDE_PLUGIN_ROOT}/scripts/finops-bridge.sh anomalies high 2>/dev/null || echo "[]"

CI failures (last 24h)

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

Sentry — unresolved issues (last 24h)

Pre-gathered so Sentry is never skipped. Sorted by event frequency. An error field that is not null means the probe itself failed (missing or expired token, unreachable API) — report that as a gap, and do NOT read an empty issues list as "no errors in production".

${CLAUDE_PLUGIN_ROOT}/bin/ops-sentry 2>/dev/null || echo '{"org":null,"issues":[],"error":"sentry probe failed"}'

External projects health

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

Home automation (only if home_automation is configured in $PREFS_PATH)

if jq -e '.home_automation' "${CLAUDE_PLUGIN_DATA_DIR:-$HOME/.claude/plugins/data/ops-ops-marketplace}/preferences.json" >/dev/null 2>&1; then
  ${CLAUDE_PLUGIN_ROOT}/bin/ops-home snapshot 2>/dev/null || echo '{"configured":true,"error":"home probe failed"}'
else
  echo '{"configured":false}'
fi

Your task

Analyze the pre-gathered data — including external projects. Then run parallel checks:

1. ECS health — parse infra data for unhealthy services, stopped tasks, failed deployments.
2. Sentry — parse the pre-gathered Sentry data above; it is always present, so never report Sentry as unchecked. Classify by blast radius: an issue affecting many users or growing fast is HIGH, a warning-level issue with a handful of events is LOW. Only reach for mcp__plugin_sentry_sentry__get_sentry_resource (stack trace, breadcrumbs) or analyze_issue_with_seer when you are about to dispatch a fix agent for that issue. If the probe returned a non-null error, say Sentry could not be read and why — an empty list is not proof production is clean.
3. CI — parse CI data for failing pipelines, broken main/dev branches.
4. GitHub Actions — gh run list --limit 20 --json status,conclusion,name,headBranch,createdAt 2>/dev/null
5. External projects — parse ops-external data. Flag auth_expired as HIGH (credential rotation needed), unreachable/degraded as MEDIUM, not_configured as LOW.
6. Home automation (only if home snapshot returned configured:true) — classify Homey incidents:
   • Active critical alarm (smoke / water leak / security breach) → P0 / CRITICAL — cross-reference /ops:ops-home alarm for details.
   • Major device offline (gateway, hub, primary thermostat) → P1 / HIGH.
   • Energy spike > 3× 7-day baseline → P2 / MEDIUM — cross-reference /ops:ops-home status. If snapshot returned configured:false, skip silently.

Classify each issue by severity: