gsi: A Go Scaffold App to Reduce AI Agent Guessing
AI coding assistants learn from whatever they find in your repo. On a new project, there's nothing to find. The AI often picks libraries you don't prefer and burns tokens sorting out the basics before writing a useful line of code. Across existing projects with inconsistent choices, it has to rediscover your preferences every time. I wanted every project to have the right patterns from the first file. So I built gsi.
What You Get
Running gsi my-app produces a complete, ready-to-build project:
- Cobra + Viper CLI: command structure,
configsubcommands (init, edit, check), version command with build-time ldflags injection - Makefile: organized targets for App, Release, Docs, UI, and Deps, plus a parallel dev runner
- goreleaser + GitHub Actions: release workflow, Linux amd64/arm64, macOS universal binary, Docker images on ghcr.io, Homebrew tap
- mkdocs-material: full docs site in
docs/, managed by uv - Optional React UI: pass
--uifor a React/shadcn/Tailwind frontend with an embedded Goservecommand and SPA routing - BMAD method: AI-assisted development framework, installed via bun
- Extras: .editorconfig, .mockery.yml, Dockerfile, git init with .gitignore
Every feature is toggleable. Pass --no-docker, --no-goreleaser, or any other --no-<feature> flag to skip what you don't need. Missing tools like bun or uv are detected automatically and their features silently disabled.
You can preview what it generates with --dry-run, skip the docs scaffold with --skip-docs, or generate only docs for an existing project with --only-docs. gsi is also idempotent. It won't clobber existing files, so you can safely run it against a project that already exists.
The Real Payoff
Every scaffolded project has the libraries already wired into go.mod and a version command that makes the stack visible. When an AI assistant opens the project, it sees the established patterns and follows them. No tokens burned on "which config library should we use?" The answer is already in the code.
This works because it's precedent, not instruction. You could write a config file listing your preferred libraries. But dependencies in go.mod and working code that uses them is a stronger signal. The AI reads the existing implementation and matches it.
Standardization across projects makes this even better. Every project uses the same libraries and the same structure. No drift from grabbing whatever was trending that week. The AI doesn't have to relearn your preferences each time. Less context spent on discovery, more available for the actual work.
Every new project I start uses this now. Install it with Homebrew and try it out.
brew install joescharf/tap/gsi
Source and docs: github.com/joescharf/gsi