Ops Fires

What the source does

• FilesystemNone observedNo reads or writes in the source
• NetworkNone observedNo outbound calls in the source
• ShellNone observedNo commands run in the source
• DependenciesPinnedNothing floats
• SecretsNone foundNo keys in source

Five audit layers

Gates applied: no behavioural pass.

Audit 0.4.1 · source sha 5e484a8e67e5 · 29 Oct 2026Report an issue or request a re-scan

• PublisherLifecycle-Innovations-Limited GitHub organizationOwner of the repository this skill is read from
• Source folderLifecycle-Innovations-Limited/claude-ops/claude-ops/skills/ops-firesThe exact folder we audited
• LicenceMITAs the repository states it
• Commit pinned for this verdict5e484a8e67e5A new audit runs when the source changes
• Repository statusNot archivedPushed today
• Sandboxed runNot runSkills are read, not executed; layer L4 is skipped

Its description: OPS on-demand: This skill should be used when the user asks to "production fires", "what is on fire"...

---
name: ops-fires
description: "OPS on-demand: This skill should be used when the user asks to \"production fires\", \"what is on fire\"..."
argument-hint: '[project-alias|all]'
allowed-tools:
  - Bash
  - Read
  - Grep
  - Glob
  - Skill
  - Agent
  - AskUserQuestion
  - TeamCreate
  - SendMessage
  - TaskCreate
  - TaskUpdate
  - Monitor
  - WebFetch
  - WebSearch
  - mcp__plugin_sentry_sentry__search_issues
  - mcp__plugin_sentry_sentry__get_sentry_resource
  - mcp__plugin_sentry_sentry__find_organizations
effort: medium
maxTurns: 30
---

# 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

| Command                                                                                                                                       | Usage          | Output                                |
| --------------------------------------------------------------------------------------------------------------------------------------------- | -------------- | ------------------------------------- |
| `aws ecs list-services --cluster <name> --query 'serviceArns'`                                                                                | ECS services   | ARN list                              |
| `aws ecs describe-services --cluster <name> --services <arn> --query 'services[0].{status:status,running:runningCount,desired:desiredCount}'` | Service health | JSON                                  |
| `aws logs tail /ecs/<service> --since 1h --format short`                                                                                      | ECS logs       | Log lines (use with Monitor for live) |

### gh CLI (GitHub)

| Command                                                                     | Usage          | Output     |
| --------------------------------------------------------------------------- | -------------- | ---------- |
| `gh run list --limit 20 --json status,conclusion,name,headBranch,createdAt` | Recent CI runs | JSON array |
| `gh run view <id> --repo <repo> --log-failed`                               | Failed CI logs | Log output |

### sentry-cli / Sentry API

| Command                                                                                                                          | Usage                             | Output     |
| -------------------------------------------------------------------------------------------------------------------------------- | --------------------------------- | ---------- |
| `sentry-cli issues list --project <slug> --status unresolved`                                                                    | Unresolved issues                 | Issue list |
| `bin/ops-sentry [org]` | Pre-gather path (already inlined below) | JSON `{org,issues,error}` |
| `OPS_SENTRY_PERIOD=7d OPS_SENTRY_LIMIT=25 bin/ops-sentry` | Widen the window or cap | JSON |
| `curl -H "Authorization: Bearer $SENTRY_AUTH_TOKEN" "https://us.sentry.io/api/0/organizations/<org>/issues/?query=is:unresolved"` | Manual probe (note: region host, org-scoped) | JSON array |

---

## 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 even

Excerpt, first 6,000 characters of SKILL.md, verbatim from the audited commit. It is text from someone else’s repository, quoted so you can judge it before your agent reads it.

git clone https://github.com/Lifecycle-Innovations-Limited/claude-ops
git -C claude-ops checkout 5e484a8e67e5

Works in

1. 2026-10-29
   ✓SAFE B 89 / 100

   first audit · source 5e484a8e67e5

Questions about Ops Fires

• github.com/Lifecycle-Innovations-Limited/claude-ops/tree/main/cl — the audited source at commit 5e484a8e67e5 and every finding aboveObserved · 29 Oct 2026

Spotted something wrong? Report a correction · Methodology