alecthomas/kong

What it does

You declare the commands, flags and arguments as a Go structure, with the help text written beside each one as a tag. It then parses what the person typed, fills the structure in, and reports a clear error when something is missing or wrong. Nested subcommands work, so tool thing create --name x needs no manual routing. Values can come from the command line, from environment variables, from a configuration file, or from a default, in an order you control. It generates the help text, including per-command help, so the documentation cannot drift away from the flags. It supports shell completion and can print the parsed result for debugging. It does not do anything at runtime beyond parsing: it builds no interactive prompts and draws no interface, so a program that wants to ask questions on screen needs something else alongside it.

Why it matters

Who it suits. Anyone writing a command-line tool in Go, particularly one with subcommands, who wants the interface described once in one place. It suits small internal tools especially well, because the help text comes free and that is the part nobody writes otherwise. Skip it if the program takes one filename and nothing else, because the standard library handles that in three lines.

Verdict. The best-designed of the three options, and the least used, which is worth knowing. Code was pushed on 11 October 2026 and it is MIT licensed. It publishes no GitHub releases at all, which is a determination rather than a gap: Go takes its versions from tags, and there is nothing missing. The honest comparison is the deciding factor. spf13/cobra has 44,600 stars against this one's 3,200, is used by most well-known Go tools, and is what a new contributor will already know, at the cost of more code to write for the same interface. urfave/cli sits in between. Choose Kong for a tool you will maintain yourself and want described in one structure; choose Cobra when the project is shared and familiarity matters more than elegance.