К основному содержанию
скилл CX Codex

go-code-review — скилл для Claude Code: ревью Go-кода

Проверяет Go-код по общепринятым стандартам стиля и выдаёт замечания по severity. Пригодится перед отправкой PR.

Установить в Claude Code · Через Skills CLI (Vercel) Все способы и платформы ↓
npx skills add cxuu/golang-skills --skill go-code-review -a claude-code
Открыть на GitHub

Что делает go-code-review

Скилл прогоняет ревью по чек-листу: форматирование, документация, обработка ошибок, именование, конкурентность, интерфейсы, структуры данных, безопасность, объявления и функции. Сначала запускаются gofmt -d . и go vet ./..., потом диф читается файл за файлом, а найденные проблемы помечаются ссылкой на строку и именем правила. В конце результаты группируются по severity: must-fix, should-fix, nit.

Внутри есть scripts/pre-review.sh для сбора результатов gofmt, go vet и golangci-lint, шаблон assets/review-template.md для единообразного вывода и references/WEB-SERVER.md для разбора HTTP-сервера, где сходятся конкурентность, контексты, логирование и завершение работы. Скилл не разбирает синтаксис языка — такие вопросы он передаёт специализированным скиллам.

Одна деталь важна заранее: примеры в references/WEB-SERVER.md используют log/slog и требуют Go 1.21+. Если проект собирается на более старой версии, этот файл вам не подойдёт. Скилл настроен на Bash(bash:*) — ему нужен доступ к запуску скриптов. После ревью он перечитывает диф и выкидывает замечания, которые нельзя подтвердить конкретной строкой.

Какие задачи решает

  • поймать механические проблемы форматирования до ручного чтения дифа
  • проверить экспортированные имена на наличие doc-комментариев
  • найти проглоченные ошибки с _ и магические значения вроде -1 или nil
  • разобрать HTTP-сервер, где смешаны конкурентность, контексты и shutdown
  • сгруппировать замечания по severity перед отправкой PR

Примеры запросов агенту

  • сделай ревью этого Go-файла по чек-листу
  • проверь диф перед PR на соответствие стандартам стиля Go
  • прогони pre-review.sh и разбери результаты gofmt и go vet

Как установить go-code-review

1Через Skills CLI (Vercel)

npx skills add cxuu/golang-skills --skill go-code-review -a claude-code

2Вручную: положить файлы

~/.claude/skills/go-code-review/SKILL.md

Папка скилла целиком; для одного проекта — .claude/skills/go-code-review/

По шагам, с командами для каждой платформы: Как установить скилл в Claude Code: пять способов

Из того же набора19

go-documentation Пишет и проверяет доккомментарии для экспортируемых типов, функций и пакетов Go. Срабатывает и сам, когда вы создаёте новый экспортируемый API. CX Codex +1 1 300установок go-concurrency Правила для горутин, каналов и мьютексов, чтобы агент не плодил утечки и гонки данных в Go-коде. CX Codex +1 1 300установок go-error-handling Скилл учит агента писать надёжную обработку ошибок в Go: выбирать между %w и %v, задавать sentinel-ошибки и не смешивать логирование с возвратом. CX Codex +1 1 300установок go-testing Скилл для написания и разбора тестов на Go: table-driven тесты, сабтесты, хелперы и сравнение через cmp.Diff. Пригодится, когда агент пишет тест к функции. CX Codex +1 1 300установок go-control-flow Скилл учит агента писать канонические циклы, ветвления и switch в Go. Пригодится при оформлении guard clauses и предотвращении багов с затенением переменных. CX Codex +1 1 200установок go-functional-options Скилл подсказывает, как собрать конструктор в Go с необязательными настройками через функциональные опции. Пригодится, когда у New* уже три и больше необязательных параметров. CX Codex +1 1 200установок go-data-structures Скилл для ИИ-агента, который подсказывает идиомы Go при работе со срезами, картами и массивами: make против new, append, nil-срезы и JSON. CX Codex +1 1 200установок go-packages Задаёт правила разбиения Go-кода на пакеты, структурирует импорты и запрещает пакеты util. Пригодится на старте проекта или при рефакторинге растущей кодовой базы. CX Codex +1 1 200установок

Похожие

