One tool to make the best CLI programs is to abstract out common usage patterns from different programs. For example, some utilities produce file sizes, either to be read by another program or by a human. Instead of a -h option for different programs to produce human readable values, use a utility, such as z3bra's human, that converts values from its input into human-readable sizes.

Another practice to make good CLI programs is to use idiomatic functions:

• A double-hyphen (--) on the argument list stops option parsing. Rather than implementing that, use getopt(3), that handles it and much more.
  
• When a program in a script writes to stdout, it is hard to guess which program failed when it does not identify itself. Using the err(1) family of functions writes "progname: errno string: comment", a idiomatic error string that identifies the program by its progname (argv[0]).
  

I made this table for a post on the book club thread.
It lists and describes the types of CLI that can be used in a script. roguelike interface is ignored, because it does not scriptable.


I think there are more (sub)categories of command-line interfaces that can be used in a pipeline.

The pretty-printer.
Pretty-printers are a subcategory of filters or sources whose output is not parseable, instead, the output is meant to be read by the user, not by another program. Pretty printers often use the number of $COLUMNS in a terminal to tabulate the output. ls(1) is a pretty-printer: you should not parse the output of ls(1).

The interactive filter.
Interactive filters are a subcategory of filters whose parsing of input and generation of output is done by the user, not programmatically by the utility. Examples are pick, smenu and fzf.

The wrapper.
Wrappers are utilities whose sole purpose is to call another utility. They programmatically set the environment (either environment variables or command-line arguments) for another utility and run them. An example is xargs(1).

The test.
Testers are a subcategory of cantrips or sinks that returns a result as exit status, not on standard output. The script checks the exit status ($?) of a test and proceeds according to its value.