This is article 3 in the series "The Art of Not Listening to the AI's Opinions." 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 the rule that forbids, in itself. A prohibition is a rule that lists out what you have decided not to allow while you develop, and you make both the AI and yourself keep to it. Rules that forbid do get created. What I stopped creating is a fresh one every time a judgment turns hard. Last time I added the reason to the prohibition. Even so, prohibitions where what falls inside them was never decided were left on my machine. What had gone undecided was not the wording but the scope, and whether the scope is decided does not show until you build a single case on the boundary.

Start by trying just one thing.

Pick one prohibition, and build one case where even you hesitate for a moment over whether it falls inside the prohibition.

Could you build one?

If you could, here is the next question. When the AI steps on that case, can you say which way it will judge?

CC BY 4.0

I settled on "do not write color literals" and took it to 0, and 254 were still there

The production project on my own machine, typingtube, a web service for practicing typing along with music videos on YouTube, holds a prohibition: colors are written with the theme's variables, and color literals are not written. You can switch among 10 themes, from light to dark, so a character whose color is written straight in as #fff is bound to sink into the background in one of them. The reason is plain, and it is the kind you do not bend.

In April I put down a pre-commit hook and took 1,775 of them to 0 in a week. I wrote "done" in the design document and took the matter to be finished.

In August I counted, for the first time, the places the hook was not looking. There were 254. style="color:#fff" in the HTML templates, and el.style.color = "#fff" in the JavaScript. The CSS files held not a single one, and 254 sat right beside them. Measuring the places where the text color was written straight in, across 10 themes, turned up a toast with white text on a white surface (a contrast ratio of 1.00) in 5 of the 10 themes.

A plan the AI wrote that same month had this in it.

To keep color literals from growing in the CSS files, push it through as an inline style

It names the prohibition, and then a detour ran through to the side the hook was not counting.

The wording was written correctly. "Do not write color literals," it said. What had gone undecided was whether a color inside a style attribute counts as a "CSS color." Not me, not the AI, not the hook had settled that.

"Which axis do we count it on" had never been decided

One more prohibition sits there with its scope undecided. This service holds one: the achievements, missions and statistics for lyrics typing and for the word decks are kept completely apart. The difficulty and the cost of a play are both different, so mixing them wrecks the value of the achievements on one side. The reason is plain here as well.

In September a third surface, the articles, was added, and a question came up that I could not answer. A user who comes in from an article and plays a word deck: which axis do you count them on?

Count by where they came in and it is the article axis. Count by the act and it is the word-deck axis. Neither reading breaks the ban on crossing over. The prohibition is written correctly, and still which side it falls on cannot be decided.

The distinction I settled on is one line long.

The axis is decided by the act (typed = word deck / read = article), not by where you came from. Where they came in is counted separately on the article axis, as a click on the path in.

What I understood fits in one sentence.

Write the reason and what falls inside the prohibition is still not decided. It gets decided once you build a single case on the boundary and write down which side that case falls on.

Why nothing is decided until the boundary case is written down

The AI that wrote "to keep color literals from growing in the CSS files" into a plan had 2 things on hand. The line of the prohibition, and the count the hook puts out. The line itself carries no scope. The count was looking at the CSS files under app/assets/stylesheets and nothing else.

The line of the prohibition arrives every time. Claude Code's documentation says instruction files and memory alike are context, not enforced configuration. Whether a line arriving that way covers the style attribute under your hands right now is judged afresh each time.

With only the conclusion line on hand, the missing part comes from what the AI carries out of its training. For the color literals there was material closer at hand than that. The hook counts the CSS files alone, and that count stays at 0. The range being counted was read straight across as the range of the prohibition. When the wording of a prohibition carries no scope, and something on hand does carry one, that becomes the scope.

The axes are the side with no material at all. The wording "kept completely apart" settles something between 2 surfaces. When a third surface arrives, that wording says nothing at all about the new pairing. What a person cannot decide by reading it, an AI cannot decide by reading it either.

