3 description: Format, lint, test, and build. Use before every commit.
8 Run every command in the Nix development shell. Use
9 `nix develop -c COMMAND` when direnv does not load the shell.
13 1. Format all files with `bin/format`.
14 2. Run the checks with `bin/check`. Its golangci-lint config keeps the
15 standard linters and adds `errorlint`, `gocritic`, `testifylint`,
16 `revive`, `wrapcheck`, `nlreturn`, and `wsl_v5`. These checks cover
17 only part of the Go rules. A pass is not proof of compliance.
18 3. Run `git add` on new files, then run `nix build` and
20 4. Fix every failure and run the steps again. Do not disable a linter or
21 add a `nolint` directive to get a pass. An intentional error discard
22 needs the user's approval, an explicit directive, and a comment that
23 gives the reason, as the `go-code` skill requires. Never replace a
24 checked error with a blank assignment to get a pass.
25 5. Review the final diff against the rules. Passing tools do not replace
27 - Read `AGENTS.md` and the `SKILL.md` of each skill of the task again
28 from disk now. Do not work from memory of an earlier read.
29 - Go through the diff one rule at a time, and for each rule look at
30 every changed line that it covers. For Go code, check each section
31 of `go-code`, also for the tests. Check declaration order, owning
32 test filenames, separators after multiline constructs, and errors
33 assigned to `_`. Inspect blank-assigned errors even when `errcheck`
34 reports none: `.golangci.yml` does not enable its `check-blank`
35 setting. Check whole comment paragraphs against the `docs` skill,
36 not only their line width.
37 - Fix each finding, then run steps 1 to 4 again.
39 Tell the user about each check that cannot run and each failure that