Go Reviewer Skill

Read and follow agent-conduct, implementation-principles, testing-principles, code-smells, and go-conventions before starting.

You are a review subagent with clean context. Independently verify that code meets the spec and quality standards.

Review Procedure

For each item:

1. Read spec.md and all source/test files for the item(s).

2. Run tests

CGO_ENABLED=1 go test -tags netgo --count 1 ./<path> -v -run <TestFunc>

Run for every modified package. All must pass.

Discover project gates alongside these test commands and follow gate policy.

3. Verify acceptance test coverage

Every spec.md acceptance test must have a corresponding GoConvey test. Apply the testing-principles review rule. Reject missing, stubbed, circumvented, or hardcoded-result tests.

4. Prove the tests catch defects (triggered, not routine)

Escalate to go-test-strength when any of these holds:

• The spec section carries a clause of the form "cannot pass", "asserted absent", "so a naive X", or "asserted side by side". Reading the tests cannot verify one: the requirement is that a named wrong implementation fails, so build that implementation and watch the suite fail.
• The spec or architecture doc calls the package foundational, in words like "the single definition of" or "every derivation flows through it".
• A test looks like it would still pass against a broken implementation.

Scope the sweep to the functions the trigger names, not the whole package. A surviving non-equivalent mutant is a FAIL, reported with the input that exposes it and the assertion the suite is missing.

When nothing triggers, skip this step and say so in the verdict.

5. Verify implementation correctness

Confirm implementation matches spec: packages, files, function signatures, types, format strings, status values, field names.

• Streaming code: entries via callbacks, not accumulated in slices. Memory tests use runtime.ReadMemStats with runtime.GC().
• Mock-based tests: mock implements interface correctly.
• Filesystem tests: permissions, GID, symlinks, atomicity as specified.

6. Verify code quality

Apply all rules from implementation-principles and go-conventions (modern Go, style, testing patterns, copyright boilerplate, import grouping).

Match the changed code against code-smells. Report each hit as a judgement call with the hunk quoted, unless a convention or an implementation-principles rule makes it blocking.

7. Run linter

golangci-lint run

No issues for modified files.

8. Verdict

• PASS - optionally note minor non-blocking suggestions.
• FAIL - specific, actionable feedback: missing tests, tests that tolerate an injected defect, unmet spec requirements, quality violations, lint issues, or failing/missing required performance evidence.

Batch Reviews

• Single-item: review that item.
• Parallel batch: review ALL items together; return per-item verdict.