Constrained Generation Techniques
Word limits, format locks, and avoiding the most common ways constraints get ignored
Constraints are easy to state and easy to lose
You already know to add constraints to a prompt — word limits, tone rules, format requirements. The advanced skill is understanding why constraints get dropped under pressure from a complex task, and the specific techniques that make them stick.
Why constraints get ignored
When a task is complex enough that most of Claude’s “attention” goes toward getting the content right, constraints stated once at the top of a long prompt can lose priority — especially soft constraints like a word count, which don’t have a hard mechanical stop the way “respond only in French” does. The fix isn’t to state the constraint more forcefully once; it’s to reinforce it at the point where it’s most likely to be violated.
Word and length limits: state it twice
A word limit mentioned only in the setup is the single most commonly violated constraint. Restating it immediately before the output starts is far more effective than stating it once, however clearly.
Write a project status summary. Hard limit: 100 words. This is
a strict limit, not a target — count as you write and stop at 100.
[... rest of task context ...]
Remember: 100 words maximum. Write the summary now.Tip: For hard numeric limits, framing it as “a strict limit, not a target” measurably reduces overshoot compared to just stating the number — Claude tends to treat a bare number as a rough target unless told otherwise.
Format locks
If you need a specific format — no bullet points, no markdown headers, plain paragraphs only, exactly three sections — state the format as a constraint on its own, separate from the content instructions, and repeat it in the same “right before generation” position.
Format rules (follow exactly):
- Plain prose only, no bullet points, no headers
- Exactly 3 paragraphs
- No em dashes
- Do not start with "In today's world" or any similar generic openerCommon failure modes and their fixes
| Failure mode | Fix |
|---|---|
| Word/length limit ignored on complex tasks | Restate the limit immediately before the output, framed as strict not a target |
| Format constraint drifts on long output | Break the task into chunks (see Lesson 2 on chaining) so no single generation has to sustain the constraint too long |
| Banned phrase or word still appears | Give a negative example showing the actual banned phrase in context, not just naming it abstractly |
| Constraint conflicts with the content instructions | Check for a genuine conflict — e.g., “cover 5 points” plus “50 words” — and loosen one before blaming the model |
Watch for: Sometimes a “violated” constraint is actually an impossible one. Asking for five distinct, substantive points in fifty words is a contradiction — no amount of reinforcement fixes a prompt that’s asking for two incompatible things at once.
Testing constraint adherence
If a constraint genuinely matters (a legal disclaimer that must appear, a strict character limit for a platform), don’t assume compliance — check the actual output against the rule every time until you’ve built enough confidence in a specific prompt phrasing to trust it, and even then, spot-check periodically. This is where the self-critique loop from Lesson 6 pairs well with constrained generation: a critique pass whose only job is “does this violate any stated constraint?” is a cheap, effective safety net.
Check this draft against these constraints and list any violations:
1. Under 100 words? (state actual word count)
2. No bullet points?
3. No em dashes?
If all three pass, respond "PASS." If not, list what failed.Try it: Take a prompt with a word limit you’ve noticed gets ignored sometimes. Add the “strict limit, not a target” framing and restate it right before the generation point. Run it five times and count how often it holds.