Degrees of Freedom

What is Degrees of Freedom, and why can't the same task always be written the same way?

Degrees of freedom refers to a decision made when writing instructions — whether a one-off prompt or documentation written into a Skill — about how explicit and rigid the guidance to Claude should be, versus giving a general direction and letting it judge the details itself. This isn't a matter of gut feeling; it should map to the actual nature of the task. Some tasks have only one correct way to do them, with real consequences for getting it wrong (a database migration that must run in a specific exact sequence). Others have many equally valid approaches where success can come from different directions (code review, where different angles of scrutiny can each catch valid issues).

Writing every task with the same "more detail is always better" approach actually creates problems: an error-tolerant task written too rigidly prevents Claude from flexibly adapting to the situation at hand, often producing a worse result than if it had been trusted to judge; a low-tolerance task given only vague direction risks real damage from a skipped step or wrong sequence.

Why is Degrees of Freedom needed, and what problem does it solve?

Without consciously recognizing this concept, many people writing instructions or Skills tend to fall into one of two extremes. One is writing every task with extreme detail regardless of its nature — the result is that considerable effort goes into instructions that, when applied to an error-tolerant task, end up boxing Claude in and wasting the judgment capability it already has. The other is giving only brief direction regardless of the task — the result is that when applied to a task genuinely requiring precise steps, a critical step gets skipped or done in the wrong order, causing real damage.

Degrees of freedom solves exactly the problem of "how do I decide how detailed to write this." It provides a decision framework: before writing, the author asks themselves "does this task tolerate multiple approaches all counting as success, or is there only one correct path," and decides how specific the instructions should be based on that answer. This turns "how detailed should this be" from a gut-feeling choice into a decision with a clear criterion to follow.

How does Degrees of Freedom actually work, and what specific levels does it break into?

This concept is typically split into three levels. High freedom fits tasks where "multiple approaches are all valid and judgment needs to adapt to context" — written as text describing a general direction, such as an instruction like "analyze code structure, check for potential bugs, suggest readability improvements," with no need to dictate an exact checking order. Medium freedom fits tasks with "a preferred approach but room for some variation" — written as example code or a process with parameters, letting the user adjust parameters based on the situation rather than copying it verbatim. Low freedom fits tasks that are "error-prone and must maintain consistency" — written as a precise instruction that shouldn't be altered, such as "run exactly this script: python scripts/migrate.py --verify --backup — do not modify the command or add additional flags."

Deciding which level to use can be understood through an analogy: imagine Claude walking along a path. If the path is a narrow bridge over a cliff with only one safe way forward, give it precise guardrails and exact instructions (low freedom). If the path is an open, flat field where many directions all reach the destination, give it general direction and trust it to find its own way (high freedom).

What does Degrees of Freedom actually mean for me, and how do I apply it when writing instructions or a Skill?

Before writing a set of instructions or a Skill, ask yourself one question: "if two people each followed this description and got different results, would both count as acceptable?" If the answer is "yes, as long as they hit the key point, different approaches could both work," this is a high-freedom task — give general direction and don't nail down every step. If the answer is "no, there's only one correct way, and getting a step wrong causes real problems," this is a low-freedom task — every step should be written precisely, with no room for ambiguity.

In practice, a single Skill often contains content at different freedom levels at once — the overall workflow might be high freedom (letting Claude judge the sequence itself), while one particular step involving a database operation needs precise, low-freedom instructions. There's no need to apply the same freedom level uniformly across an entire Skill; judging each sub-task separately usually produces instructions closer to what's actually needed than applying one style across the board.