The short version

Older prompting patterns sometimes began Claude’s answer in advance: an opening brace for JSON, a label such as “Summary,” or the first words of a continuation. Current Claude guidance recommends stating the required output directly. For current models that do not support a prefilled final assistant turn, the requirement must live in the prompt or a structured-output mechanism.

Describe the contract

An output contract makes implicit steering explicit. Define:

  • Shape: the fields, sections, or schema the response must contain.
  • Values: allowed labels, types, or enumerations.
  • Order: the sequence in which information should appear.
  • Boundaries: length limits, prohibited additions, and optional fields.
  • Opening: whether Claude should respond directly, use a named first line, or continue from supplied text.

This is easier to inspect and maintain than relying on a fragment at the start of the response.

Example

Instead of beginning Claude’s response with part of a JSON object, ask:

Return exactly one JSON object with the fields category, priority, and reason. category must be Access, Data, Reporting, or Other. priority must be Low, Medium, or High. Include no prose before or after the object.

For a production workflow, prefer a genuine schema or tool definition when machine-valid structure is essential. Prompt-only formatting can be effective, but a schema gives the surrounding application a stronger contract.

Three common migrations

Formatting: Replace a seeded brace, YAML header, or label with explicit fields and valid values.

No preamble: Say “Respond directly without a preamble” and describe the desired first section. If strict machine output is needed, validate it outside the model.

Continuation: Put the end of the interrupted response in the next user message and tell Claude to continue from that point. This keeps the conversation roles valid and makes the continuation context visible.

Why this improves systems

Explicit requirements are testable. A team can compare the result with a schema, log validation failures, and update one documented contract when a downstream consumer changes. A hidden starting fragment is easier to overlook and may fail differently across model versions.

The contract should still allow appropriate flexibility. Define only constraints the consumer actually needs. Over-specifying punctuation or prose can make natural answers less useful without adding reliability.

Practical checklist

  • Move formatting requirements into the user or system instruction.
  • Name every required field and allowed value.
  • State whether extra prose is allowed.
  • Use structured outputs for strict machine consumption.
  • Provide interrupted text in the user turn for continuations.
  • Validate the result before a downstream action depends on it.

Try it

Find one prompt that relies on Claude starting with a particular label or character. Rewrite it as a complete output contract, then decide whether prompt instructions or a formal schema provides the right level of assurance.