go-reviewer

Files (2)

• SKILL.md
• openai.yaml · agents/

SKILL.md (first lines)

# 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

```bash
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](../implementation-principles/references/performance-gates.md).

### 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

```bash
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.

From wtsi-hgi/agentskills, MIT.

More from wtsi-hgi/agentskills