## Procedure
1. Format all files with `bin/format`.
-2. Run the checks with `bin/check`.
+2. Run the checks with `bin/check`. Its golangci-lint config keeps the
+ standard linters and adds `errorlint`, `gocritic`, `testifylint`,
+ `revive`, `wrapcheck`, `nlreturn`, and `wsl_v5`. These checks cover
+ only part of the Go rules. A pass is not proof of compliance.
3. Run `git add` on new files, then run `nix build` and
`nix flake check`.
4. Fix every failure and run the steps again. Do not disable a linter or
- add a `nolint` directive to get a pass, unless the user agrees.
+ add a `nolint` directive to get a pass. An intentional error discard
+ needs the user's approval, an explicit directive, and a comment that
+ gives the reason, as the `go-code` skill requires. Never replace a
+ checked error with a blank assignment to get a pass.
5. Review the final diff against the rules. Passing tools do not replace
this review.
- Read `AGENTS.md` and the `SKILL.md` of each skill of the task again
from disk now. Do not work from memory of an earlier read.
- Go through the diff one rule at a time, and for each rule look at
every changed line that it covers. For Go code, check each section
- of `go-code`, also for the tests.
+ of `go-code`, also for the tests. Check declaration order, owning
+ test filenames, separators after multiline constructs, and errors
+ assigned to `_`. Inspect blank-assigned errors even when `errcheck`
+ reports none: `.golangci.yml` does not enable its `check-blank`
+ setting. Check whole comment paragraphs against the `docs` skill,
+ not only their line width.
- Fix each finding, then run steps 1 to 4 again.
Tell the user about each check that cannot run and each failure that