How Senior DevOps Engineers Are Building Prompt Libraries Their Whole Team Uses

For DevOps Engineers

7 min read

·

Aug 2, 2026

--

Listen

Share

And why copying prompts from ChatGPT threads is the worst way to use AI at work.

Most teams are using AI like this:

• Someone Googles “ChatGPT prompt for Terraform”
• Finds a random Reddit thread
• Copy-pastes it into Claude or ChatGPT
• Gets a mediocre answer
• Edits it manually for 20 minutes
• Never saves it anywhere

Next week? Same engineer does the same thing again. From scratch.

Meanwhile, a senior engineer on another team has spent 3 hours building a prompt that works perfectly for their stack and it’s sitting in their personal notes, helping nobody else.

That’s an enormous waste. And it’s fixable in an afternoon.

What’s a Prompt Library, Actually?

Nothing fancy. Don’t let the name intimidate you.

A prompt library is just:

• 📁 A shared folder (GitHub repo, Notion, Confluence your choice)
• 📝 A collection of prompts that actually work for YOUR team’s tools
• 🏷️ Organized by task so people can find what they need fast
• ✅ Maintained like code versioned, updated, improved over time

Think of it like your team’s scripts/ folder but for AI prompts instead of bash scripts.

The difference between a random internet prompt and a library prompt:

Random internet prompt: “Write me a Terraform module for AWS”

Library prompt: “Write a production Terraform module for an AWS RDS instance. Use our naming convention <env>-<service>-db.

Tag all resources with environment, team=platform, managed-by=terraform. Target region: var.region.

No hardcoded values. AWS provider 5.x. Include variables.tf, main.tf, outputs.tf."

Same task. Completely different output quality.

Why Senior Engineers Are the Ones Building These

Here’s something interesting.

Junior engineers use AI a lot — but they don’t know enough to write good prompts yet. They don’t know what “production-ready” looks like for your specific stack.

Senior engineers know exactly what good output looks like. They know:

• Your team’s naming conventions
• Which AWS regions you use
• That you’re on Terraform 1.6, not 1.3
• That your K8s version is 1.29
• Which patterns your team has banned (and why)

When a senior engineer writes a prompt they bake all of that in.

The result? Every junior engineer on the team suddenly gets senior-level AI output. Without needing to ask the senior for help every time.

That’s the real value. It’s a way to scale expertise.

What Goes Into a Good Prompt Library

Here’s what teams are actually organizing their prompts around:

🏗️ Infrastructure

• Terraform module generator (with your conventions baked in)
• Terraform plan reviewer (flags security issues, cost surprises)
• Security group audit (checks for 0.0.0.0/0 rules)
• IAM policy writer (with least-privilege built in)
• AWS cost explainer (plain English from Cost Explorer output)

🐳 Kubernetes

• Deployment YAML generator (with resource limits, probes, security context)
• Pod troubleshooter (paste your kubectl output, get a diagnosis)
• HPA tuner (given your metrics, suggest scale settings)
• NetworkPolicy writer (describe what you need, get the YAML)

🚀 CI/CD

• GitHub Actions pipeline generator (your stack, your conventions)
• Pipeline failure debugger (paste the failed log, get the fix)
• Release notes writer (from git log to stakeholder summary)
• Rollback decision helper (should we roll back? give it the metrics)

📟 Incidents & On-Call

• Alert enricher (paste the alert, get context + first steps)
• Root cause analyzer (paste logs + timeline, get diagnosis)
• Postmortem writer (structured, blameless, action-oriented)
• Runbook generator (from bash scripts to documented runbooks)

📝 Writing & Documentation

• ADR writer (architecture decision records from meeting notes)
• Jira ticket writer (from Slack message to proper story)
• Stakeholder email (incident summary for non-technical people)
• Weekly update writer (from git activity to team update)

What a Real Library Entry Looks Like

Don’t just save raw prompts. Structure each entry properly.

Here’s a real template:

markdown

## Prompt: Terraform Module Generator

**Use when:** You need to create a new Terraform module from scratch

**Last tested:** May 2026 | **Model:** Claude Sonnet 4

**Owner:** Platform Team | **Slack:** #platform-team
---

### The Prompt

You are a senior AWS infrastructure engineer.

Write a production-ready Terraform module for: [DESCRIBE WHAT YOU NEED]

Our standards:
- AWS provider: 5.x
- Terraform: >= 1.6.0
- Naming: <env>-<service>-<resource> (e.g. prod-payments-sg)
- Tags on every resource: environment, team, managed-by=terraform
- Region: always use var.region, never hardcode
- No hardcoded account IDs or ARNs
- Use data sources instead of hardcoded IDs

Output these files: variables.tf, main.tf, outputs.tf, versions.tf

Add a README.md with usage example.

Do NOT include:
- Provider block (this is a module)
- Backend config
- Hardcoded secrets

---

### Example Input
"AWS SQS queue with dead letter queue, encrypted, 
 max message size 256KB, retention 7 days"

### Example Output Quality
[link to a sample output in the repo]

### Known Limitations
- Doesn't handle cross-region setups yet
- Always double-check IAM permissions generated

Notice what’s in there:

• ✅ When to use it (not just what it does)
• ✅ Which model it was tested on
• ✅ Who owns it (so people know who to ping)
• ✅ Example input so people know how to fill it in
• ✅ Known limitations (honesty builds trust)

