OpenSRE is an open-source framework for building AI agents that investigate and resolve production incidents using operational data and tools. It is for site reliability engineers who want customizable incident-response workflows, training, and evaluation on their own infrastructure.
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 Tracer-Cloud/opensre --skill reporting-github-ci-failuresgit clone --depth 1 https://github.com/Tracer-Cloud/opensreWrote 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/tracer-cloud/opensre/reporting-github-ci-failures)<a href="https://agentmods.dev/skills/tracer-cloud/opensre/reporting-github-ci-failures"><img src="https://agentmods.dev/badge/skills/tracer-cloud/opensre/reporting-github-ci-failures/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/tracer-cloud/opensre/reporting-github-ci-failures"><img src="https://agentmods.dev/badge/skills/tracer-cloud/opensre/reporting-github-ci-failures.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.00061 | $0.00674 |
| Opus 5 | $0.00030 | $0.00337 |
| Sonnet 5 | $0.00012 | $0.00135 |
| Haiku 4.5 | $0.00006 | $0.00067 |
Grade A, and why
reporting-github-ci-failures 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 today.
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 — 64 lines — stays where its author put it; the contents beside it link to each section on GitHub.
GitHub CI health
Use this skill to report failing CI checks for exactly one configured GitHub
repository. The schedule must supply owner and repo; it may supply either
branch or pr_number, never both.
The scheduled runner supplies a pre-fetched CI health block. Treat that block as the complete source of truth and return it faithfully as the final report; do not discover a broader organization or repository scope. Preserve every failing check, link, age, responsible PR or branch, coverage notice, and repair handoff in the block.
Tool usage
This skill does not issue GitHub tool calls during unattended execution. Before
the skill runs, the scheduled runner invokes run_github_ci_health, which
collects the configured repository's CI data through read-only GitHub REST GET
requests and supplies the complete rendered report.
Do not perform additional or fallback GitHub discovery. The only interactive
tool used by this skill is propose_scheduled_delivery, which configures the
recurring report and is never called during an unattended run.
This workflow is read-only. Never call fix_github_pr_ci, github_cli,
shell_run, or any other mutating or external-command tool during unattended
execution. Repairs must be requested interactively and explicitly approved.
When offering this report as a recurring task interactively, use kind
recurring_skill and skill name reporting-github-ci-failures. Pass the exact owner and
repo, plus at most one of branch or pr_number, to
propose_scheduled_delivery so confirmation preserves the repository scope.
Interactively, the repository comes from the request; when it names none,
call scan_local_git_workspace and ask with ask_user_choice. Never run
cli_exec (opensre health, opensre integrations …), shell_run, or
github_cli to discover the repository, the token, or the environment: they
print unrelated integration state and are not part of this skill. To show
the checks failing right now during an interactive turn, use
summarize_github_pr_status; this skill's own report is produced by the
scheduled runner only.
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.
- today Changed 3d4d6db8f2f1
- yesterday First seen · 64 lines · 61 tokens per session scan A 64f934951ce6
reporting-github-ci-failures is a skill published in the GitHub repository Tracer-Cloud/opensre (11,038 stars, last pushed today), licensed Apache-2.0. It adds 61 tokens to every session and 674 once invoked, about $0.0003 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-09-10.
Other skills, from other repositories
bitbucket
Bitbucket code repository integration for managing repos, branches, PRs, issues, and CI/CD pipelines.
grafana-expert
Expert-level Grafana dashboards, visualization, data sources, alerting, and production operations. Use when the user mentions dashboards, visualization, monitoring, observability, or alerting, or when the task involves Grafana Architecture, Installation on Kubernetes, Data Sources, or Dashboard JSON.
host_bash
A read-only shell skill for examining files and running diagnostic commands in a restricted environment. A shell is a text interface for operating-system commands.
host_restart_service
A tool for restarting approved systemd services, which are background programs managed by Linux's service manager.
datadog
Full-stack observability with Datadog APM, logs, metrics, synthetics, and RUM. Use when implementing monitoring, tracing, alerting, or cost optimization for production systems.
monitoring-expert
Expert-level monitoring and observability with Prometheus, Grafana, logging, and alerting. Use when the user mentions observability, Prometheus, Grafana, logging, metrics, or alerting, or when the task involves The Three Pillars of Observability, Monitoring Fundamentals, Prometheus Configuration, or Alert Rules.