Applying mandatory naming rules can cause broad, compatibility-breaking renames
Source references: 3The Skill phrases many preferences as MUST/NEVER and explicitly says that applying the fixes means renaming existing identifiers. Renaming exported names, interface methods, constructors, or enum members can affect the entire workspace and external callers. The text itself acknowledges that manual edits can miss call sites or break interface satisfaction.
If an agent interprets a review request as authorization to refactor, the user may receive persistent cross-file changes, build failures, broken interface implementations, or incompatible public APIs.
The Skill is allowed to Edit/Write and explicitly says applying its fixes means renaming existing identifiers. If used to apply naming fixes during a refactor, changes to exported APIs, interface methods, or enum names could affect callers inside and outside the workspace. It acknowledges that manual edits can miss call sites or break interface satisfaction, then refers to another Skill not included here. A user can restrict it to read-only review or require a rename-impact list and call-site verification first.
install: []allowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agentpaths:Show 2 other places
All Go identifiers MUST use `MixedCaps` (or `mixedCaps`). NEVER use underscores in identifiers — the only exceptions are test function subcases (`TestFoo_InvalidInput`), generated code, and OS/cgo interop. This is load-bearing, not cosmetic — Go's export mechanism relies on capitalization, and tooling assumes MixedCaps throughout.Applying these fixes means renaming existing identifiers — → See `samber/cc-skills-golang@golang-gopls` skill to do it safely: its rename updates every call site across the workspace and refuses a rename that would break interface satisfaction, which a grep/sed or manual Edit-based rename silently misses.