How to Actually Build One -Without It Becoming a Project

The biggest mistake teams make: they treat this like a big initiative.

They create a Notion template, schedule a meeting, assign owners, and plan a “prompt library sprint.”

Six weeks later, nothing exists.

Here’s how senior engineers actually do it:

Week 1 - Start with 3 prompts only

Pick the 3 tasks your team does most often that involve AI. Write proper prompts for just those.

For most DevOps teams that’s:

• Terraform plan review
• Kubernetes YAML generation
• Incident root cause analysis

That’s it. Ship those 3. Get feedback. Improve them.

Week 2-3 - Add prompts as you use AI

Every time someone on the team uses AI and gets a great result:

• Save the prompt
• Add it to the library
• Note what made it work

Every time someone gets a terrible result:

• Figure out what was missing from the prompt
• Fix it
• Save the improved version

Month 2 - The library grows itself

Once engineers see the value, they start contributing without being asked.

The key is making it stupidly easy to contribute:

/prompts
  /terraform         ← drop your .md file here
  /kubernetes
  /incidents
  /cicd
  /documentation
  README.md          ← explains the format

No approval process. No form to fill. No meeting to request.

Where to Store It - Keep It Simple

Option 1: GitHub repo ← recommended for most teams

team-prompt-library/
├── README.md
├── terraform/
│   ├── module-generator.md
│   ├── plan-reviewer.md
│   └── security-audit.md
├── kubernetes/
│   ├── deployment-generator.md
│   └── pod-troubleshooter.md
├── incidents/
│   ├── root-cause-analyzer.md
│   └── postmortem-writer.md
└── documentation/
    ├── runbook-generator.md
    └── adr-writer.md

Why GitHub:

• Everyone already has access
• Version controlled (you can see who changed what)
• Pull requests for improvements (peer review on prompts)
• Easy to link to in Slack

Option 2: Notion or Confluence -if your team lives there already

Just don’t overcomplicate the structure. Flat is fine. Searchable is all that matters.

Option 3: CLAUDE.md in your infra repo

If your team uses Claude Code - put the core context directly in a CLAUDE.md file at the root of your infra repo.

markdown

# CLAUDE.md

## Our Stack
- Cloud: AWS (us-east-1 primary)
- Kubernetes: EKS 1.29
- Terraform: 1.6.x, AWS provider 5.x
- CI/CD: GitHub Actions
- Registry: our-registry.io
## Naming Convention
<env>-<service>-<resource>
## Never Do
- Don't hardcode regions
- Don't use count if for_each works
- Don't suggest CloudFormation
- Don't add * to IAM policies

Claude Code reads this automatically. Every session starts with your team’s full context.

The Prompt That Pays for Everything

If you only build one prompt for your library - make it this one:

The Terraform Plan Reviewer

You are a senior AWS DevOps engineer reviewing a Terraform plan
before it gets applied to production.

Our environment:
- AWS provider: 5.x
- All resources must be tagged: environment, team, managed-by=terraform
- Security groups: no 0.0.0.0/0 rules except on 443 for public ALBs
- S3: all buckets must have versioning and encryption enabled
- IAM: no * actions, no * resources
- RDS: must have deletion_protection = true in production
Review this terraform plan output and flag:
🔴 BLOCKERS - things that would stop me approving this
🟡 WARNINGS - things worth discussing before applying  
✅ LOOKS GOOD - things done correctly worth noting
For each issue: what's wrong, where it is, and the exact fix.
[paste your terraform plan output here]

This single prompt has saved teams from shipping open security groups, unencrypted S3 buckets, and overly permissive IAM roles - multiple times.

The Mistake That Kills Prompt Libraries

Here’s the one thing that makes these fail:

Treating prompts like they’re permanent.

A prompt that works great with Claude Sonnet today might need tweaking in 6 months. New model, different behavior. Or your team adopts a new tool. Or you upgrade Terraform versions.

Prompts need maintenance - just like code.

Simple way to handle this:

• Add a “Last tested” date to every prompt
• When someone uses a prompt and it doesn’t work well-they open a PR to fix it
• Review prompts quarterly as part of your team retrospective

That’s it. Don’t make it complicated.

Real Impact - What Teams Are Seeing

Some concrete results from teams who’ve built this properly:

• 🕐 New engineers producing usable Terraform in day 2 instead of week 3
• 📉 PR review cycles shortened because AI output matches team standards from the start
• 😴 On-call engineers spending 15 minutes less per incident using the RCA prompt
• 📝 Postmortems getting actually written because the prompt does the heavy lifting
• 🎓 Juniors getting senior-quality output without needing to ping seniors for help

The best part? The prompts keep getting better. Every time someone improves one - the whole team benefits immediately.

Start Today - Literally Right Now

You don’t need a plan. You don’t need a meeting.

Do this in the next 30 minutes:

1. Create a folder called prompt-library in your team's GitHub org
2. Write one good prompt for the task your team does most with AI
3. Post the link in your team Slack with: “I started a prompt library. Drop your best prompts here.”

That’s it. See what happens.

The teams that have the best AI setups didn’t plan them. They started small, kept what worked, and let it grow.

Your prompt library is 30 minutes away from existing. The rest is just momentum.