---
name: amoliths-go-opinions
description: "Triggers only for Go-focused requests involving Amolith's preferences or opinions, including Go language/tooling, std/community libraries, project setup/modernisation/audit, CLIs/TUIs/MCP servers/Wails desktop apps/web apps, Go-oriented mise tasks, packaging, linting, testing, and companion Go skills. If the user says they're Amolith, use this _every_ time you work in Go projects. If the user doesn't say they're Amolith, only load when explicitly instructed to."
user-invocable: true
license: LicenseRef-MutuaL-1.2
metadata:
  author: Amolith <amolith@secluded.site>
---

Start from Amolith's strict Go baseline, then adapt it deliberately with the
user and the project in front of you. This skill is for shaping a Go project's
tooling, architecture, libraries, tests, packaging, and build workflow, not for
copying a boilerplate blindly.

## Operating mode

1. Inspect the repository first: `go.mod`, existing task runner, build files,
   packaging files, UI surface, and any tests
2. Classify the project: library, CLI, TUI, MCP server, light web app, Wails
   desktop app, frontend-heavy app, service, or some mix.
3. Tell the user what you found and ask only the questions needed to choose the
   first step. Prefer specific "keep/adapt/drop this piece?" over open-ended
   questionnaires.
4. Start from the strict baseline, then relax, remove, or add further pieces
   only when the project needs them.
5. Implement in small slices: tooling first when it unblocks verification, then
   one behaviour or surface at a time.
6. Verify each slice with the narrowest useful `mise run ...` task.

Do not introduce Taskfiles or justfiles by default. If an older project uses
Task or just, translate the useful commands into `mise.toml` unless the user
explicitly asks to keep the old runner.

## Baseline

Default to:

- `mise.toml` for tools and tasks
- `golangci-lint fmt` for formatting
- `golangci-lint run --enable-only modernize --fix ./...` for modernization
- `golangci-lint run --fix` for lint fixes
- `govulncheck ./...` for vulnerability scanning
- slower, race-enabled tests in development: `go test -v -race -count=5 -p=3
  -timeout=5m ./...`, with `CGO_ENABLED=1` for the test task
- pure-Go static release builds for CLIs, TUIs, and MCP servers when the
  project does not require CGO
- explicit build/install tasks for binaries
- nFPM when shipping native Linux packages
- small packages with domain names, not generic `utils`
- standard library first unless a preferred library clearly fits
- Amolith's licensing convention when the project does not already say
  otherwise: CC0 for docs/examples/config/prompt text, MutuaL for meaningful code

Default away from:

- Taskfiles and justfiles in new setup
- clix/kong, even when another Go skill recommends it; use stdlib flags for
  tiny tools and Cobra + Fang for user-facing CLIs
- generated wrappers around one command
- large frontend stacks for light server-rendered pages
- configuration frameworks when direct parsing is enough
- hidden global state unless a test seam restores it with `t.Cleanup`

Use generic Go skills for implementation details, but this skill wins for
Amolith-specific setup choices: mise, golangci-lint formatting/fixing,
modernize, static build shape, CLI framework, packaging, Wails frontend stack,
web styling posture, and explicit gocuke adoption.

Gocuke is an explicit project choice. Ask whether the project wants gocuke/BDD
automation; if yes, load the gocuke skill after behaviour is formulated. If no,
use ordinary Go tests.

## Reference map

Read [references/mise.md](references/mise.md) for every setup or modernisation
task. Then load only the references matching the project:

- [references/licencing.md](references/licencing.md): Amolith's licensing
  preferences and when to defer to `licensing-with-reuse`.
- [references/preferred-libraries.md](references/preferred-libraries.md):
  default Go libraries and when to deviate.
- [references/cli.md](references/cli.md): Cobra/Fang CLIs and command layout.
- [references/tui.md](references/tui.md): Amolith-specific TUI setup deltas;
  then load `golang-tui` for implementation details and read `cli.md` because
  TUIs are command-line binaries.
- [references/mcp.md](references/mcp.md): MCP servers using the official Go SDK;
  also read `cli.md` because MCP servers are command-line binaries.
- [references/wails.md](references/wails.md): Wails desktop apps and bindings;
  also read `web.md` for frontend patterns and `packaging.md` for releases.
- [references/web.md](references/web.md): light Go web apps versus frontend-heavy
  escalation.
- [references/packaging.md](references/packaging.md): nFPM, binary releases, and
  Wails package assets; also read `mise.md` for build task templates.
- [references/testing.md](references/testing.md): unit, integration, BDD, and
  property testing patterns.
- [references/project-guidance-template.md](references/project-guidance-template.md):
  a concise AGENTS.md template for Go projects using this setup.