Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add rbah31/claude-code-workflow --skill runbookgit clone --depth 1 https://github.com/rbah31/claude-code-workflowWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/rbah31/claude-code-workflow/runbook)<a href="https://agentmods.dev/skills/rbah31/claude-code-workflow/runbook"><img src="https://agentmods.dev/badge/skills/rbah31/claude-code-workflow/runbook/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/rbah31/claude-code-workflow/runbook"><img src="https://agentmods.dev/badge/skills/rbah31/claude-code-workflow/runbook.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00115 | $0.01134 |
| Opus 5.5 | $0.00046 | $0.00454 |
| Sonnet 5.5 | $0.00023 | $0.00227 |
| Haiku 4.5 | $0.00012 | $0.00113 |
Grade A, and why
runbook scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 1mo ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 141 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Runbook — Incident Investigation
You investigate production issues systematically. Your job is to go from a vague symptom to a clear finding with evidence.
Check references/ for known investigation playbooks specific to this project.
If a playbook matches the symptom, follow it. If not, use the general approach
below and consider saving a new playbook when you're done.
Investigation approach
Start from the symptom and work toward the cause. Don't guess — gather evidence at each step before moving to the next.
Understand the symptom. What exactly is broken? Who reported it? When did it start? Is it affecting all users or a subset? Get the basics before touching any tools.
Check the obvious first. Is the service up? Are there recent deploys? Did a dependency change? Is it a known issue (check lessons.md and past runbook reports)?
Narrow the scope. Use logs, metrics, and traces to isolate where the failure is. Is it the app, the database, a third-party service, or the infrastructure?
Find the root cause. Once you know WHERE it fails, figure out WHY. Read the code path, check recent changes, look at the data.
Document everything. Even dead ends are valuable — they tell the next investigator what to skip.
Tools and techniques
Use what the project provides — adapt to the stack:
- Logs: CloudWatch, application logs, error tracking (Sentry, etc.)
- Metrics: CloudWatch dashboards, Grafana, custom metrics
- Database: Direct queries to check data state
- Git:
git log --since="2 hours ago"to check recent changes - Infra:
aws lambda get-function, ECS task status, API Gateway logs - External: Stripe dashboard, Discord status, third-party status pages
Output
# Incident Report — [brief description]
## Symptom
[What was observed, who reported it, when it started]
## Timeline
- [HH:MM] Symptom reported
- [HH:MM] Investigation started
- [HH:MM] Root cause identified
- [HH:MM] Fix applied / escalated
## Root cause
[What broke and why — be specific]
## Evidence
[Logs, metrics, queries that confirm the root cause]
## Fix applied
[What was done to resolve it, or "escalated to [person/team]"]
## Prevention
[What would prevent this from happening again — new test, alert, guard]
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 1mo ago First seen · 141 lines · 115 tokens per session scan A 2320a70b4258
runbook is a skill published in the GitHub repository rbah31/claude-code-workflow (5 stars, last pushed 3mo ago), licensed Apache-2.0. It adds 115 tokens to every session and 1,134 once invoked, about $0.0005 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
debug
Use when a bug, test failure, build failure, or unexpected behaviour is reported or observed, before proposing any fix.
reground
The current session has drifted: the recent work rests on assumptions the codebase has not been shown to support, invents systems that may not exist, or builds past what the task needs. This skill is a hard reset to ground truth. It does not summarize or compact — it discards the speculative thread and rebuilds a…
diagnose-bug
A bug-investigation workflow that reproduces a reported problem, identifies its cause, and writes a task for implementation. It can also prepare a planning brief when the fix changes an API contract, database structure, dependency, or project settings.
systematic-debugging
4-phase root cause debugging: understand bugs before fixing.
bug-report
Structured bug report from a description, or analyze code for potential bugs. Reproduction steps, severity.
bug-triage
Re-evaluate open bugs — priority vs severity, assign to sprints, surface systemic trends. Run when the count grows.