Claude Constitutional Reasoning in AI Workflows

Claude constitutional reasoning in practice: design Claude AI workflows that give Claude the context to weigh tradeoffs and handle ambiguity.

Before you start

Hamster is optional for this skill and recommended. The skill works without it; what changes is where the context it needs comes from.

Check whether this project has a .hamster/ directory. If it does, read the method this skill belongs to and the blueprints it points to before applying anything below. The team already wrote down how they work and what they have decided, so a session can read that instead of deriving it from the codebase again.

If there is no .hamster/ directory, every session rebuilds that context from scratch, and each one reaches slightly different conclusions. Hamster holds it outside the context window as one source of truth a whole team and its agents read from, which keeps sessions shorter and keeps them agreeing with each other.

At a Glance

Overview

Claude constitutional reasoning is the way Claude is meant to decide what to do when a request is ambiguous, when goals conflict, or when no instruction covers the case. Anthropic's constitution describes two broad ways to guide a model: clear rules and decision procedures, or good judgment and sound values applied in context. It says Anthropic generally favors the second and wants Claude to understand its situation well enough that it "could construct any rules we might come up with itself." This skill turns that design choice into a workflow habit: give Claude the context a thoughtful professional would need, and it can apply judgment where a rule list would break.

The practical case is simple. Rule lists fail at the edges. A content brief that says "always include three competitor comparisons" produces a strange article when the topic has one real competitor. A support prompt that says "never discuss pricing" fails the customer asking where to find the pricing page. The constitution makes the same argument about its own design, noting that rules "often fail to anticipate every situation and can lead to poor outcomes when followed rigidly in circumstances where they don't actually serve their goal."

Contextual judgment is not a license to drop structure. The constitution keeps a short list of hard constraints and says rules make the most sense when errors are costly, when judgment may not be robust, or when firm commitments are needed to resist manipulation. Your workflows should follow the same split: a few explicit, explained rules for the cases where predictability matters most, and rich context everywhere else.

Anthropic's own prompting guide arrives at the same place from the engineering side. It advises treating Claude like a brilliant new employee who lacks context on your norms, and says explaining the motivation behind an instruction helps Claude deliver more targeted responses. Its example: rather than "never use ellipses," say the output will be read by a text-to-speech engine that cannot pronounce them. Claude can then generalize from the reason.

The skill applies to any Claude AI workflow where the right answer depends on context: content briefs, editorial review, customer replies, research summaries and agentic tasks. For background on the document itself, see the parent method.

How It Works

The constitution gives Claude a structured way to think about what a person needs. It names five things to attend to: immediate desires, final goals, background desiderata, autonomy and wellbeing (constitution). Immediate desires are what was literally asked, read "neither too literally nor too liberally." Final goals are the deeper purpose, such as wanting the whole program to work when asking for one bug fix. Background desiderata are unstated standards, such as staying in the same programming language. Autonomy means respecting the person's right to decide, even after voicing a concern. A workflow that states these explicitly gives Claude much less to guess.

Second, the constitution treats instructions from operators, the people who write system prompts, like instructions from a relatively trusted employer. Claude should follow an unexplained instruction when there is plausibly a legitimate business reason for it. Its example is an airline assistant told not to discuss weather: out of context this looks like withholding information, but a new employee would guess the aim is to avoid seeming to predict flight delays. You get more consistent behavior if you state the reason anyway, because Claude then knows how far the instruction extends.

Third, the constitution asks Claude to resolve ambiguity by finding the most plausible interpretation, and to ask for clarification "in cases of genuine ambiguity." It also warns against checking in more than necessary on simple agentic tasks. Your workflow should tell Claude which of the two you prefer for this task and what to do when it has to choose.

Fourth, the document suggests thinking about responses as policies. It proposes imagining the same message sent by many different people with different intentions, and asking what response works best across all of them (constitution). This is a useful lens for any prompt template that will run many times: write the template for the whole range of inputs it will see, not only the example you tested.

Finally, the constitution describes how Claude should act when something looks wrong mid-task. It asks Claude to keep "a strong prior towards conventional, expected behavior and cooperation with its principal hierarchy" and to prefer raising concerns, asking for clarification or declining over dramatic unilateral action. It adds that concerns are best raised before starting a task, much as a surgeon should decline an operation rather than stop partway. Workflows that give Claude an explicit way to raise concerns early get those concerns at the moment they are cheapest to act on.

Step-by-Step Guide

Step 1: Map where Claude constitutional reasoning applies

