Name package-level code for its feature

The go-code skill now asks for a feature prefix on each package-level
name that belongs to one feature or integration, and on the names of its
files. A name stays generic only when more than one feature uses it. All
the code is in one main package, so every name is visible in every file,
and generic names such as a client, a request, or a poll interval of one
service read as if they belong to all of them.

The skill also asks for unexported names, because an exported name has
no effect in a main package, and for initialisms in one case.

diff --git a/.agents/skills/go-code/SKILL.md b/.agents/skills/go-code/SKILL.md
index a9e705b7d1c53ecae9d952b35def3a5d4859dcf2..71ff6c9eb749de60864ac6d91f84a2c1c594765f 100644 (file)
--- a/.agents/skills/go-code/SKILL.md
+++ b/.agents/skills/go-code/SKILL.md
@@ -15,6 +15,13 @@ description: Go style rules. Use before you write or review Go code.
   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.
+- Start each package-level name that belongs to one feature or
+  integration with the name of that feature. Start the names of its
+  files with the same name. Keep a name generic only when more than one
+  feature uses it.
+- Use unexported names. In the `main` package, an exported name has no
+  effect.
+- Write all the letters of an initialism in one case.
 - 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.