Developing the SDK
The SDK’s source is github.com/smarter-sh/smarter-golang.
It follows the platform’s practices and architecture decisions, the
Python SDK, which is the reference implementation, and the
Smarter CLI, which is also written in Go: the same features, the same tests,
the same recorded responses, the CLI’s Go hooks (gofmt, go vet, goimports, golangci-lint),
semantic versioning and conventional commits. Its own decisions are recorded in its doc/adr/
folder, numbered as the Python SDK’s, and its Agent Skills in skills/ describe how it is
developed, for people and for AI coding agents.
git clone https://github.com/smarter-sh/smarter-golang.git
cd smarter-golang
make init # the release tooling, and the pre-commit hooks
make test # the unit tests, with the race detector
make coverage # with coverage
make vet # go vet and golangci-lint
Tests
The unit tests never reach a platform: a RoundTripper answers every request, with sanitized
copies of real platform responses, the same files as the Python SDK’s. The package’s runnable
examples, which pkg.go.dev shows, are tests too. They run in CI on every supported Go release,
which also checks that coverage stays at 90% or more.
The live tests check the SDK against a running platform. They decode real responses into every
struct, including a Describe of a real resource of every kind, decoded into its SAM struct.
They prompt an LLMClient, which makes billable LLM requests, and they never deploy anything.
SMARTER_BASE_URL=http://localhost:9357 SMARTER_API_KEY=<api key> make test-live
Keeping in step with the platform
Command |
What it refreshes |
|---|---|
|
The platform’s api contract, from a checkout of the
platform beside the SDK ( |
|
|
When the platform changes a contract or a manifest kind, refresh, run the tests, and fix what they find. The tests also fail when the platform publishes an API operation that the SDK doesn’t call. The API reference is pkg.go.dev, which a release tag updates.