However, be warned that we may want more than just pure documentation here. As much as possible, we try to generate our documentation from the gopls source. This prevents duplication, and helps ensure that documentation doesn't go stale. It also makes it easier to compile our documentation into JSON that can be read by editors. You can see examples of this in x/tools/gopls/doc/generate.go.
I haven't thought too much about code actions, but we should try to do something similar, basing our documentation off of x/tools/internal/lsp/source.DefaultOptions().SupportedCodeActions. One way to enforce that we have documentation would be to change the type of SupportedCodeActions. For example:
In the future we could also go further and try to refactor such that code actions are parameterized, similarly to inlay hints (see x/tools/internal/lsp/source.AllInlayHints), but I don't think it is wise to undertake that refactoring now.
CC @suzmue@jamalc who may have opinions, having just done this for inlay hints.