Hey all, really cool project! I'm a big an of interface definition languages, codegen, and tooling surrounding this space, and did a lot of work in that area at Amazon (retail + AWS) and CLI's definitely deserve more 1st-class treatment. The more I think about the different examples and design questions through the repo, the harder it has become for me to identify a CLI schema that couldn't be perfectly, perhaps even ergonomically, represented in JSONSchema/OpenAPI. I'm sure this isn't a novel idea, but a few examples.

Dynamic Arguments / Dependent Arguments

Dynamic arguments, mutually exclusive as mentioned here seem to be representable using dependentRequired, dependentSchemas, and literal if-then-else clauses I believe (along with the tradition all/any/one-of schema combinators).

{
 "type": "object",
 "oneOf": [
 { "type": "object", "properties": { "this": { "type": "string" } }, "required": ["this"], "additionalProperties": false },
 { "type": "object", "properties": { "that": { "type": "string" } }, "required": ["orThat"], "additionalProperties": false },
 ]
}

{
 "type": "object",
 "properties": {
 "website": { "type": "string", "format": "uri" },
 "email": { "type": "string", "format": "email" },
 "consentToReceiveEmails": { "enum": [ true, false ] }
 },
 "dependentRequired": {
 "email": ["consentToReceiveEmails"]
 }
}

Arity

{
 "type": "array",
 "items": {
 "type": "string",
 "format": "ipv4"
 }
}

C Compiler-like flags

{
 "type": "object",
 "patternProperties": {
 "D\S+": { "type": "string", "description": "Compiler flags" }
 }
}

Misc

Command Groups: Command groups map pretty well to "paths" in an OpenAPI spec. Path parameters become positional arguments.
Stdin/stdout: Could be mapped using the request/response schema mechanism, including content encoding as applicable.
Environment Variables:
I can see environment variables as being a type of parameter location - i.e. an argument could be located as a CLI arg, environment variable, or a configuration file entry, with different orders of precedence, similar to how Go's Viper or MS's Microsoft.Extensions.Configuration packages are organized.

The best examples I can think of that are lacking are things like:

• Option usage formatting (-arg, --arg, --argName ,--arg-name, = vs no equals, quotation and escaping, multiple arguments via multiple --options ABC --options DEF vs --options ABC DEF)
• Complex object specification (at the very least, an escape hatch to JSON seems prudent :) The AWS CLI is a good example of this). Otherwise, JSON? (--person '{"name": "John","age":31:}') JSON paths? (--person.0.name John --person.0.age 31 --person.1.name Steve --person.1.age 40), the sky's the limit

I coud go on, and I know I'm not blowing anyone's minds with these suggestions. My question is simple:

Is the goal of this repo to nail down the details like the formatting conventions, different ways to accept configuration, configuration vs arguments, those kinds of semantics? Or is the goal of the repo to make a conscious effort to build a format to make the most spectacular CLI development/consumption experience possible, without any intention to interop with API specifications (unless they're literally just free).

If I could mention the goals I'd be interested in, its kinda a blend - ideally it'd allow for structured input/outputs with a strong type system (TypeScript mixed with Powershell would be a dream), generics, full request-response flows (like an LSP that communicates over JSONRPC on stdin/stdout), but be flexible enough to model things like chess UCI protocol.

I'm just trying to align how I think about this project to understand the goal and how I could contribute, if I'd even be of value. I hope my question makes sense. Either way, very cool project and I'll be following the journey!