golang-modernize samber Скилл обновляет Go-код до актуальных идиом языка, стандартной библиотеки и инструментов. Пригодится при ревью старых паттернов, апгрейде версии Go или обновлении CI. CX Codex +1 40 300установок encore-go-code-review encoredev Скилл проверяет Go-код на Encore: инфраструктура внутри функций, забытый context, SQL-инъекции и другие анти-паттерны перед мержем. CX Codex +1 553установок code-review-pro OneWave-AI Разбирает файлы, модуль, диф или ветку и выдаёт находки по критичности: уязвимости, баги, узкие места, проблемы поддержки. С доказательствами и готовыми правками. CX Codex +1 2 600установок trailmark-review-gate trailofbits Скилл запускает структурный контроль изменений веток и коммитов через анализ графов Trailmark. Он выявляет удаление проверок доступа, рост радиуса атаки и новые пути передачи опасных данных. CX Codex +1 1 300установок code-review llama-farm Разбирает изменённый код в диффе: ищет утечки секретов, инъекции, пустые catch и заглушки. Сам определяет домен по путям файлов. CX Codex +1 1 200установок golang-naming samber Скилл задаёт правила имён в Go: пакеты, типы, ошибки, булевы поля и тесты. Пригодится при написании, ревью и рефакторинге кода. CX Codex +1 40 900установок

Рядом в теме «Код-ревью и рефакторинг»

Всё по теме «Код-ревью и рефакторинг» →

Вопросы о go-code-review

Как установить go-code-review в Claude?

Выполните npx skills add cxuu/golang-skills --skill go-code-review -a claude-code. Скилл окажется в ~/.claude/skills/go-code-review/SKILL.md.

Что делает go-code-review?

Прогоняет Go-код по чек-листу: форматирование, документация, ошибки, именование, конкурентность, интерфейсы, структуры данных, безопасность, объявления и функции. Замечания помечаются ссылкой на строку и группируются по severity.

Какие инструменты нужны для работы скилла?

Скилл запускает gofmt, go vet и golangci-lint через scripts/pre-review.sh, поэтому они должны быть доступны в проекте. Примеры в references/WEB-SERVER.md требуют Go 1.21+.

Исходный текст

SKILL.md · Apache-2.0
---
name: go-code-review
description: Use when reviewing Go code or checking code against community style standards. Also use proactively before submitting a Go PR or when reviewing any Go code changes, even if the user doesn't explicitly request a style review. Does not cover language-specific syntax — delegates to specialized skills.
allowed-tools: Bash(bash:*)
---

# Go Code Review Checklist

> Compatibility: `references/WEB-SERVER.md` uses `log/slog` examples that require Go 1.21+.

## Resource Routing

- `assets/review-template.md` - Use when formatting review output with Must Fix, Should Fix, and Nits sections.
- `scripts/pre-review.sh` - Run before manual review to collect gofmt, go vet, and golangci-lint results.
- `references/WEB-SERVER.md` - Read when reviewing an HTTP server that combines concurrency, context, logging, error handling, and shutdown behavior.

## Review Procedure

> Use `assets/review-template.md` when formatting the output of a code review to ensure consistent structure with Must Fix / Should Fix / Nits severity grouping.

1. Run `gofmt -d .` and `go vet ./...` to catch mechanical issues first
2. Read the diff file-by-file; for each file, check the categories below in order
3. Flag issues with specific line references and the rule name
4. After reviewing all files, re-read flagged items to verify they're genuine issues
5. Summarize findings grouped by severity (must-fix, should-fix, nit)

> **Validation**: After completing the review, re-read the diff once more to verify every flagged issue is real. Remove any finding you cannot justify with a specific line reference.

---

## Formatting

- [ ] **gofmt**: Code is formatted with `gofmt` or `goimports` → [go-linting](../go-linting/SKILL.md)

---

## Documentation

- [ ] **Comment sentences**: Comments are full sentences starting with the name being described, ending with a period → [go-documentation](../go-documentation/SKILL.md)
- [ ] **Doc comments**: All exported names have doc comments; non-trivial unexported declarations too → [go-documentation](../go-documentation/SKILL.md)
- [ ] **Package comments**: Package comment appears adjacent to package clause with no blank line → [go-documentation](../go-documentation/SKILL.md)
- [ ] **Named result parameters**: Only used when they clarify meaning (e.g., multiple same-type returns), not just to enable naked returns → [go-documentation](../go-documentation/SKILL.md)

---

## Error Handling

