TigerCli 0.8.0: A Year Later, My CLI Framework Is Public

Nearly a year ago, I started working on a small idea: make my command-line tools easier to build, easier to test, and nicer to use.

That small idea became TigerCli.

TigerCli is an opinionated .NET framework for building command-driven CLI/TUI applications. It is not just an argument parser, and it is not a general-purpose terminal rendering toolkit. It sits somewhere else: around the shape of real command-line applications.

Most of my tools are not console art. They are commands over a domain: list something, show something, add something, edit something, delete something, run something, validate something, copy something, query something. They need arguments and options, but they also need help, validation, prompts, structured output, progress, exit codes, localization, tests, and predictable behavior in automation.

That is the space TigerCli is designed for.

One command model

The most important idea in TigerCli is that the app should not need separate implementations for different usage styles.

The same command model can support:

• non-interactive execution from scripts
• semi-interactive prompting when values are missing
• command menus and guided workflows
• app-boundary tests
• AI-assisted development

Mode changes presentation and prompting policy. It should not fork the business operation.

That has been one of the strongest design principles behind the framework.

More than parsing

TigerCli includes support for:

• typed command handlers and settings
• arguments, options, and selectors
• generated command help
• command menus
• prompts and provider-backed choices
• structured output with CliList, CliDetails, and CliTable
• semantic styling and themes
• activity/progress dialogs
• typed exit-code policies
• localization support
• test shells and app-boundary testing

The goal is not to support every possible terminal UI idea. The goal is to make practical CLI tools coherent.

Why it took so long

I originally thought this would be smaller.

Then I started dogfooding it.

The framework had to support real tools, not demo apps. That meant fixing things that are easy to ignore in examples: non-interactive behavior, cancellation, generated help, testability, output consistency, semantic styles, terminal rendering, documentation comments, generated artifacts, package metadata, and release validation.

Even in the last days before publishing, TigerCli found a few hidden problems. Live TUI rendering and generated output were not using the same rendering path. Foreground-only overlays were losing the underlying background. Theme tuning exposed rendering bugs. Publishing pressure forced documentation cleanup and stricter build hygiene.

That was frustrating, but useful. The public release is better because of it.

TigerCli is public

TigerCli 0.8.0 is now public on GitHub and available on NuGet.

Install the main package:

dotnet add package ItTiger.TigerCli --version 0.8.0

The shared support package is also available:

dotnet add package ItTiger.Core --version 0.8.0

Links:

• GitHub: https://github.com/rkozlowski/TigerCli
• NuGet: https://www.nuget.org/packages/ItTiger.TigerCli/
• NuGet: https://www.nuget.org/packages/ItTiger.Core/
• Project page: https://www.ittiger.net/projects/tigercli/

What comes next

The next real test is using the public packages in my existing tools.

TigerQuery and tiger-sqlcmd are first. TigerWrap comes after that.

I do not want to publish a big roadmap or promise a long list of future features. For now, the important thing is simpler: TigerCli exists, it is public, and it is ready to be used by real IT Tiger tools.

A Leviathan is in the wilderness.