Making the Output Contract Explicit

A request has substance and shape. People write only the substance, so the shape comes out at its default. And the shape does not move when you turn the thinking knob — making the model think less is not the same operation as making it say less.

Problem

When you write "fix this function," you say what you want done. You do not say how you want it returned. Yet whatever comes back has a shape — how many lines of explanation accompany it, how much it narrates while working, how many pages the document it writes runs to, and when it announces a correction to something it said a moment ago. Because you did not write them, all of those are decided by defaults.

Defaults are not bad. But a default is a single point that the tool's authors judged reasonable for most users. It was not fitted to the task in front of you. Some situations need a long explanation; others need only the conclusion. The shape that comes out is the same either way.

And the first knob most people reach for is the wrong one. They read "the answer is too long" as "it is thinking too much" and lower the thinking effort. But the official documentation is explicit that effort controls how much the model thinks, not how much it says — it goes as far as stating that lowering effort does not reliably shorten the visible response (Official, Anthropic; source in the practice section). That operation can therefore lower quality while leaving the length intact.

If you want it shorter, the only way is to say so.

Context

Apply when:

• A human reads the output, or a downstream step consumes it — somebody is paying for the mismatch in shape
• You run the tool for a long stretch — without a defined granularity for progress, you miss the moment worth interrupting
• Deliverables persist as files — conversation flows past, but a written document stays and costs its readers time on every read

Do not apply when:

• The defaults are not causing trouble. A shape specification is resident context too; it starts charging rent the moment you write it. If nothing hurts, there is no reason to pay
• Cutting explanation would break the work. "Be concise" can cut away the room to state reasons. Brevity can be traded against the justification for a judgment
• The shape is machine-checkable. If the output format can be verified mechanically, put it in a gate rather than in the request (see Separating Mechanical Gates from Semantic Gates)

Boundaries with adjacent patterns:

• Matching Thinking Depth to the Task — that pattern governs how much it thinks; this one governs how much it says. Within what could be verified, only the Anthropic side states that these are separate knobs; the GitHub-side material contains no such distinction (Official and Absence Confirmed; the range checked is in the practice section)
• Instruction Layering and Scoping — that pattern governs which layer the shape contract belongs in. This is not decoration: the github.com documentation names response style as a use for the personal layer, while warning that the same kind of instruction may cause problems in the layer of a large and diverse repository (Official, github.com; source in the practice section)
• Resident Context Inventory — a shape contract is resident context as well. Counting the rent you added is that pattern's job
• Rules Ranked by Binding Force — that pattern decides how much binding force the contract carries
• Diff Review and Incremental Adoption — that pattern is about how you receive what comes out; this one specifies the shape before it comes out

Solution

Why does it work? Because shape is part of the request and yet never appears in the request. Substance is written, so it comes out as specified. Shape is not written, so it comes out at the default. That asymmetry is the whole of the problem. The remedy is plain: write the layer that goes unwritten.

The primary source names four faces by example — the length of conversational responses, the frequency and form of progress updates during work, the length of documents written to disk, and the threshold at which the model announces a correction to its own earlier statement. The last is easy to overlook. Correction itself is good, but narrating every correction that changes nothing for the user is padding and nothing else (Official, Anthropic; source in the practice section).

There is a direction to how you write it. Positive examples of the shape you want tend to work better than a list of prohibitions, as the documentation states (Official, Anthropic; source in the practice section). "Don't be verbose" does not settle where verbose begins. "Lead with the outcome in your first sentence, and put the detail after it" does. A prohibition only narrows the space; an example supplies coordinates.

And one more. Put the shape contract in the wrong layer and it does not merely fail — it can do harm. The github.com documentation lists response style as a use for the personal layer, while warning that the same kind of instruction may cause problems in the layer of a large and diverse repository, naming a character-limit instruction among examples that "may not have the intended results" (Official, github.com; source in the practice section). This is coherent: "answer in under 1000 characters" holds up as one person's preference but not as a rule binding every contributor and every use of a repository. Where a shape contract belongs depends on whose preference it is.

Trade-offs

Benefits

• You can tighten output without paying in quality. You no longer buy shorter answers with reduced thinking. That these are separate knobs is stated in the documentation (Official, Anthropic; source in the practice section)
• Fixing the grain of progress fixes the point of intervention. If it is settled where reports arrive, a human can stop there. If it is not, reports are either too many or too late
• It can be inventoried later. A shape specification is concrete, so you can decide to delete it once it is no longer needed

Costs

• A contract is resident context. It starts charging rent the moment you write it. Stack all four faces and you dilute every other instruction by that much. This is in direct tension with Resident Context Inventory
• Compliance is not guaranteed. The github.com documentation states plainly that, given the non-deterministic nature of AI, custom instructions may not be followed in exactly the same way every time (Official, github.com; source in the practice section). Calling shape a "contract" is a metaphor; there is no enforcement
• ⚠ The wrong layer walks into territory the documentation warns about. Instructions about response style or level of detail are named as potentially problematic in the layer of a large and diverse repository (Official, github.com; source in the practice section). This pattern does not say "always write it somewhere." Decide whose preference it is, then place it
• Brevity trades against justification. "Shorter" compresses explanation; it does not improve the quality of the judgment. When reasons get cut on hard problems, the reviewer pays.

GitHub Copilot in Practice

