diff --git a/agents/AGENTS.md b/agents/AGENTS.md
index fa9b8e9..249bf7d 100644
--- a/agents/AGENTS.md
+++ b/agents/AGENTS.md
@@ -85,27 +85,9 @@ loop or brute-force through API calls.
 
 ## Code health
 
-Strategic over tactical, with follow-through. Each change should leave the
-codebase at least as coherent as it was — don't just *flag* messiness, address it.
-
-- **Default to acting on cleanups, not just mentioning them.** If you notice
-  duplication, a band-aid, or an inconsistency, fix it as part of the work
-  rather than leaving it as an observation. "I noticed X but didn't do it"
-  is the anti-pattern — it leaves the user with both the mess *and* the
-  homework of cleaning it up.
-- **Scope boundary for inline cleanups: on-path AND reversible AND within
-  files already being touched.** Inline when all three hold. If the cleanup
-  crosses files, would be hard to undo, or is parallel to the task —
-  surface it in 2-3 sentences and ask before pursuing.
-- **Tolerate duplication until the pattern is real.** Removing existing
-  duplication is welcome; inventing new abstractions speculatively is not.
-  Rule of three: don't unify two instances, wait for the third.
-- **Treat friction as architectural data.** Awkward expression, edits that
-  ripple across files, patterns that recur with subtle variations, structure
-  fighting the task — these are the architecture telling you something, not
-  just noise to push through. Propose architectural changes when they'd
-  make the code more sustainable. Frame as proposals with a clear ask
-  ("now, or follow-up?"), not silent rewrites.
+The `coding` skill carries the rules (act on cleanups, scope boundary, rule of
+three, friction as architectural data, per-language style). Load it before
+editing code if it did not trigger on its own.
 
 ## Interpreting requests