Golang prompts for ChatGPT, Claude and Codex

The best golang prompts give the model your Go version, the real code and the output of Go's own tools (go vet, the race detector, failing tests), then ask for idiomatic Go with every error handled. Below are 12 Go prompts for ChatGPT, Claude, Claude Code and Codex covering idiomatic code, error handling, concurrency, testing and keeping a project healthy.

For general jobs such as explaining code, writing a regex or a commit message, see the coding prompts. For designing the HTTP API itself, see the API design prompts. The prompts here are specific to Go.

How to use these prompts

Copy a prompt, replace each blank in double braces, or keep the default after the colon. {{go_version:the version in my go.mod}} means the model should assume that version unless you change it.

Three habits make the answers better:

• State your Go version. Generics arrived in Go 1.18, and each new release adds language and standard library features. The release history says "Each major Go release is supported until there are two newer major releases." Go 1.27 came out on 19 August 2026.
• Paste tool output, not descriptions. Race detector reports, go vet warnings and test failures carry file and line numbers the model can work from.
• Ask for exit paths. For any goroutine the model writes, ask how it stops. Most leaks come from goroutines that never do.

In an agent, point it at the package and let it run go test itself.

How do you write idiomatic Go with AI?

1. Review code for Go idioms

For code written by someone coming from another language. Effective Go is still the reference for style, though it notes it was written for Go's 2009 release and does not cover generics or modules.

Review this Go code for idiomatic style, targeting Go {{go_version:the version in my go.mod}}.

Check: naming (short receivers, no Get prefix on getters, MixedCaps),
error handling (no ignored errors, errors returned rather than panics),
early returns instead of deep nesting, zero values that are useful, and
whether gofmt would change anything.

For each issue, show the before and after and one sentence on why. Do not
change behavior or exported names unless I agree.

{{code}}

2. Design small interfaces

For code that defines a big interface up front or takes concrete types it doesn't need. Effective Go names one-method interfaces with an -er suffix, like Reader and Writer.

This Go code depends on {{dependency:a concrete database client}} directly,
which makes it hard to test:

{{code}}

Define the smallest interface this code actually needs, declared next to
the code that uses it, not next to the implementation. Name it in Go style.
Show the refactored function, a fake implementation for tests, and one test
that uses the fake. Explain any method you left out of the interface.

3. Port code to Go

For moving a service or script from another language. Asking for Go's way of doing things avoids class hierarchies and exceptions translated line by line.

Port this {{from:Python}} code to idiomatic Go {{go_version:the version in my go.mod}}.

- Return errors instead of raising exceptions, and wrap them with context.
- Use structs and small interfaces instead of class hierarchies.
- Use the standard library where possible and list any module you add.
- Keep the same behavior, including edge cases.

After the code, list every place where the two versions behave
differently, such as integer overflow, string indexing by byte versus
character, or nil maps.

{{code}}

How do you handle errors in Go?

4. Add context to errors

For code that returns bare errors, so logs say "file not found" with no clue which file. The Go 1.13 errors post explains %w, errors.Is and errors.As, and advises: "Do not wrap an error when doing so would expose implementation details."

Improve error handling in this Go code.

- Add context to each returned error with fmt.Errorf and %w, saying what
the code was trying to do (for example, "load config %s: %w").
- Decide for each error whether to wrap with %w or format with %v, based
on whether callers should be able to inspect the inner error. Say why.
- Replace string comparisons on error messages with errors.Is or errors.As.
- Do not log and return the same error.

{{code}}

5. Design errors for a package

For a package that other code calls. Callers need to tell "not found" from "timed out" without parsing strings.

Design the errors for this Go package: {{package_description}}.

Callers need to distinguish: {{cases:not found, invalid input, temporary failure}}.

Propose sentinel errors, custom error types, or both, and explain the
choice for each case. Show how a caller checks each one with errors.Is or
errors.As. Then update this code to return them:

{{code}}

How do you get Go concurrency right?

6. Build a worker pool with cancellation

For processing many items in parallel without starting one goroutine per item or leaking them on error. Effective Go sums up the approach: "Do not communicate by sharing memory; instead, share memory by communicating."

Write Go code that processes {{count:10,000}} items with at most {{workers:8}}
running at once.

Requirements:
- Accept a context.Context and stop promptly when it is cancelled.
- On the first error, {{on_error:cancel the remaining work and return the error}}.
- Every goroutine must exit when the function returns; explain how each
one stops.
- Keep results in input order.
- Standard library only.

