{"title":"Write a Dockerfile","description":"Produce a secure, small, well-layered Dockerfile.","tags":["docker","containers"],"content":"Write a production Dockerfile for a {{stack}} app.\n\nRequirements:\n- Multi-stage build to keep the final image small.\n- Run as a non-root user.\n- Pin base image versions; no `latest`.\n- Order layers so dependency installs cache well.\n- Include a healthcheck and sensible default command.\n- No secrets baked into the image.\n\nExplain the key choices in a few comments.","variables":[{"name":"stack","description":"Language/framework and runtime","required":true}]}
{"title":"Author a CI Pipeline","description":"Design a CI workflow that catches problems fast and cheaply.","tags":["ci","pipeline","automation"],"content":"Write a CI pipeline for {{platform}} for a {{stack}} project.\n\nStages: 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.","variables":[{"name":"platform","description":"CI system (GitHub Actions, GitLab CI, etc.)","required":true},{"name":"stack","description":"Project stack","required":true}]}
{"title":"Debug a Failing Deploy","description":"Systematically diagnose a deployment that won't come up.","tags":["deploy","incident","troubleshooting"],"content":"My deployment is failing: {{symptom}}\n\nWalk me through diagnosis in order of likelihood:\n1. What to check first (logs, events, health, config, resources).\n2. How to tell apart a config error, a resource limit, a dependency outage, and a code bug.\n3. The exact commands/queries to run at each step.\n\nGuide me iteratively based on what I report. Prioritize getting it back up (rollback?) over root cause if this is production.","variables":[{"name":"symptom","description":"How the deploy is failing","required":true}]}
{"title":"Write Infrastructure as Code","description":"Provision infrastructure declaratively and safely.","tags":["iac","terraform","provisioning"],"content":"Write {{tool}} configuration to provision: {{infrastructure}}\n\nRequirements:\n- Parameterize environment-specific values; no hardcoded secrets or account IDs.\n- Apply least-privilege access.\n- Tag resources for ownership and cost tracking.\n- Make it idempotent and safe to re-apply.\n\nExplain what a `plan`/dry-run would show and what to double-check before applying to production.","variables":[{"name":"tool","description":"IaC tool (Terraform, Pulumi, etc.)","required":true},{"name":"infrastructure","description":"What to provision","required":true}]}
{"title":"Set Up Observability","description":"Instrument a service with metrics, logs, and traces that matter.","tags":["observability","monitoring","metrics"],"content":"Help me make this service observable: {{service}}\n\nDefine: 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.","variables":[{"name":"service","description":"The service to instrument","required":true}]}
{"title":"Write a Deployment Runbook","description":"Document how to deploy and roll back a service safely.","tags":["runbook","operations","rollback"],"content":"Write a deployment runbook for: {{service}}\n\nInclude: 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.","variables":[{"name":"service","description":"The service being deployed","required":true}]}
{"title":"Incident Response Walkthrough","description":"Run a calm, structured response to a live incident.","tags":["incident","sre","mitigation"],"content":"I have a live incident: {{incident}}\n\nHelp me respond methodically:\n1. Stabilize first — what's the fastest safe mitigation (rollback, scale, feature-flag off)?\n2. What to communicate, to whom, and how often.\n3. What signals to watch to confirm we're recovering.\n4. What to capture now for the postmortem.\n\nPrioritize stopping customer pain over understanding root cause. Tell me the immediate next action.","variables":[{"name":"incident","description":"What's happening","required":true}]}
{"title":"Harden a Shell Script","description":"Make a shell script safe, portable, and predictable.","tags":["bash","scripting","safety"],"content":"Review and harden this shell script:\n\n```\n{{script}}\n```\n\nApply: `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.","variables":[{"name":"script","description":"The shell script","required":true,"multiline":true}]}
{"title":"Write a Kubernetes Manifest","description":"Produce a sound Kubernetes deployment for a service.","tags":["kubernetes","k8s","deploy"],"content":"Write Kubernetes manifests for a {{stack}} service that: {{requirements}}\n\nInclude: 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.","variables":[{"name":"stack","description":"App stack","required":true},{"name":"requirements","description":"What the service needs","required":true}]}
{"title":"Design a Backup and Restore Plan","description":"Plan backups you can actually restore from.","tags":["backup","restore","disaster-recovery"],"content":"I need a backup strategy for: {{data}}\n\nDesign 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.","variables":[{"name":"data","description":"What needs backing up","required":true}]}
{"title":"Speed Up a Slow CI Pipeline","description":"Make CI faster without losing safety.","tags":["ci","performance","caching"],"content":"My CI pipeline is too slow: {{description}}\n\nFind 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.","variables":[{"name":"description","description":"The pipeline and its slow parts","required":true}]}
{"title":"Right-size Resource Limits","description":"Set CPU and memory requests and limits sensibly.","tags":["resources","tuning","cost"],"content":"Help me set resource requests and limits for: {{workload}}\n\nExplain 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.","variables":[{"name":"workload","description":"The workload to size","required":true}]}
{"title":"Write a Health Check","description":"Design liveness and readiness checks that tell the truth.","tags":["healthcheck","kubernetes","reliability"],"content":"Design health checks for: {{service}}\n\nDistinguish 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.","variables":[{"name":"service","description":"The service to health-check","required":true}]}
{"title":"Set Up Secrets Management","description":"Handle credentials without leaking them.","tags":["secrets","security"],"content":"I need to manage secrets for: {{context}}\n\nDesign 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.","variables":[{"name":"context","description":"What needs secrets","required":true}]}
{"title":"Configure Autoscaling","description":"Scale a service with load without thrashing.","tags":["autoscaling","scaling"],"content":"I want to autoscale: {{workload}}\n\nChoose 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.","variables":[{"name":"workload","description":"The workload to scale","required":true}]}
{"title":"Plan a Zero-Downtime Deploy","description":"Ship a change without dropping requests.","tags":["deployment","zero-downtime"],"content":"I need to deploy this without downtime: {{change}}\n\nChoose 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.","variables":[{"name":"change","description":"The change to deploy","required":true}]}