- [ ] **Handle errors**: No discarded errors with `_`; handle, return, or (exceptionally) panic → [go-error-handling](../go-error-handling/SKILL.md)
- [ ] **Error strings**: Lowercase, no punctuation (unless starting with proper noun/acronym) → [go-error-handling](../go-error-handling/SKILL.md)
- [ ] **In-band errors**: No magic values (-1, "", nil); use multiple returns with error or ok bool → [go-error-handling](../go-error-handling/SKILL.md)
- [ ] **Indent error flow**: Handle errors first and return; keep normal path at minimal indentation → [go-error-handling](../go-error-handling/SKILL.md)

---

## Naming

- [ ] **MixedCaps**: Use `MixedCaps` or `mixedCaps`, never underscores; unexported is `maxLength` not `MAX_LENGTH` → [go-naming](../go-naming/SKILL.md)
- [ ] **Initialisms**: Keep consistent case: `URL`/`url`, `ID`/`id`, `HTTP`/`http` (e.g., `ServeHTTP`, `xmlHTTPRequest`) → [go-naming](../go-naming/SKILL.md)
- [ ] **Variable names**: Short names for limited scope (`i`, `r`, `c`); longer names for wider scope → [go-naming](../go-naming/SKILL.md)
- [ ] **Receiver names**: One or two letter abbreviation of type (`c` for `Client`); no `this`, `self`, `me`; consistent across methods → [go-naming](../go-naming/SKILL.md)
- [ ] **Package names**: No stuttering (use `chubby.File` not `chubby.ChubbyFile`); avoid `util`, `common`, `misc` → [go-packages](../go-packages/SKILL.md)
- [ ] **Avoid built-in names**: Don't shadow `error`, `string`, `len`, `cap`, `append`, `copy`, `new`, `make` → [go-declarations](../go-declarations/SKILL.md)

---

## Concurrency

- [ ] **Goroutine lifetimes**: Clear when/whether goroutines exit; document if not obvious → [go-concurrency](../go-concurrency/SKILL.md)
- [ ] **Synchronous functions**: Prefer sync over async; let callers add concurrency if needed → [go-concurrency](../go-concurrency/SKILL.md)
- [ ] **Contexts**: First parameter; not in structs; no custom Context types; pass even if you think you don't need to → [go-context](../go-context/SKILL.md)

---

## Interfaces

- [ ] **Interface location**: Define in consumer package, not implementor; return concrete types from producers → [go-interfaces](../go-interfaces/SKILL.md)
- [ ] **No premature interfaces**: Don't define before used; don't define "for mocking" on implementor side → [go-interfaces](../go-interfaces/SKILL.md)
- [ ] **Receiver type**: Use pointer if mutating, has sync fields, or is large; value for small immutable types; don't mix → [go-interfaces](../go-interfaces/SKILL.md)

---

## Data Structures

- [ ] **Empty slices**: Prefer `var t []string` (nil) over `t := []string{}` (non-nil zero-length) → [go-data-structures](../go-data-structures/SKILL.md)
- [ ] **Copying**: Be careful copying structs with pointer/slice fields; don't copy `*T` methods' receivers by value → [go-data-structures](../go-data-structures/SKILL.md)

---

## Security

- [ ] **Crypto rand**: Use `crypto/rand` for keys, not `math/rand` → [go-defensive](../go-defensive/SKILL.md)
- [ ] **Don't panic**: Use error returns for normal error handling; panic only for truly exceptional cases → [go-defensive](../go-defensive/SKILL.md)

---

## Declarations and Initialization

- [ ] **Group similar**: Related `var`/`const`/`type` in parenthesized blocks; separate unrelated → [go-declarations](../go-declarations/SKILL.md)
- [ ] **var vs :=**: Use `var` for intentional zero values; `:=` for explicit assignments → [go-declarations](../go-declarations/SKILL.md)
- [ ] **Reduce scope**: Move declarations close to usage; use if-init to limit variable scope → [go-declarations](../go-declarations/SKILL.md)
- [ ] **Struct init**: Always use field names; omit zero fields; `var` for zero structs → [go-declarations](../go-declarations/SKILL.md)
- [ ] **Use `any`**: Prefer `any` over `interface{}` in new code → [go-declarations](../go-declarations/SKILL.md)

---

## Functions

- [ ] **File ordering**: Types → constructors → exported methods → unexported → utilities → [go-functions](../go-functions/SKILL.md)
- [ ] **Signature formatting**: All args on own lines with trailing comma when wrapping → [go-functions](../go-functions/SKILL.md)
- [ ] **Naked parameters**: Add `/* name */` comments for ambiguous bool/int args, or use custom types → [go-functions](../go-functions/SKILL.md)
- [ ] **Printf naming**: Functions accepting format strings end in `f` for `go vet` → [go-functions](../go-functions/SKILL.md)

