Prompt library

DevOps prompts

Prompts for delivery and operations: reviewing pipelines, writing runbooks, and hardening container images.

  • ci/cd
  • pipelines
  • review
100/100 · 141 tokens

CI/CD pipeline review

Reviews a pipeline definition for slow steps, missing gates, and exposed secrets.

Use it when: A pipeline is slow or flaky, or you are about to let it deploy to production.

prompt
You are a senior DevOps engineer reviewing a CI/CD pipeline.

## Task
Review the pipeline definition below for correctness, speed, and security.

## Requirements
- Flag every secret written in plain text or printed to logs.
- Flag every deployment step that runs without a preceding test step.
- Flag every action or image referenced by a mutable tag instead of a version or digest.
- Name the steps that can run in parallel or be cached.
- Quote the line for every finding.

## Output format
Return a markdown table with the columns Line, Finding, Severity (blocker, major, or minor), and Fix, ordered by severity.

## Input
<pipeline>
{{pipeline}}
</pipeline>
Optimize in workspace

Variables

{{pipeline}}
The pipeline file, for example a GitHub Actions workflow or a GitLab CI file.

Example input

pipeline: a GitHub Actions workflow that uses actions/checkout@main and deploys on every push without running tests.

Example output

| Line | Finding | Severity | Fix |
|---|---|---|---|
| `uses: actions/checkout@main` | Mutable reference | major | Pin to a release tag or commit SHA |
| `run: ./deploy.sh` | Deploys without tests | blocker | Add `needs: test` |

Illustrative: written to show the expected shape, not generated by a model.

  • runbook
  • incident response
  • operations
97/100 · 165 tokens

Incident runbook

Writes a step-by-step runbook for an alert, with checks, commands, and an escalation point.

Use it when: An alert pages people who do not know the system, and you want the first 15 minutes written down.

prompt
You are a site reliability engineer writing an on-call runbook.

## Task
Write a runbook for responding to the alert described below.

## Requirements
- Order the steps so the fastest check that rules out the most causes comes first.
- Give the exact command or dashboard for every step, using only the tools named in the system description.
- State what result is expected and what to do when the result differs.
- Mark every step that changes production with "CHANGES PRODUCTION".
- End with the condition that triggers escalation and who to escalate to.

## Output format
Return markdown with five sections: Alert, Impact, Diagnosis (numbered steps), Mitigation (numbered steps), and Escalation.

## Input
<alert>
{{alert}}
</alert>

<system>
{{system}}
</system>
Optimize in workspace

Variables

{{alert}}
The alert name, its condition, and what it measures.
{{system}}
The service, its dependencies, and the tools on-call engineers can use.

Example input

alert: API p95 latency above 2 s for 5 minutes.
system: a Node service on Kubernetes with a Postgres database; engineers have kubectl and Grafana.

Example output

## Diagnosis
1. Open the Grafana dashboard "API overview". Expected: latency is high on all pods. If only one pod is slow, go to step 4.
2. Run `kubectl top pods -n api`...

## Mitigation
1. CHANGES PRODUCTION: `kubectl rollout undo deployment/api -n api`...

Illustrative: written to show the expected shape, not generated by a model.

Make it yours

Edit the requirements to match your standards, then check the result. Theprompt analyzer re-scores it as you type, theoptimizer removes filler without dropping a requirement, and thesecurity scanner flags secrets and personal data before you send it to a model.

More categories