Module 11 · Lesson 04
Building a Shared Team Prompt Library
Reading time: 16 minutes Track: Claude Fluency for Teams · Required for all learners
The compounding value problem
When a team member writes a great prompt for a recurring task, that knowledge typically dies in one of three places:
- Buried in their conversation history
- Living in their personal notes
- Transferred only if someone happens to ask
This means every team member reinvents prompts for the same tasks, quality varies wildly between people, and good work doesn't compound. A prompt library solves this.
What belongs in a prompt library
Not every prompt is worth capturing. The criteria for library-worthy prompts:
- Recurring: Used more than 2-3 times per month
- Non-trivial: Took meaningful effort to get right
- Transferable: Works for others doing the same task, not just the original author
- Verified: Produced actually good output, not just okay output
Common categories worth capturing:
| Category | Examples |
|---|---|
| Code tasks | PR review template, debugging starter, test generation |
| Document tasks | Email templates, report structure, executive summary |
| Analysis | Competitive analysis framework, decision matrix, risk analysis |
| Communication | Meeting follow-up, stakeholder update, incident post-mortem |
| Research | Literature review, technology comparison, requirement extraction |
Anatomy of a library entry
A useful prompt library entry contains more than just the prompt. Each entry should have:
Prompt name: Short, searchable label Use case: One sentence on when to use this The prompt: Full text, with [PLACEHOLDERS] for variable parts Example output: A real output this produced (helps others evaluate fit) Notes: What makes this prompt work, common pitfalls, suggested variations Owner/date: Who wrote it, when — so you know who to ask questions
Example entry:
Name: Technical Post-Mortem Draft
Use case: After any production incident, generate a structured post-mortem outline
Prompt:
You are a senior engineer writing a blameless post-mortem for [INCIDENT DESCRIPTION].
Timeline of events: [PASTE TIMELINE]
Services affected: [LIST]
Customer impact: [DESCRIBE]
Write a structured post-mortem covering:
1. Summary (2-3 sentences)
2. Timeline (format as table: time | event | who noticed)
3. Root cause analysis (what happened, not who caused it)
4. Contributing factors
5. Impact summary
6. Remediation actions (format as: action | owner | due date)
7. Preventive measures for the future
Tone: factual, blameless, focused on systems not individuals.
Notes: Works best when you provide a detailed timeline. The more specific the incident description, the less generic the output.
Where to keep the library
The format matters less than it being used. Common options:
- Notion or Confluence page: Easy to update, comment on, share links. Good for teams already using these tools.
- GitHub/GitLab repo: Prompts as markdown files, version-controlled, PRs for additions. Good for engineering teams.
- Google Docs folder: Simple, accessible. Works for any team.
- CLAUDE.md sections: For project-specific prompts, a "Common Prompts" section in CLAUDE.md puts them directly in Claude Code sessions.
Maintaining the library
A prompt library that isn't maintained becomes useless. Two practices keep it alive:
- Monthly review: 30-minute team session to add new prompts, mark outdated ones, update prompts as the team's tools or needs change.
- Usage signals: Note in each entry the last time it was used. Prompts unused for 6 months should be archived or deleted.
Getting started: the 3-prompt sprint
Don't try to build a comprehensive library from day one. Instead, run a 3-prompt sprint with your team:
- Each person identifies one recurring task where they've developed a good prompt
- Everyone writes up that prompt using the template above
- Share and debrief: what works, what's missing
Three solid, well-documented prompts that people actually use beat fifty prompts nobody looks at.