Applies to auto-loaded artifacts: rules declared in the plugin manifest, SKILL.md on skill invocation, READMEs on plugin fetch
Out of scope: every file the agent loads only after electing to open it — skills/<name>/references/**, lookup tables, worked examples, any file reached through a pointer
The test is load-time, not directory. A file the agent receives without choosing it is in scope. A file it opens after reading a reference is not, whatever directory holds it
rules/skill-authoring.md Keep Skills Compact names reference files as the destination for detail moved off the loaded surface
PR descriptions are the archive — they carry the motivation and incident references stripped from rules, and follow looser discipline
What to Cut and Structure do not govern PR descriptions. What to Cut names the PR description as where the stripped explanation goes; a connective ban there would leave it nowhere to live
A PR description runs as long as its archive role needs, carrying the motivation, incidents, and worked examples stripped from rules
Line-count and section-count budgets target single-concept rules; rules that cover one coherent policy area with several sub-aspects (e.g., context-artifacts covering structure/review/sync/audit; skill-authoring covering frontmatter/preamble/steps/calls) may run larger
Lists and quoted literals naming the forbidden terms themselves (e.g., this rule's own bullets enumerating the connectives and intensifiers) are not violations — the directive is the list, not prose use of the listed words

What to Cut

Logical connectives are why-content detectors: therefore, however, because, since, thus, consequently, moreover, although, despite, as a result, in order to
When you write one of these, strip the entire clause it introduces and move the explanation to the PR description
Em-dash, colon, and semicolon are not loopholes — using them to attach the same justifying clause is the same violation
Intensifiers used as noise modifiers: very, extremely, quite, really, fully, exactly, precisely, narrowly, completely. Keep when carrying a real constraint (sum to exactly 100, fully enumerable, narrowly scoped)
Reinforcement and hedging restatements of conclusions the preconditions already entail
Meta-justification prose explaining why the rule exists — belongs in the PR description
Reference incidents, dated outages, worked examples tracing a case through the rule — belongs in the PR description
Cross-rule rationale shoulder-taps; a bare reference suffices, the relationship stays out
Pointers like "see PR #X" left behind after cutting incidents — rules stand alone; the archive is not ongoing reference
Anti-patterns buried in prose — bullet them instead ("X does NOT qualify" is rule content, not commentary)

What to Keep

File paths, command names, flag literals, version numbers, dates, function names, env vars, error codes
Constraint-bearing words: required, optional, mandatory, forbidden, deprecated
Carve-out preconditions in full, in the rule or in the skill reference its binding pointer names (preconditions are the rule for edge cases)

Reader-Side — Consult the Archive

The PRs that changed a rule are the archive for motivation, incidents, and worked examples cut from its body
Find them through git log on the rule file, or the (#N) on each CHANGELOG.md line
Older CHANGELOG.md entries carry the archive for changes made before PR titles replaced entries
Read each plugin's archive when a rule spans plugins
Pull the archive when judging an edge case
Pull the archive when debugging an unexpected directive
Pull the archive when auditing whether a rule still describes current reality
Never infer that missing rationale in a rule body means the rule is incomplete

Structure

Atomic bullets — one directive per bullet
Carve-outs: lead with "Narrow exception for X.", then numbered preconditions, then a one-line reset stating every other case follows the rule
A carve-out whose preconditions live in a skill reference keeps in the rule its trigger ("Narrow exception for X." plus one applies-when line), the pointer Preconditions are binding: read <path> <Section> before relying on it, and its reset
Never comma-splice preconditions with "; AND ...; AND ..."
3–6 H2 sections per rule, ~25–40 lines total
At most one parenthetical clause per sentence — break out a second clause into its own bullet. Function-call notation (Skill(), print(), etc.), label tags inside lists, and other literal-syntax parens do not count as parenthetical clauses
Active voice, present tense; drop articles where the referent is unambiguous