Check out my configuration for Continue that finally made it useful for Go development.

Hey everyone! 👋 I've been wrestling with Continue for my Go projects for *weeks*. Out of the box, it felt a bit too generic—it would suggest code that didn't follow our patterns, hallucinate non-existent libraries, and just generally felt like it wasn't really "understanding" the Go ecosystem. I was about to write it off, but then I spent a solid weekend deep-diving into its configuration.

Turns out, with a fairly detailed `.continuerc.json`, you can transform it from a frustratingly general assistant into a powerhouse for Go. The key was being **extremely specific** about context, constraints, and the tools it should use.

Here's my current configuration, which has made it an indispensable part of my workflow. The main pillars are: **contextual awareness**, **enforcing Go conventions**, and **leveraging the right underlying models.**

```json
{
"models": [
{
"title": "Claude 3.5 Sonnet",
"provider": "openai",
"model": "claude-3-5-sonnet-20241022",
"apiBase": "https://api.openai.com/v1",
"apiKey": ""
},
{
"title": "Ollama: Codellama",
"provider": "ollama",
"model": "codellama:13b-instruct"
}
],
"modelRoles": {
"default": "Claude 3.5 Sonnet",
"chat": "Claude 3.5 Sonnet",
"edit": "Ollama: Codellama"
},
"tabAutocompleteModel": {
"provider": "ollama",
"model": "codellama:13b-instruct"
},
"contextProviders": [
{
"name": "code",
"params": {
"useCodeSnippets": true
}
},
{
"name": "docs",
"params": {}
},
{
"name": "diff",
"params": {}
},
{
"name": "terminal",
"params": {}
},
{
"name": "github",
"params": {}
},
{
"name": "websearch",
"params": {}
}
],
"customCommands": [
{
"name": "go-generate-mocks",
"prompt": "Generate a mock implementation for the given Go interface using the 'github.com/stretchr/testify/mock' package. Follow our project's mock naming convention: prefix with 'Mock' and place in a `mocks` directory.",
"description": "Creates a testify mock for a Go interface"
},
{
"name": "go-add-error-handling",
"prompt": "Review this code block and add comprehensive error handling. In Go, every error must be checked and logged appropriately with context. Return early on errors. Use wrapped errors with fmt.Errorf where applicable.",
"description": "Enforces robust Go error handling patterns"
}
],
"slashes": {
"share": {
"description": "Share selected code",
"prompt": "I would like to share the following code: {{selected_code}}"
}
},
"systemMessage": "You are an expert Go developer. Adhere strictly to: 1) The standard Go style guide (gofmt). 2) Use pointer receivers only when necessary. 3) Prefer composition over inheritance. 4) Write table-driven tests for functions with multiple test cases. 5) Use `context.Context` for propagation and cancellation. 6) Never suggest the use of `panic` for normal error flow. 7) Suggest `go.uber.org/zap` for logging. Assume the project uses Go 1.21+. Always consider performance implications and concurrency safety."
}
```

**Why this setup works so well:**

* **Model Roles:** I use Claude 3.5 Sonnet for chat/complex reasoning because it's fantastic at understanding intent and our codebase context. But for quick, localized edits and tab-autocomplete, a locally-run Codellama model via Ollama is faster and perfectly adequate. This balance keeps costs and latency down.
* **Aggressive Context:** The `contextProviders` section is crucial. `terminal`, `diff`, and `github` mean the assistant knows what commands I just ran, what I just changed, and can even pull in relevant issue/PR context. It stops the "out of nowhere" suggestions.
* **System Message as Enforcer:** This is the most important part. The `systemMessage` isn't just "you are helpful"; it's a strict coding standards document. It preemptively corrects common LLM tendencies (like overusing pointers or suggesting panics) and bakes in our team's preferences (like using Zap for logging).
* **Custom Commands for Repetitive Tasks:** The `go-generate-mocks` and `go-add-error-handling` commands save me *so much* time. They ensure consistency across the codebase for tasks that are otherwise tedious and prone to variation.

**A concrete example from yesterday:** I was working on a new HTTP handler. I selected a block of struct definitions and used `/go-add-error-handling`. It not only added the error checks but also correctly wrapped the errors with the function name and used a sentinel error for a specific not-found case—exactly as our style guide dictates. It felt like pairing with a very pedantic, but brilliant, teammate.

The journey from "this is neat but useless" to "I can't work without this" was all about configuration. It's a fantastic tool, but you have to teach it your world. I'd love to hear if other Go devs have different prompts or configurations that have worked for them! What's in your `.continuerc.json`?