Some application require complex API where verbs are nested and grouped for clarity. For example, this is a hypothetical finance application:

myfinance Report Recalculate --id 0a0e0000000
myfinance Report Publish
myfinance Account ShowBalance --id 0a0e0000000

It has two nested verbs Report and Account. You can create such an API using nested verbs.

The nested verb must be declared in a specific way. It must take one ICommandLineBuilderparameter and use the following method body:

// sync sub-verb
public static int Account(ICommandLineBuilder subVerbBuilder)
{
  return subVerbBuilder
    .Use<AccountApi>()
    .Run();
}

// async sub-verb
public static Task<int> Report(ICommandLineBuilder subVerbBuilder, CancellationToken cancellationToken)
{
  return subVerbBuilder
    .Use<ReportApi>()
    .RunAsync(cancellationToken);
}

Where AccountApi is class with list of sub-verbs of Account verb.

Sub-verbs could be nested to any depth: a sub-verb class could declare its own ICommandLineBuilder verbs.

The sub-verb builder inherits the parent's CommandLineConfiguration, IServiceProvider and properties. Calling Configure() on it changes the configuration for this sub-verb set only:

public static int Account(ICommandLineBuilder subVerbBuilder)
{
  return subVerbBuilder
    .Configure(config => config.FailOnUnknownOptions = true)
    .Use<AccountApi>()
    .Run();
}

A verb with sub-verbs is not checked for unknown options, only its sub-verbs are.

See Sub-verb help.