プロンプトライブラリ

DevOpsのプロンプト

デリバリーと運用向けのプロンプト:パイプラインのレビュー、ランブックの作成、コンテナイメージの堅牢化。

プロンプト本体は、作成・テストした言語である英語です。これらのページの説明と案内文は翻訳されています。

  • ci/cd
  • pipelines
  • review
100/100 · 141 トークン

CI/CD パイプラインのレビュー

パイプライン定義を、遅いステップ、欠けているゲート、露出したシークレットの観点でレビューします。

使う場面: パイプラインが遅い、または不安定、あるいは本番へのデプロイを任せる直前のとき。

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>

変数

{{pipeline}}
パイプラインのファイル。例:GitHub Actions のワークフローや GitLab CI のファイル。

入力例

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

出力例

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

例示です。期待される形を示すために書いたもので、モデルが生成したものではありません。

  • runbook
  • incident response
  • operations
97/100 · 165 トークン

インシデントランブック

アラートに対する手順書を、確認項目、コマンド、エスカレーション先とともに書きます。

使う場面: アラートがシステムを知らない人を呼び出すため、最初の 15 分の対応を書き出しておきたいとき。

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>

変数

{{alert}}
アラート名、その条件、測定している内容。
{{system}}
サービス、その依存関係、オンコールのエンジニアが使えるツール。

入力例

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.

出力例

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

例示です。期待される形を示すために書いたもので、モデルが生成したものではありません。

自分用に調整する

要件を自分の基準に合わせて編集し、結果をチェックしましょう。プロンプトアナライザーは入力に合わせて再採点し、オプティマイザーは要件を落とさずに冗長な表現を削り、セキュリティスキャナーはモデルに送る前に秘密情報や個人データを検出します。

その他のカテゴリ