Help. Help should be available for all tools. Command-line tools should print a helpful message (if appropriate) if invoked with no arguments (if any command line tools are designed to accept input as a pipe, it is acceptable to forego this rule). If multiple options are available, the product should present a text menu detailing the probable choices rather than forcing the user to retype everything up to that point. All command-line tools must print a summary of use and available subcommands if invoked with invalid or missing arguments. GUI tools must have help available from any screen, either via a button, context-sensitive help, or a summary of help on the page (web forms may take the latter route).

Feedback. Each tool should give feedback to the user describing the results of their last action; in other words, issue submissions should be acknowledged (with a response message from standard output, a follow-on web page, or return email) with some positive indication of the result ("Your issue has been reported and filed with ID 523", for example). If preconditions for an action have not been met (an issue is filed with an invalid or inappropriate format, for example, or the user is not of a class allowed to perform these actions) the feedback should indicate that the desired action has not been accomplished and give an indication of the error and how it could be fixed. If these error messages involve files and/or line numbers, the response will be in the form of file:line:comment.

Command-line options. If command-line tools can accept arguments, they will support them according to the standards laid out in the GNU coding standards, and should support both short and long forms.