SKILL.md

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 for every setup or modernisation task. Then load only the references matching the project: