rbadillap/sre

Guides the first response to a suspected or confirmed security incident, such as leaked credentials, unexpected access, an identity or key nobody created, or exposure of a service that should be private. Contain first, preserve evidence, find persistence, and protect legitimate workloads. Phrases like "credentials leaked", "someone created a user", "suspicious API calls", "this port is open to the internet", "compromised key".

Defines service level indicators and objectives from what users actually need to do, with eligibility and attribution rules and an error budget. Use when a team needs to define reliability, when dashboards are green but customers complain, when engineering and product disagree about whether a service is healthy, or when a customer asks for an SLA. Phrases like "what should our SLO be", "define SLIs", "error budget", "customers say it's unreliable", "can we promise 99.99%".

Designs alerting that pages for real user impact and stays quiet otherwise, using symptoms, error budget burn rates and clear page versus warning rules, tested against past incidents. Use when on-call gets too many pages or misses what matters, when setting alerts for a new SLO or service, or after an incident nobody was paged for. Phrases like "too many alerts", "alert fatigue", "we weren't paged", "what should page", "burn rate alerts".

Discipline. Verify before saying something is true, and say what wasn't verified. Applied by the orchestrators in this package before stating a cause, declaring a fix effective or reporting a result.

Discipline. Change a data structure, schema, format or interface in separate steps (add the new form next to the old one, move to it, then remove the old one) so every version that runs at the same time keeps working and a rollback stays safe. Applied by the orchestrators in this package when a change touches stored data, caches, messages or APIs.

Finds failures that current monitoring can't see, and proposes signals or checks to cover them. Use when dashboards look green but users complain, when something failed and no alert fired, when a tool reports "success" you don't trust, or before trusting a new system's monitoring. Phrases like "nothing alerted", "everything looks healthy", "how did we miss this", "is our monitoring enough".

Discipline. An operation that can run more than once must give the same result, so retries, redeliveries and repeated messages can't break anything. Applied by the orchestrators in this package when designing workers, queues, APIs, migrations or recovery steps.

Turns the lessons of a postmortem or review into proposed changes to how the team and this package work, such as templates, alert policies, runbooks, the skills themselves, or how and when they get used, for a person to approve. Use after a postmortem, after a review that found the process was wrong, or when the same kind of incident happens again. Phrases like "what should we change", "this keeps happening", "update the playbook", "lessons learned".

Discipline. Prevent the next incident by turning what was learned into a default, not a reminder, so the reliable path is also the easiest one. Applied by the orchestrators in this package when proposing follow-ups, prevention or standards.

Plans maintenance that takes capacity away, such as draining nodes, upgrading clusters or hosts, rotating machines or updating devices in batches, so users don't notice. Use before node drains, cluster or OS upgrades, host replacements, or any maintenance window, and when past maintenance caused errors. Phrases like "drain the nodes", "cluster upgrade", "maintenance window", "errors during upgrades", "rotate the hosts".

Plans a change to stored data, schemas, indexes, cache formats or message formats so every running version keeps working and the way back is clear. Use before a database migration, a schema or index change, a change to a cache or message format, a data backfill, or moving data between systems. Phrases like "migration", "add a column", "change the index", "new cache format", "move the data", "is this migration safe".

Handles infrastructure that no longer matches its code, separating what's dangerous from what's merely different, keeping an audit trail, and never applying blindly. Use when an infrastructure-as-code plan shows unexpected changes, when someone changed resources by hand, or when a plan wants to destroy or replace something important. Phrases like "terraform drift", "the plan wants to replace the database", "someone changed this in the console", "plan shows changes we didn't make".

Discipline. Before solving a reliability problem, state what the real problem is. Applied by the orchestrators in this package at the start of the work, and whenever a fix "should have worked" but didn't.

Guides the response to a production alert or an incident. It scopes the problem, finds where it hurts, mitigates safely, communicates, and decides when to escalate. Use when an alert fires, users report errors or slowness, latency or error rates jump, or something is down. Phrases like "latency is up", "users can't log in", "we're getting 503s", "is this an incident", "should I wake someone up".

Discipline. Stop the impact before finding the root cause, starting with actions that can be undone; anything irreversible waits for a person. Applied by the orchestrators in this package before proposing a mitigation, a rollback or a change in production.

Reviews how a new or changed system will behave under failure before it carries real traffic, covering dependencies, shutdown and restart, capacity, retries and duplicate work, and what the team needs to operate it. Use for a production readiness review, before launching a service, before adding a dependency, or when a design will be hard to change later. Phrases like "production readiness", "is this ready for production", "review the architecture", "what can go wrong", "launch review".

Reviews a change before it ships to production, and proposes how to release it safely. Use before deploying, before approving a pull request that changes behavior, data formats, schemas, caches, configuration or infrastructure, before an over-the-air update to a device fleet, or when someone asks to ship under time pressure. Phrases like "is this safe to deploy", "ready to ship", "can we release Friday", "plan the rollout".

Discipline. Find out how far a reliability problem reaches, and pick the signals that describe what users live, before acting. Applied by the orchestrators in this package when sizing an incident, a release risk or a monitoring gap.

Router for site reliability work. Use when you're not sure which reliability skill fits, or when someone describes a production situation in general terms ("something's wrong in production", "help me with reliability", "where do I start"). It reads the situation and points to the right orchestrator in this package.

Discipline. Data and shared state get their own plan, because rolling back code doesn't roll back data. Applied by the orchestrators in this package when a change, an incident or a recovery touches databases, caches, queues or stored files.

Discipline. Tell people what is known to be affected, without claiming a cause too early. Applied by the orchestrators in this package when writing status updates, customer messages, escalations or incident summaries.

Writes a blameless postmortem from an incident, with the timeline, the impact, the contributing factors, why it wasn't detected sooner, and follow-up actions that change defaults. Use after an incident is mitigated, or when someone asks for a postmortem, an incident review, a retrospective or "what happened and how do we stop it happening again".