Write prompts
worth saving.
The difference between a library you use daily and one you abandon after a week comes down to how the prompts are written. Six rules that make the difference.
What separates prompts that stick from ones that rot.
These aren't theoretical. They come from the patterns that actually make prompts reusable across sessions — the difference between a library you open every day and one you forget about.
Be specific about the task, not the persona
Write "Review this code for SQL injection vulnerabilities" rather than "Act as a security expert". Task-specific prompts produce consistent, usable output. Persona prompts produce unpredictable responses.
Act as a senior engineer and review this.
Review this pull request for correctness, edge cases, and maintainability. Call out risky assumptions before suggesting changes.
Use variables for the parts that change
Build reusable prompts with {{variables}} like {{diff}}, {{topic}}, or {{audience}} for the parts that change each session. Static framing stays saved; PromptMate asks for the variable values when you click Use.
Explain Kubernetes to me.
Explain {{topic}} clearly. Start with a one-sentence definition, then give me the intuition, then a practical example. Assume I know software engineering basics.
One task per prompt
Prompts that ask for three things produce output that does two of them well and one poorly. Save separate prompts for separate tasks. Compose them manually in a session when you need both.
Review my code, write tests for it, and then document it.
Save three separate prompts: one for review, one for tests, one for documentation.
Match tone and format to the reader, not the task
A code review written as prose is slow to scan. A technical spec in bullet points loses nuance. The output format should match how the output will actually be read — not just what feels right to write.
Explain the bug fix. (No format set)
Format: Steps numbered 1–N. Each step: what changed, why, and what to verify. Written for a junior engineer reading in a PR comment.
Test before saving, not after
Use a prompt two or three times in real sessions before saving it. If you need to edit it every time, it's not ready. Save the version that works without adjustment — that's the one worth keeping.
Saving a prompt the first time you write it "just in case".
Run it twice with different inputs. Edit until no adjustments are needed. Then save.
Include the context the model can't infer
Language, framework, audience, constraints, what to avoid. The model doesn't know you're on a Kubernetes cluster or writing for a non-technical PM. Put that in the prompt — it won't drift session to session.
Write documentation for this function.
Write JSDoc documentation for this TypeScript function. Audience: engineers onboarding to this codebase. Cover: what it does, parameters, return value, one usage example, and edge cases to watch for.
Put each instruction in the right place.
A prompt library gets easier to use when repeated context moves up a level and the saved prompt stays focused on the task.
User context
Use for stable facts about you: role, stack, audience preferences, and how you like answers.
Do not put one project, one task, or one pasted input here.
Group instruction
Use for rules shared by a workflow: code review standards, writing voice, product constraints, or team conventions.
Do not repeat the same group instruction inside every prompt.
Prompt body
Use for the reusable task: what to do, what to inspect, and what a good answer should include.
Do not make one prompt do three unrelated jobs.
Variables
Use for changing values: {{diff}}, {{topic}}, {{error_message}}, {{target_reader}}, or {{feature_goal}}.
Do not save a prompt that forces you to edit text after inserting it.
Build a library that sticks.
Small patterns that make PromptMate worth keeping open every session.
Start with prompts you already reuse
Think about instructions you type every week — code review format, email drafts, explaining concepts to teammates. Those are your first 5 saves. Don't start from scratch — start from what's already working.
Use variables instead of editing pasted text
If the same part changes every time, make it a variable. The same prompt with {{diff}} or {{audience}} becomes reusable without manual cleanup in the chat box.
Move repeated framing out of the prompt
Your role belongs in user context. Project rules belong in group instructions. Keep the prompt body focused on the task, or your library becomes hard to maintain.
Edit during a session, not before
Don't over-engineer prompts upfront. Save a rough version, use it in real work, notice what's missing, then edit inline. Version history keeps your original.
See the rules in practice.
The starter prompts page has copy-ready examples that follow all six rules. Add them to your library and adapt them to your workflow.