# Hodios paste pack: DevOps
Everything in DevOps from Hodios, the open prompt library by Hermes IDE: 13 entries, catalog 2026.1003.0.
Every entry is dedicated to the public domain under CC0 1.0. Copy, change and share them freely, no attribution needed.
Browse and search the library at https://hermes-ide.com/prompts
## How to use
Find an entry below and copy the text inside its block into ChatGPT, claude.ai or any chat. Replace each [PLACEHOLDER] with your own material. Personas, rules and styles work best as custom instructions or project instructions.
## Contents
- DevOps
- [Design a deployment strategy](#design-deployment-strategy) (prompt)
- [DevOps engineer](#devops-engineer) (persona)
- [Plan backups and disaster recovery](#plan-disaster-recovery) (prompt)
- [Reduce cloud spend](#reduce-cloud-spend) (prompt)
- [Release track](#release-track) (workflow)
- [Review a Dockerfile](#review-dockerfile) (prompt)
- [Review an infrastructure plan before apply](#review-iac-plan) (prompt)
- [Slim down a container image](#slim-container-image) (prompt)
- [Speed up a CI pipeline](#speed-up-ci-pipeline) (prompt)
- [Write a Docker Compose dev environment](#write-docker-compose) (prompt)
- [Write a GitHub Actions workflow](#write-github-actions-workflow) (prompt)
- [Write a Terraform module](#write-terraform-module) (prompt)
- [Write Kubernetes manifests](#write-kubernetes-manifests) (prompt)
---
## Design a deployment strategy
`design-deployment-strategy` · prompt · DevOps · https://hermes-ide.com/prompts/design-deployment-strategy
Chooses and specifies a deployment strategy (rolling, blue-green, canary or feature-flagged) with health gates, automated rollback triggers and database-change ordering. Use when deploys feel risky.
````markdown
Deploys are scary when a bad release reaches every user at once, when nobody knows it is bad until customers complain, and when rollback is a manual procedure that has never been practised. The fix is not one technique but a combination sized to the system: limiting how many users see a release before it is trusted, automated checks that compare the new version against the old, a rollback that is one action and tested, schema changes ordered so old and new code both work, and separating deploying code from releasing features. Each technique has costs: blue-green needs double capacity, a canary needs enough traffic to produce a signal, and feature flags add code paths that must be cleaned up.
Design the deployment strategy for:
[SYSTEM]
1. Choose the strategy and justify it against the system's properties: stateless or stateful, traffic volume (enough requests in a canary slice to detect a regression within minutes), long-lived connections or sessions, client versions you do not control (mobile apps, partner integrations), capacity cost, and the risk profile. Say why the alternatives are worse here. Combine techniques where it helps, for example a canary for the deploy plus feature flags for risky behaviour changes.
2. Define the rollout stages: traffic share or instance count per stage, bake time per stage, and whether each promotion is automatic or needs approval.
3. Define health gates for each stage: pre-traffic checks (readiness, smoke tests against the new version), and live comparisons of the new version against the current one on error rate, latency percentiles, saturation and one business signal (checkouts, sign-ins). Give each gate a threshold, a comparison window and a minimum sample size, as starting values.
4. Define automated rollback triggers: which gate failures roll back without a human, how fast, and what alerts and records are produced. Say which failures should page someone even after an automatic rollback.
5. Order database and schema changes with expand and contract: migrations must work with both the current and the new code; destructive steps ship in a later release after the old code is gone; backfills run separately and are throttled. State the rule for what may ship together in one deploy.
6. Specify the rollback procedure: one command or button, how long it takes, what it does not undo (migrations, messages already sent, cache entries, data written in a new format), and how often it is rehearsed.
7. Describe the implementation on the platform: which native features or tools provide traffic splitting, analysis and rollback, the pipeline stages, deploy markers on dashboards, and deploy freeze rules.
8. Plan the move from the current process in small steps, each one an improvement on its own.
If the system description lacks traffic volume, state handling or how rollback works today, and the choice depends on it, ask for it before choosing. Otherwise state assumptions.
- Choose the simplest strategy that meets the risk profile. A low-traffic internal tool does not need a five-stage canary.
- Every threshold is a starting value with the reason for it, to be tuned from real deploys.
- Name tools only as examples of a capability available on the platform.
- Never treat "roll back" as free: list what a rollback cannot undo.
- Separate what you verified from what you inferred. Mark inferences as such.
- When you do not know, say "I don't know" once and state what would settle it.
## Recommendation
The strategy in two or three sentences, and why the alternatives lose.
## Rollout stages
Table: stage | traffic or instances | bake time | promotion (automatic or approval).
## Health gates and rollback triggers
Table: signal | comparison | threshold | window | action on failure.
## Database and schema changes
Numbered rules, then an example sequence for a column rename across releases.
## Rollback procedure
Steps, expected duration, and what it does not undo.
## Implementation
How to build it on the platform, with a pipeline sketch as a code block in the platform's format where possible.
## Migration plan
Numbered steps from today's process to the target.
## Risks and open questions
Bullets.
````
---
## DevOps engineer
`devops-engineer` · persona · DevOps · https://hermes-ide.com/prompts/devops-engineer
Acts as a DevOps engineer who automates the second time, keeps pipelines fast and reproducible, and makes every change reversible. Use for CI/CD, infrastructure and release work.
````markdown
From now on, work as this persona: DevOps engineer.
You are a DevOps engineer who has run on-call for the systems you build. You care about how software gets from a commit to production and how it behaves once it is there: builds that are fast and give the same result every time, deploys that are boring, and failures that are noticed and undone quickly. You do something by hand once to understand it, and automate it the second time.
How you work:
- Read what exists before proposing anything: the pipeline definitions, Dockerfiles, infrastructure code, deployment manifests, scripts and runbooks. Fit changes to the team's current tools unless there is a stated reason to change them.
- Treat infrastructure and pipelines as code: in version control, reviewed, and applied by automation, never edited by hand in a console. Show the plan or diff (`terraform plan`, `kubectl diff`, a dry run) before anything is applied.
- Make builds reproducible: pin tool and base-image versions, use lockfiles, and avoid steps that depend on the network state or time of day. Cache what is expensive and safe to cache, and know what invalidates each cache.
- Keep the feedback loop short: run the fastest checks first, parallelise independent jobs, and fail early with a clear message. You know roughly how long each stage takes and treat a slow pipeline as a defect.
- Design every change to be reversible: deploys roll back with one action, database changes follow expand-and-contract, risky features ship behind flags, and you say what the rollback is before the change goes out.
- Prefer small, frequent releases with progressive delivery (canary, percentage rollout, blue-green) over big-bang cutovers, gated on health signals rather than on the clock.
- Make systems observable before they are needed: structured logs, the four golden signals, alerts on symptoms users feel, and dashboards that answer "is the last deploy the problem?".
- Run read-only commands freely to investigate. Ask before any command that changes shared state: applying infrastructure, deploying, deleting resources, rotating secrets or running migrations.
What you flag:
- Secrets in code, pipeline logs, images or environment files; long-lived credentials where short-lived or workload identity would do; over-broad IAM permissions.
- Mutable tags (`latest`), unpinned actions or images, and build steps that download and run scripts without verification.
- Manual steps in a release, snowflake servers, and drift between environments or between code and what is deployed.
- Deploys with no health check, no rollback path, or that require downtime the team has not agreed to.
- Single points of failure, missing backups or backups that have never been restored, and alerts nobody would act on.
- Cost surprises: idle resources, unbounded autoscaling, log volumes nobody reads.
Your habits:
- You give the exact command or config, and say what it changes and how to undo it.
- You estimate blast radius before acting, and you start with the smallest one.
- You write runbooks as you go, because the next incident will happen at 3 a.m.
- You explain trade-offs in terms of reliability, speed and cost, and you say plainly when the simple setup is enough.
- You never claim a pipeline or deployment works until you have seen it run.
````
---
## Plan backups and disaster recovery
`plan-disaster-recovery` · prompt · DevOps · https://hermes-ide.com/prompts/plan-disaster-recovery
Writes a backup and disaster-recovery plan with RPO and RTO targets, dependency order, restore drills and owner checklists. Use when a system has backups nobody has restored, or no plan at all.
````markdown
Disaster-recovery plans fail on the things nobody listed: backups that were never restored, replicas that faithfully copied the corruption, the secrets manager or the backup credentials living in the region that went down, a DNS change only one person knows how to make. A useful plan is specific to the system, measured in minutes and data lost, and proven by drills.
Write a backup and disaster-recovery plan for:
[SYSTEM]
Recovery point objective:
Recovery time objective:
1. If an objective above is blank, propose per-tier targets with reasoning and mark them "proposed, needs business sign-off". Do not present them as decided.
2. Inventory every component and data store. Assign each a tier, and list what it depends on to start: identity, secrets, DNS, certificates, container registry, CI/CD, third-party APIs.
3. Cover these scenarios separately, because each needs a different answer: accidental deletion, logical corruption (replication copies it, so point-in-time recovery is required), loss of a zone, loss of a region, compromised cloud account or ransomware, and a critical vendor outage.
4. For each data store, specify the backup method, frequency (it must meet the RPO), retention, encryption and where the key lives, and isolation: a separate account or immutable storage so an attacker with production access cannot delete backups.
5. Choose a recovery strategy per tier (backup and restore, pilot light, warm standby or active-active) and justify it against the RTO and cost.
6. Write the recovery order from the dependency graph: what must be up before what, with an estimated time per step and a total compared against the RTO.
7. Define restore drills: what is restored, how often, success criteria (measured RPO and RTO), and who signs off.
- Replication and high availability are not backups. Do not count them toward recovery from corruption or deletion.
- A backup is only counted as working once a restore of it has been tested. Mark untested backups as risks.
- Use the details given. Where a fact is missing (sizes, regions, owners), write a clearly marked placeholder and list it under Open risks rather than inventing it.
- Separate what you verified from what you inferred. Mark inferences as such.
- When you do not know, say "I don't know" once and state what would settle it.
## Summary
The targets (stated or proposed), the strategy per tier, and the three biggest gaps today.
## Inventory
A table: component, tier, data store (yes/no), depends on, current backup, gap.
## Scenarios
One short subsection per scenario: detection, decision owner, recovery path, expected data loss and downtime.
## Backup policy
A table: data store, method, frequency, retention, isolation, encryption key location, last tested restore.
## Recovery order
Numbered steps with estimated durations and a total against the RTO.
## Drills
A table: drill, frequency, success criteria, owner.
## Owner checklists
One checklist per role (for example incident lead, database owner, platform owner).
## Open risks
Bullets: missing information and unproven assumptions.
````
---
## Reduce cloud spend
`reduce-cloud-spend` · prompt · DevOps · https://hermes-ide.com/prompts/reduce-cloud-spend
Analyses a cloud bill or cost export alongside the architecture and ranks savings by monthly impact, effort and risk. Use when the cloud bill grows faster than usage.
````markdown
Cloud cost advice is usually a generic list ("use spot", "rightsize", "buy reservations") with no link to the actual bill. Real savings come from reading where the money goes, which is often not compute: NAT gateway processing, cross-zone and internet egress, log ingestion, idle environments, forgotten snapshots and over-provisioned database storage. Every recommendation must trace back to a line of the bill and carry an honest risk.
Find savings in this bill:
[BILL_EXPORT]
1. Identify the provider and the bill's currency. Group spend by service and usage type; list the items that make up 80% of the total and the month-over-month trend.
2. Look for savings in four groups:
- Waste: unattached volumes and IPs, old snapshots and images, idle load balancers, non-production environments running all week, unused provisioned capacity.
- Rightsizing: instances, databases and containers whose utilisation is low. Recommend this only when utilisation data supports it; otherwise mark it "verify utilisation first".
- Pricing: commitments (savings plans, committed use, reservations) sized to the steady baseline only; spot or preemptible capacity for fault-tolerant stateless work; storage tiers and lifecycle rules.
- Architecture: data transfer paths, NAT gateway traffic that could use private endpoints, log and metric volume, chatty cross-zone traffic, over-replication.
3. For each saving, estimate the monthly amount with the arithmetic from the bill lines, and rate effort (S/M/L) and risk (low/medium/high, with what could break).
4. Rank by monthly saving adjusted for effort and risk. Separate reversible quick wins from commitments that lock in spend.
- Every number must come from the export or be marked as an estimate with its assumption. Do not invent usage figures.
- Never recommend deleting data, snapshots or backups without first checking retention, legal hold and restore needs; say so on those items.
- Size commitments to the lowest steady usage, not the average, and say what the lock-in period is.
- Quote amounts in the bill's currency, written as the currency code followed by the number (for example "USD 1,200").
- Separate what you verified from what you inferred. Mark inferences as such.
- When you do not know, say "I don't know" once and state what would settle it.
## Spend summary
Total, trend, and a table of the top cost lines with their share.
## Ranked savings
A table: rank, change, monthly saving, effort, risk, reversible (yes/no).
## Details
One short subsection per saving: evidence from the bill, the exact action, what could break, how to verify the saving next month.
## Do not touch
Items that look wasteful but are not, and why.
## Data needed
What extra data (utilisation, tags, traffic) would sharpen the estimates.
````
---
## Release track
`release-track` · workflow · DevOps · https://hermes-ide.com/prompts/release-track
Takes a release from change review to changelog, checklist, staged rollout, verification and announcement, pausing for approval between steps. Use for any release users will notice.
````markdown
Takes this release from review to announcement, one approved step at a time:
[RELEASE_SCOPE]
Releases go wrong when nobody looks at the whole set of changes together, when the rollback path is assumed rather than checked, and when "deployed" is mistaken for "working". Each step produces one artifact and stops for the release owner's approval; later steps build on the approved versions. You prepare, check and write; the release owner runs deploys and other actions that affect users, and you never claim a step happened unless they confirm it. Never invent commits, metrics, dates or approvals: when something is unknown, ask or mark it.
## Steps
Work through these steps in order. Do not skip a gate.
1. change-review (review)
2. changelog (ship)
3. release-checklist (ship)
4. staged-rollout (ship)
5. verification (operate)
6. announcement (ship)
### Step 1: Change review
Understand exactly what is in this release before anything is written about it.
1. Collect the changes. If you can read the repository, list the commits or merged pull requests between the last release tag and the release candidate. Otherwise use the scope given, and if it is too thin to review (no change list), ask for it once and wait.
2. Group the changes: features, fixes, performance, security, dependencies, internal or refactoring, and documentation.
3. Mark the risky ones and say why: database migrations (and whether they are backwards compatible with the previous version running during rollout), API or configuration changes that could break clients or deployments, changed defaults, new or upgraded dependencies, security-sensitive code, and anything touching payments, authentication or data deletion.
4. Check readiness for each risky change: is it behind a feature flag, does it have tests, is there a migration and rollback note, is anything partially merged.
5. Write a version recommendation under the project's versioning policy (for semantic versioning: major for breaking changes, minor for features, patch for fixes) with the reason.
Output a change review: the grouped change table (change, type, risk, flag or test, notes), the risky changes with what could go wrong, the version recommendation, and blockers that must be resolved before release.
Stop and wait for approval. Do not write the changelog yet.
**Gate:** stop here and wait for the user's approval before step 2 (changelog).
### Step 2: Changelog
Write the changelog entry from the approved change review.
1. Follow the project's existing changelog format if there is one; otherwise use Keep a Changelog sections (Added, Changed, Deprecated, Removed, Fixed, Security) under the version and release date placeholder.
2. Write each item from the user's point of view: what they can now do or will notice, in one sentence. Leave internal refactors out unless they change behaviour or performance users will see.
3. Put breaking changes first with the action users must take, and link to a migration note where one is needed.
4. Credit contributors and reference issue or pull request numbers if the project does so.
Output the changelog entry in a fenced Markdown block, plus a list of items you left out and why.
Stop and wait for approval. Do not build the release checklist yet.
**Gate:** stop here and wait for the user's approval before step 3 (release-checklist).
### Step 3: Release checklist
Build the go or no-go checklist for this specific release and deployment method.
1. **Before release:** CI green on the release commit, one artifact built and promoted (not rebuilt per environment), version and tag prepared, changelog merged, migrations reviewed for lock and runtime impact, flags in their launch state, secrets and configuration present in the target environment.
2. **Rollback plan:** the exact rollback action for the deployment method (previous image or version, flag off, app store halt of a phased release, package deprecation for registries that do not allow unpublishing), how long it takes, and what cannot be rolled back (data migrations, sent emails, published packages). For anything irreversible, require a forward-fix plan.
3. **People and timing:** release owner, on-call engineer, channel, and a window that avoids low-staff periods and peak traffic.
4. **Go or no-go criteria:** the conditions that must hold to start, stated so they can be checked yes or no.
Output the checklist as checkboxes grouped by phase, with owner placeholders, followed by the go or no-go criteria. Mark items you could not verify.
Stop and wait for the release owner's go decision. Do not plan the rollout yet.
**Gate:** stop here and wait for the user's approval before step 4 (staged-rollout).
### Step 4: Staged rollout
Plan how the release reaches users in stages, so a problem hits few of them and is caught fast.
1. Pick stages the deployment method supports: for example staff first, then 1 to 5%, 25%, 50% and 100% for canaries and flags; phased release for app stores; a pre-release tag for libraries.
2. For each stage: the duration or bake time, the signals to watch (error rate, latency percentiles, crash-free sessions, a key business metric, and the risks from step 1, compared with the baseline over the same period), the threshold that triggers an automatic or manual rollback, and who decides to proceed.
3. Write the exact commands or console actions for each stage only as instructions for the release owner to run, with the rollback action next to each.
Output a stage table (stage, audience, duration, signals and thresholds, proceed decision, rollback action), then the runbook for the owner.
Stop and wait for the owner to run the rollout and report results. Do not declare any stage complete yourself.
**Gate:** stop here and wait for the user's approval before step 5 (verification).
### Step 5: Verification
Confirm the release works for users, not just that it deployed.
1. Ask the release owner for the observed data at full rollout: the signals from step 4, version adoption, error and crash reports grouped by new issues, support tickets, and results of smoke tests on the critical user journeys.
2. Compare against the pre-release baseline and the thresholds. Call out regressions, even small ones, and new error groups that appeared with this version.
3. Check the specific risks from step 1: migrations finished, flags in the intended state, deprecated behaviour still served where promised.
4. Recommend one outcome: verified, verified with follow-ups, or roll back or forward-fix now, with the evidence. If data is missing, say what is missing instead of concluding.
Output a verification report: outcome, evidence table (signal, baseline, now, status), follow-ups with owners, and anything that must go into a postmortem if the release caused an incident.
Stop and wait for approval. Do not write the announcement until the release is verified.
**Gate:** stop here and wait for the user's approval before step 6 (announcement).
### Step 6: Announcement
Tell the people who care, in the form each audience reads.
1. From the approved changelog and verification, write: release notes for users (highlights first, breaking changes and required actions clearly marked, links to docs and migration notes), a short internal message for support, sales or other teams (what changed, what customers may ask, known issues), and, if relevant, a social or community post of a few sentences.
2. Keep every claim to what was released and verified. Do not mention features still behind flags that are off.
3. Use user-facing language: describe outcomes, not internal component names.
Output each piece under its own heading, ready to paste, followed by a short list of where to publish each one.
This is the last step. List any open follow-ups from verification with their owners.
````
---
## Review a Dockerfile
`review-dockerfile` · prompt · DevOps · https://hermes-ide.com/prompts/review-dockerfile
Reviews a Dockerfile for security, image size, build cache use and runtime correctness, and returns ranked findings with a corrected file. Use before shipping a new or changed container image.
````markdown
A Dockerfile decides what ships to production: which base image and its vulnerabilities, which user the process runs as, whether secrets end up in a layer, and how long every build takes. Most problems are invisible until an image is scanned, pulled at scale or stopped mid-request.
Review [DOCKERFILE]. If it is a path, read it, plus `.dockerignore` and the files it copies.
Weight your attention toward: all.
Check, citing the line for each issue:
1. Base image: a specific version tag (never `latest`), ideally pinned by digest; a slim or distroless variant where the app allows it; the same family across stages.
2. Stages: build tools, compilers and dev dependencies stay in a build stage; the final stage copies only the artefacts it needs.
3. Secrets: no credentials in `ARG`, `ENV`, copied files or the build context. Build-time secrets use BuildKit secret mounts.
4. User: the final stage runs as a non-root user with a fixed UID, and files it does not need to write are not owned by it.
5. Cache order: dependency manifests and lockfiles are copied and installed before the source, so a code change does not reinstall dependencies.
6. Package installs: update and install in one `RUN`, without recommended extras, with package lists removed in the same layer; lockfile-respecting install commands.
7. `.dockerignore`: excludes `.git`, local env files, build output and dependency folders.
8. Runtime: exec-form `ENTRYPOINT`/`CMD` so the process receives signals; a process that handles SIGTERM, or an init when it spawns children; `HEALTHCHECK` only when the platform uses it; `WORKDIR` set; no `ADD` from URLs and no download-and-run commands.
- Every finding cites a line and says what goes wrong in practice (attack, failure or cost), not only which rule it breaks.
- Do not quote image size or build time savings as facts. Mark them as estimates unless you built the image.
- Keep the app's behaviour the same in the revised file. If a fix needs information you do not have (the app's port, its writable paths), say so instead of guessing.
- Skip style-only remarks such as instruction casing or comment wording.
- Read the relevant code before making a claim about it. Do not guess what a file, function or config contains.
- If the information you need is not available, say what is missing and how to get it instead of inventing it.
## Verdict
One line: `ship`, `ship-after-fixes` or `rework`, with the number of findings by severity.
## Findings
Numbered, most severe first: `[high|medium|low] line N — problem — impact — fix`.
## Revised Dockerfile
The full corrected file, with a short comment on each changed line. Omit this section if there are no findings above low.
## Not checked
What you could not verify (base image vulnerabilities, actual image size, the app's signal handling). "None" if empty.
````
---
## Review an infrastructure plan before apply
`review-iac-plan` · prompt · DevOps · https://hermes-ide.com/prompts/review-iac-plan
Reviews a Terraform, OpenTofu or other IaC plan for destructive changes, security exposure, cost surprises and changes outside the stated intent. Use before running apply, especially in production.
````markdown
A plan is the last cheap moment to stop an outage. Reviewers skim the summary line ("2 to add, 1 to change, 1 to destroy") and miss that the one destroy is the production database, or that an innocent rename forces replacement of a load balancer and everything that references its ID. Your job is to read every resource change the way an experienced platform engineer does and say plainly whether it is safe to apply.
Review this plan.
[PLAN_OUTPUT]
1. If you were given only the summary line or a truncated plan, ask for the full output (or `terraform show -json`) and stop.
2. Classify every resource change: create, update in place, replace (destroy then create, or create before destroy), destroy, move, import, or read. Count each action and check your counts against the plan's own summary line.
3. Destructive changes: list every destroy and replace. For each, name the attribute that forces replacement, whether the resource holds state (databases, buckets, volumes, queues, DNS zones, KMS keys, IAM roles in use), and what depends on it. Flag values shown as "known after apply" on IDs that other resources reference, because they cascade into further replacements.
4. Drift and intent: report anything under "Objects have changed outside of Terraform", and compare every change against the stated intent; changes the intent does not explain are likely drift, a provider upgrade or a mistake. Say whether applying would revert a manual hotfix.
5. Security: public ingress (0.0.0.0/0 or ::/0) on non-HTTP ports, public buckets or ACLs, IAM wildcards, encryption or logging turned off, secrets or sensitive values printed in clear text, deletion protection removed.
6. Cost: new or larger instances, NAT gateways, provisioned IOPS or throughput, load balancers, increased counts, cross-region replication. Give an order-of-magnitude monthly estimate only when you can justify it; otherwise name the line item to price.
7. Give a verdict.
- Only report what is in the plan. Do not invent resources, attributes or values; quote the resource address exactly as it appears (`module.db.aws_db_instance.main`) for every finding.
- If the plan is truncated or you cannot tell whether an action is a replace, say so and treat it as a replace.
- Do not suggest running apply or any state-changing command yourself.
- Treat a production-environment destroy of a stateful resource as blocking unless the plan shows a `moved` block or the user says it is intended.
- Keep findings to what changes the apply decision. No style comments on the code.
- Read the relevant code before making a claim about it. Do not guess what a file, function or config contains.
- If the information you need is not available, say what is missing and how to get it instead of inventing it.
## Verdict
One line: safe to apply | apply after changes | do not apply. Then one sentence why.
## Summary
`N to add, N to change, N to replace, N to destroy`, and whether it matches the plan's summary line.
## Destructive changes
A table: resource address, action, forcing attribute, holds state (yes/no), dependents. "None" if empty.
## Security
Numbered findings: resource address, the problem, the fix.
## Cost
Bullets, or "No material change".
## Drift and surprises
Bullets: drift, and changes the intent does not explain, each with its likely cause. Or "None".
## Before you apply
A checklist: backups or snapshots to take, `moved` blocks or `lifecycle` settings to add, people to notify, and the `-target` or staged apply to use if the change should be split.
````
---
## Slim down a container image
`slim-container-image` · prompt · DevOps · https://hermes-ide.com/prompts/slim-container-image
Rewrites a Dockerfile for a smaller, faster, safer image with multi-stage builds, cache-friendly layers, pinned bases and a non-root user. Use when images are large, slow or flagged by scanners.
````markdown
Image size, build time and attack surface usually come from the same mistakes: compilers and dev dependencies shipped to production, source copied before dependencies so every code change reinstalls everything, floating base tags, package-manager caches left in layers, secrets passed as build args, and a root user. A good rewrite fixes all of these without changing how the application behaves at runtime.
Rewrite this Dockerfile:
[DOCKERFILE]
1. Work out the runtime, the package manager and the build output from the file. If you cannot tell the runtime or what command starts the app, ask and stop.
2. Split into stages: a build stage with the toolchain, and a runtime stage with only what runs. Choose the runtime base deliberately: distroless or a `-slim` image by default; `scratch` only for static binaries; Alpine only if you have checked that musl will not break native modules or Python wheels, and say so.
3. Order layers for caching: copy lockfiles, install dependencies, then copy source. Use BuildKit cache mounts for package caches, install production dependencies only in the final stage, and clean package lists in the same `RUN` that creates them.
4. Pin each base image by tag plus digest (leave the digest as a placeholder for the user to fill if you do not know it).
5. Run as a non-root user with a numeric UID and GID; make application files owned by root and read-only unless the app must write to them.
6. Replace any secret passed through `ARG` or `ENV` with a BuildKit secret mount.
7. Use exec-form `ENTRYPOINT`/`CMD` and make sure the process receives signals (an init such as tini when the runtime does not reap children).
8. Write a `.dockerignore` that excludes VCS data, local env files, tests and build caches.
- Keep runtime behaviour the same: exposed port, entrypoint semantics, working directory, environment variables and file paths the app reads. List anything you had to change under "Behaviour to check".
- Size and time savings are estimates unless you were given measurements. Label them as estimates.
- Do not add tools the original image did not need (curl, shells) "for debugging".
- Do only what was asked. If you notice something else worth changing, mention it in one line at the end instead of changing it.
- Keep the change as small as it can be while still being correct.
## Dockerfile
The full rewritten file in one fenced block, with short comments only where a choice is non-obvious.
## .dockerignore
One fenced block.
## Changes
A table: change, why, effect on size, build time or security.
## Behaviour to check
Bullets, or "None".
## Verify
Commands to compare image size and layers before and after, run the container as a non-root user, and scan it.
````
---
## Speed up a CI pipeline
`speed-up-ci-pipeline` · prompt · DevOps · https://hermes-ide.com/prompts/speed-up-ci-pipeline
Analyses a slow CI configuration and its job timings, then proposes caching, parallelism and test splitting with the minutes each change saves. Use when builds are slowing the team down.
````markdown
Developers wait on wall-clock time, and only the critical path through the job graph sets it. Shaving five minutes off a job that runs in parallel with a longer one saves nothing. Generic advice ("add caching", "use bigger runners") without the arithmetic leads teams to spend a week on changes that save seconds. Every proposal here must say how many minutes it removes from the critical path, and why.
Speed up this github-actions pipeline:
[CI_CONFIG]
1. Build the job graph from the config (stages, `needs` or dependencies, matrices, conditions) and find the critical path. If timings are missing, say so, estimate durations from typical step costs, label every number as an estimate, and tell the user which timing data would confirm it.
2. Look for savings in this order, because earlier items are cheaper and safer:
- Skip work: path filters, affected-only builds in monorepos, cancelling superseded runs on the same branch, shallow clones.
- Cache: dependency caches keyed on the lockfile hash and OS, build and compiler caches, container layer caches.
- Restructure: replace serial stages with a dependency graph so independent jobs start together; move slow checks off the merge-blocking path only if the team accepts that.
- Parallelise: shard tests by recorded timing, not by file count; size the shard count so setup time does not eat the gain.
- Hardware: larger runners only where a job is CPU-bound and the cost is worth it.
3. For each change, estimate minutes saved on the critical path and on total compute, and show the arithmetic.
4. Flag hidden time sinks: retries that mask flaky tests, repeated dependency installs across jobs, artifacts uploaded and never used, Docker builds without cache.
- Cache keys must include the lockfile hash and the OS or image. Never share caches across trust boundaries, such as from fork pull requests into the main branch.
- Do not remove or weaken a required check to save time. If a check looks redundant, say so and let the team decide.
- Write config only in the syntax of github-actions; if it is `other`, ask which system and stop before writing config.
- Do only what was asked. If you notice something else worth changing, mention it in one line at the end instead of changing it.
- Keep the change as small as it can be while still being correct.
## Critical path
A table: job, duration, on the critical path (yes/no). Then the current wall-clock total.
## Changes
Numbered, ranked by critical-path minutes saved. Each: the change, minutes saved (critical path / total compute) with the arithmetic, effort (S/M/L), risk, and any cost change.
## Config changes
The edited config as a diff, for the top changes only.
## Expected result
Wall-clock before and after, and which numbers are estimates.
## Measure
How to confirm the gain over the next 20 runs.
````
---
## Write a Docker Compose dev environment
`write-docker-compose` · prompt · DevOps · https://hermes-ide.com/prompts/write-docker-compose
Writes a Docker Compose local development setup that mirrors production dependencies, with health checks, named volumes, seed data, env files and a one-command start. Use when onboarding developers.
````markdown
A local environment earns its keep when a new developer can clone the repo, run one command and have a working app with realistic data in minutes, and when "works on my machine" bugs stop coming from version drift. Compose files usually fall short in the same ways: `latest` images that differ from production, apps that start before the database accepts connections, data lost on every restart, secrets committed in the file, ports exposed on every network interface, and no seed data, so everyone builds their own by hand.
Write a Docker Compose development environment for:
[SERVICES]
1. If the repository is available, read the existing Dockerfiles, dependency manifests, environment variable usage and any current compose file first, and build on them.
2. Pin every dependency image to the same major and minor version as production (for example `postgres:16.4`), never `latest`. Where production uses a managed service with no local equivalent, choose a compatible local stand-in and record the gap.
3. Write `compose.yaml` following the current Compose Specification (no top-level `version:` key):
- App services built from the repo's Dockerfile, using a development target or stage if one exists, with the source bind-mounted for hot reload (or a `develop.watch` section), and dependency folders kept inside the container so host and container builds do not clash.
- A `healthcheck` on every dependency using its own readiness command (`pg_isready`, `redis-cli ping`, an HTTP health endpoint), and `depends_on` with `condition: service_healthy` on the app services.
- Named volumes for all persistent data; no anonymous volumes for data that should survive a restart.
- Ports published on `127.0.0.1` only, with defaults that avoid common clashes and can be overridden from the env file.
- Optional services (admin UIs, observability, workers that are not always needed) behind `profiles`.
4. Put configuration in an env file: write `.env.example` with every variable, safe local defaults and a comment per variable; the real `.env` stays git-ignored. Never put production credentials or real secrets anywhere.
5. Provide seed data: database init scripts or a one-shot seed service that runs after the database is healthy (`condition: service_completed_successfully` for services that depend on it), is idempotent, and creates a few realistic, clearly fake records, including a known login for local use.
6. Give the one-command start (`docker compose up --wait` or a `make dev` / script wrapper), plus reset, logs, shell and test commands.
7. List every remaining difference from production and its consequence, and a short troubleshooting section (port in use, CPU architecture mismatches on ARM machines, stale volumes, file-watching on mounted folders).
If a service's build or start command is unknown and the repository is not available, ask for it rather than inventing one.
- Every image is pinned. Every dependency has a health check. Every data store has a named volume.
- No secrets, tokens or real personal data in any file. Local passwords are obviously local (for example `localdev`).
- Do not add services that were not asked for, except a local stand-in for a dependency that has none; say why each was added.
- Keep it runnable on macOS, Linux and Windows with WSL; call out anything that is not.
- Before saying the work is done, run the check that proves it (tests, build, type check or the command the user gave) and report the real result.
- If you could not run a check, say so plainly and say which one.
## Assumptions
Bullets, only those that shaped the setup.
## compose.yaml
One `yaml` code block, with short comments on non-obvious lines.
## .env.example
One code block.
## Seed data
The seed scripts or seed service, and what records they create.
## Commands
A table: task | command. Include start, stop, reset data, logs, shell, run tests.
## Differences from production
Table: area | production | local | consequence.
## Troubleshooting
Short bullets: symptom, then fix.
````
---
## Write a GitHub Actions workflow
`write-github-actions-workflow` · prompt · DevOps · https://hermes-ide.com/prompts/write-github-actions-workflow
Writes a secure, cached and least-privilege GitHub Actions workflow that fits the repository's real build and test commands. Use when adding CI, a release job or a scheduled task.
````markdown
Most CI workflows are copied from a template and then patched until they pass. The usual results are a token with write access to everything, unpinned third-party actions, no caching, and untrusted pull request data flowing into shell scripts. A workflow that is right the first time is short, uses the project's own commands, and grants only what each job needs.
Write a GitHub Actions workflow that does this: [GOAL]
1. Inspect the repository first: languages, package manager and lockfile, the scripts or make targets that lint, build and test, runtime version files (`.nvmrc`, `.python-version`, `go.mod`, `rust-toolchain.toml`), and the workflows already in `.github/workflows/`. Reuse existing commands instead of inventing new ones.
2. Choose triggers that match the goal, including `paths` or `branches` filters when they avoid useless runs.
3. Set `permissions` at the workflow level to `contents: read`, and grant more only on the job that needs it, with a comment saying why.
4. Use the official setup action for the runtime with its built-in dependency cache keyed on the lockfile. Install with the lockfile-respecting command (`npm ci`, `pip install -r` with hashes, `cargo --locked`).
5. Add `concurrency` that cancels superseded runs on the same branch, and a `timeout-minutes` on every job.
6. Use a matrix only when the goal needs several versions or operating systems.
7. Write the file to `.github/workflows/.yml`. If `actionlint` is available, run it and fix what it reports.
- Pin every third-party action to a full commit SHA with the version in a trailing comment. If you cannot look up the SHA, use the major version tag and list that action under Follow-ups.
- Use only actions you are certain exist. Never invent an action name or an input.
- Never place pull request titles, branch names, commit messages or other event fields directly inside a `run:` script. Pass them through `env:` and quote the variable.
- Do not use `pull_request_target` or expose secrets to jobs that run code from forks.
- Reference secrets by name only, and list every secret the user must create.
- Do only what was asked. If you notice something else worth changing, mention it in one line at the end instead of changing it.
- Keep the change as small as it can be while still being correct.
- Before saying the work is done, run the check that proves it (tests, build, type check or the command the user gave) and report the real result.
- If you could not run a check, say so plainly and say which one.
## Workflow
The path, then the complete YAML file.
## Decisions
One bullet per non-obvious choice (trigger filters, permissions, cache key, matrix), each with the reason.
## Verify
How you checked the file (actionlint output, or "not run") and how the user can trigger a first run.
## Follow-ups
Secrets to create, actions still to pin, and branch protection settings to update. "None" if empty.
````
---
## Write a Terraform module
`write-terraform-module` · prompt · DevOps · https://hermes-ide.com/prompts/write-terraform-module
Writes a reusable Terraform module with typed, validated variables, secure defaults, documented outputs and an example. Use when wrapping cloud resources for other teams to consume.
````markdown
A Terraform module is an API. Its variables are the inputs other teams depend on and its outputs are the contract they build on, so changing either later is a breaking change. Generated modules usually fail in the same ways: untyped `any` variables, hard-coded regions and account IDs, provider blocks inside the module, `count` where `for_each` belongs, and insecure defaults such as public access or wildcard IAM. The target here is a module a platform team would publish to its internal registry.
Write a reusable Terraform module for aws that does this:
[RESOURCE_GOAL]
1. If the goal leaves open a decision that changes the design (single or multi-region, public or private, whether data must survive `terraform destroy`), ask up to 3 questions and stop. If the gap is a detail, choose the safe default and record it under Assumptions.
2. Draw the boundary: one cohesive purpose. Take shared things (VPC or network IDs, KMS keys, DNS zones) as inputs instead of creating them.
3. Variables: explicit types (object types with `optional()` attributes rather than `any`), a description on each, `validation` blocks for formats, ranges and allowed values, `sensitive = true` where it applies. Required inputs have no default; everything else defaults to the safe choice.
4. Resources: encryption at rest on, public access off, least-privilege IAM with no wildcard action on a wildcard resource, deletion protection or `prevent_destroy` on stateful resources where the provider supports it, and tags or labels merged from a `tags` variable.
5. Use `for_each` keyed by stable names for collections, so removing one item does not recreate the others.
6. Pin `required_version` and providers with pessimistic constraints in `versions.tf`. Never put a `provider` or `backend` block in the module.
7. Output what callers need (IDs, ARNs or self-links, endpoints), each with a description; mark secrets `sensitive`.
- Use only resources and arguments that exist in the current aws provider. If you are unsure an argument exists in the pinned version, say so under Assumptions instead of guessing silently.
- No hard-coded account IDs, regions, CIDRs, image IDs or names. They come from variables or data sources.
- No provisioners or `local-exec` unless the goal cannot be met otherwise; explain why if you use one.
- The code must pass `terraform fmt` and `terraform validate`. You cannot run them here, so do not claim they pass.
- Do only what was asked. If you notice something else worth changing, mention it in one line at the end instead of changing it.
- Keep the change as small as it can be while still being correct.
## Assumptions
Bullets: each default you chose and why. "None" if the goal settled everything.
## Files
One fenced `hcl` block per file, headed by its path: `versions.tf`, `variables.tf`, `main.tf`, `outputs.tf`, `examples/basic/main.tf`.
## README
An inputs table (name, type, default, description), an outputs table, and a short usage paragraph.
## Verify
The commands to run (`terraform fmt -check`, `terraform validate`, `terraform plan` on the example, plus a static scanner such as tflint or checkov) and what to look for in the plan.
````
---
## Write Kubernetes manifests
`write-kubernetes-manifests` · prompt · DevOps · https://hermes-ide.com/prompts/write-kubernetes-manifests
Writes production-ready Kubernetes manifests for a service with probes, resource requests, a disruption budget and a restricted security context. Use when deploying a service to a cluster.
````markdown
Most Kubernetes outages caused by manifests come from a short list: liveness probes that check a database and restart every pod when it blips, no readiness probe so traffic hits pods that are still starting, missing memory requests so the scheduler overpacks nodes, a disruption budget that blocks every node drain, all replicas on one node or zone, and containers running as root with a writable filesystem. These manifests should survive a node drain, a zone loss and a security review.
Write Kubernetes manifests for this service, for the prod environment, packaged as plain:
[SERVICE]
1. If the description lacks the image, the listening port or whether the service holds state, ask for them and stop. Everything else you may default; record each default under Assumptions.
2. A stateless service gets a Deployment; one that owns disk state gets a StatefulSet. Say which and why.
3. Deployment: rolling update with `maxUnavailable: 0` and a small `maxSurge`; replicas of at least 3 in prod, 2 in staging, 1 in dev; topology spread constraints across zones and nodes; a dedicated ServiceAccount with `automountServiceAccountToken: false` unless the app calls the API server.
4. Probes with distinct jobs: a startup probe for slow boots, a readiness probe that reflects ability to serve, and a liveness probe that checks only the process itself, never downstream dependencies.
5. Resources: CPU and memory requests sized from the description; a memory limit equal to the memory request; no CPU limit unless the user asks for one (explain the throttling trade-off).
6. Security context: `runAsNonRoot`, a numeric non-zero UID, `readOnlyRootFilesystem` (with an `emptyDir` for any scratch path), `allowPrivilegeEscalation: false`, all capabilities dropped, `seccompProfile: RuntimeDefault`. Label the namespace for the `restricted` Pod Security Standard.
7. Graceful shutdown: a `terminationGracePeriodSeconds` and a short `preStop` sleep so endpoints are removed before the process stops.
8. Also write: a Service, a PodDisruptionBudget (`maxUnavailable: 1`; omit it when replicas are 1, because it would block drains), a HorizontalPodAutoscaler for prod, and a NetworkPolicy that denies ingress except from the callers described.
9. Config comes from a ConfigMap; secrets are referenced by name from a Secret or external secret store, never written with values.
10. Packaging: `plain` is one multi-document YAML file; `kustomize` is a base plus an overlay per environment; `helm` is a chart with `values.yaml`, templates and per-environment values files.
- Use stable API versions only (`apps/v1`, `policy/v1`, `autoscaling/v2`, `networking.k8s.io/v1`).
- Pin the image by digest or an immutable version tag, never `latest`.
- Do not invent hostnames, registry paths or secret names; use clearly marked placeholders such as `REPLACE_ME_REGISTRY` and list them under Assumptions.
- Do only what was asked. If you notice something else worth changing, mention it in one line at the end instead of changing it.
- Keep the change as small as it can be while still being correct.
## Assumptions
Bullets: every default and placeholder.
## Manifests
One fenced `yaml` block per file, headed by its path.
## Why these values
A table: setting, value, reason. Cover replicas, probes, requests and limits, the disruption budget and the security context.
## Verify
Commands: `kubectl apply --dry-run=server`, a schema check such as kubeconform, and how to confirm the rollout and a node drain behave as intended.
````