This is article 5 in the series "The Art of Not Telling." It lays out symptoms that go wrong and their remedies, one at a time. Each article is finished once you put down a single file or script. Why that mechanism is needed becomes clear when you read the explanation afterward. The whole picture and the list of articles are in the introduction.

This time it is emphasis. Bold, ⚠️, the word "always," and the important line moved to the top. Inside my instruction file, the more I wanted a line honored, the more strongly I wrote it.

In the introduction to the previous series, "The Art of Not Reading," I wrote that rules dilute as you add them, and that adding one is making every other one a little weaker. The same thing happens with emphasis.

Start by counting just one thing.

What to count is how many lines in your instruction file (CLAUDE.md, AGENTS.md) hold bold, ⚠️, or the phrases "always," "absolutely," "most important."

Of those, how many are lines that make something fail when they are broken?

CC BY 4.0

The section I wrote most strongly had the thinnest machinery

The instruction file for the production project on my own machine (typingtube, a web service for practicing typing along with music videos on YouTube) is 102 lines, or 69 with the blank lines and the headings taken out. 7 of them held emphasis.

Before I counted, I took it that the emphasis sat where I really thought it mattered.

In fact it was not so. For 5 of those 7 lines, machinery is holding the same thing. By machinery I mean a mechanism that works whether or not it is read, such as a hook or an automated test.

  • The syntax check on the translation files (a pre-commit hook runs it)
  • The design ratchet (a pre-commit hook fails on it)
  • The guard on starting a subagent, 2 lines (nothing starts unless it is in the catalog of missions)
  • The parallel guard on the tests (the 2nd run in parallel does not start)

Break one and it is not the emphasis that stops you. The hook stops you.

The remaining 2 lines are the one section in this instruction file that calls itself "most important": the rule that you do not run Ruby or Node commands directly on the host, that everything goes through the container. There is no machinery here. Running the tests is the one entrance I have blocked, but for bundle, npm and rake alike there is nothing in place that stops them.

So: the section I wrote most strongly is the one with the thinnest machinery.

Whether it is working cannot be measured

Let me be honest. That section has not been broken. I run through the container, and so does the AI.

That still does not let me say the emphasis worked. In article 6 of the previous series I wrote this: pick the 1 prohibition in your instruction file that matters most, and can you say how many times it was broken last month? Not being able to say is normal, because nothing happens when it is broken.

Emphasis is the same. Whether it went unbroken because the emphasis worked, or whether the moment to break it never came at all, I cannot tell the two apart.

And with something you cannot tell apart, adding more or taking some away makes no visible difference. Because nothing shows, it grows.

What growth leads to is what the introduction to the previous series described. You reorganize the rules, give them priorities, and move the important ones to the top in bold. 80 lines. The AI honors them even less. Emphasis is relative, and in a document where everything is emphasized there is not 1 strong line.

Anthropic's prompting guidance now points the other way as well. What earlier models under-responded to, the model now responds to properly, so cut the over-specified instructions, and anything of the form "when in doubt, do X" invites an over-reaction. It goes as far as saying that if you had been adding words that urge thoroughness, soften them. A sentence that drives the point home is exactly one of those words that urge thoroughness.

What I understood fits in one sentence.

Emphasis grows where there is no machinery. And whether it worked cannot be measured. So what you watch is not the effect but only how it grows.

The mechanism: leave the effect unmeasured and put a ratchet on the count

What you put down is 1 automated test. It counts the lines that hold emphasis and fails when the count goes past the baseline, and that is all it does. A ratchet: a catch that moves in one direction only.

# test/reference/claude_md_emphasis_ratchet_test.rb (a shortened version of the code on my machine)
EMPHASIS = /\*\*|⚠️|最重要|絶対|必ず/
BASELINE = 7          # measured on 2026-09-04. 5 of the 7 lines have machinery

test "emphasis in the instruction file does not grow past the baseline" do
  lines = File.readlines(Rails.root.join("CLAUDE.md"))

  # ⚠️ do not pass with 0 targets. If what it reads breaks, it fails here
  assert_operator lines.count { |l| l.strip.present? }, :>=, 50

  emphasized = lines.each_with_index
                    .select { |line, _| line.match?(EMPHASIS) }
                    .map { |line, i| "CLAUDE.md:#{i + 1}: #{line.strip}" }

  assert_operator emphasized.size, :<=, BASELINE,
                  "emphasis went past the baseline. before adding one, see whether the line " \
                  "can be guarded by a check instead. if it cannot, raise BASELINE and " \
                  "write down why\n#{emphasized.join("\n")}"
end

This is the shape I wrote about in article 6 of the previous series: for rules you cannot fix everywhere right now, make a ratchet. It does not measure the effect. Pretend to measure what cannot be measured and everything past that point becomes a lie. This automated test says 1 thing only: before you add one, see whether machinery can hold the line instead.

The escape hatch is left open as well. Raise the baseline and it passes. That is fine. When you raise it, you stop once and think about whether this line could become an automated test. That is the real work, and the number is only what prompts it.

What I stopped driving home

Driving the point home. Adding more bold, adding a ⚠️, moving an important line to the top. Whenever I found a rule that was not being honored, I used to do one of those 3 things.

Now I look first at whether it can become an automated test. When it can, it moves into the automated test and disappears from the instructions, emphasis and all. Only when it cannot do I add 1 piece of emphasis and raise the baseline.

Caveat: the effect cannot be measured, and it sees only the wording

One, this automated test does not measure the effect. I cannot say that rules get honored once the emphasis goes down. All I can say is that every time you add one, you look once at whether a line machinery could hold is still sitting there as emphasis.

Two, it sees only the wording. Bold, ⚠️, and 3 phrases, that is all. Rewrite "very important" as "extremely important" and it slips past (the same structure as article 1).

Three, this article is lined with ⚠️ as well. Count them and there are far more than I put in my instruction file. Emphasis is not what is wrong. What is wrong is only these 2: trying to guard with emphasis what machinery could guard, and letting emphasis keep growing.

How to verify: add one, and confirm that it fails

Prerequisites

  • You have finished putting down 1 automated test that counts the lines holding emphasis, and recording the current count in a file as the baseline
  • That automated test passes right now

Time required: 10 minutes

Steps

  1. You add 1 line holding bold or ⚠️ to the instruction file. The content does not matter (the point is to push the count past the baseline)
  2. You run that automated test
  3. You go through the lines listed in the failure message one at a time and count how many of them machinery is holding. By machinery I mean a mechanism that works whether or not it is read, such as a hook or an automated test

Pass conditions (all of them have to hold)

  • The automated test fails
  • The failure message lists every line that currently holds emphasis

If it does not pass

  • It says only "the count went past the baseline" and lists no lines — step 3 is impossible. Rework it into a shape that prints the list of lines, then start over
  • It does not fail — the baseline file holds a value larger than the current count

Step 3 is the real point of this verification. The automated test is not there to fail; it is there so that when it fails, the list is in front of your eyes. This is where you find out how many of the lines still sitting as emphasis can move into an automated test (in this article's example, 5 of the 7).

Cleanup

  • Delete the line you added in step 1 and confirm that the automated test goes back to passing

Next time it is "Spell out your subagents' output, and only that." Your subagents' output is the one thing that goes badly wrong unless you spell it out in detail.

Series: The Art of Not Telling