One style that I've seen that I really like is having the help system be its own first-class subcommand. E.g., just `p4 help` gives you the quick summary with a list of available subcommands, then something like `p4 help filelog` gives you the details on just the filelog subcommand. I find that this avoids the problem of a having a single help spiel that is either too brief or too verbose to be useful.
(The article sort of touches on this with mention of `mycli subcommand --help` as something that should show help and `mycli subcommand help` as potentially confusing `help` with an argument. But I find that making help a full subcommand tends to avoid avoid this ambiguity. And having the bare help command give the table of contents lends structure to the help system.)
perhaps I should've called this out explicitly, but yes, I would expect a CLI to do this.
I have future plans for oclif to take this a step further and make the help contextual based on what you're working with. For example, if you wanted to see what commands might relate to a file you might get different commands than a directory.
(The article sort of touches on this with mention of `mycli subcommand --help` as something that should show help and `mycli subcommand help` as potentially confusing `help` with an argument. But I find that making help a full subcommand tends to avoid avoid this ambiguity. And having the bare help command give the table of contents lends structure to the help system.)