operations-engineer
Purpose During Development
Use this skill when Codex and similar AI coding agents need to plan, implement, or review the operational readiness of a project.
This is a reusable development-time reasoning framework. It is not runtime code and must not be coupled into the product being operated.
When To Apply
- preparing a project for production, demos, handoff, support, or repeated use
- defining logs, metrics, alerts, backups, incident response, runbooks, or maintenance tasks
- reviewing reliability, recoverability, support burden, or operational ownership
- deciding how much operations work is enough for the simplest feasible launch
What To Inspect
- deployment path, runtime model, data stores, background jobs, queues, storage, and external services
- existing observability, logging, monitoring, error reporting, backup, and support tools
- failure modes for startup, deploy, rollback, migration, secrets, data loss, rate limits, and dependencies
- ownership notes, runbooks, incident docs, support workflows, and on-call expectations
- cost and security constraints that affect operations
Rules To Enforce
- define the minimum operational controls needed for the project’s actual risk
- prefer existing observability and support tools when they pass security review
- make failure modes and recovery actions explicit before launch
- keep runbooks short enough to use during stress
- avoid expensive monitoring, tracing, or incident systems before the project needs them
- coordinate with
deployment-engineer, security-engineer, and finance-engineer for production-facing decisions
Common Anti-Patterns To Catch
- launching without knowing how to detect failure
- logs that omit useful context or leak sensitive data
- backups that are configured but never restored in testing
- alerts that page on symptoms nobody can act on
- operational plans that require paid tooling for a low-risk prototype
- undocumented manual steps that only work on one machine
Expected Output From The Agent
- operational readiness summary
- observability plan
- failure modes and recovery plan
- runbook expectations
- backup and data-retention notes
- support and maintenance ownership
- verification plan
Output Structure
- Summary
- Key Findings
- Risks
- Affected Files
- Affected Areas
- Operational Readiness
- Observability Plan
- Recovery Plan
- Suggested Improvements
- Suggested Tests
- Skills applied
Example Usage
"Use this skill to prepare this deployed project for basic production operations."
"Review this launch plan for logging, monitoring, backups, runbooks, and support risk."
1---2name: operations-engineer3description: Plan, implement, or review operational readiness, observability, reliability, recovery, runbooks, backups, support, and maintenance for projects.4---56# operations-engineer78## Purpose During Development910Use this skill when Codex and similar AI coding agents need to plan, implement, or review the operational readiness of a project.1112This is a reusable development-time reasoning framework. It is not runtime code and must not be coupled into the product being operated.1314## When To Apply1516- preparing a project for production, demos, handoff, support, or repeated use17- defining logs, metrics, alerts, backups, incident response, runbooks, or maintenance tasks18- reviewing reliability, recoverability, support burden, or operational ownership19- deciding how much operations work is enough for the simplest feasible launch2021## What To Inspect2223- deployment path, runtime model, data stores, background jobs, queues, storage, and external services24- existing observability, logging, monitoring, error reporting, backup, and support tools25- failure modes for startup, deploy, rollback, migration, secrets, data loss, rate limits, and dependencies26- ownership notes, runbooks, incident docs, support workflows, and on-call expectations27- cost and security constraints that affect operations2829## Rules To Enforce3031- define the minimum operational controls needed for the project’s actual risk32- prefer existing observability and support tools when they pass security review33- make failure modes and recovery actions explicit before launch34- keep runbooks short enough to use during stress35- avoid expensive monitoring, tracing, or incident systems before the project needs them36- coordinate with `deployment-engineer`, `security-engineer`, and `finance-engineer` for production-facing decisions3738## Common Anti-Patterns To Catch3940- launching without knowing how to detect failure41- logs that omit useful context or leak sensitive data42- backups that are configured but never restored in testing43- alerts that page on symptoms nobody can act on44- operational plans that require paid tooling for a low-risk prototype45- undocumented manual steps that only work on one machine4647## Expected Output From The Agent4849- operational readiness summary50- observability plan51- failure modes and recovery plan52- runbook expectations53- backup and data-retention notes54- support and maintenance ownership55- verification plan5657## Output Structure5859- Summary60- Key Findings61- Risks62- Affected Files63- Affected Areas64- Operational Readiness65- Observability Plan66- Recovery Plan67- Suggested Improvements68- Suggested Tests69- Skills applied7071## Example Usage7273"Use this skill to prepare this deployed project for basic production operations."7475"Review this launch plan for logging, monitoring, backups, runbooks, and support risk."
PolakiniO