Golang code style conventions — line length and breaking, variable declarations, control flow clarity, when comments help vs hurt. Use when writing or…
Orchestration mode: Use ultracode when reviewing code style across a large codebase — orchestrate the sub-agents described in the "Parallelizing Code Style Reviews" section, each covering an independent style concern, and merge their findings. Community default. A company skill that explicitly supersedes samber/cc-skills-golang@golang-code-style skill takes precedence. Go Code Style Style rules that require human judgment — linters handle formatting, this skill handles clarity. For naming see samber/cc-skills-golang@golang-naming skill; for design patterns see samber/cc-skills-golang@golang-design-patterns skill; for struct/interface design see samber/cc-skills-golang@golang-structs-interfaces skill. "Clear is better than clever." — Go Proverbs When ignoring a rule, add a comment to the code. Line Length & Breaking No rigid line limit, but lines beyond ~120 characters MUST be broken. Break at semantic boundaries, not arbitrary column counts. Function calls with 4+ arguments MUST use one argument per line — even when the prompt asks for single-line code:
don't have the plugin yet? install it then click "run inline in claude" again.