Of the four faces, only one has a confirmed official counterpart on the GitHub side. For the remaining three — progress updates, written deliverable length, and the correction threshold — no description was found within the range checked, and only the Anthropic side documents them. This gap is shown rather than smoothed over.

github.com — response style is named as a use for the personal layer

Source: About customizing Copilot responses (retrieved 2026-07-26; full text retrieved and searched) Official:

Personal instructions apply to all conversations you have with Copilot Chat across the GitHub website. They allow you to specify your individual preferences, such as preferred language or response style, ensuring that the responses are tailored to your personal needs.

Note the range — the original concerns Copilot Chat on github.com, and it makes this statement while describing personal instructions specifically. That is the layer in which specifying response style is officially named.

github.com — but the documentation warns about the same instruction in the repository layer

From later in the same page Official:

You should also consider the size and complexity of your repository. The following types of instructions may work for a small repository with only a few contributors, but for a large and diverse repository, these may cause problems:

• Requests to refer to external resources when formulating a response
• Instructions to answer in a particular style
• Requests to always respond with a certain level of detail

It goes on to give this as an example of an instruction that may not have the intended results Official:

Answer all questions in less than 1000 characters, and words of no more than 12 characters.

What matters here is that the two statements do not contradict each other. The first concerns the personal layer, the second the repository layer, and the same specification is right in one and wrong in the other. This is exactly where Instruction Layering and Scoping intersects.

The same page is also explicit about compliance Official:

Due to the non-deterministic nature of AI, Copilot may not always follow your custom instructions in exactly the same way every time they are used.

VS Code — the thinking knob is documented only as a thinking knob

Source: Language models (retrieved 2026-07-26; full text retrieved and searched) Official:

Some models support configurable thinking effort, which controls how much reasoning the model applies to each request.

What the original connects is thinking effort → amount of reasoning, not the length of the visible response.

Absence Confirmed — the range checked, stated explicitly. On 2026-07-26 the full text of Language models (109,455 bytes), Optimize agent usage (62,889 bytes), and About customizing Copilot responses (892,478 bytes) was retrieved, tags were stripped, and the body was searched for visible response, response length, how much it says, verbosity, progress update, and conciseness. All returned zero hits (thinking effort returns 9 hits in Language models, so the search itself works).

In other words, the GitHub side does not document the distinction that lowering thinking effort will not reliably shorten the visible response. This is not "the documentation denies it" but "there is no description." Only the Anthropic side, below, states the distinction, and this catalog treats that as one vendor's Official.

Anthropic — the side that names all four faces

Source: Prompting Claude Opus 5 (retrieved 2026-07-26; raw markdown retrieved and searched) Official. The original names Claude Opus 5; it is not a general rule across all models and tools.

Thinking versus saying — the Response length and verbosity section:

lowering effort can reduce thinking volume without reliably shortening the visible response. To control response length, prompt for it explicitly.

How to write progress guidance — the User-facing progress updates section:

Positive examples of the communication style you want tend to be more effective than instructions about what not to do.

Written deliverable length — the Written deliverable length section, given in a form usable directly as an instruction:

Match the length of written documents to what the task needs: cover the substance, but do not pad with filler sections, redundant summaries, or boilerplate.

The correction threshold — the Self-correction section:

Only correct an earlier statement when the error would change the user's code, conclusions, or decisions.

Faces and where they are documented

Face of output	GitHub side	Anthropic side
Response length and style	Official github.com (named for the personal layer; cautioned for the repository layer)	Official
Progress update frequency and form	Absence Confirmed (search terms and range above)	Official
Written deliverable length	Absence Confirmed (same)	Official
Threshold for announcing corrections	Absence Confirmed (same)	Official
Thinking volume being separate from response length	Absence Confirmed (same)	Official

How to read this table: the cells say Absence Confirmed rather than being left blank because the range searched must be stated. It does not mean "GitHub lacks this capability" — it means only that no description was found within the material checked.

Also Known As

Name	Source
Response style / custom instructions	Primary — but this names the mechanism, not this pattern (source in the practice section)
Conciseness instruction	Primary — the Anthropic side's name for an instruction about response brevity. It names one of the four faces only
Making the Output Contract Explicit	Descriptive — this catalog's descriptive name; no primary source uses it

Primary sources give names to the container (custom instructions) and to individual faces (response style, conciseness). The whole — that shape is part of the request, and defaults fill it in when you do not specify it — has no established name within what could be verified. Using the name of one face as the name of the pattern drops the other three out of view. The name was therefore given to the structure that holds the faces together, not to a face.

Related

• Matching Thinking Depth to the Task — the adjacent, different knob. How much it thinks belongs there; how much it says belongs here, and turning one does not reliably move the other. This is the first page to read when you are tempted to buy shorter answers with less thinking
• Instruction Layering and Scoping — which layer the shape contract belongs in. Given that the documentation says different things about the personal and repository layers, placement is part of this pattern
• Resident Context Inventory — a shape contract pays rent too. Before stacking all four faces, count what is already resident
• Rules Ranked by Binding Force — decides whether the contract is a "must" or a "if you can"
• Diff Review and Incremental Adoption — how to receive what comes out. This pattern is the side that settles the shape before receiving it
• Recording by Provenance — specifying output shape does not say whether its content is fact, a source claim, or an inference. That pattern preserves the attribution
• Read next: Matching Thinking Depth to the Task — without the distinction between the two knobs, either one you turn will miss