Runtime Context

Before triaging, load:

1. Preferences: cat ${CLAUDE_PLUGIN_DATA_DIR:-$HOME/.claude/plugins/data/ops-ops-marketplace}/preferences.json — read project registry for repo paths
2. Daemon health: cat ${CLAUDE_PLUGIN_DATA_DIR}/daemon-health.json — ensure services healthy
3. Secrets: Resolve via Doppler MCP (mcp__doppler__*) → env → Doppler CLI fallback → password manager: SENTRY_AUTH_TOKEN, LINEAR_API_KEY, GITHUB_TOKEN
4. Ops memories: Check ${CLAUDE_PLUGIN_DATA_DIR}/memories/topics_active.md for issue context

OPS ► CROSS-PLATFORM TRIAGE

CLI/API Reference

gh CLI (GitHub)

sentry-cli / Sentry API

Linear GraphQL (fallback when MCP unavailable)

Agent Teams support

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

• Fix agents can share findings (e.g., agent fixing Sentry error discovers the same root cause as a Linear issue)
• You can redirect agents if cross-referencing reveals duplicate issues
• Agents report progress and you can prioritize which fix to merge first

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

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

Use broadcast(content="Root cause found: missing index on users.email — check if your issue is related") to share discoveries.

If the flag is NOT set, fall back to standard parallel subagents.

Phase 1 — Gather issues in parallel

Run all of these simultaneously:

GitHub Issues

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

GitHub Issues (registry-driven)

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

If Sentry MCP is connected, fetch unresolved issues for all projects. Otherwise run: echo "Sentry MCP not available"

Linear

Use mcp__linear__list_teams to get team IDs, then mcp__linear__list_issues with filter: {state: {type: {in: ["unstarted", "started"]}}} for each team.

Phase 2 — Cross-reference against code

For each Sentry issue, check if it's already fixed:

1. Extract the error message, file path, and line number from the Sentry event.
2. grep for the relevant code in the affected repo.
3. Check git log: git log --oneline --all -- [file] 2>/dev/null | head -20
4. If the fix is merged and deployed (check ECS deploy timestamps), mark as resolved.

For each GitHub Issue:

• Check if any merged PR references the issue number (gh pr list --state merged --search "#[N]")
• If referenced and merged, mark as potentially resolved

Phase 3 — Confirm and resolve fixed issues

For issues confirmed fixed in code AND deployed, show the full list and use 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]

If user picks "Review each one", show each issue individually with [Resolve] / [Skip] via AskUserQuestion.

For confirmed issues:

• Sentry: use Sentry MCP to resolve the issue
• Linear: use mcp__linear__update_issue with state: "Done"
• GitHub: gh issue close [N] --comment "Auto-closed: fix confirmed deployed"

Log all resolutions.

Phase 4 — Present triage board

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 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?]

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

Use batched AskUserQuestion calls (max 4 options each):

AskUserQuestion call 1:

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

AskUserQuestion call 2 (only if "More..."):

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

Superpowers Integration

During this command's execution, invoke the following superpower skill at the specified checkpoint:

• Checkpoint: When diagnosing an active issue before proposing a fix (root-cause investigation during Phase 2 cross-reference or Phase 4 agent dispatch brief).
• Skill: superpowers:systematic-debugging
• Why: Enforces hypothesis-driven root-cause analysis so fix agents target the real defect, not the symptom.

Dispatch fix agent

When dispatching for an issue, spawn an Agent using agents/triage-agent.md with:

• Full issue context (error, stack trace, affected code)
• Instruction to create feature branch, fix, and open PR
• Report back on completion or if blocked

Filter to $ARGUMENTS project/source if specified.

Native tool usage

Tasks — triage progress

Use TaskCreate for each issue being investigated. Update with TaskUpdate as issues are resolved/dispatched/skipped. Gives the user a live triage checklist.

WebFetch — Sentry/GitHub enrichment

When Sentry MCP hits quota limits, fall back to WebFetch with https://sentry.io/api/0/projects/<org>/<project>/issues/?query=is:unresolved (using SENTRY_AUTH_TOKEN header). Same for GitHub issue details when gh is slow.

WebSearch — error context

Use WebSearch to find known solutions for recurring errors (e.g., "AWS RDS connection reset", "ECS task stopped reason"). Include findings in the triage board as context.

LSP — code navigation for fix agents

When dispatching fix agents, use LSP to find symbol definitions, references, and call hierarchies. This helps agents navigate unfamiliar codebases faster than grep.

Ledger Integration

CLAIM_KEY by issue type:

• Sentry: sentry:issue:<short_id>
• GitHub issue: gh:pr:<owner>/<repo>#<number> (reused for issues when no PR exists)
• Infra alert: ci:run:<repo>:<run_id>

Pre-flight skip-check

CLAIM_KEY="sentry:issue:<short_id>"   # adjust per issue type
ledger query --claim-key "$CLAIM_KEY" --since=-PT24H

Skip issues with in_progress or done. Present awaiting_sam issues at the top of the triage board as "needs your decision."

Claim + resolve

# Claim when opening a triage pass on an issue
ledger write \
  --claim-key "$CLAIM_KEY" \
  --kind "fix" \
  --status "in_progress" \
  --title "Triage: <issue title>" \
  --ttl-sec 7200

# Resolve after fix dispatched or issue escalated
ledger write \
  --claim-key "$CLAIM_KEY" \
  --kind "fix" \
  --status "done" \
  --title "Triage: <issue title>" \
  --context "fix dispatched|escalated|snoozed: <reason>"