I reviewed all the rules I wrote for AI; there are about 220 rules in total. Among these, approximately 24 rules have mechanisms ready for execution. Of the 60 rules with the highest cost, 48 of them the AI remembers independently. This situation reflects that I wrote the rules but did not provide triggers, executors, or verification methods; therefore, they remained only as text. I conducted this review because after removing a third of the main rule file, it expanded again within 18 days. I used AGENTS.md. Claude Code users typically use CLAUDE.md, and ChatGPT side uses custom commands with different names, yet the situations encountered are similar.
- You have a rule file for AI to read, and it's getting longer, you vaguely feel it should be organized
- You simplified it once, but after a few weeks it went back to the original state, not knowing where the problem was
- You wrote a lot of rules, but you don't know if AI is actually following them
- A four-column checklist to check if your rules are actually being executed, including a manual version without hook environment
- Three access gates that can be directly copied to use, changing the default value from 'add' to 'not add'
- A real slimming and weight gain curve, along with my explanation of why it happened
How it all started
One day, I saw a post that quoted an interview with an Anthropic engineer, saying they cut down the system prompt for Claude Code by 80%. The reason was counterintuitive: the stronger the model, the fewer instructions it should be given, because too many constraints and examples would compress the model's problem-solving space.
My first reaction was, then my rule base should also be cut down again.
I first let Codex help me verify, and after checking, I found two things.
First, the statement in the post that 'over 90% of engineers are building self-improvement loops' couldn't be found in the official sources. The closest statements I found were about different things, so this number I don't cite.
Second, the official best practices document for Anthropic's Claude Code still clearly states that you can put specific multi-step processes into custom commands. So 'cutting 80%' has its context, and it's not a rule that can be directly applied.
By the way, the statement 'cutting 80%' itself is a second-hand report, and I couldn't find the original interview source. All the judgments in this post are based on my own data, not on that 80%.
So should I cut it or not? I first measured my own numbers.
My actual curve
| Time | Word count | Change |
|---|---|---|
| Before weight loss on 7/4 | 25,036 | |
| After weight loss on 7/4 | 15,822 | Cut 37% |
| 7/16 | 21,028 | +5,206 |
| 7/18 | 23,412 | +2,384 |
| 7/22 | 24,219 | +807 |
Gained 8,397 words in 18 days.
First, let me explain the limitations of these numbers: these word counts are calculated from the rule files in my own automatic backup folder at various time points. These are my private files, which you cannot verify, only see my records. Also, backups are periodically cleaned up, so this curve itself will also disappear. I will mention this again later.
This curve made me abandon the idea of cutting again. It also made me realize another thing: I have no mechanism to prevent the rules from increasing. In this state, cutting again would likely result in the same curve in 18 days.
Why did I regain weight?
The following is my own explanation, not an experimental conclusion.
I have a methodology called the 'Subtraction License Agreement,' distilled from the open-source skill package Ponytail. It says any rule with subtractive properties needs three components.
Decision Ladder Turn the vague adjective 'please be concise' into a checklist with order and tickable items. Adjectives cannot be executed, but a ladder can.
Burden of Proof Reversal Change the default from 'do' to 'do not.' Anyone wanting to add something must first prove it is necessary. The burden of proof shifts from those wanting to delete to those wanting to add.
Red Line Retention When any subtractive rule is launched, simultaneously pin a list of things that will never be cut. Principles are responsible for cutting complexity, and the list is responsible for protection.
I looked at my own situation: there is a staircase, there is a red line, but there is no reversal evidence.
I considered this gap the reason for weight regain. Each time a new rule is added to the main file, the default response suggests adding it because adding a few hundred words seems minor. The cost of addition is zero; the cost of deletion is high. Consequently, the curve will only increase. The issue resides with the default value favoring weight regain rather than my diligence.
What does the anti-weight regain engine look like?
The things I added are very simple, which are three questions. Before adding anything to the rule main file, first answer:
- I am asking about the frequency of loading for this rule across conversation rounds. Some rules are important; others are only needed in specific situations. Therefore, it should be placed in the on-demand loading area.
- Are the existing rules or tools already covering this? Repeatedly maintaining the same thing will eventually become two conflicting versions.
- Which executor does this rule belong to? Hook, script, existing workflow mounting point, or purely self-discipline? If it's purely self-discipline, what is the cost of violating it? Only keep purely self-discipline if the cost is low.
If any of the three questions cannot be answered, do not add it to the main file.
These three questions can be directly copied and used, regardless of the name of your rule file:
I want to add a new rule to the rule main file. Before writing, first answer the three questions: 1. Does this rule need to be loaded for every conversation round (the question is about the frequency of loading, not the importance)? 2. Are the existing rules or tools already covering this? 3. Which executor does this rule belong to (Hook/script/workflow mounting point/pure self-discipline)? If it's pure self-discipline, what is the cost of violating it? If any of the three questions cannot be answered, do not add it to the main file, instead place it in the on-demand loading area.
I also made it into a Hook. When modifying the main file, it will automatically pop up to ask me, and also tell me the current number of words and how much it exceeds the baseline. It does not block, only reminds, and only appears once in the same workflow stage, so it won't be annoying.
I chose the prompt type because I still don't know if it is effective. After one month, I will look at the word count curve. If it stops rising, I will maintain the prompt type. If it is still rising, I will consider upgrading to blocking it.
What to do if there is no Hook environment?
The Hook mentioned above requires an environment that can run scripts. If you are using the web version of ChatGPT or Claude, you can do the same, just manually.
Save the above prompt as a fixed custom command or note snippet. Before modifying the rule file, paste it once, let the AI answer the three questions with you, and then proceed.
Open a spreadsheet, one row for each rule, with four columns for trigger, executor, evidence, and cross-family coverage. You can paste the entire rule file to AI, ask it to output according to these four columns, and then check a few of them yourself to see if they are marked incorrectly.
Fix a day every week to record the word count of the rule file to the second sheet of the same spreadsheet, one line per entry. After four weeks, you will have your own curve.
The difference is only between automatic and manual. The judgment logic is completely the same.
A more valuable discovery
While doing this, I also went through the entire rule main file. I found a sub-agent to read through 259 lines, labeling each line with four fields.
| Field | The question to answer |
|---|---|
| Trigger | Who, and when, will read this line? |
| Executor | Hook, script, workflow mounting point, or purely manual awareness? |
| Evidence | What output can prove it was done? |
| Cross-family coverage | Every AI tool I use, is it really subject to this rule? |
I came up with about 220 rules. About 24 of them have mechanical executors.
Going further down, I picked out the ones with high cost, meaning those that delete data, overwrite, send externally, deploy, or show to customers, totaling 60 rules. Of these 60, 12 have executors.
That means the 48 rules with the highest cost are entirely remembered by AI itself.
A limitation exists here: my judgment regarding whether the cost is high is subjective. Boundary cases might have an error involving about three rules. The number lacks precision; however, the scale will not differ much.
The most glaring rule is 'cross-family review.' I require important outputs to be reviewed by models from different families, prohibiting self-review. This is the foundation of my entire quality system, written in the 'quality hard threshold' section. It has no mechanical checks.
This round of work did indeed run four rounds of cross-family reviews, including this article itself, but I requested it myself, and nothing reminded me to do so.
During the inventory, I observed a pattern: rules that experienced issues later had Hooks added. Rules that did not experience issues still depended on self-awareness. My patching mechanism is reactive. Among the 48 rules, some may remain unpatched because they have not caused issues; however, I did not track each rule's history individually. This represents my overall impression.
This is more important than cutting words
Going back to the original question: Should we cut another round?
The answer is no, at least not as a priority. The number of rules and whether the rules are effective are two different things.
A rule without a trigger, an executor, and evidence of completion, even if written as concisely as possible and placed in a prominent position, is still just a piece of text. Conversely, a rule with a Hook blocking it, even if it takes up 200 words, is working every day.
Therefore, my later order is: first measure the execution coverage, then decide whether to delete, move, merge, or mechanize. Cutting words first will lead to the realization that the necessary barriers are still not in place.
Here's a habit I have when writing articles, which coincidentally follows the same principle. When an article exceeds the word limit, I used to cut words, keeping the original structure and trimming one word at a time, cutting several rounds but still not reducing the word count much. Later, I changed to cutting paragraphs, re-evaluating whether the reader needs to know this information, and removing the entire paragraph, summarizing it with one sentence.
Both methods have their applicable scenarios. When it's clear that every paragraph should be kept, but the sentences are wordy, cutting words is effective. When the structure is not yet determined, or when you yourself feel that certain paragraphs are unnecessary, cutting paragraphs is much more effective. The rule base is the same; instead of trimming words in the text, first ask, 'Does this rule need to be loaded every round?' If the answer is no, move the entire rule, and the main file immediately loses a section.
What you can do
If you are also maintaining a rule file for AI, I recommend the following order.
Find a day to mark each rule with those four fields. You will quickly discover which provisions have no trigger points and which have never been checked for compliance. This step is read-only and will not alter anything.
Identify the provisions that have high cost but no executor. For each, decide: add a mechanical check, rewrite it into a triggered form, or downgrade it to a place where it is loaded on demand. Do not add all hooks. Too many hooks will interfere with each other and increase the rate of false positives.
Put the above three steps into a workflow, so that new rules must pass through before entering the main file. This is the key to preventing the system from becoming bloated again. Without this step, after a few weeks, you will see the same curve again.
There is also a fourth step, which I only thought of at the end of this process, and it was pointed out to me by Codex.
Fourth step: leave evidence
You must be able to prove that the mechanism is effective. Initially, I recorded the word count within the prompt hook, but it only recorded the first time each stage was modified and did not shorten. Deletions were never recorded, and whether the length had decreased was exactly the question this curve was meant to answer.
Later, I split the recording into an independent branch, measuring it after the modification, and recording it every time. Only then did this curve become something that could be used to make decisions. Without this step, after a month, you could only say "it seems better" based on intuition.
There is also a fifth step, and it is the insurance for the previous four steps.
Step 5: Set up a fixed review schedule
The first four steps are one-time actions. The gate is set up, the evidence is recorded, but if no one goes back to check regularly, that curve is just an unread file.
My approach is to set up an automatic schedule every week, running three tasks at fixed times: check the word count curve to see if it has stopped rising, check if any new rules have been added to the main file but not answered three questions, and randomly check one rule with an executor to see if it is still running. If there is no scheduling tool, setting a recurring reminder in the calendar will work, the key point is that it will find you, not wait for you to remember.
This step is applying what this article talks about to yourself. If review relies only on memory, it becomes the 48th rule that is not executed.
Finally
The most valuable part of that post is actually its last sentence: fewer instructions does not mean fewer rules, the key is to leave the most important boundaries, goals, permissions, verification, and stopping conditions.
I completely agree with this sentence. Using this ruler to measure my rule base, the result is: what I should do is add executors to the 48 rules that are not executed, and cutting down can be postponed for a bit.
Cutting down to the end, you will find that there is actually limited to cut. What truly determines whether the rule base is useful is whether there is something behind each rule that helps execute it.