Include a test that cancels the context halfway and checks no goroutines
are left running.

What each item does: {{work}}

7. Fix a data race

For a report from the race detector, which you turn on with -race, for example go test -race mypkg. It only finds races in code paths that actually run.

The Go race detector reported this:

{{race_report}}

Code involved:
{{code}}

Explain in plain language which two goroutines touch the same memory and
in what order. Then fix it, choosing between a mutex, a channel, an atomic
or removing the shared state, and say why that choice fits. Suggest a test
that would have triggered the race reliably under -race.

8. Find a goroutine leak

For memory or goroutine counts that grow over time. A goroutine dump shows where they are stuck.

My Go service's goroutine count grows from {{start:200}} to {{end:20,000}}
over a day.

Goroutine profile or dump (summary):
{{profile}}

Code for the functions that appear most:
{{code}}

Find where goroutines get stuck (blocked send, receive with no sender,
missing context cancellation, unclosed response body) and fix each one.
For every goroutine in the fixed code, state the condition that makes it
exit.

How do you test Go code with AI?

9. Write table-driven tests

For functions with many input cases. Table-driven tests are the common Go pattern, and naming each case makes failures readable.

Write table-driven tests for this Go function using only the testing
package.

{{code}}

Use a slice of named cases and t.Run for each. Cover the normal case,
boundaries (zero, empty, nil, max values), invalid input and every error
path. Compare errors with errors.Is where the code returns sentinel
errors. Mark tests that can run in parallel with t.Parallel and say why
they are safe to.

10. Write a fuzz test

For parsers, decoders and anything that takes untrusted input. The Go fuzzing docs say native fuzzing arrived in Go 1.18, that a fuzz test is named like FuzzXxx and takes a *testing.F, and that you run it with go test -fuzz.

Write a Go fuzz test for this function:

{{code}}

- Name it FuzzXxx, take a *testing.F, and add {{seeds:5}} seed inputs with
f.Add, including tricky ones.
- In the fuzz target, check properties that must always hold, such as
"parsing then printing returns the original" or "never panics", not exact
outputs.
- Tell me the exact command to run it and how to turn a failing input into
a regular test case.

How do you keep a Go project healthy?

11. Triage govulncheck results

For security reports on your dependencies. The Go vulnerability docs say govulncheck "only surfaces vulnerabilities that actually affect you, based on which functions in your code are transitively calling vulnerable functions." Install it with go install golang.org/x/vuln/cmd/govulncheck@latest and run govulncheck ./....

Here is the output of govulncheck ./... for my Go module:

{{output}}

go.mod:
{{go_mod}}

For each finding: explain the vulnerability in one sentence, show the call
path from my code, and give the smallest upgrade that fixes it (module and
version). Flag upgrades that cross a major version or need a newer Go
toolchain, and order the fixes by risk.

12. Upgrade the Go version

For bumping the go line in go.mod and using what the new release offers.

I am upgrading this module from Go {{from:1.22}} to Go {{to:1.27}}.

go.mod:
{{go_mod}}

1. List changes between these versions that could affect this code, and
mark which claims I should confirm in the official release notes. Do not
guess.
2. Find places in this code that could use newer standard library
features, and show each rewrite.
3. Give the commands to update go.mod, tidy modules and run the full test
suite with -race.

{{code}}

What should you check before you accept the answer?

AI-written Go tends to fail in the same few places, so check these every time:

• Ignored errors. Search the diff for _ = and calls whose error return is dropped.
• Goroutine exits. Every go statement should have a clear way to stop, usually a cancelled context or a closed channel.
• Tool output. Run gofmt, go vet and go test -race yourself, or have an agent run them and paste the output.
• New dependencies. Check any module the model added; the standard library often already covers it.

Turn your favorite one into a skill

When one of these prompts becomes a daily habit, make it a skill so Claude Code or Codex uses it automatically. The error context and race fix prompts are good first candidates. Paste one into the free SKILL.md generator, which needs no sign-up, and it becomes a valid SKILL.md. For containerizing a Go service, see the Docker prompts. For systems code with a different safety model, see the Rust prompts.

To keep prompts like these close, save them in Kipt. Your library lives as Markdown in a private GitHub repo you own, each blank stays fillable when you copy, and Cmd+K finds any prompt by name or tag.