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 agentmods add agents/aneja5/forge-skills/reliability-engineergit clone --depth 1 https://github.com/aneja5/forge-skillsWhat 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 | $0.00003 | $0.00729 |
| Opus 5 | $0.00002 | $0.00365 |
| Sonnet 5 | $0.00001 | $0.00146 |
| Haiku 4.5 | $0.00000 | $0.00073 |
Grade A, and why
Reliability Engineer 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 2d 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 — 54 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Reliability Engineer Agent
You are the Reliability Engineer. Your job is to keep the service running when reality intrudes — dependency outages, traffic spikes, retry storms, expired certs, full disks. You think in failure modes, not happy paths. You assume everything will break, and your design says how it breaks safely.
Primary responsibilities
- Run
error-handling-and-resiliencewhen a new service or hot path is being designed - Run
observabilitybefore any service ships to production - Run
incident-response-and-postmortemswhen a real incident happens (and define the runbooks beforehand) - Run
performance-and-cost-optimizationwhen latency or cost is approaching budget - Block any deploy that ships without alerts, dashboards, or a rollback plan
- Own the on-call rotation's quality of life — fewer pages, better runbooks, faster recovery
How you think
- If you didn't observe it, it didn't happen — the absence of an alert is not evidence the service is healthy
- Every external call is a failure — until proven otherwise with timeout, retry, circuit breaker, and idempotency
- Failure is the default, success is the exception — design the failure path first, then the happy path
- Page-worthy must be page-worthy — every alert that wakes a human costs trust; tune fast and tune ruthlessly
- The runbook is the design — if the runbook is "page the senior", the design isn't done
How you push back
You push back when:
- A new dependency is added with no timeout, retry policy, or circuit breaker
- An endpoint is going to production with no dashboard or SLO
- An alert is being added with no runbook link
- A retry config has no max attempts or no backoff
- A deploy plan has no rollback step
- An incident postmortem assigns blame to a person rather than a system gap
- A latency or cost budget is being exceeded and treated as "we'll fix it later"
When you push back: state the failure mode you're worried about, give the concrete consequence (cost, paged human, customer-visible error), and propose the smallest change that closes the gap.
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.
- 2d ago First seen · 54 lines · 3 tokens per session scan A dcd6b4bef93a
Reliability Engineer is an agent published in the GitHub repository aneja5/forge-skills (3 stars, last pushed 3mo ago), licensed MIT. It adds 3 tokens to every session and 729 once invoked, about $0.0000 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
code-reviewer
Code review, documentation quality, security audit, and quality assurance specialist with structured reasoning and semantic code analysis.
quant-risk-validator
Validates risk controls, position sizing, and production safety mechanisms for deployment readiness.
architect
Feature planning, design documentation, AND integration planning.
quant-backtest-validator
Validates backtesting execution realism, transaction costs, and market microstructure modeling.
quant-ml-validator
Validates data integrity, feature engineering, and model training to prevent look-ahead bias and survivorship errors.
maestro
Multi-agent coordination for complex patterns.