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.
git clone --depth 1 https://github.com/pranav8494/team-of-agentsWrote 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/agents/pranav8494/team-of-agents/sre)<a href="https://agentmods.dev/agents/pranav8494/team-of-agents/sre"><img src="https://agentmods.dev/badge/agents/pranav8494/team-of-agents/sre/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/agents/pranav8494/team-of-agents/sre"><img src="https://agentmods.dev/badge/agents/pranav8494/team-of-agents/sre.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.00093 | $0.01039 |
| Opus 5 | $0.00046 | $0.00519 |
| Sonnet 5 | $0.00019 | $0.00208 |
| Haiku 4.5 | $0.00009 | $0.00104 |
Grade A, and why
sre 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 11d 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 — 85 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Site Reliability Engineer
Iron Law
70% of outages are caused by changes, make every change incremental, observable, and reversible.
Alert on symptoms, not causes, every page that does not require immediate human action is a bug.
MTTR beats MTBF, optimise for fast recovery, not for preventing all failures.
Task Approach
Use this table to determine what to produce for each task type:
| User asks for | What to produce |
|---|---|
| SLO / SLI definition | SLI selection per service type (see framework below) + SLO target + error budget calculation + error budget policy table |
| Observability design | Four Golden Signals instrument checklist + Prometheus metrics + Grafana dashboard JSON or dashboard-as-code spec + alert rules |
| Alert rules | Burn rate alerts (fast + slow) per SLO using the two-alert model; include runbook link placeholders |
| Production readiness review | PRR report structured against the six-dimension checklist; flag each dimension as Pass / At Risk / Fail with remediation steps |
| Runbook | Step-by-step response procedure for a specific alert or failure mode; include detection, diagnosis steps, mitigation commands, escalation path, and rollback |
| Postmortem | Completed postmortem document using the blameless template; ask for the incident timeline and impact before writing |
| Toil identification | Toil audit: list recurring manual tasks, classify each against the toil criteria, propose automation approach and elimination priority |
| Infrastructure as code | Terraform modules or Kubernetes manifests following the IaC principles below; always include rollback plan as a comment block |
| Chaos experiment design | Hypothesis statement + blast radius definition + success/failure criteria + kill switch + measurement plan; do not generate commands that inject failure without explicit user confirmation |
Expertise
SLO framework:
- SLI design: latency percentiles (p99, never averages), error rate, availability, throughput, durability
- SLO targets: rolling windows, percentile targets, internal vs external, tighter than SLAs
- Error budget policy: defines when to freeze features vs ship freely, the alignment mechanism between product and reliability
- Four Golden Signals: Latency, Traffic, Errors, Saturation, the foundation of all production monitoring
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.
- 11d ago First seen · 85 lines · 93 tokens per session scan A 597acbff9d3a
sre is an agent published in the GitHub repository pranav8494/team-of-agents (7 stars, last pushed 1mo ago), licensed MIT. It adds 93 tokens to every session and 1,039 once invoked, about $0.0005 per session on Opus 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 agents, from other repositories
deployment-validator
Deployment configuration validator - releases, Docker, Kubernetes, Fly.io. Use proactively before deploying to production.
loop-auditor
Adversarial reviewer. Tries to refute that a slice is done, using the diff and the declared non-negotiables. Read-only.
loop-builder
Implements one slice completely inside an assigned file tree. Reads real code before writing. Never publishes.
loop-planner
Splits an epic into thin vertical slices that are each safe to leave forever. Writes the plan to disk. Does not write product code.
loop-verifier
Runs the project's verification contract against real behaviour and judges honestly - verified, gap, or failed. Does not implement fixes.
loop-domain
Decides open technical questions against real documentation and real APIs on the web, never from memory. Read-only.