Anthropic's guidance on how to write skills says to match how specific your instructions are to how fragile and how variable the operation is. Prose guidelines for open ground where judgment is called for, exact commands for the narrow bridge where only one procedure is safe. The "conclusion" of a prohibition calls for judgment, so prose will do, and the "scope" is a narrow bridge. Within one and the same item, you are allowed to change how you write. The same page goes on to say that examples convey the style and the level of detail you want more clearly to Claude than descriptions alone do. So the scope gets written as cases, not as description.

The mechanism: write the scope as an axis, and put the boundary cases down one line at a time

Last time's sheet has a "Scope" heading under the conclusion and the reason. What this article puts down is what goes under it. What you write is only which side things fall on when you are unsure.

### NG13 No crossing over between lyrics typing, word decks and articles for achievements, missions and statistics (3 axes)

**Scope**:

- Do not post a word-deck play to the lyrics-side aggregate table (the decks are a system of their own)
- ⚠️ A word-deck play entered from an article is posted to the **word-deck axis** (not the article axis).
  The axis is decided by the act (typed = word deck / read = article), not by where you came from
- ⚠️ No achievements or missions on the article axis for the time being. It holds access analytics alone.
  ★ When you want one, **rewrite this line first**, then build it (no adding it quietly)

The wording of the prohibition does not get repeated here. Writing the conclusion out a second time adds no scope to it. Cases that clearly fall inside, and cases that clearly fall outside, do not go into the scope either. The judgment there comes out the same whether a scope is written or not. What is left is only the cases where you yourself hesitated for a moment.

The ★ on the third line is the procedure for lifting it. In the measurement in article 1, the line the second one went through was one of this shape.

And axes get added later. This prohibition started with 2 axes and grew to 3. A new boundary case is born every time one is added, so adding an axis and adding a line for the boundary are a set.

A boundary line takes effect on the judgments that come after it. Whatever is already scattered about does not go down by a single one when you settle the boundary. A boundary line also teaches, in the same breath as deciding which side things fall on, that this side here gets through.

What I stopped being asked about

"Does this fall inside the prohibition?" I used to decide it every time it came up. Sometimes the AI asked, sometimes it crossed without asking, and the second kind I noticed only after the implementation was done. Since the boundary lines went in, the place where you would hesitate is already in writing, so I am not asked to decide.

Caveat: add an axis and the combinations grow

With 2 axes there is 1 boundary, and with 3 axes there are 3. The cost of adding an axis lands not on the number of axes but on the number of combinations. In my case, what took the most time on the day I added the 3rd axis was not defining the article axis but settling the boundary for "article × word deck."

How to verify: break the boundary from both directions

Prerequisites

  • The prohibition has a "Scope" written under it, and at least one boundary line in it
  • An automated test is watching that boundary, and it passes right now
  • You start from a state with no work in progress (git status is empty)

Time required: 20 minutes

A boundary has 2 directions. Check one of them alone and you come away convinced that an automated test watching half of it is watching both.

Steps

  1. You pick one boundary line (in the example above, "which axis do you count a user who comes in from an article and plays a word deck on")
  2. You break it in one direction. If the boundary says the count goes by the act, you deliberately write 1 line of implementation that counts by where they came in. Run the automated test and note the result
  3. You put that 1 line back and break it in the other direction. This time you write an implementation that crosses from the opposite side. Run the automated test and note the result

Pass conditions (all of them have to hold)

  • The automated test fails in step 2
  • The failure message in step 2 shows which direction you broke it in
  • The automated test fails in step 3 as well

If it does not pass

  • It does not fail in step 3 — that automated test is watching one side alone. Finding that out is what this verification yields. You add one assertion for the other direction
  • It does not fail either way — the automated test does not have that boundary among what it scans

Cleanup

  • Put back the 1 line you wrote in step 3, and confirm that the automated test goes back to passing and that git diff is empty

An automated test that goes in one direction alone is watching half of the boundary. The test that watches this prohibition in my environment says "nothing leaks in either direction" because there was a time when I closed off one side and felt safe.

Next time it is "Check your subagents' input, and only that." Your subagents' input is the one thing to check, and leaving it unchecked ends in something terrible.

Series: The Art of Not Listening to the AI's Opinions