The pre-mortem: find how your plan fails before it does
Hands the model a plan and asks it to write the post-mortem for a failure that hasn't happened yet. Surfaces the risks your team is too invested to name out loud.

Podcast episode
Why PromptsBuddy exists, what a community-run prompt library should and shouldn't be, and the three rules we start with: tested, attributed, versioned.

Audio drops soon
The Notes app graveyard
Audio drops soon — subscribe and it lands when it goes live.
The origin story is unremarkable: a Notes app with a hundred and forty prompts in it, no titles, no dates, and no way to find the good one about meeting notes at the moment it was needed.
The interesting question is why almost every prompt library ends up in the same state — technically full, practically unusable.
People paste a prompt that worked once. They never write what it was for, what model it was tested on, or what “done” looked like. Six months later the file is a graveyard of almost-working text.
A library that cannot answer “does this still work?” is not a library. It is a drawer.
Tested. Every prompt here has been run on a real job, not only a demo chat.
Attributed. Someone stands behind it. Anonymous paste dumps are how rot starts.
Versioned. When the prompt changes, the change is visible. Silent edits break trust.
No leaderboards. No engagement bait. No “top prompts this week” that reward noise. The point is a prompt you can ship with — not a feed you scroll.
Someone reads the prompt, tries it, and checks that the description matches what actually happens. If it fails that check, it does not publish. That is slower than dumping everything into a folder. That is the point.
Hands the model a plan and asks it to write the post-mortem for a failure that hasn't happened yet. Surfaces the risks your team is too invested to name out loud.