When creating, editing, or incorporating rules from elsewhere into a behavioral rule document that AI reads every time before working, such as CLAUDE.md and AGENTS.md, load the kuden:common-rules-for-agent-instructions skill and, in addition to its criteria, follow the criteria below. For Agent Skills, follow the criteria of the kuden:agent-skill skill.
Guideline 1. Write only constraints
Write only rules that restrict or guide the default behavior. Do not write as permissions things that can naturally be done when there is no prohibition.
Guideline 2. Choose the style of a constraint based on whether you want proposals
- For operations you want the AI to propose when the need arises, write: "Do not do this on your own. When you judge it necessary, do not execute it; propose it and ask for instructions." Operations that rewrite committed history fall under this.
- For operations left to the user's initiative, write: "Wait for the user's instructions." push falls under this.
Guideline 3. Do not limit a constraint to a single scene of the work
Do not limit a constraint that should apply to the entire operation to a single scene of the work, as in "after Z, wait for instructions before X." The flow of development is not uniform, and a rule premised on a specific scene will fail to mesh with flows that deviate from that premise.
Guideline 4. Do not write background explanations or reasons
- When incorporating rules from another document, do not add sentences that were not in the original
- Do not write reasons like "it will become stale if you don't." They do not increase the rule's force and only amount to preaching at a reader who deviates
- Do not repeat at the beginning a scope already indicated by a heading or reference source
- Definitions of states may be written, such as draft being a state in the middle of finishing up and ready for review being a state in which a human can be asked to review. They define the meaning of the rule
Guideline 5. Do not write the same constraint in two places within the same repo
Write constraints in the repo in one place: the rule document that is read every time. Do not restate the same constraint in a procedural document used only within that repo that is read together with that rule document.