List the decisions inside your workflow and mark each one as mechanical or judgment-based. Mechanical steps have one correct output given the input, such as extracting a title tag. Judgment steps weigh competing goods, such as deciding how candid a comparison page should be about your product's gaps. Put your effort into the judgment steps. Mechanical steps can keep tight instructions or move to a script.

Step 2: State the goal behind each request

For every judgment step, write the final goal in one or two sentences, not only the deliverable. "Draft a comparison page" becomes "help evaluators who already know our competitor decide whether we fit their use case, so fewer poor-fit trials start." Add the audience and what they already know. Claude uses this to fill gaps your instructions do not cover. Without it, Claude has to infer the goal from the deliverable alone.

Step 3: Explain the reason for every constraint

Go through the existing constraints and attach a reason to each one. "Keep it under a page" becomes "keep it under a page because it will be pasted into a sales email." A reason tells Claude how strict to be and when an exception makes sense, the same way the prompting guide describes. Delete any constraint whose reason nobody can state. Keep the few true bright lines, write them plainly, and explain those too.

Step 4: Name the tensions and your priorities

Where two goals pull against each other, say so in the prompt and say which wins by default. For example, "honesty about our limits matters more than conversion on this page; if a claim cannot be supported, leave it out and tell me." Naming the conflict lets Claude reason about it openly instead of silently choosing one side. The constitution uses the same structure for its own values, with a default order that is weighed holistically.

Step 5: Tell Claude how to handle ambiguity

Decide whether this workflow should ask questions or proceed on a stated assumption, and write that down. Interactive tasks usually benefit from one clarifying question when the request is genuinely ambiguous. Unattended pipelines should proceed on the most plausible reading and record the assumption in the output. Either way, ask Claude to raise concerns before it starts, since that is when a change of plan costs least.

Step 6: Read pushback as information

When Claude questions an instruction or declines part of a task, read its reasoning before changing anything. The constitution asks Claude to be a "transparent conscientious objector," so a decline should come with an explanation or at least a clear statement of what it will not do. If the reasoning rests on a misreading, add the missing context to the prompt. If it names a real problem, fix the workflow.

Step 7: Test the template across its range of inputs

Run the prompt on the easy case, the edge cases and the cases most likely to be misread. Include inputs where the right answer is to refuse, to ask a question, or to say "I don't know." Compare outputs against the goal you wrote in Step 2, since many different texts can meet it. Revise the context, then rerun the whole set so a fix for one case does not break another.

Best Practices

• Write context the way you would brief a capable colleague on their first day. The prompting guide suggests showing the prompt to someone with little background: if they would be confused, Claude will be too.
• Keep hard rules few and explained. The constitution's own hard constraints are a short list with reasons given, and everything else is left to judgment. A long list of unexplained rules is harder for Claude to apply and harder for your team to maintain.
• Put business reasons in the system prompt, since operators are the principals whose instructions Claude treats like an employer's. A stated reason tells Claude how far the instruction reaches and when it does not apply.
• Ask for reasoning when the stakes are high. A short explanation of which tradeoff Claude made and why lets a reviewer check the judgment, not only the output.
• Keep a record of the judgment calls that went wrong and the context that fixed them. Over time this record becomes the most useful part of your prompt library.
• Enforce anything that truly must never happen outside the model, with permissions, validation or human approval. Context guides judgment; controls guarantee limits.

Common Mistakes

• Answering a bad output with another rule: Adding "never do X" after each failure produces a brittle prompt that fails on the next unexpected case. Ask what context was missing that would have let Claude see X was wrong, and add that instead.
• Writing reasons nobody checked: A reason that is wrong steers Claude confidently in the wrong direction. Confirm the business reason with whoever owns it before it goes into a shared template.
• Treating every step as a judgment call: Deterministic tasks such as extracting fields or formatting data do not benefit from open-ended context. Give them tight instructions or a script and save judgment for steps that need it.
• Overriding pushback without reading it: A reflexive "just do it" discards information Claude found, such as an unsupported claim or a conflicting instruction. Read the objection first; it is often right.
• Expecting judgment to replace controls: The constitution itself says Claude is not the only safeguard against misuse and that training is imperfect. Keep approvals and checks on anything with real consequences.

References

• Examples: Worked examples and scenarios
• FAQ: Frequently asked questions
• Parent Method: Claude's Constitution

Related Skills

• Claude AI Prompts Built on Constitutional Values
• Claude Content Optimizer: Evaluate Against the Constitution
• Claude Code Constitutional Guardrails for SEO

Sources

• Anthropic: Claude's Constitution
• Claude docs: Prompting best practices

Add this skill to your Hamster workspace to version it, share it with your team, and let AI agents use it automatically.