Prompting Cheatsheet
The four parts of a good prompt
- Intent: what you want, and why (the why powers good guesses)
- Constraints: must / must not ("one HTML file", "don't change the design")
- Acceptance criteria: what done looks like, concretely
- Example: one sample input → expected output beats paragraphs
Patterns that work
| Instead of | Try |
|---|---|
| "add tests" | "write a test covering [specific scenario]; run it and show me the output" |
| "fix the bug" | "[exact symptom + screenshot/error]. Find the cause and explain it before fixing anything" |
| "make it look better" | "[paste screenshot] match this; then screenshot the result and list the differences" |
| "add feature X" | "add X. It should [criteria]. Don't change [thing you care about]. Show me it working" |
| "is this code okay?" | "review this as a [security auditor / picky senior dev]; report problems ranked by severity" |
Prompt-ending phrases worth making reflexive
- "…and show me the evidence."
- "…explain the cause before fixing anything."
- "…ask me questions before you start if anything is ambiguous."
- "…keep the change as small as possible."
The big-feature move
Two commands package this whole conversation:
/office-hours, when the idea needs interrogating: pitch it and take the hard questions (who's it for? what's the smallest version?)/spec, when you're ready to decide: it interviews you into a precise, buildable specification. Whole system in waterfall; just this session's slice in agile, spec the slice, not the system
Then start a fresh session to build from the spec. (No-tools fallback, works anywhere: "I want to build [X]. Interview me about it, requirements, edge cases, what's in and out of scope. One question at a time. Don't ask obvious questions.")
Mode guide
- One-sentence change → just ask
- Anything bigger / vaguer / scarier → plan mode first (
Shift+Tab), read the plan, correct it, then approve - Corrected the same thing twice? → revert,
/clear, one better prompt that includes what the failures taught you