What this prompt does
This prompt generates a production-grade Rust CLI tool scaffold around a stated purpose rather than a bare argument parser. You set [tool_purpose] and [subcommands], and the AI builds the full structure: clap derive-API argument parsing, a custom error type from [error_lib] with context propagation, colored output via [color_lib], indicatif progress bars for long operations, configuration support in [config_format] with fallback defaults, tracing-based logging with configurable verbosity, and an [async_runtime] for I/O. It produces the parts that make a CLI pleasant to actually use, which is exactly where most hand-rolled tools fall short.
The variables target the parts that genuinely vary between tools. [error_lib] decides your error-handling layer, with thiserror plus anyhow giving typed errors where you need them and easy context at the top, while [color_lib] and [config_format] set the UX and config surface, and [async_runtime] covers any I/O-bound work. The prompt also asks for graceful Ctrl+C handling via tokio signal, unit and integration tests with assert_cmd, cross-platform build configuration, a Cargo.toml, a README with usage examples, and a GitHub Actions release workflow so binaries ship without manual fuss.
When to use it
- Scaffolding internal tooling or infrastructure CLIs in Rust from a clean base
- Standing up a tool with proper error context instead of a scatter of bare unwraps
- Adding progress bars and colored output to a long-running command
- Wiring config-file plus sensible-defaults support into a new CLI
- Setting up cross-platform release builds via GitHub Actions from day one
- Generating integration tests with assert_cmd alongside the implementation itself
Example output
You get a complete project skeleton: a Cargo.toml with the right dependencies, a main module wiring [subcommands] to handlers, a custom error type, colored and progress-bar output, config loading with defaults, tracing setup, and graceful shutdown. Alongside the code you get a README with usage examples, unit and integration tests, and a GitHub Actions workflow that builds release binaries for Linux, macOS, and Windows so cross-platform distribution is handled.
Pro tips
- Make
[tool_purpose]and[subcommands]specific; vague purposes produce vague, generic handlers you will rewrite anyway - Keep
[error_lib]as thiserror plus anyhow unless you have a reason; it is the idiomatic pairing for libraries plus binaries - Match
[config_format]to your ecosystem; TOML fits Cargo-native projects naturally and reads cleanly - Only request
[async_runtime]if the tool does real I/O; a synchronous CLI does not need tokio and runs simpler - Build the GitHub Actions release workflow early so cross-platform binaries are never a last-minute scramble
- Wire the tracing verbosity flags so users can run with -v for normal output and -vv when they need to debug a failure
- Treat the generated code as a strong scaffold and review the error-context chains before you ship it to anyone
