-
Notifications
You must be signed in to change notification settings - Fork 21
Use Cases
Real-world scenarios showing how different types of users get value from claude-ops. Each scenario shows the situation, the commands used, and the outcome.
Situation: You start the day with 6 tabs open — GitHub, Linear, Slack, WhatsApp, your AWS console, and Gmail. Context-switching costs you 20 minutes before you write a line of code.
Commands:
/ops:go
What happens: Claude runs 5 shell scripts in parallel (git status, open PRs, CI failures, ECS health, unread messages), combines the results, and presents a single dashboard in under 10 seconds. One message shows you: no fires, 3 WhatsApp messages, 1 PR ready to merge, sprint is on track, AWS spend is normal.
Then:
/ops:next
/ops:next applies the priority stack and tells you: merge the PR first (it's been sitting for 2 days), then reply to the WhatsApp thread, then get back to the sprint.
Outcome: 60 seconds instead of 20 minutes. Full situational awareness before opening a single tab.
Situation: You're a team lead with 4 engineers. End of sprint, there are 7 open PRs across 3 repos. Some have review comments, some have CI failures, two have merge conflicts. You don't have time to review each one manually.
Commands:
/ops:merge
What happens: The merge pipeline scans all repos for open PRs, classifies each one by status (ready/CI failing/needs review/conflicted), and spawns subagents in parallel. Each subagent reads the PR, checks CI logs, addresses review comments in code, resolves conflicts, then merges when green. You get a report when each one is done.
Flags:
/ops:merge --dry-run # preview what would be merged
/ops:merge --repo org/myapp # scope to one repo
/ops:merge --main # also sync dev→main after merging
Outcome: 7 PRs processed in the time it would take you to manually review 2. Fixable CI failures are resolved automatically; ones requiring judgment are flagged for your input.
Situation: 2am. PagerDuty fires. You're on call. You need to know: which service is down, is it ECS or application-level, what are Sentry showing, and is there a recent bad deploy.
Commands:
/ops:fires
What happens: Claude pulls ECS service health for all clusters, recent Sentry errors, and CI failures from the last 24 hours. Classifies each issue by severity (CRITICAL / HIGH / MEDIUM / LOW) and presents a dashboard. Shows running/desired task counts, stopped task reasons, top Sentry errors with counts, and recent GitHub Actions failures.
Then choose an action:
a) Dispatch fix agent for [top critical issue]
b) View ECS logs for [service]
c) Open Sentry dashboard
Scope to one project:
/ops:fires myapp
Outcome: From alert to root cause in 30 seconds. Fix agent handles straightforward issues autonomously; complex ones get a clear triage report to hand off.
Situation: Weekly CTO review. You want an unfiltered picture of the business — what's breaking, what's burning money, what's falling through the cracks — before you talk to the team.
Commands:
/ops:yolo
What happens: Claude pre-gathers all available data (infra, git, PRs, CI, messages, AWS costs, Linear sprint, GSD roadmaps), then spawns 4 agents in parallel:
- CTO agent (claude-opus-4-6, high effort): Technical debt time-bombs, services at risk, scalability limits, corners that were cut
- CFO agent (claude-opus-4-6, high effort): Actual vs. perceived burn rate, waste identification, runway, ROI on current work
- COO agent (claude-opus-4-6, high effort): What's falling through the cracks, stale PRs, broken processes, communication failures
- CEO agent (claude-opus-4-6, high effort): Synthesizes all three reports into a unified executive summary — growth blockers, resource allocation, what to tell an investor unfiltered
Each agent writes to /tmp/yolo-[session]/ and the CEO agent produces the final report.
Outcome: A Hard Truths report that surfaces things your team meeting won't. The CTO agent found that your auth service has a SPOF that will cause a P0 at 3x current load. The CFO agent found $400/month in orphaned ECS task definitions. The COO agent found 4 PRs that have been open for over a week with no activity.
Optional — hand over the controls:
After reading the report, type YOLO to let Claude autonomously process the inbox, merge ready PRs, fix identified fires, advance GSD phases, and deploy.
Situation: Fully remote team across 3 timezones. Messages come in on Slack, WhatsApp, and occasionally email. You need to stay responsive without being always-on.
Commands:
/ops:inbox
/ops:inbox slack
/ops:inbox whatsapp
/ops:inbox email
What happens: Claude scans all channels for the FULL inbox state — not just unread, but all recent conversations classified as NEEDS_REPLY, WAITING, or HANDLED. For each message needing a reply, it drafts a response (or asks you to confirm a send). Archives handled threads. Reports what's waiting on others.
Send a specific message:
/ops:comms send "build is green, merging now" to #eng-team on Slack
/ops:comms send "can we push the call 30 mins?" to John Smith on WhatsApp
Outcome: Inbox zero across all channels in a single session. Messages are prioritized so you reply to urgent items first. No more missing a critical Slack DM because you were in Gmail.
Situation: AWS bill came in higher than expected. You want to know which services are driving cost and whether any credits are about to expire.
Commands:
/ops:revenue
/ops:revenue costs
/ops:revenue credits
What happens: Claude queries AWS Cost Explorer for current month costs by service, last 3 months trend, and credit balance. Identifies the top cost drivers, compares to prior months, flags anomalies, and estimates runway if pre-paid credits are factored in.
What you see:
- Top 10 services by cost this month
- Month-over-month trend (up/down/flat)
- Credits balance with expiry dates
- Estimated monthly runway
- Project-level revenue stages from your registry
Outcome: Identified $800/month in ECS tasks running for a deprecated service. Credits expiring in 23 days. Runway updated based on actual spend vs. estimate.
Situation: Sprint planning day. You need to see what's in the current cycle, what's blocked, what's been sitting too long, and sync with what's actually in the code.
Commands:
/ops:linear
/ops:linear sprint
/ops:linear create
/ops:linear backlog
What happens: Claude connects to Linear via MCP and shows the current sprint cycle with all issues, their statuses, assignees, and priorities. You can create new issues, update existing ones, add comments, and compare Linear state against your GSD roadmap if GSD is installed.
Cross-platform triage:
/ops:triage
Pulls issues from Sentry (MCP), Linear (MCP), and GitHub Issues (gh), cross-references them against the codebase, and identifies: already-fixed issues to auto-resolve, duplicates to merge, and active issues to dispatch fix agents for.
Outcome: Sprint board up to date in 5 minutes instead of 30. 3 Sentry errors auto-resolved because the fix was already merged. 2 Linear issues marked done that were fixed last week but never closed.
Situation: You have a heads-down coding day planned and want to delegate all operational work.
Morning:
/ops:go # situational awareness
/ops:next # get first action
Delegate inbox:
/ops:inbox # Claude reads, drafts replies, archives handled
Delegate PR queue:
/ops:merge # Claude reviews, fixes CI, merges ready PRs
Delegate fires:
/ops:fires # Claude triages, dispatches fix agents
Full autonomous handover:
/ops:yolo
# Read the Hard Truths report
# Type: YOLO
After you type YOLO, Claude enters autonomous loop mode: processes inbox, merges PRs, fixes fires, advances GSD phases, deploys. Reports back when done or when it needs a decision.
Outcome: You wrote code for 6 hours. Claude merged 4 PRs, replied to 12 messages, resolved 2 Sentry errors, and advanced 1 GSD phase. You reviewed the activity log at end of day.