📝 Fix wording to avoid confusion between CLI program, command, subcommand

README.md

@@ -31,7 +31,7 @@ Typer is library to build <abbr title="command line interface, programs executed
 The key features are:
 
 * **Intuitive to write**: Great editor support. <abbr title="also known as auto-complete, autocompletion, IntelliSense">Completion</abbr> everywhere. Less time debugging. Designed to be easy to use and learn. Less time reading docs.
-* **Easy to use**: It's easy to use for the final users. Automatic help commands, and (optional) automatic completion for all shells.
+* **Easy to use**: It's easy to use for the final users. Automatic help, and (optional) automatic completion for all shells.
 * **Short**: Minimize code duplication. Multiple features from each parameter declaration. Fewer bugs.
 * **Start simple**: The simplest example adds only 2 lines of code to your app: **1 import, 1 function call**.
 * **Grow large**: Grow in complexity as much as you want, create arbitrarily complex trees of commands and groups subcommands, with options and arguments.

docs/features.md

@@ -42,7 +42,7 @@ But by default, it all **"just works"**.
 
 The resulting CLI apps created with **Typer** have the nice features of many "pro" command line programs you probably already love.
 
-* Automatic help commands and options.
+* Automatic help options for the main CLI program and all the its subcommands.
 * Automatic command and subcommand structure handling (you will see more about subcommands in the Tutorial - User Guide).
 * Automatic autocompletion for the CLI app in all operating systems, in all the shells (Bash, Zsh, Fish, PowerShell), so that the final user of your app can just hit <kbd>TAB</kbd> and get the available options or subcommands. *
 

docs/index.md

@@ -31,7 +31,7 @@ Typer is library to build <abbr title="command line interface, programs executed
 The key features are:
 
 * **Intuitive to write**: Great editor support. <abbr title="also known as auto-complete, autocompletion, IntelliSense">Completion</abbr> everywhere. Less time debugging. Designed to be easy to use and learn. Less time reading docs.
-* **Easy to use**: It's easy to use for the final users. Automatic help commands, and (optional) automatic completion for all shells.
+* **Easy to use**: It's easy to use for the final users. Automatic help, and (optional) automatic completion for all shells.
 * **Short**: Minimize code duplication. Multiple features from each parameter declaration. Fewer bugs.
 * **Start simple**: The simplest example adds only 2 lines of code to your app: **1 import, 1 function call**.
 * **Grow large**: Grow in complexity as much as you want, create arbitrarily complex trees of commands and groups subcommands, with options and arguments.

docs/tutorial/arguments.md

@@ -13,7 +13,7 @@ But you can change that.
 
 In fact, it's very common to have **optional** *CLI arguments*, it's way more common than having **required** *CLI options*.
 
-As an example of how it could be useful, let's see how the `ls` command works.
+As an example of how it could be useful, let's see how the `ls` CLI program works.
 
 <div class="termy">
 
@@ -158,7 +158,7 @@ Hello Camila
 </div>
 
 !!! tip
-    Notice that "`Camila`" here is an optional *CLI argument*, not a *CLI option*, because we didn't use something like "`--name Camila`", we just passed "`Camila`" directly to the program/command.
+    Notice that "`Camila`" here is an optional *CLI argument*, not a *CLI option*, because we didn't use something like "`--name Camila`", we just passed "`Camila`" directly to the program.
 
 ## An optional *CLI argument* with a default
 
@@ -194,7 +194,7 @@ They are normally required and, when present, they are normally the main subject
 
 For that reason, Typer (actually Click underneath) doesn't attempt to automatically document *CLI arguments*.
 
-And you should document them as part of the command documentation, normally in a <abbr title="a multi-line string as the first expression inside a function (not assigned to any variable) used for documentation">docstring</abbr>.
+And you should document them as part of the CLI app documentation, normally in a <abbr title="a multi-line string as the first expression inside a function (not assigned to any variable) used for documentation">docstring</abbr>.
 
 Check the last example from the <a href="https://typer.tiangolo.com/tutorial/first-steps/#document-your-cli-app" target="_blank">First Steps</a>:
 
@@ -202,7 +202,7 @@ Check the last example from the <a href="https://typer.tiangolo.com/tutorial/fir
 {!./src/first_steps/tutorial006.py!}
 ```
 
-Here the *CLI argument* `NAME` is documented as part of the command help text.
+Here the *CLI argument* `NAME` is documented as part of the help text.
 
 You should document your *CLI arguments* the same way.