Prompt Design and Prompt Engineering
Specificity beats cleverness
Claude follows instructions literally, so underspecification is the dominant failure mode: vague verbs ("improve", "handle"), missing audience, missing length, missing output schema. State the task, the role and audience, the constraints, and the exact output format. Prefer positive instructions ("respond in prose under 100 words") over negative ones ("don't be verbose") - models reason poorly about absence.
Structure and separation
Use XML-style tags to delineate regions: instructions, document, examples. This is not cosmetic; it keeps the model from treating retrieved text as instructions and is a first line of defense against prompt injection. Multi-shot examples are the strongest single lever on format and tone - two or three well-chosen examples usually beat paragraphs of description. Inconsistent examples teach nothing.
Reasoning and prefill
For multi-step problems, ask for reasoning before the answer, or enable extended thinking with an explicit token budget rather than begging "think step by step." Where assistant prefill is used, it can force format or steer past preamble.
Ordering long context
When a prompt carries a large document, place the long data first and the question plus instructions last. Recall degrades for material buried in the middle of very long inputs. Narrow the window with retrieval instead of assuming more context is always better; irrelevant context dilutes attention and raises cost.
Rule of thumb
When a prompt fails, first ask whether a competent new hire could follow it unaided. If not, the prompt - not the model - is the bug.