Hi, I called it "CLI framework" because it is more of a ecosystem of modules that contains everything you need to build a CLI, argument parsing is just part of it. The @crustjs/core module is the argument parser, and there are more modules such as @crustjs/skills that would derive agent skills from your command definition, @crustjs/store that state persistent and so on

Both in the frontend and the backend, I've usually used "If it calls your code, it's a framework, if you call its code, it's a library", and would seem to fit here too. An argument parser you'd call from your main method, then do stuff with what it returns. In Crust, it seems you instead setup the command + what will happen when it's called, then let the framework call your code.

good point.

we’re using “framework” intentionally because it goes beyond argument parsing. crust handles parsing, but also:

type inference across args + flags end to end compile-time validation (so mistakes fail before runtime) plugin system with lifecycle hooks (help, version, autocomplete, etc.) composable modules (prompts, styling, validation, build tooling) auto-generates agent skills and modules from the CLI definitions

so it sits a layer above a traditional arg parser like yargs or commander, closer to something like oclif, but much lighter and bun-native.

will fix in the next hour!

one of the examples would be trynia.ai (search and index api for ai agents)

here is github: github.com/nozomio-labs/nia-cli

tens of KBs (v small)

thanks for the catch, what we meant is that we’re not committing to strict stability guarantees yet, so APIs may still change as we iterate toward 1.0.

Fixed above. Thanks for the heads-up!

thanks for flagging! the post itself works, just the link at the bottom