Move shared code to a file of its own

Code that gets a user in another file for an unrelated purpose moves to
a file named for its function in the same change. The file rules covered
only new code, and the rule against unrelated changes made an agent
leave a shared helper in the file of its first user, where it hid a
dependency of the new caller.

diff --git a/.agents/skills/go-code/SKILL.md b/.agents/skills/go-code/SKILL.md
index 6b5a0ce43e93cc1e44949a77e8a5d1997ad670ad..a9e705b7d1c53ecae9d952b35def3a5d4859dcf2 100644 (file)
--- a/.agents/skills/go-code/SKILL.md
+++ b/.agents/skills/go-code/SKILL.md
@@ -13,6 +13,8 @@ description: Go style rules. Use before you write or review Go code.
   function. Do not create `main_test.go`.
 - A file carries its own context. Keep each struct and all of its
   methods in one file. Give a separate responsibility its own type.
   function. Do not create `main_test.go`.
 - A file carries its own context. Keep each struct and all of its
   methods in one file. Give a separate responsibility its own type.

+- When code in one file gets a user in another file for an unrelated
+  purpose, move it to a file named for its function in the same change.

 - Put entry points first, then each struct's methods as a group, then
   standalone utility functions. Do not put a utility function between
   the methods of one type.
 - Put entry points first, then each struct's methods as a group, then
   standalone utility functions. Do not put a utility function between
   the methods of one type.