A prompt collection is smaller and more useful than a prompt library. A library is everything that exists; a collection is the thirty prompts your team runs every week, edited for your work, kept where people can reach them, and maintained by someone. Most teams have a collection already, scattered across chat histories and personal notes. This guide is about turning that into one thing that works for everyone.
Start from tested prompts, not from scratch
The fastest way to a collection is to take prompts that already work and edit them toward your situation. Writing from a blank page produces the same mistakes a library has already fixed. Pick the prompts for your recurring tasks from a library organised by task, run each one on a real input, change one bracket at a time, and keep the version that worked. Our prompt library is built for that use, with full briefs you edit rather than one-liners you expand.
What goes in a collection
The recurring work. A marketing team's collection is the weekly email, the campaign brief, the social post set, the landing page section. A support team's is the reply templates, the escalation summary, the help article. A developer's is code review, tests, documentation and the bug triage prompt. Ten to thirty prompts cover most of a team's week; a collection with two hundred is a library again, and nobody opens it.
Each prompt in the collection has the same five parts, so anyone can use it without asking its author.
- Title: the task, in the words people use when they need it.
- When to use it: one line, including when not to.
- The prompt: the full text with brackets marked and a note on what goes in each.
- An example output: so people know what good looks like before they run it.
- Owner and date: who maintains it and when it was last run successfully.
The owner and date are the parts teams skip and the parts that keep a collection alive. A prompt with no owner stops working after a model update and nobody notices; a prompt with a date tells you when to re-test.
Where to keep it
Where the team already looks. A shared document, a wiki page, a folder in the tool the team lives in. The best location is the one that needs no new habit. Avoid putting the collection only inside a chat tool's saved prompts; those are per person and per model, and the collection should be neither.
Keeping it working
Three rules. A prompt is added only after it has been run successfully on a real input by someone other than its author. A prompt is re-run on its test input when its model updates, and the date moves. A prompt that nobody has used in a quarter is moved to an archive; the collection stays short.
Review the collection together once a month for fifteen minutes: what got used, what failed, what is missing. The prompts people wrote in their own chats during the month are the candidates for the collection; the ones several people wrote independently are the obvious ones.
The categories a team collection usually grows into
Writing and editing, because every team writes. The department's own work: marketing, sales, customer service, coding, operations. Meetings and email, because every team has those. And a small set of thinking prompts, for decisions and plans, that cross departments. The library's categories follow the same lines, which makes it the natural source when a new task appears.
A collection is finished when a new team member can do their first week's work from it. That is the test, and it is also why the collection is worth the hour a month it costs to maintain: it is the team's way of working, written down in the form a model can run. For the mechanics of improving a single prompt before it goes in, the prompt optimization guide is the companion piece.
