← ClaudeAtlas

devpilot-google-go-stylelisted

ALWAYS use when working in a Go project — writing new Go code, modifying .go files, reviewing Go PRs, or discussing Go design decisions. Triggers on any .go file interaction, Go package design, Go naming questions, Go error handling patterns, Go test writing, or Go code review. Even if the user doesn't mention "style" or "conventions", if you're touching Go code, this skill applies.
SiyuQian/devpilot · ★ 4 · AI & Automation · score 70
Install: claude install-skill SiyuQian/devpilot
# Google Go Style Guide This skill enforces the Google Go Style Guide when writing or reviewing Go code. It covers naming, formatting, error handling, documentation, testing, and language patterns. The guide is organized by priority: naming and errors matter most because they affect every reader. Formatting is handled by `gofmt`. The rest improves clarity and maintainability. When **writing** Go code, follow these rules directly. When **reviewing** Go code, flag violations with the specific rule and a concrete fix. ## Quick Reference — The Rules That Matter Most ### Naming **MixedCaps everywhere.** Use `MixedCaps` or `mixedCaps`, never `snake_case`. This applies to constants, variables, functions, methods — everything except filenames and flag names. **No stuttering.** Don't repeat the package name in exported symbols: - `widget.New` not `widget.NewWidget` - `db.Load` not `db.LoadFromDatabase` **Short receivers.** One or two letters, abbreviating the type. Consistent across all methods: - `func (s *Server)` not `func (self *Server)` or `func (server *Server)` **No Get prefix.** Use `Counts()` not `GetCounts()`. Use `Compute` or `Fetch` for expensive operations. **Variable length proportional to scope.** Single-letter vars are fine in small scopes (loops, short functions). Larger scopes need descriptive names. Don't abbreviate by dropping letters — `Sandbox` not `Sbx`. **Don't encode types in names:** - `users` not `userSlice` - `count` not `numUsers` or `usersInt`