There's no official way to see help messages for nested subcommands.

The usage for kcctl is easy to view, via kcctl help, kcctl -h, or kcctl --help, and provides a list of all commands along with a brief description of what each does.

The usage for any top-level commands (e.g., kcctl apply) is also easy to view, via kcctl help <command> (e.g., kcctl help apply or kcctl help delete).

If any of these commands contains nested subcommands, the subcommands are listed with a brief description of what they do. For example:

> kcctl help delete
Usage: kcctl delete [<args>...] [COMMAND]
Deletes connectors
      [<args>...]
Commands:
  connector  Deletes specified connector

However, there's no way to get usage information for those nested subcommands that doesn't involve hacks like throwing in an unrecognized flag (e.g., -h) that causes the command to exit with a non-zero status and print an error message. For example:

> kcctl delete connector -h
Unknown option: '-h'
Usage: kcctl delete connector [-e] [CONNECTOR NAME...]
Deletes specified connectors
      [CONNECTOR NAME...]   Name of the connector
  -e, --reg-exp             use CONNECTOR NAME(s) as regexp pattern(s) to apply
                              on all connectors

We should make it as easy as possible for users to learn about the syntax/semantics of subcommands. Some options for this include:

1. kcctl help <command> <subcommand> (right now this only shows the usage information for <command>)
2. kcctl <command> help <subcommand> (right now this prints an error message and then the usage information for <command>)
3. kcctl <command> <subcommand> -h and/or kcctl <command> <subcommand> --help (right now this prints an error message and then the usage information for <subcommand>)
4. kcctl <command> <subcommand> help (right now this invokes the subcommand with an argument of help)

IMO option 1 has the most intuitive syntax, but may be difficult to implement. Options 2 and 3 are straightforward to implement via the existing CommandLine.HelpCommand class and mixinStandardHelpOptions annotation option, respectively. Option 4 is also straightforward to implement with the CommandLine.HelpCommand class, but is a little uglier as it causes the subcommand to have its own subcommand named help, which pollutes usage messages a bit.

I'd like to implement option 3 unconditionally (-h is a deeply-ingrained reflex for many CLI users), and then either option 1 (if it can be done with reasonable effort) or option 2 (if option 1 can't be done). Interested in others' perspectives!