StemCode for Go Developers: AI Coding with modules, gopls, and real tests.

Give StemCode durable repository instructions before asking it to edit.

Add an AGENTS.md file at the repository root for persistent project instructions. StemCode loads AGENTS.md or .agent/AGENTS.md from the workspace into the model context, so this is the right place for architecture boundaries, generated-file rules, coding conventions, validation expectations, and manual setup notes that should apply across sessions.

# Go Project Instructions

This is a Go project.

Important source and configuration paths:
- go.mod
- go.sum
- go.work
- cmd/
- internal/
- pkg/
- *_test.go

Generated or disposable paths — do not modify:
- bin/
- dist/
- coverage.out
- tmp/
- generated output not reviewed as source

Follow these rules:
- Follow standard gofmt formatting.
- Keep package dependencies acyclic and simple.
- Prefer the repository's existing error and logging conventions.
- Propagate context cancellation through request-scoped work.
- Do not edit generated Go files unless the generator workflow explicitly requires it.
- Run focused tests before repository-wide go test ./....

Validation:
- gofmt -w <changed-go-files>
- go vet ./...
- go test ./...
- go build ./...

Commit the file with the project so the same instructions are reviewable and shared by everyone using StemCode in the repository.

Use repository-aware AI without replacing the tools your stack already needs.

StemCode works best when it can understand the repository around a task, inspect related files, use code intelligence where available, run the project's normal validation commands, and review the final diff before you accept a change.

Install StemCode and open the project root.

Launch StemCode from the module or workspace root so go.mod, go.sum, workspace files, internal packages, commands, tests, generated-code rules, and Git history are available together.

cd your-project
stemcode
/init

Keep StemCode at the repository root so project instructions, source, configuration, tests, and Git history are visible from one workspace.

Expose package boundaries and tests while excluding generated binaries and caches.

Go repositories are usually easy to analyze when package structure, module files, generated-code markers, and tests remain visible. Keep temporary build output and vendored/generated data out of the search path when it is not authoritative source.

go.mod
go.sum
go.work
cmd/
internal/
pkg/
*_test.go

bin/
dist/
coverage.out
tmp/
generated output not reviewed as source

Add generated paths to Git ignore rules or .stemcode/.stemcodeignore so repository search stays focused.

Use gopls for semantic Go navigation and diagnostics.

gopls provides definitions, references, diagnostics, implementations, and type information that are especially useful when interfaces and package boundaries spread behavior across the repository.

/lsp refresh
/lsp

Trace interfaces and package ownership before changing implementations.

Good Go changes usually preserve simple package boundaries, explicit dependencies, small interfaces, and straightforward error handling. Ask StemCode to discover those conventions before adding abstractions.

Keep gofmt, vet, tests, and the real build in the loop.

Go’s standard toolchain provides a strong validation baseline. Use repository-specific Makefile, Taskfile, or CI commands when they add generated-code, race, lint, integration, or container checks.

For concurrency changes, run the repository’s race-enabled tests when available. For large modules, begin with the affected package and then expand to ./... after the focused checks pass.

Run the smallest relevant validation first. If it passes, run the broader project checks and review the final diff.

Keep longer-lived architecture context alongside your project instructions.

Use AGENTS.md for concise rules the agent should follow on every task. Keep longer architecture notes, domain context, and workflow references in repository-level StemCode memory so both stay reviewable and versionable.

Follow standard gofmt formatting.
Keep package dependencies acyclic and simple.
Prefer the repository's existing error and logging conventions.
Propagate context cancellation through request-scoped work.
Do not edit generated Go files unless the generator workflow explicitly requires it.
Run focused tests before repository-wide go test ./....

Review the change in terms of your stack, not only the generated code.

Ask StemCode to inspect its own diff and check the integration points that are easiest to miss in a repository-wide change.

- context cancellation and deadlines
- goroutine and channel lifetime
- error wrapping and propagation
- interface ownership and package coupling
- data races and shared state
- API compatibility
- generated-code workflow
- go vet, tests, and build results

Common setup questions.

Does StemCode work with gopls?

Use gopls as the Go language-intelligence layer and combine it with repository search for configuration, generated code, SQL, migrations, and other non-Go context.

What about Gin, Fiber, chi, or gRPC?

Keep the framework already used by the repository. The workflow is the same: trace routing and middleware into service logic, persistence, external calls, and tests before editing.

Should vendor be indexed?

Only when the repository intentionally commits and reviews vendor code as part of development. In most tasks, module source and your own packages are the useful context.

Put StemCode to work in a real repository.

Install StemCode, open the project you already work in, and begin with a repository-understanding task before asking the agent to change code. That gives the model better context and keeps the workflow reviewable.

npm install -g stemcode
cd your-project
stemcode