1---
2name: amoliths-go-opinions
3description: "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."
4user-invocable: true
5license: LicenseRef-MutuaL-1.2
6metadata:
7 author: Amolith <amolith@secluded.site>
8---
9
10Start from Amolith's strict Go baseline, then adapt it deliberately with the
11user and the project in front of you. This skill is for shaping a Go project's
12tooling, architecture, libraries, tests, packaging, and build workflow, not for
13copying a boilerplate blindly.
14
15## Operating mode
16
171. Inspect the repository first: `go.mod`, existing task runner, build files,
18 packaging files, UI surface, and any tests
192. Classify the project: library, CLI, TUI, MCP server, light web app, Wails
20 desktop app, frontend-heavy app, service, or some mix.
213. Tell the user what you found and ask only the questions needed to choose the
22 first step. Prefer specific "keep/adapt/drop this piece?" over open-ended
23 questionnaires.
244. Start from the strict baseline, then relax, remove, or add further pieces
25 only when the project needs them.
265. Implement in small slices: tooling first when it unblocks verification, then
27 one behaviour or surface at a time.
286. Verify each slice with the narrowest useful `mise run ...` task.
29
30Do not introduce Taskfiles or justfiles by default. If an older project uses
31Task or just, translate the useful commands into `mise.toml` unless the user
32explicitly asks to keep the old runner.
33
34## Baseline
35
36Default to:
37
38- `mise.toml` for tools and tasks
39- `golangci-lint fmt` for formatting
40- `golangci-lint run --enable-only modernize --fix ./...` for modernization
41- `golangci-lint run --fix` for lint fixes
42- `govulncheck ./...` for vulnerability scanning
43- slower, race-enabled tests in development: `go test -v -race -count=5 -p=3
44 -timeout=5m ./...`, with `CGO_ENABLED=1` for the test task
45- pure-Go static release builds for CLIs, TUIs, and MCP servers when the
46 project does not require CGO
47- explicit build/install tasks for binaries
48- nFPM when shipping native Linux packages
49- small packages with domain names, not generic `utils`
50- standard library first unless a preferred library clearly fits
51- Amolith's licensing convention when the project does not already say
52 otherwise: CC0 for docs/examples/config/prompt text, MutuaL for meaningful code
53
54Default away from:
55
56- Taskfiles and justfiles in new setup
57- clix/kong, even when another Go skill recommends it; use stdlib flags for
58 tiny tools and Cobra + Fang for user-facing CLIs
59- generated wrappers around one command
60- large frontend stacks for light server-rendered pages
61- configuration frameworks when direct parsing is enough
62- hidden global state unless a test seam restores it with `t.Cleanup`
63
64Use generic Go skills for implementation details, but this skill wins for
65Amolith-specific setup choices: mise, golangci-lint formatting/fixing,
66modernize, static build shape, CLI framework, packaging, Wails frontend stack,
67web styling posture, and explicit gocuke adoption.
68
69Gocuke is an explicit project choice. Ask whether the project wants gocuke/BDD
70automation; if yes, load the gocuke skill after behaviour is formulated. If no,
71use ordinary Go tests.
72
73## Reference map
74
75Read [references/mise.md](references/mise.md) for every setup or modernisation
76task. Then load only the references matching the project:
77
78- [references/licencing.md](references/licencing.md): Amolith's licensing
79 preferences and when to defer to `licensing-with-reuse`.
80- [references/preferred-libraries.md](references/preferred-libraries.md):
81 default Go libraries and when to deviate.
82- [references/cli.md](references/cli.md): Cobra/Fang CLIs and command layout.
83- [references/tui.md](references/tui.md): Amolith-specific TUI setup deltas;
84 then load `golang-tui` for implementation details and read `cli.md` because
85 TUIs are command-line binaries.
86- [references/mcp.md](references/mcp.md): MCP servers using the official Go SDK;
87 also read `cli.md` because MCP servers are command-line binaries.
88- [references/wails.md](references/wails.md): Wails desktop apps and bindings;
89 also read `web.md` for frontend patterns and `packaging.md` for releases.
90- [references/web.md](references/web.md): light Go web apps versus frontend-heavy
91 escalation.
92- [references/packaging.md](references/packaging.md): nFPM, binary releases, and
93 Wails package assets; also read `mise.md` for build task templates.
94- [references/testing.md](references/testing.md): unit, integration, BDD, and
95 property testing patterns.
96- [references/project-guidance-template.md](references/project-guidance-template.md):
97 a concise AGENTS.md template for Go projects using this setup.