Ever notice how the best prompt for that gnarly task leaves with the person who wrote it? 😅 We've all lost those little gems when someone moves teams.
Building a prompt library that outlasts us means treating it less like a notepad and more like a shared codebase. It needs structure and context to be useful for the next person.
Here’s what’s working for us: a simple `/prompts` folder in our main project repo, organized by job-to-be-done (e.g., `code-review/`, `onboarding/`, `debugging/`). Each prompt is a markdown file with a consistent header: a **one-line description**, the **expected input format**, and a **short example of the output**. The magic is in the comment block at the top explaining *when* and *why* to use it.
The real key? A `README.md` that acts as a prompt index, sorted by common problems. New hires find it on day one. It’s not about having hundreds of prompts, but about having a *curated* few that are documented well enough for a stranger to use.