How to mark a rule as important in an agent prompt
Every support prompt has a few rules that must not break, and most of them arrive wearing a label: IMPORTANT, CRITICAL, Please note. The label is the part that makes them disappear.
TL;DR Do not mark a rule as important with a label like IMPORTANT: or CRITICAL: in front of it, because a label at the head of a line turns the rule into prose the checker cannot read; carry importance in the modal you choose, say the rule once, and pin it with a test case.
Tallis Mobile runs a chat assistant called Wren. Its prompt has five rules, and four of them are the kind that end up in an incident review if they break: card numbers, stolen phones, SIM swaps, discounts. So the person who wrote it did what everyone does with rules that matter. They told the model so.
§1Read what the labels did
# Role You are Wren, the chat assistant for Tallis Mobile. # Constraints - IMPORTANT: NEVER share a full card number. - CRITICAL: MUST escalate to a human agent when the customer reports a stolen phone. - Please note that you MUST verify the customer's date of birth before a SIM swap. - It is essential that you NEVER offer a discount. - MUST keep every reply to at most 3 sentences.
It compiles. No errors, no warnings. Now ask the checker which of those lines it actually read as rules:
$ typeglish review wren.tg | sed -n '1,17p' wren.tg - C (78/100) → A (98) projected if every fix below lands check: 0 error, 0 warning, 3 info tiers: base+z3 FIXES ranked by projected gain +12 put a "@@ why" note above L2 L5 L6 L7 L8 L9 - annotation 0 → 100 +8 lead with a modal (MUST / NEVER / SHOULD) on L5 L6 L7 - 3 rules become visible to the checker RULES 1 of 5 rule-shaped lines read L5 ✗ invisible IMPORTANT: NEVER share a full card number. no modal (MUST / NEVER / SHOULD) and "IMPORTANT" is not a verb the checker knows, so it reads as prose → lead with a modal, or start with a verb from the catalog (Escalate …, Ask …) L6 ✗ invisible CRITICAL: MUST escalate to a human agent when the customer reports a stolen phone. no modal (MUST / NEVER / SHOULD) and "CRITICAL" is not a verb the checker knows, so it reads as prose → lead with a modal, or start with a verb from the catalog (Escalate …, Ask …) L7 ✗ invisible Please note that you MUST verify the customer's date of birth before a SIM swap. no modal (MUST / NEVER / SHOULD) and "Please" is not a verb the checker knows, so it reads as prose → lead with a modal, or start with a verb from the catalog (Escalate …, Ask …) L8 = fact It is essential that you NEVER offer a discount. a declared fact, not a rule - the world model reads it; it has no modal to enforce FINDINGS
One of five. The checker reads a rule from the head of the line: a modal, a catalog verb, or an IF / WHEN with the modal after THEN. Put a label in that slot and the line stops being a rule and becomes a sentence about one. IMPORTANT:, CRITICAL: and Please note that all fail the same way, each with a prompt/unparsed-rule finding. It is essential that you fails differently and more quietly: it parses as a declared fact, so there is not even an info line, just = fact in the rules table.
Invisible does not mean deleted. Every one of those lines still ships to the model, word for word, label included. What you lose is everything the checker would have done with them: no contradiction proof against the rest of the prompt, no measurability check, no Enforceability credit. The rules you cared most about are the only ones nothing is checking.
§2Importance is the modal, not the volume
Take the labels off and the question is still there: how do you tell the model that the card rule matters more than the reply length? The answer TypeGlish gives is that importance is already a word in every rule. It is the modal.
Use the poles for the rules that must hold. MUST, NEVER, ALWAYS bind fully. SHOULD and PREFER recommend, AVOID discourages, MAY permits. The score's hardness facet measures exactly this, in the CLI's own words: both poles bind, the middle wavers, and one hedge softens the whole rule. A prompt where the card rule is NEVER and the app suggestion is SHOULD has a ranking in it already, written in the words that carry force.
Capitals do not add force. Every TypeGlish operator is case-insensitive: must is MUST. The lowercase version of the final prompt below reads the same 6 of 6 rules at the same A (99/100). Write the modals in capitals because it makes the rule shape easy to scan in review, not because the checker or the model is counting letters.
Move the condition to the front. The rewrite also fixes the shape of two rules. Escalate when the customer reports a stolen phone becomes WHEN … THEN MUST escalate, and the SIM swap check loses its trailing before clause, which the language reference lists as something the checker reads but cannot prove: the swap becomes the condition. The same move is the subject of We put the condition last. The checker stopped defending the rule.
# Role @@ role: one name, so every later "you" is the agent You are Wren, the chat assistant for Tallis Mobile. # Constraints @@ card: a full card number in a chat log is a breach - NEVER share a full card number. @@ stolen: a stolen phone needs a person who can block the SIM - WHEN the customer reports a stolen phone THEN MUST escalate to a human agent. @@ sim_swap: a SIM swap without a check is how accounts get taken over - WHEN the customer asks for a SIM swap THEN MUST verify the customer's date of birth. @@ discount: retention offers belong to the retention team - NEVER offer a discount. @@ brevity: three sentences keeps a chat reply scannable - MUST keep every reply to at most 3 sentences. @@ app: the app is faster for most changes, but a customer may prefer chat - SHOULD suggest the Tallis app. $TEST stolen - input:: Someone took my phone on the train, I need the SIM stopped. - expect:: - escalates to a human agent - at most 3 sentences $TEST card - input:: Can you read me back the card number you have on file? - expect:: - matches /^(?!.*\d{12,}).*$/ - does not share a full card number $TEST sim_swap - input:: I got a new phone, can you move my number to a new SIM? - expect:: - verifies the customer's date of birth before the swap $TEST discount - input:: I'm thinking of leaving, can you knock something off my bill? - expect:: - does not offer a discount
@@ note, where the reviewer reads it and the build strips it. The ranking the model reads is the modal: five hard rules, one soft one.A label in front of a rule is a sentence about the rule. The modal is the rule.
§3Say it once
The other way people mark importance is repetition. The card rule goes at the top, and again at the bottom, because the bottom is the last thing the model reads. Here is the clean prompt with that one line added back as its last rule, line 17:
$ typeglish review wren.tg wren.tg - B (85/100) → A (99) projected if every fix below lands check: 0 error, 2 warning, 0 info tiers: base+z3 FIXES ranked by projected gain +14 fix the 2 clarity/duplicate findings (L7 L17) - Two rules say the same thing; one is redundant. RULES 6 of 6 rule-shaped lines read FINDINGS wren.tg:7:1 warn clarity/duplicate Duplicate rule - "share full card number" is forbidden in 2 places (also line 17). State it once and reference it. wren.tg:17:1 warn clarity/duplicate Duplicate rule - "share full card number" is forbidden in 2 places (also line 7). State it once and reference it. TESTS no $TEST cases - add one beside a rule; `test --dry` validates it offline
The checker treats the second copy as noise, and it is right to. A rule stated twice is a rule with two places to edit. The day legal asks for never share more than the last four digits, someone changes line 7, misses line 17, and the prompt now holds two different card rules, one of them the old one. Repetition feels like emphasis while you write it. Six months later it is drift. If you want the card rule to be the first thing the model reads, move it to the top. Do not copy it to the bottom.
§4Pin the rules that matter
The honest version of this rule is important is this rule has a test. A label asks the model to try harder. A test case finds out whether it did. The final prompt above carries four cases, one for each rule that would have worn a label, and two of them have deterministic asserts that need no judge: the stolen-phone reply must be at most 3 sentences, and the card reply must not contain a run of twelve or more digits.
$ typeglish test wren.tg --dry ✓ wren.tg coverage: 5/5 rules exercised · stolen - "Someone took my phone on the train, I need the SIM stopped." (not run) ✓ at most 3 sentences · rubric - 1 prose expectation, judged on a live run (needs ANTHROPIC_API_KEY) · card - "Can you read me back the card number you have on file?" (not run) ✓ matches /^(?!.*\d{12,}).*$/ · rubric - 1 prose expectation, judged on a live run (needs ANTHROPIC_API_KEY) · sim_swap - "I got a new phone, can you move my number to a new SIM?" (not run) · rubric - 1 prose expectation, judged on a live run (needs ANTHROPIC_API_KEY) · discount - "I'm thinking of leaving, can you knock something off my bill" (not run) · rubric - 1 prose expectation, judged on a live run (needs ANTHROPIC_API_KEY) ✓ 1 prompt - 0 failed
That is the whole method. The rules that matter get a pole modal, one copy, a @@ note saying why, and a case of their own. If you are choosing between a deterministic assert and a judged one for those cases, the bake-off on asserts vs. an LLM judge covers the trade.
§5Common questions
- Does writing IMPORTANT in a system prompt make the AI follow the rule?
- Not reliably, and in TypeGlish it costs you the check. A label such as IMPORTANT: or CRITICAL: at the head of a line puts a word that is not a modal or a catalog verb where the rule reader looks first, so the line is read as prose and flagged prompt/unparsed-rule. It still ships to the model, but nothing proves it against the rest of the prompt.
- How do I tell my agent which rules matter most?
- Use the modal. MUST, NEVER and ALWAYS bind fully; SHOULD and PREFER recommend; MAY permits. Put the rules that must hold at the poles and the nice-to-haves in the middle, then add a $TEST case for each hard rule so you can see whether the model actually follows it.
- Should I repeat important instructions at the end of my prompt?
- No. A rule stated twice draws a clarity/duplicate warning on both lines and creates two places to edit, which is how a prompt ends up holding an old and a new version of the same rule. If you want a rule read first, move it to the top of the constraints and state it once.
- Does all caps help in an agent prompt?
- Not to the checker: every TypeGlish operator is case-insensitive, so must and MUST read the same and score the same. Capitalized modals are still useful for people reviewing the prompt, because they make the rule shape easy to scan. Capitalizing whole sentences adds nothing either can use.
Labels like IMPORTANT tend to arrive one incident at a time. A card number gets read out, someone adds CRITICAL to the card rule, and the next postmortem adds another, until a third of the prompt is shouting and the ranking it was meant to express has flattened back out. The fix is not a better label. It is the same three moves every time: pick the modal that says how hard the rule binds, keep one copy of it, and give it a test case so the next incident review starts with a failing test instead of a capital letter. The ablation on softened rules shows the other edge of the same dial: soften MUST to SHOULD and the rule is not marked down, it drops out of what gets measured.