X-Git-Url: https://git.giacomolli.uk/onechat/blobdiff_plain/7c84ed87ef71088b880a3765b2653e1ded57bf14..f4509310b5abe5012cb83bed3960404e8fa92217:/.agents/skills/check/SKILL.md?ds=sidebyside diff --git a/.agents/skills/check/SKILL.md b/.agents/skills/check/SKILL.md index 4dff349..6882267 100644 --- a/.agents/skills/check/SKILL.md +++ b/.agents/skills/check/SKILL.md @@ -11,18 +11,29 @@ Run every command in the Nix development shell. Use ## 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