> Markdown rendition of https://typeglish.dev/blog/mark-rule-important ("How to mark a rule as important in an agent prompt - Tidelines"). Canonical page: https://typeglish.dev/blog/mark-rule-important · All pages: https://typeglish.dev/llms.txt [← Tidelines](https://typeglish.dev/blog)/ Guides Oct 4, 2026 # 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. by **TypeGlish team** 7 min read #guides Louder is not harder. **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. ## §1 Read what the labels did wren.tg - the rules that matter, marked as important ✓ compiles ```typeglish # 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. ``` Five rules, four of them flagged as the ones that matter most. The fifth is about reply length. It compiles. No errors, no warnings. Now ask the checker which of those lines it actually read as rules: tg review - wren.tg ✗ 1 of 5 read ``` $ 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 ``` The one rule the checker can see is the one nobody thought was important. 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. ## §2 Importance 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.](https://typeglish.dev/blog/condition-last-ablation) wren.tg - no labels, one ranking ✓ A (99/100) ```typeglish # 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 ``` The reason a rule matters goes in its `@@` 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. ## §3 Say 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: tg review - the card rule, said twice ⚠ B (85/100) ``` $ 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 ``` Fourteen points for one repeated line, and a warning on both copies. 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. ## §4 Pin 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. tg test --dry - wren.tg ✓ 5/5 rules exercised ``` $ 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 ``` Coverage counts five rules, not six; the soft app suggestion is not in the count, and no case mentions it. A case covers a rule when its expectations share the rule's wording, so 5/5 says every counted rule has a case that talks about it. The live run says whether the model listened. 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](https://typeglish.dev/blog/test-asserts-vs-judge) covers the trade. ## §5 Common 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. Field note 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](https://typeglish.dev/blog/deontic-force-ablation) 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. ∿ washed up Oct 4, 2026 ∿