go-style-guide

# Go Style Guide Reviewer

Review Go code against comprehensive style guide, focusing on critical bugs and important maintainability issues.

**This guide assumes Go 1.25+ and does not consider backwards compatibility.** All patterns use modern Go best practices.

## Reference Files

Load references based on code patterns found during review:

| Code Pattern | Reference File |
|--------------|----------------|
| `go func()`, `sync.Mutex`, `sync.`, channels, atomic | `references/concurrency.md` |
| `err`, `error`, `panic`, `Must` functions | `references/errors.md` |
| `interface`, embedding, receivers, `func New`, `init()` | `references/api-design.md` |
| slice/map return, `slices.Clone`, `maps.Clone` | `references/api-design.md` |
| `_test.go`, `t.`, `b.` | `references/testing.md` |
| naming, comments, logging | `references/style.md` |

**Quick reference**: `references/review-checklist.md` - critical patterns with code examples

**Note**: "Copying at boundaries" lives in api-design.md but relates to concurrency safety - check both when ownership/encapsulation is the concern.

## Quick Style Reference

Basic rules that don't need a file lookup:

- **Package names**: lowercase, no underscores, singular (`net/url` not `net/urls`)
- **Receiver names**: 1-2 letters, consistent across all methods (`func (c *Client) Connect()`)
- **Error strings**: lowercase, no punctuation (`errors.New("connection failed")`)
- **Variable names**: short for small scopes (`i`, `v`), longer for large scopes (`requestTimeout`)

## Review Process

Follow this 3-phase workflow for systematic code review:

### Phase 1: Scope Identification

Determine what code to review based on the user's request:

**Pull Request / Branch Review**:
```bash
# Get all changed files in branch
git diff --name-only main...HEAD | grep '\.go$'

# Get diff with context
git diff main...HEAD
```

**Specific Files**:
```bash
# User specifies file(s) directly
# Read the files using the Read tool
```

**Recent Work**:
```ba