Bibliothèque de prompts

Prompts DevOps

Prompts pour la livraison et l’exploitation : relire des pipelines, écrire des runbooks et durcir des images de conteneur.

Les prompts sont en anglais, la langue dans laquelle ils ont été écrits et testés. Les descriptions et les consignes de ces pages sont traduites.

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

Revue d’un pipeline CI/CD

Relit la définition d’un pipeline pour repérer les étapes lentes, les contrôles manquants et les secrets exposés.

À utiliser quand : Un pipeline est lent ou instable, ou vous allez le laisser déployer en 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>
Optimiser dans l’espace de travail

Variables

{{pipeline}}
Le fichier du pipeline, par exemple un workflow GitHub Actions ou un fichier GitLab CI.

Exemple d’entrée

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

Exemple de sortie

| 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` |

Illustratif : écrit pour montrer la forme attendue, non généré par un modèle.

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

Runbook d’incident

Écrit un runbook pas à pas pour une alerte, avec vérifications, commandes et point d’escalade.

À utiliser quand : Une alerte réveille des personnes qui ne connaissent pas le système et vous voulez consigner les 15 premières minutes.

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>
Optimiser dans l’espace de travail

Variables

{{alert}}
Le nom de l’alerte, sa condition et ce qu’elle mesure.
{{system}}
Le service, ses dépendances et les outils dont disposent les ingénieurs d’astreinte.

Exemple d’entrée

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.

Exemple de sortie

## 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`...

Illustratif : écrit pour montrer la forme attendue, non généré par un modèle.

Adaptez-le à votre cas

Modifiez les exigences selon vos normes, puis vérifiez le résultat. L’analyseur de prompts le renote pendant que vous tapez, l’optimiseur retire le remplissage sans perdre une exigence, et le scanner de sécurité repère secrets et données personnelles avant l’envoi à un modèle.

Autres catégories