title: Write a Dockerfile

description: Produce a secure, small, well-layered Dockerfile.

content:
Write a production Dockerfile for a {{stack}} app.

Requirements:
- Multi-stage build to keep the final image small.
- Run as a non-root user.
- Pin base image versions; no `latest`.
- Order layers so dependency installs cache well.
- Include a healthcheck and sensible default command.
- No secrets baked into the image.

Explain the key choices in a few comments.

stack

description: Language/framework and runtime


title: Author a CI Pipeline

description: Design a CI workflow that catches problems fast and cheaply.

content:
Write a CI pipeline for {{platform}} for a {{stack}} project.

Stages: install (cached), lint, typecheck, test, build. Make it fail fast, run independent steps in parallel, and cache dependencies between runs. Add the gate that should block merge. Keep it readable and explain any non-obvious step. Note what I'd add later for deployment but leave out for now.

platform

description: CI system (GitHub Actions, GitLab CI, etc.)

description: Project stack


title: Debug a Failing Deploy

description: Systematically diagnose a deployment that won't come up.

content:
My deployment is failing: {{symptom}}

Walk me through diagnosis in order of likelihood:
1. What to check first (logs, events, health, config, resources).
2. How to tell apart a config error, a resource limit, a dependency outage, and a code bug.
3. The exact commands/queries to run at each step.

Guide me iteratively based on what I report. Prioritize getting it back up (rollback?) over root cause if this is production.

symptom

description: How the deploy is failing


title: Write Infrastructure as Code

description: Provision infrastructure declaratively and safely.

content:
Write {{tool}} configuration to provision: {{infrastructure}}

Requirements:
- Parameterize environment-specific values; no hardcoded secrets or account IDs.
- Apply least-privilege access.
- Tag resources for ownership and cost tracking.
- Make it idempotent and safe to re-apply.

Explain what a `plan`/dry-run would show and what to double-check before applying to production.

tool

description: IaC tool (Terraform, Pulumi, etc.)

infrastructure

description: What to provision


title: Set Up Observability

description: Instrument a service with metrics, logs, and traces that matter.

content:
Help me make this service observable: {{service}}

Define: the handful of metrics that actually indicate health (think RED/USE), what to log at each level, where tracing spans add value, and the 3-5 alerts worth paging on (symptom-based, not cause-based). Avoid alert noise and vanity metrics. Tell me what 'good' looks like for each signal.

service

description: The service to instrument


title: Write a Deployment Runbook

description: Document how to deploy and roll back a service safely.

content:
Write a deployment runbook for: {{service}}

Include: pre-deploy checks, the exact deploy steps, how to verify success (and the specific signals to watch), the rollback procedure, and who to contact if it goes wrong. Write it so a tired on-call engineer can follow it at 3am without prior context. Note the one step most likely to be skipped under pressure.

description: The service being deployed


title: Incident Response Walkthrough

description: Run a calm, structured response to a live incident.

content:
I have a live incident: {{incident}}

Help me respond methodically:
1. Stabilize first — what's the fastest safe mitigation (rollback, scale, feature-flag off)?
2. What to communicate, to whom, and how often.
3. What signals to watch to confirm we're recovering.
4. What to capture now for the postmortem.

Prioritize stopping customer pain over understanding root cause. Tell me the immediate next action.

incident

description: What's happening


title: Harden a Shell Script

description: Make a shell script safe, portable, and predictable.

content:
Review and harden this shell script:

```
{{script}}
```

Apply: `set -euo pipefail`, quote all expansions, validate inputs, handle spaces/edge cases in paths, and fail loudly on error. Flag any non-portable or dangerous construct (unguarded `rm -rf`, unvalidated `eval`, parsing `ls`). Show the hardened version with brief comments on each change.

script

description: The shell script


title: Write a Kubernetes Manifest

description: Produce a sound Kubernetes deployment for a service.

content:
Write Kubernetes manifests for a {{stack}} service that: {{requirements}}

Include: a Deployment with resource requests and limits, liveness and readiness probes, a Service, and config via ConfigMap or Secret (no secrets inline). Run as non-root. Set a sensible replica count and a rolling-update strategy. Explain the probe and resource choices, and what would make this production-ready versus a starting point.

stack

description: App stack

requirements

description: What the service needs


title: Design a Backup and Restore Plan

description: Plan backups you can actually restore from.

content:
I need a backup strategy for: {{data}}

Design it around the RESTORE, not the backup. Specify what to back up, frequency, retention, and where copies live (including off-site or immutable). State the realistic recovery time and recovery point. Most importantly, describe how restores are tested regularly, because an untested backup isn't a backup. Flag the failure that would defeat this plan.

data

description: What needs backing up


title: Speed Up a Slow CI Pipeline

description: Make CI faster without losing safety.

content:
My CI pipeline is too slow: {{description}}

Find the time sinks and cut them: cache dependencies and build artifacts, parallelize independent jobs, run only the tests affected by a change where safe, and move slow checks off the critical path. Order steps to fail fast. Keep the gate that blocks merge intact. Estimate the time saved per change and call out any speedup that trades away real safety.

description

description: The pipeline and its slow parts


title: Right-size Resource Limits

description: Set CPU and memory requests and limits sensibly.

content:
Help me set resource requests and limits for: {{workload}}

Explain how to measure real usage (p50 and p99 over a representative period) before guessing. Set requests near typical usage and limits with headroom for spikes, and explain the consequence of getting each wrong (eviction, throttling, OOM kills, wasted cost). Note the difference between CPU (throttled) and memory (killed) and how that changes the limit strategy.

workload

description: The workload to size


title: Write a Health Check

description: Design liveness and readiness checks that tell the truth.

content:
Design health checks for: {{service}}

Distinguish liveness (is the process wedged and in need of a restart?) from readiness (can it serve traffic right now?). Decide what each actually checks — readiness should verify critical dependencies, liveness should NOT (or a dependency blip restarts everything). Avoid checks that are too shallow (always pass) or too deep (cascade failures). Define timeouts and thresholds, and explain what each failure makes the orchestrator do.

service

description: The service to health-check


title: Set Up Secrets Management

description: Handle credentials without leaking them.

content:
I need to manage secrets for: {{context}}

Design it so secrets never land in source, images, logs, or env dumps. Recommend where they live (a secret manager / vault), how the app gets them at runtime, how they rotate, and who can access them. Cover the lifecycle: injection, rotation without downtime, and revocation after a leak. Flag the common leaks — secrets in CI logs, baked into images, or committed in a .env — and how to prevent each.

context

description: What needs secrets


title: Configure Autoscaling

description: Scale a service with load without thrashing.

content:
I want to autoscale: {{workload}}

Choose the scaling signal (CPU, memory, queue depth, request latency, custom) that actually tracks load for this workload, and explain why the obvious one might mislead. Set min/max replicas, the target, and the scale-up/scale-down behavior to avoid flapping. Account for startup time and warm-up. Flag the cases autoscaling handles badly — sudden spikes, slow-starting pods, and stateful work.

workload

description: The workload to scale


title: Plan a Zero-Downtime Deploy

description: Ship a change without dropping requests.

content:
I need to deploy this without downtime: {{change}}

Choose the strategy (rolling, blue-green, canary) for my constraints. Handle the hard parts: in-flight requests during shutdown (graceful drain), backward-compatible database changes (expand then contract), and old and new versions running at once. Define the health gate that must pass before traffic shifts and the rollback trigger. Flag any change that cannot be made zero-downtime in one step and how to split it.

change

description: The change to deploy