Command-line interfaces have become the backbone of developer productivity, yet they remain stuck in the past. We waste countless hours:
- Writing help text that becomes outdated the moment code changes
- Answering the same questions because tools are hard to discover
- Debugging cryptic errors that teach users nothing
- Maintaining separate documentation that never stays in sync
Meanwhile, users struggle with:
- Hidden functionality they never discover
- Frustrating error messages that require source code diving
- Steep learning curves for every new tool
- Documentation hunting instead of actual work
We envision a world where CLI tools are self-teaching, discoverable, and delightful to use.
Where developers can focus on building features instead of maintaining documentation, and users can learn tools naturally through exploration rather than manual reading.
Help text should be automatically generated from code, not manually maintained.
Your method names, parameter descriptions, and code structure are the documentation. When you change your code, the help changes with it—automatically, instantly, accurately.
Users should explore functionality naturally, not memorize commands.
Commands reveal themselves through intelligent exploration. Users learn by doing, not by reading lengthy manuals. The interface teaches itself through context-aware guidance and progressive disclosure.
Errors should educate, not just complain.
When users make mistakes, the system provides clear, actionable guidance. Error messages become learning opportunities that teach proper usage and help users understand the tool better.
Interfaces should feel conversational, not transactional.
Command-line interactions should flow naturally, like a conversation with an expert guide. Users express intent, and the system understands context.
$ mytool --help
# Output: Generic help text you wrote six months ago
# Reality: Half the options have changed or been removed
$ mytool subcommand --wrong-option
# Output: Error: invalid option --wrong-option
# User: What's the right option? Guess I'll Google it...$ mytool
# Output: Available commands: build, deploy, test, monitor
# Use 'mytool <command> --help' for detailed help
$ mytool build --wrong-option
# Output: Unknown option: --wrong-option
# Did you mean --output? Available options: --output, --verbose, --force
# Usage: mytool build [--output DIR] [--verbose] [--force]To Developers: Stop writing documentation. Start building experiences. Focus on your features, not your help text.
To Users: Stop reading manuals. Start exploring tools. Learn naturally through interaction, not memorization.
- LiveCommands/Lua - Fluent CLI framework for Lua
- LiveCommands/Java - Type-safe CLI framework for Java
- Read our specification
- Try our implementations
- Join our discussions
- Share your ideas and experiences
- Build tools people love to use
We're creating an ecosystem where:
- Every CLI tool is instantly understandable
- Documentation never gets outdated
- Users learn by doing, not by reading
- Developers focus on features, not help text
- Command-line interfaces feel magical, not mechanical
Stop writing documentation. Start building experiences.
Join us in making CLI tools people actually love to use.