---

## Style

- [ ] **Line length**: No rigid limit, but avoid uncomfortably long lines; break by semantics, not arbitrary length → [go-style-core](../go-style-core/SKILL.md)
- [ ] **Naked returns**: Only in short functions; explicit returns in medium/large functions → [go-style-core](../go-style-core/SKILL.md)
- [ ] **Pass values**: Don't use pointers just to save bytes; pass `string` not `*string` for small fixed-size types → [go-performance](../go-performance/SKILL.md)
- [ ] **String concatenation**: `+` for simple; `fmt.Sprintf` for formatting; `strings.Builder` for loops → [go-performance](../go-performance/SKILL.md)

---

## Logging

- [ ] **Use slog**: New code uses `log/slog`, not `log` or `fmt.Println` for operational logging → [go-logging](../go-logging/SKILL.md)
- [ ] **Structured fields**: Log messages use static strings with key-value attributes, not fmt.Sprintf → [go-logging](../go-logging/SKILL.md)
- [ ] **Appropriate levels**: Debug for developer tracing, Info for notable events, Warn for recoverable issues, Error for failures → [go-logging](../go-logging/SKILL.md)
- [ ] **No secrets in logs**: PII, credentials, and tokens are never logged → [go-logging](../go-logging/SKILL.md)

---

## Imports

- [ ] **Import groups**: Standard library first, then blank line, then external packages → [go-packages](../go-packages/SKILL.md)
- [ ] **Import renaming**: Avoid unless collision; rename local/project-specific import on collision → [go-packages](../go-packages/SKILL.md)
- [ ] **Import blank**: `import _ "pkg"` only in main package or tests → [go-packages](../go-packages/SKILL.md)
- [ ] **Import dot**: Only for circular dependency workarounds in tests → [go-packages](../go-packages/SKILL.md)

---

## Generics

- [ ] **When to use**: Only when multiple types share identical logic and interfaces don't suffice → [go-generics](../go-generics/SKILL.md)
- [ ] **Type aliases**: Use definitions for new types; aliases only for package migration → [go-generics](../go-generics/SKILL.md)

---

## Testing

- [ ] **Examples**: Include runnable `Example` functions or tests demonstrating usage → [go-documentation](../go-documentation/SKILL.md)
- [ ] **Useful test failures**: Messages include what was wrong, inputs, got, and want; order is `got != want` → [go-testing](../go-testing/SKILL.md)
- [ ] **TestMain**: Use only when all tests need common setup with teardown; prefer scoped helpers first → [go-testing](../go-testing/SKILL.md)
- [ ] **Real transports**: Prefer `httptest.NewServer` + real client over mocking HTTP → [go-testing](../go-testing/SKILL.md)

---

## Automated Checks

Run automated pre-review checks:

```bash
bash scripts/pre-review.sh ./...         # text output
bash scripts/pre-review.sh --json ./...  # structured JSON output
```

Or manually: `gofmt -l <path> && go vet ./... && golangci-lint run ./...`

Fix any issues before proceeding to the checklist above. For linter setup and configuration, see [go-linting](../go-linting/SKILL.md).

---

## Related Skills

- **Style foundations**: See [go-style-core](../go-style-core/SKILL.md) when resolving formatting debates or applying the clarity > simplicity > concision priority
- **Linting setup**: See [go-linting](../go-linting/SKILL.md) when configuring golangci-lint or adding automated checks to CI
- **Error strategy**: See [go-error-handling](../go-error-handling/SKILL.md) when reviewing error wrapping, sentinel errors, or the handle-once pattern
- **Naming conventions**: See [go-naming](../go-naming/SKILL.md) when evaluating identifier names, receiver names, or package-symbol stuttering
- **Testing patterns**: See [go-testing](../go-testing/SKILL.md) when reviewing test code for table-driven structure, failure messages, or helper usage
- **Concurrency safety**: See [go-concurrency](../go-concurrency/SKILL.md) when reviewing goroutine lifetimes, channel usage, or mutex placement
- **Logging practices**: See [go-logging](../go-logging/SKILL.md) when reviewing log usage, structured logging, or slog configuration

© cxuu · Apache-2.0 · cxuu/golang-skills

Смотрите также

Спонсоры проекта

Компании, которые помогают держать аналитику открытой