CORE GUIDE

PRACTICEFOUNDATION7 min read

Prompt specificity

Prompt specificity makes the task, constraints, output contract and success criteria concrete enough that the model does not have to invent important requirements from vague language.

Mental model

Think of specificity as reducing the size of the acceptable-behavior space. A prompt should make the decision boundary clearer without trying to enumerate every possible sentence the model may produce.

Why it matters

Vague prompts create hidden product decisions inside the model: what counts as complete, which source should win, what format is valid, and when to ask for clarification. Specificity moves those choices into an inspectable contract while still leaving room for the model to solve the task.

01

Specify decisions, constraints and observable acceptance

State the task outcome first, then identify non-negotiable constraints, relevant context, output structure and evidence requirements. Use examples only when they clarify a boundary that prose cannot express cleanly. If a requirement can be checked by code or a reviewer, phrase it so the check is observable rather than relying on adjectives such as good, careful or comprehensive.

02

Example: 'summarize this contract' hides the real decision

A legal assistant is asked to 'summarize this contract'. Different runs emphasize different clauses because the prompt never says who the reader is or which risks matter. The revised request asks for renewal date, termination window, payment obligations and unusual liability terms, with source section references and an explicit 'not found' state. Variation remains, but the important decision surface is now bounded.

Common failure modes

  • Adding many words without clarifying any decision boundary.
  • Encoding every possible edge case in the prompt until the instruction becomes unreadable.
  • Using examples that accidentally override the actual policy or output contract.

Engineering heuristics

  • Specify the user-visible decision or artifact before stylistic preferences.
  • Turn critical requirements into observable fields, checks or refusal conditions.
  • Use clarification when a required fact is genuinely missing instead of guessing.

Takeaways

  1. 01Specificity reduces hidden requirements the model must infer.
  2. 02A specific prompt defines boundaries without prescribing every token.
  3. 03Observable acceptance criteria are stronger than persuasive adjectives.

Reading evidence

UnseenPractice not completed

This records actions you actually took; it does not claim mastery, proficiency, or certification.

Used in

This Concept is reused across these canonical learning paths.

Related concepts from the Knowledge Graph

These relationships come from the canonical graph, not a separate Guide taxonomy.