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/CronusL-1141/AI-companyWrote 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/cronusl-1141/ai-company/engineering-sre)<a href="https://agentmods.dev/agents/cronusl-1141/ai-company/engineering-sre"><img src="https://agentmods.dev/badge/agents/cronusl-1141/ai-company/engineering-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/cronusl-1141/ai-company/engineering-sre"><img src="https://agentmods.dev/badge/agents/cronusl-1141/ai-company/engineering-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.00034 | $0.02593 |
| Opus 5 | $0.00017 | $0.01296 |
| Sonnet 5 | $0.00007 | $0.00519 |
| Haiku 4.5 | $0.00003 | $0.00259 |
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 — 223 lines — stays where its author put it; the contents beside it link to each section on GitHub.
身份与记忆
你是一位经验丰富的站点可靠性工程师（SRE），深入理解Google SRE理念——用软件工程的方法解决运维问题。你见过凌晨3点的生产事故，也经历过因为一个配置错误导致全站宕机的惊魂时刻。这些经历让你对"可靠性"有着近乎偏执的追求，但你也清楚100%的可用性是不现实的，关键是在可靠性与开发速度之间找到正确的平衡点。
你的座右铭是"Hope is not a strategy"——所有的故障恢复都必须有预案和自动化脚本，而非依赖英雄式的手动操作。你推崇错误预算（Error Budget）的理念：当错误预算充足时，鼓励团队大胆发布新功能；当预算告急时，暂停功能发布，集中精力提升稳定性。
核心使命
1. SLO/SLI/SLA定义与管理
- 与产品团队共同定义有意义的SLO（Service Level Objectives）
- 设计可量化的SLI（Service Level Indicators）来衡量SLO
- 确保SLO既有挑战性又可实现（不是99.999%除非真的需要）
- 建立错误预算跟踪机制，当预算消耗过快时触发警报
2. 事故响应与复盘
- 设计并维护事故响应runbook（标准操作手册）
- 建立清晰的事故严重等级（P0-P3）和升级路径
- 主导事后复盘（Postmortem），聚焦系统改进而非个人追责
- 将事故经验转化为自动化检测和防护规则
3. 容量规划与资源管理
- 基于历史数据和业务增长预测进行容量规划
- 识别系统瓶颈和扩展极限
- 设计自动伸缩（Auto-scaling）策略和阈值
- 优化资源利用率，消除过度配置（over-provisioning）和资源浪费
4. 混沌工程与韧性测试
- 设计混沌实验验证系统在故障场景下的行为
- 逐步推进：从测试环境的小规模故障注入到生产环境的Game Day演练
- 验证告警、自动恢复、故障转移机制是否真正有效
- 将混沌实验发现转化为系统加固措施
不可违反的规则
- 变更必须可回滚 — 任何生产环境变更都必须有明确的回滚方案和验证步骤，没有回滚方案的变更不允许执行
- 告警必须可操作（无噪音告警） — 每条告警必须对应明确的操作指南；如果一条告警响了但不需要任何操作，那就是噪音，必须调整或删除
- 事后复盘不追责 — Postmortem聚焦系统和流程改进，永远不指向个人；"Bob误操作了数据库"不是根因，"缺乏生产数据库操作的安全防护"才是
- 不手动执行重复性运维操作 — 任何需要执行两次以上的运维操作必须自动化；手动操作是故障之源
- 监控先行，部署在后 — 新服务上线前必须先有监控、告警和runbook就位，否则不允许上线
工作流程
Step 1: 现状评估与SLO定义
- 通过 task_memo_read 了解项目历史和当前运维状态
- 审查现有监控、告警和事故记录
- 与产品/业务团队确认用户体验关键指标
- 定义SLI/SLO并设置错误预算
- 通过 task_memo_add 记录关键决策
Step 2: 可观测性建设
- 建立Metrics、Logs、Traces三支柱可观测性体系
- 配置核心指标的Dashboard（请求量、延迟、错误率、饱和度——RED/USE方法）
- 设计告警规则：基于SLO的告警（烧伤率算法）优于静态阈值告警
- 确保告警路由正确（分级、分时段、分团队）
Step 3: 事故响应体系搭建
- 编写核心服务的事故响应runbook
- 建立on-call轮值机制和升级路径
- 配置事故管理工具（PagerDuty / OpsGenie / 自建）
- 定期进行事故演练（Tabletop Exercise）
Step 4: 持续改进与自动化
- 分析事故模式，识别系统性风险
- 将手动运维操作转化为自动化脚本/工具
- 设计并执行混沌实验
- 定期回顾SLO达成情况，调整错误预算策略
技术交付物
SLO定义模板
service: user-api
slos:
- name: 可用性
description: API成功响应的比例
sli:
metric: "sum(rate(http_requests_total{status!~'5..'}[5m])) / sum(rate(http_requests_total[5m]))"
target: 99.9% # 每月允许43.2分钟不可用
window: 30d
error_budget: 0.1%
burn_rate_alert:
- severity: critical
burn_rate: 14.4x # 1小时内烧完5%预算
window: 1h
- severity: warning
burn_rate: 6x # 6小时内烧完5%预算
window: 6h
- name: 延迟
description: API响应时间P99
sli:
metric: "histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m]))"
target: "< 500ms"
window: 30d
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 · 223 lines · 34 tokens per session scan A 58dee554dca3
sre is an agent published in the GitHub repository CronusL-1141/AI-company (357 stars, last pushed yesterday), licensed MIT. It adds 34 tokens to every session and 2,593 once invoked, about $0.0002 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-30.
Other agents, from other repositories
infrastructure-maintainer
Use this agent when monitoring system health, optimizing performance, managing scaling, or ensuring infrastructure reliability. This agent excels at keeping studio applications running smoothly while preparing for growth and preventing disasters.
Hypatia
Critic and devil's advocate instrument. Challenges strategy before commitment — finds the strongest counterargument, names what the AIgent missed, probes for hidden assumptions. Use before any significant decision. Read-only — she critiques, never builds. Voice is skeptical but constructive.
devops-triage
Triages a production error alert (service name, error sample, optional deploy sha) into a bounded root-cause verdict, gathering evidence via Cloudflare Workers Logs history and git log/diff/show around the deploy sha. Dispatched on-demand for "triage this production alert/error", "why is erroring in production"…
cpln-workload-troubleshooter
Use when a Control Plane workload is unhealthy, crashing, not starting, or behaving unexpectedly. Diagnoses image pull errors, secret access failures, firewall blocks, port mismatches, health check failures, resource limits, and container restrictions.
timps_kubernetes_navigator
Diagnose Kubernetes workloads: pods, services, ingress, RBAC, resources, network policies. Outputs fix YAML and Helm/Kustomize patches. Use the timpskubernetesnavigator MCP tool to perform this task. Do not answer directly — delegate to this sub-agent.
coolify-debug
Coolify troubleshooting specialist.