Build Your Personal Prompt Notebook

The most valuable prompt library is not a folder of impressive sentences. It is a record of jobs you actually completed and what you learned when a prompt failed. To keep the notebook honest, use Compare Two Prompt Versions Without Fooling Yourself on the same small test set before saving a winner.

I keep six fields: Job: What did I want to accomplish? Input: What information did I provide, with sensitive material removed? Prompt version: What exact instruction did I use? Result: What did the model return? Test: Which criteria passed, failed, or were unclear? Next change: What one edit will I try next? For a code-review prompt, I might note that v1 produced style suggestions but missed a negative-score boundary bug. In v2, I added the intended scoring contract and requested test-triggering inputs. If v2 finds the bug but makes unsupported claims about other modules, I record that too.

When I reuse a prompt, I rerun one normal, one messy, and one boundary case. That helps me notice whether a new edit broke something that used to work. It also tells me when a prompt is useful only for one narrow task.

If I publish a prompt example in this community, I use fictional code or sanitized notes. I can share the structure of a successful test without leaking a real client's data or unreleased work. Try it: Create one notebook page for a task you repeat. Save today’s prompt and a result that did not work. Write the failed criterion and one targeted revision. In a week, review whether the change actually helped. Keep learning: What to Put in a Reusable Prompt Template, Compare Two Prompt Versions Without Fooling Yourself, and How to Test a Prompt on More Than One Example.