ds-go-review
Skill20 starsChanged 47 days agoMITView on GitHub
Review Go code with Tiger Style constraints and Go idioms.
In this repository52 other files it gives its agents.
- ds-dev-skill-benchSkill
- ds-agent-reviewSkill
- ds-architecture-planSkill
- ds-arenaSkill
- ds-blast-radiusSkill
- ds-blueprintSkill
- ds-bug-reviewSkill
- ds-clarity-reviewSkill
- ds-code-quality-reviewSkill
- ds-comment-reviewSkill
- ds-data-modeSkill
- ds-data-reviewSkill
- ds-debugSkill
- ds-deslopSkill
- ds-doc-quality-reviewSkill
- ds-exploreSkill
- ds-git-modeSkill
- ds-grill-meSkill
- ds-handoffSkill
- ds-howSkill
- ds-humanizeSkill
- ds-interaction-modeSkill
- ds-java-reviewSkill
- ds-notebook-reviewSkill
- ds-onboardingSkill
- ds-osvSkill
- ds-perf-planSkill
- ds-project-checkpointSkill
- ds-project-resumeSkill
- ds-python-reviewSkill
- ds-quality-gateSkill
- ds-reflectSkill
- ds-retroSkill
- ds-roadmapSkill
- ds-rust-reviewSkill
- ds-security-reviewSkill
- ds-semgrepSkill
- ds-shell-reviewSkill
- dsSkill
- ds-specSkill
- ds-step-modeSkill
- ds-tdd-modeSkill
- ds-test-modeSkill
- ds-test-quality-reviewSkill
- ds-tiger-style-modeSkill
- ds-tldtSkill
- ds-ts-reviewSkill
- ds-ui-modeSkill
- ds-ui-quality-reviewSkill
- ds-verify-thisSkill
- ds-zig-reviewSkill
- ds-zoom-outSkill
The file
We split this skill into the rules it gives an agent
1 rule. About 0 are common, 0 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈0
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 22
Use the checklist as a lens, not a scorecard: reason about the actual change, report real violations anchored to file:line, and flag issues …
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Applies to: Go 1.24+. Backend services, CLIs, APIs.
Arguments
Scan the invocation for the --no-tiger, --fix, and --full flags. Treat every other argument as review scope (files or directories); if no scope is given, review the changed files on the current branch.
--no-tigerpresent → skip the Tiger Style section; run Go Idioms, Performance, Security, and Testing only.--no-tigerabsent → run all sections (default).--fix→ after reporting, apply only the violations whose fix is mechanical and unambiguous (a rename to the idiom, a missing error check the review is certain about). Anything that changes logic or rests on an unverified assumption — especially security and correctness findings — stays report-only. After applying, re-run any build/test/lint check already in the loop and revert any fix that breaks it — or that touched more than the intended mechanical edit. End with a summary of what was applied and what was left.--full→ review the entire codebase instead of just the branch's changes. Explicit positional scope still wins;--fullonly replaces the no-scope default.
Example: /ds-go-review --no-tiger dir1/ dir2/ reviews dir1/ and dir2/ without Tiger Style.
Review Checklist
Use the checklist as a lens, not a scorecard: reason about the actual change, report real violations anchored to file:line, and flag issues even when they aren't listed. Don't manufacture findings to fill a category. Report only violations — no praise, no summary.
Tiger Style
Skip this section entirely if --no-tiger was passed. Otherwise it is mandatory.
- Non-trivial functions assert their preconditions and key invariants — don't demand assertions in thin wrappers or trivial accessors
- All loops have explicit bounds; no unbounded iteration over external input
- No recursion without provable termination
- All errors explicitly handled — no
_discard of error returns - No post-initialization dynamic allocation in paths actually identified as hot — don't flag ordinary allocation
- Functions under 70 lines
- Variable names include units/qualifiers where applicable
Go Idioms
- Errors are values. Check them. Wrap with context using
fmt.Errorf("op: %w", err) - Interfaces defined at point of use (consumer package), not in producer package
- No exported interface with a single method that could be a function
- Goroutines have explicit lifecycle: context cancellation, WaitGroup, or channel close
- No goroutine leak: every goroutine has a clear exit condition
- Context is first parameter when present:
func F(ctx context.Context, ...) - Prefer table-driven tests
- No
init()functions that have side effects - Struct fields that are sync primitives (Mutex, WaitGroup) are not copied — pointer receivers used
- Prefer stdlib
slices/maps/cmpand themin/max/clearbuiltins over hand-rolled equivalents;for i := range nfor integer counts - Sequences exposed as
iter.Seq/iter.Seq2where iteration is the public API (Go 1.23+) json:",omitzero"(notomitempty) when the intent is to omit zero values — notably zerotime.Time- Tool dependencies declared in
go.mod(go get -tool, run viago tool), not a legacytools.goblank-import shim (Go 1.24+) - Structured logging via stdlib
log/slog(Go 1.21+), not the unstructuredlogpackage or a third-party logger pulled in out of habit - Legacy idioms a modernizer would rewrite are flagged — pre-
slices/mapshelpers,interface{}overany, manualb.Nloops (rungolangci-lint'smodernize, orgo fixon Go 1.26+)
Performance
Idiom-level checks only — for a ranked, costed optimization plan, use /ds-perf-plan.
- No allocation in request hot path (profile with
go test -benchmemif critical) - Slice pre-allocated with
make([]T, 0, knownCap)where capacity is known sync.Poolused for frequently allocated/freed objects in hot paths- No manual
runtime.GOMAXPROCStuning orautomaxprocsin containers — Go 1.25+ honors the cgroup CPU quota automatically - Database queries not issued inside loops
- N+1 query patterns absent
Security
- No
fmt.Sprintfconstructing SQL queries — use parameterized queries - No
exec.Commandwith unsanitized user input - Filesystem paths built from user input go through
os.OpenRoot/*os.Root, not manualfilepath.Clean/prefix checks — blocks traversal and symlink escape (Go 1.24+) - No hardcoded credentials or secrets
- HTTP handlers validate and bound all user-controlled inputs
http.Serversets ReadTimeout/WriteTimeout/IdleTimeout;http.ClientsetsTimeoutor uses context deadlines
Testing
- Public surface and error paths have meaningful coverage — flag notable gaps, not every untested accessor
- Error paths tested, not just happy path
- Benchmarks for performance-critical functions, written with
for b.Loop()rather than a manualfor i := 0; i < b.Nloop (Go 1.24) - No
time.Sleepin tests — use channels or sync primitives, ortesting/synctest's fake clock for time-dependent concurrency (Go 1.25+)
Version-specific checks
Read the target Go version from go.mod (the go directive). Run the checklist above for every project. If it targets Go 1.26 or newer, also read 1.26.md in this skill directory and apply its checks on top. If the version can't be determined, run the base and note that version-specific checks were skipped.
Output Format
<file>:<line>: <severity>: <problem>. <fix>.Severity levels: critical (correctness/security), major (reliability/performance), minor (idiom/style).
Skip formatting nits unless they affect correctness or readability significantly.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

