Reference and make use of `go fix` before having the LLM do more.

[metalmatze]

I came across this skill and it's great.

One thing I wish it would do on systems with the latest 1.26+ Go toolchain would be to the skill actually use the deterministic go fix before then continuing with the examples the skill mentions.

I had my AI read the go fix documentation and then make adjustments to the SKILL.md accordingly.

28a29,54
> **When modernizing existing Go files**, if the **installed toolchain** is Go 1.26 or newer, run `go fix` on the target package(s) **before reading any file**. Go 1.26 rewrote `go fix` to ship the modernize analyzer suite (see https://go.dev/blog/gofix), which mechanically applies most of the rewrites listed below: range-over-int loops, `min`/`max`, `any`, `strings.Cut`, `fmt.Appendf`, `maps.…` migrations, `strings.Builder` for concatenation in loops, redundant `x := x` in range loops, `new(expr)` for pointer helpers, and more.
> 
> ```bash
> go version                            # gate on the installed toolchain
> 
> go fix -diff ./path/to/pkg/...        # preview (the unflagged form writes files in place)
> go fix ./path/to/pkg/...              # apply
> go fix ./path/to/pkg/...              # run a second pass; one fix often enables another
> 
> go build ./path/to/pkg/...            # verify nothing broke
> go test ./path/to/pkg/...
> ```
> 
> Then read the post-fix files and apply manual modernizations from the Features list for anything `go fix` did not catch. Do not Read a Go file you plan to modernize until `go fix` has run on its package, otherwise you will end up doing work the tool would have done for free.
> 
> Caveats:
> 
> - `go fix` only applies a fix when the file's or module's declared Go version permits the target feature (`go 1.X` in `go.mod` or `//go:build go1.X` in the file).
> - Generated files (per `//go:generate`) are skipped. Fix the generator instead.
> - Each run analyzes one build configuration. For code with `GOOS`/`GOARCH` build tags, re-run per combo (e.g. `GOOS=linux GOARCH=amd64 go fix ./...`, then `GOOS=darwin GOARCH=arm64 go fix ./...`).
> - The tool resolves syntactic conflicts but can leave semantic ones (e.g. now-unused variables). Compilation errors after `go fix` are normal and require manual resolution.
> - Prefer committing the `go fix` diff as a separate commit from any manual follow-ups so reviewers can see what the tool produced versus what you wrote.
> - `go tool fix help` lists the available fixers; `-name=false` disables a specific one (e.g. `go fix -minmax=false ./...`).
> 
> If the installed toolchain is older than Go 1.26, skip `go fix` (its older versions only contain a handful of long-deprecated stdlib rewrites that are not useful here) and go straight to reading files and applying the Features list manually.
> 

Feel free to use this diff to update your SKILL. Thanks for sharing it in the first place!