06 — Prompting Best Practices — How You Ask Is What You Get

Treating the prompt as a wish and hoping was my prompting method, and the hopes came back half-met. Writing it down straightened out one idea: how you talk to the AI determines the quality of what comes back [1]. That isn't a platitude. It's a literal input-output relationship. The prompt is the spec the model implements, and a vague spec produces vague code the same way a vague ticket produces vague work from a human. The roadmap compresses the whole discipline into five rules, and they all trace back to that one idea.

The framing that clicked: the prompt is a specification, not a wish. When I write a ticket for a junior, I'm careful — scope, constraints, examples, what not to do. The AI deserves the same care, because it answers the spec literally.

One thing at a time

The first habit, and the one I keep relearning: ask for one thing per prompt. A prompt like "add auth, set up the database, build the dashboard, and style it" comes back as four half-done things, none of them right. The model allocates its attention across everything I asked for, and each piece gets a quarter of the effort.

The discipline: break the work into the smallest unit that produces a verifiable result, prompt for that, verify, then move on. "Add a login form that posts to /api/login and shows the error on failure" is one thing. "Build the whole auth flow" is four. The four single-thing prompts produce better total output than the one four-thing prompt, and each step is checkable before the next begins.

Be specific, and show examples

The second and third habits reinforce each other: be specific, and show examples [1]. Specificity means naming the exact behavior, the exact shape, the exact edge cases. "Handle errors" is not specific. "Return a 422 with { field, message } for validation errors and a 500 with { requestId } for server errors" is specific. The model fills unspecified gaps with its prior — and its prior is "the most common thing," which is rarely mine.

Examples are specificity's multiplier. The roadmap names them directly: _show examples_ [1]. A prompt with a sample input, a sample output, and a sample error is dramatically more likely to land than the same prompt in prose. This is the same reason mockups and screenshots matter in planning — concrete anchors tighten the model's output to my intent. When I have a reference, I paste it. When I don't, I sketch one.

Say what to avoid

The fourth habit is the one I most often forgot: tell the model what to avoid [1]. "Don't add new dependencies." "Don't touch files outside src/auth/." "Don't use any." Without these constraints, the model reaches for the path of least resistance, which often introduces churn — a new library, an edit somewhere unrelated, a loosened type. Negative constraints are cheap to state and prevent a class of rework that's annoying to unwind.

A useful pattern I keep: every build prompt ends with a short "avoid" list — three or four bullets specific to the task. It takes ten seconds and saves the most common form of drift.

The context document: don't repeat yourself

The fifth habit is the highest-leverage of all, and it took me longest to adopt: _use a context document so you don't repeat yourself every session_ [1]. Every fresh session starts with the model knowing nothing about my project. Without a context doc, I spend the first ten minutes re-explaining the stack, the conventions, the structure, the decisions — and the model still misses things I forgot to mention. With one, I paste a single file and the model is caught up.

A context doc is short. Mine is a few paragraphs:

PROJECT: habit-tracker
STACK: Next.js App Router, TypeScript strict, Tailwind, Supabase
STRUCTURE: app/[locale]/ for pages, lib/ for logic, store/ for Zustand slices
CONVENTIONS:
- Server Components by default; 'use client' only for interactivity
- Fetch from Supabase in Server Components; mutations via Server Actions
- No `any`; use unknown + type guards
CURRENT FOCUS: shipping the streaks feature (Phase 2)

This is the project's stable context — the stuff that doesn't change between sessions. The current focus line gets edited as I move; everything else stays. With it, each new session starts at "caught up" instead of "blank slate," and the model's first answer is already shaped by my project's actual decisions.

The roadmap points to a dedicated Prompt Engineering roadmap for going deeper [1][2], and the three approaches to shaping model output — retrieval, fine-tuning, and prompt engineering — are worth understanding as a spectrum [2]. For most app-level vibe coding, prompt engineering (with a context doc) is the right tier; the other two are heavier lifts for narrower gains.

How I use this

A short checklist before every build prompt: one thing only, specifics over wishes, a concrete example if I can make one, an "avoid" list of three or four constraints, and the context doc pasted at the top of any fresh session. The discipline is small; the payoff is that the first answer is usable far more often, and the loop converges in fewer turns. The thing I stopped doing: wishing at the model and being surprised when it answered the wish literally.

References

[1] roadmap.sh, "Prompting Best Practices," 2026. [Online]. Available: https://roadmap.sh/vibe-coding/prompting-best-practices

[2] roadmap.sh, "Prompt Engineering Roadmap," 2026. [Online]. Available: https://roadmap.sh/prompt-engineering