diff --git a/docs/generated/cli/affected.md b/docs/generated/cli/affected.md
index 490a417fc9..fb0a387251 100644
--- a/docs/generated/cli/affected.md
+++ b/docs/generated/cli/affected.md
@@ -20,49 +20,49 @@ Install `nx` globally to invoke the command directly using `nx`, or use `npx nx`
 Run custom target for all affected projects:
 
 ```shell
- nx affected --target=custom-target
+ nx affected -t custom-target
 ```
 
 Run tests in parallel:
 
 ```shell
- nx affected --target=test --parallel=5
+ nx affected -t test --parallel=5
 ```
 
 Run the test target for all projects:
 
 ```shell
- nx affected --target=test --all
+ nx affected -t test --all
 ```
 
 Run lint, test, and build targets for affected projects. Requires Nx v15.4+:
 
 ```shell
- nx affected --targets=lint,test,build
+ nx affected -t lint test build
 ```
 
 Run tests for all the projects affected by changing the index.ts file:
 
 ```shell
- nx affected --target=test --files=libs/mylib/src/index.ts
+ nx affected -t test --files=libs/mylib/src/index.ts
 ```
 
 Run tests for all the projects affected by the changes between main and HEAD (e.g., PR):
 
 ```shell
- nx affected --target=test --base=main --head=HEAD
+ nx affected -t test --base=main --head=HEAD
 ```
 
 Run tests for all the projects affected by the last commit on main:
 
 ```shell
- nx affected --target=test --base=main~1 --head=main
+ nx affected -t test --base=main~1 --head=main
 ```
 
 Use the currently executing project name in your command.:
 
 ```shell
- nx affected --target=build --tag=$NX_TARGET_TASK_PROJECT:latest
+ nx affected -t build --tag=$NX_TARGET_TASK_PROJECT:latest
 ```
 
 ## Options
diff --git a/docs/generated/cli/print-affected.md b/docs/generated/cli/print-affected.md
index 5a1fce8598..b65d25d4ec 100644
--- a/docs/generated/cli/print-affected.md
+++ b/docs/generated/cli/print-affected.md
@@ -32,19 +32,19 @@ Print information about the projects affected by the changes between main and HE
 Prints information about the affected projects and a list of tasks to test them:
 
 ```shell
- nx print-affected --target=test
+ nx print-affected -t test
 ```
 
 Prints the projects property from the print-affected output:
 
 ```shell
- nx print-affected --target=build --select=projects
+ nx print-affected -t build --select=projects
 ```
 
 Prints the tasks.target.project property from the print-affected output:
 
 ```shell
- nx print-affected --target=build --select=tasks.target.project
+ nx print-affected -t build --select=tasks.target.project
 ```
 
 ## Options
diff --git a/docs/generated/cli/run-many.md b/docs/generated/cli/run-many.md
index 91620395d8..bcacf2666e 100644
--- a/docs/generated/cli/run-many.md
+++ b/docs/generated/cli/run-many.md
@@ -20,37 +20,37 @@ Install `nx` globally to invoke the command directly using `nx`, or use `npx nx`
 Test all projects:
 
 ```shell
- nx run-many --target=test
+ nx run-many -t test
 ```
 
 Test proj1 and proj2 in parallel:
 
 ```shell
- nx run-many --target=test --projects=proj1,proj2
+ nx run-many -t test -p proj1 proj2
 ```
 
 Test proj1 and proj2 in parallel using 5 workers:
 
 ```shell
- nx run-many --target=test --projects=proj1,proj2 --parallel=5
+ nx run-many -t test -p proj1 proj2 --parallel=5
 ```
 
 Test proj1 and proj2 in sequence:
 
 ```shell
- nx run-many --target=test --projects=proj1,proj2 --parallel=false
+ nx run-many -t test -p proj1 proj2 --parallel=false
 ```
 
 Test all projects ending with `*-app` except `excluded-app`. Note: your shell may require you to escape the `*` like this: `\*`:
 
 ```shell
- nx run-many --target=test --projects=*-app --exclude=excluded-app
+ nx run-many -t test --projects=*-app --exclude excluded-app
 ```
 
 Test all projects with tags starting with `api-`. Note: your shell may require you to escape the `*` like this: `\*`:
 
 ```shell
- nx run-many --target=test --projects=tag:api-*
+ nx run-many -t test --projects=tag:api-*
 ```
 
 Run lint, test, and build targets for all projects. Requires Nx v15.4+:
diff --git a/docs/generated/cli/watch.md b/docs/generated/cli/watch.md
index 5fb31bdeb6..e35e2fccdc 100644
--- a/docs/generated/cli/watch.md
+++ b/docs/generated/cli/watch.md
@@ -26,7 +26,7 @@ Watch the "app" project and echo the project name and the files that changed:
 Watch "app1" and "app2" and echo the project name whenever a specified project or its dependencies change:
 
 ```shell
- nx watch --projects=app1,app2 --includeDependentProjects -- echo \$NX_PROJECT_NAME
+ nx watch --projects=app1,app2 --includeDependencies -- echo \$NX_PROJECT_NAME
 ```
 
 Watch all projects (including newly created projects) in the workspace:
diff --git a/docs/generated/packages/jest/documents/overview.md b/docs/generated/packages/jest/documents/overview.md
index ef6e645203..b7eb3dc5a1 100644
--- a/docs/generated/packages/jest/documents/overview.md
+++ b/docs/generated/packages/jest/documents/overview.md
@@ -86,7 +86,7 @@ Snapshot files should be checked in with your code.
 
 ### Performance in CI
 
-Typically, in CI it's recommended to use `nx affected --target=test --parallel=[# CPUs] -- --runInBand` for the best performance.
+Typically, in CI it's recommended to use `nx affected -t test --parallel=[# CPUs] -- --runInBand` for the best performance.
 
 This is because each [jest process creates a workers based on system resources](https://jestjs.io/docs/cli#--maxworkersnumstring), running multiple projects via nx and using jest workers will create too many process overall causing the system to run slower than desired. Using the `--runInBand` flag tells jest to run in a single process.
 
diff --git a/docs/generated/packages/nx/documents/affected.md b/docs/generated/packages/nx/documents/affected.md
index 490a417fc9..fb0a387251 100644
--- a/docs/generated/packages/nx/documents/affected.md
+++ b/docs/generated/packages/nx/documents/affected.md
@@ -20,49 +20,49 @@ Install `nx` globally to invoke the command directly using `nx`, or use `npx nx`
 Run custom target for all affected projects:
 
 ```shell
- nx affected --target=custom-target
+ nx affected -t custom-target
 ```
 
 Run tests in parallel:
 
 ```shell
- nx affected --target=test --parallel=5
+ nx affected -t test --parallel=5
 ```
 
 Run the test target for all projects:
 
 ```shell
- nx affected --target=test --all
+ nx affected -t test --all
 ```
 
 Run lint, test, and build targets for affected projects. Requires Nx v15.4+:
 
 ```shell
- nx affected --targets=lint,test,build
+ nx affected -t lint test build
 ```
 
 Run tests for all the projects affected by changing the index.ts file:
 
 ```shell
- nx affected --target=test --files=libs/mylib/src/index.ts
+ nx affected -t test --files=libs/mylib/src/index.ts
 ```
 
 Run tests for all the projects affected by the changes between main and HEAD (e.g., PR):
 
 ```shell
- nx affected --target=test --base=main --head=HEAD
+ nx affected -t test --base=main --head=HEAD
 ```
 
 Run tests for all the projects affected by the last commit on main:
 
 ```shell
- nx affected --target=test --base=main~1 --head=main
+ nx affected -t test --base=main~1 --head=main
 ```
 
 Use the currently executing project name in your command.:
 
 ```shell
- nx affected --target=build --tag=$NX_TARGET_TASK_PROJECT:latest
+ nx affected -t build --tag=$NX_TARGET_TASK_PROJECT:latest
 ```
 
 ## Options
diff --git a/docs/generated/packages/nx/documents/print-affected.md b/docs/generated/packages/nx/documents/print-affected.md
index 5a1fce8598..b65d25d4ec 100644
--- a/docs/generated/packages/nx/documents/print-affected.md
+++ b/docs/generated/packages/nx/documents/print-affected.md
@@ -32,19 +32,19 @@ Print information about the projects affected by the changes between main and HE
 Prints information about the affected projects and a list of tasks to test them:
 
 ```shell
- nx print-affected --target=test
+ nx print-affected -t test
 ```
 
 Prints the projects property from the print-affected output:
 
 ```shell
- nx print-affected --target=build --select=projects
+ nx print-affected -t build --select=projects
 ```
 
 Prints the tasks.target.project property from the print-affected output:
 
 ```shell
- nx print-affected --target=build --select=tasks.target.project
+ nx print-affected -t build --select=tasks.target.project
 ```
 
 ## Options
diff --git a/docs/generated/packages/nx/documents/run-many.md b/docs/generated/packages/nx/documents/run-many.md
index 91620395d8..bcacf2666e 100644
--- a/docs/generated/packages/nx/documents/run-many.md
+++ b/docs/generated/packages/nx/documents/run-many.md
@@ -20,37 +20,37 @@ Install `nx` globally to invoke the command directly using `nx`, or use `npx nx`
 Test all projects:
 
 ```shell
- nx run-many --target=test
+ nx run-many -t test
 ```
 
 Test proj1 and proj2 in parallel:
 
 ```shell
- nx run-many --target=test --projects=proj1,proj2
+ nx run-many -t test -p proj1 proj2
 ```
 
 Test proj1 and proj2 in parallel using 5 workers:
 
 ```shell
- nx run-many --target=test --projects=proj1,proj2 --parallel=5
+ nx run-many -t test -p proj1 proj2 --parallel=5
 ```
 
 Test proj1 and proj2 in sequence:
 
 ```shell
- nx run-many --target=test --projects=proj1,proj2 --parallel=false
+ nx run-many -t test -p proj1 proj2 --parallel=false
 ```
 
 Test all projects ending with `*-app` except `excluded-app`. Note: your shell may require you to escape the `*` like this: `\*`:
 
 ```shell
- nx run-many --target=test --projects=*-app --exclude=excluded-app
+ nx run-many -t test --projects=*-app --exclude excluded-app
 ```
 
 Test all projects with tags starting with `api-`. Note: your shell may require you to escape the `*` like this: `\*`:
 
 ```shell
- nx run-many --target=test --projects=tag:api-*
+ nx run-many -t test --projects=tag:api-*
 ```
 
 Run lint, test, and build targets for all projects. Requires Nx v15.4+:
diff --git a/docs/generated/packages/nx/documents/watch.md b/docs/generated/packages/nx/documents/watch.md
index 5fb31bdeb6..e35e2fccdc 100644
--- a/docs/generated/packages/nx/documents/watch.md
+++ b/docs/generated/packages/nx/documents/watch.md
@@ -26,7 +26,7 @@ Watch the "app" project and echo the project name and the files that changed:
 Watch "app1" and "app2" and echo the project name whenever a specified project or its dependencies change:
 
 ```shell
- nx watch --projects=app1,app2 --includeDependentProjects -- echo \$NX_PROJECT_NAME
+ nx watch --projects=app1,app2 --includeDependencies -- echo \$NX_PROJECT_NAME
 ```
 
 Watch all projects (including newly created projects) in the workspace:
diff --git a/docs/generated/packages/storybook/documents/storybook-composition-setup.md b/docs/generated/packages/storybook/documents/storybook-composition-setup.md
index d2970dd7b4..747ba8ee0d 100644
--- a/docs/generated/packages/storybook/documents/storybook-composition-setup.md
+++ b/docs/generated/packages/storybook/documents/storybook-composition-setup.md
@@ -57,7 +57,7 @@ In order to get it working for you, you need to two things:
 1. Make sure your "composed" Storybook instances are running. For that you can do:
 
 ```shell
-nx run-many --target=storybook --projects=one-composed,two-composed,three-composed --parallel=3
+nx run-many -t storybook -p one-composed two-composed three-composed --parallel=3
 ```
 
 2. Start your host Storybook in another tab of your terminal:
@@ -94,7 +94,7 @@ In your project's targets, in the `storybook` target, you will notice that the d
 
 We can keep this port for the project which will serve as the host of our configuration, but we must change the port numbers of the other projects, the projects which will be composed/composed. The reason for that is the following:
 
-- When the `nx run-many --target=storybook --parallel=3` command executes, it will go and look into your `project.json` file to see the port you have assigned for that project's Storybook.
+- When the `nx run-many -t storybook --parallel=3` command executes, it will go and look into your `project.json` file to see the port you have assigned for that project's Storybook.
 - When it finds a port that it is already used, it will change the port number randomly (usually adding `1` until it finds an empty port).
 
 Since we are using the `--parallel` flag, and the commands are executed in parallel, we cannot know for sure the order that the `storybook` command will be executed. So, we cannot be sure which port will correspond to which of the projects.
diff --git a/docs/nx-cloud/reference/config.md b/docs/nx-cloud/reference/config.md
index 19b23b883f..bc3c473ca0 100644
--- a/docs/nx-cloud/reference/config.md
+++ b/docs/nx-cloud/reference/config.md
@@ -25,7 +25,7 @@ Only operations listed in `cacheableOperations` can be cached using Nx Cloud and
 By default, Nx Cloud requests will time out after 10 seconds. `NX_CLOUD_NO_TIMEOUTS` disables the timeout.
 
 ```shell
-NX_CLOUD_NO_TIMEOUTS=true nx run-many --target=build --all
+NX_CLOUD_NO_TIMEOUTS=true nx run-many -t build --all
 ```
 
 ## Logging
diff --git a/docs/nx-cloud/reference/nx-cloud-cli.md b/docs/nx-cloud/reference/nx-cloud-cli.md
index f5530f8825..10f0cee694 100644
--- a/docs/nx-cloud/reference/nx-cloud-cli.md
+++ b/docs/nx-cloud/reference/nx-cloud-cli.md
@@ -35,10 +35,10 @@ target: `npx nx-cloud start-ci-run --stop-agents-after=e2e`.
 Invoking `npx nx-cloud start-ci-run` will tell Nx to distribute by default. You can enable/disable distribution for
 individual commands as follows:
 
-- `nx affected --target=build --dte` (explicitly enable distribution, Nx >= 14.7)
-- `nx affected --target=build --no-dte` (explicitly disable distribution, Nx >= 14.7)
-- `NX_CLOUD_DISTRIBUTED_EXECUTION=true nx affected --target=build` (explicitly enable distribution)
-- `NX_CLOUD_DISTRIBUTED_EXECUTION=false nx affected --target=build` (explicitly disable distribution)
+- `nx affected -t build --dte` (explicitly enable distribution, Nx >= 14.7)
+- `nx affected -t build --no-dte` (explicitly disable distribution, Nx >= 14.7)
+- `NX_CLOUD_DISTRIBUTED_EXECUTION=true nx affected -t build` (explicitly enable distribution)
+- `NX_CLOUD_DISTRIBUTED_EXECUTION=false nx affected -t build` (explicitly disable distribution)
 
 ## npx nx-cloud stop-all-agents
 
diff --git a/docs/shared/angular-standalone-tutorial/4-task-pipelines.md b/docs/shared/angular-standalone-tutorial/4-task-pipelines.md
index aa857c3917..d21bb5ba13 100644
--- a/docs/shared/angular-standalone-tutorial/4-task-pipelines.md
+++ b/docs/shared/angular-standalone-tutorial/4-task-pipelines.md
@@ -257,7 +257,7 @@ The change made to the `cart` project is also affecting the `store` project. Thi
 To run the `test` targets only for affected projects, run the command:
 
 ```shell
-npx nx affected --target=test
+npx nx affected -t test
 ```
 
 This can be particularly helpful in CI pipelines for larger repos, where most commits only affect a small subset of the entire workspace.
diff --git a/docs/shared/angular-tutorial/4-workspace-optimization.md b/docs/shared/angular-tutorial/4-workspace-optimization.md
index 255f794b56..7483bd5f3a 100644
--- a/docs/shared/angular-tutorial/4-workspace-optimization.md
+++ b/docs/shared/angular-tutorial/4-workspace-optimization.md
@@ -31,7 +31,7 @@ The change made to the `common-ui` project is also affecting the `admin` and `st
 To run the `test` targets only for affected projects, run the command:
 
 ```shell
-npx nx affected --target=test
+npx nx affected -t test
 ```
 
 This can be particularly helpful in CI pipelines for larger repos, where most commits only affect a small subset of the entire workspace.
diff --git a/docs/shared/concepts/how-caching-works.md b/docs/shared/concepts/how-caching-works.md
index 87ec9d1fce..9326e16c9d 100644
--- a/docs/shared/concepts/how-caching-works.md
+++ b/docs/shared/concepts/how-caching-works.md
@@ -115,7 +115,7 @@ commands are identical from the caching perspective.
 
 ```shell
 npx nx build remixapp
-npx nx run-many --target=build --projects=remixapp
+npx nx run-many -t build -p remixapp
 ```
 
 In other words, Nx does not cache what the developer types into the terminal.
@@ -125,7 +125,7 @@ from
 cache or run. This means that from the caching point of view, the following command:
 
 ```shell
-npx nx run-many --target=build --projects=header,footer
+npx nx run-many -t build -p header footer
 ```
 
 is identical to the following two commands:
diff --git a/docs/shared/concepts/illustrated-dte-guide.md b/docs/shared/concepts/illustrated-dte-guide.md
index 67b185e746..043fd05fdb 100644
--- a/docs/shared/concepts/illustrated-dte-guide.md
+++ b/docs/shared/concepts/illustrated-dte-guide.md
@@ -12,7 +12,7 @@ A task, from Nx's perspective, is a target running on a project. i.e. The target
 
 ## Nx Cloud Schedules Your CI Tasks Automatically
 
-![when you turn on DTE, Nx will schedule your commands' tasks in CI.  for example, say you want to run these 3 commands to verify your code: nx affected --target=lint, nx affected --target=test and nx affected --target=build](../images/dte/schedule-tasks.jpeg)
+![when you turn on DTE, Nx will schedule your commands' tasks in CI.  for example, say you want to run these 3 commands to verify your code: nx affected -t lint, nx affected -t test and nx affected -t build](../images/dte/schedule-tasks.jpeg)
 
 Let's imagine for every PR in CI, you want to lint, test and build all affected projects. When you write your CI workflow, you have no way of knowing how many projects will be affected by each PR or how long each task will take. No matter how carefully you set things up, there will be wasted time if you manually assign a static number of agent machines for linting, testing and building. This approach is called binning.
 
diff --git a/docs/shared/concepts/improve-worst-case-ci-times.md b/docs/shared/concepts/improve-worst-case-ci-times.md
index 89b0879806..a3ad67a368 100644
--- a/docs/shared/concepts/improve-worst-case-ci-times.md
+++ b/docs/shared/concepts/improve-worst-case-ci-times.md
@@ -13,9 +13,9 @@ The CI setups we'll discuss are:
 Most organizations start their CI as a single job that is responsible for running any tasks that are required. The script for this CI setup using Nx would look something like this:
 
 ```yaml
-- nx affected --target=lint
-- nx affected --target=test
-- nx affected --target=build
+- nx affected -t lint
+- nx affected -t test
+- nx affected -t build
 ```
 
 This script will run all lint, test and build targets for projects that are affected by the current PR.
@@ -46,17 +46,17 @@ To improve the performance of the worst case CI time, you have to implement some
 
 ```yaml {% fileName="lint-agent.yml" %}
 # Run lint for all projects defined in PROJECTS
-- nx run-many --projects=$PROJECTS --target=lint
+- nx run-many --projects=$PROJECTS -t lint
 ```
 
 ```yaml {% fileName="test-agent.yml" %}
 # Run test for all projects defined in PROJECTS
-- nx run-many --projects=$PROJECTS --target=test
+- nx run-many --projects=$PROJECTS -t test
 ```
 
 ```yaml {% fileName="build-agent.yml" %}
 # Run build for all projects defined in PROJECTS
-- nx run-many --projects=$PROJECTS --target=build
+- nx run-many --projects=$PROJECTS -t build
 ```
 
 Here's a visualization of how this approach works:
@@ -90,7 +90,7 @@ The setup looks like this:
 # Coordinate the agents to run the tasks
 - npx nx-cloud start-ci-run
 # Run any commands you want here
-- nx affected --target=lint & nx affected --target=test & nx affected --target=build
+- nx affected -t lint & nx affected -t test & nx affected -t build
 # Stop any run away agents
 - npx nx-cloud stop-all-agents
 ```
diff --git a/docs/shared/core-features/distribute-task-execution.md b/docs/shared/core-features/distribute-task-execution.md
index 844e1471fe..f4d4ae6d86 100644
--- a/docs/shared/core-features/distribute-task-execution.md
+++ b/docs/shared/core-features/distribute-task-execution.md
@@ -108,7 +108,7 @@ machine. I.e., Nx Cloud doesn't manage your agents--you need to do it in your CI
 Nx Cloud is an orchestrator. The main job tells Nx Cloud what you want to run, and Nx Cloud will distribute those tasks
 across the agents. Nx Cloud will automatically move files from one agent to another, from the agents to the main job.
 
-The end result is that when say `nx affected --target=build` completes on the main job, all the file artifacts created
+The end result is that when say `nx affected -t build` completes on the main job, all the file artifacts created
 on agents are copied over to the main job, as if the main job had built everything locally.
 
 ## Running Things in Parallel
diff --git a/docs/shared/core-features/run-tasks.md b/docs/shared/core-features/run-tasks.md
index 5bd43a870d..e47f56b8b6 100644
--- a/docs/shared/core-features/run-tasks.md
+++ b/docs/shared/core-features/run-tasks.md
@@ -65,12 +65,12 @@ npx nx test header
 To run the `build` target for all projects in the repo, run:
 
 ```shell
-npx nx run-many --target=build
+npx nx run-many -t build
 ```
 
 This will build the projects in the right order: `footer` and `header` and then `myapp`.
 
-```{% command="npx nx run-many --target=build" %}
+```{% command="npx nx run-many -t build" %}
     ✔  nx run header:build (501ms)
     ✔  nx run footer:build (503ms)
     ✔  nx run myapp:build (670ms)
@@ -88,7 +88,7 @@ the name of the target.
 You can also run a command for all the projects affected by your PR like this:
 
 ```shell
-npx nx affected --target=test
+npx nx affected -t test
 ```
 
 Learn more about the affected command [here](/concepts/affected).
diff --git a/docs/shared/core-tutorial/04-build-affected-projects.md b/docs/shared/core-tutorial/04-build-affected-projects.md
index 423a72819d..b2327baaa6 100644
--- a/docs/shared/core-tutorial/04-build-affected-projects.md
+++ b/docs/shared/core-tutorial/04-build-affected-projects.md
@@ -63,7 +63,7 @@ Update `packages/ascii/assets/cow.txt`:
 
 Printing the affected projects can be handy, but usually you want to do something with them. For instance, you may want to build everything that has been affected.
 
-**Run `nx affected --target=build` to rebuild only the projects affected by the change.**
+**Run `nx affected -t build` to rebuild only the projects affected by the change.**
 
 ```shell
     ✔  nx run blog:build (1s)
@@ -78,12 +78,12 @@ Printing the affected projects can be handy, but usually you want to do somethin
 
 Note that Nx only built `blog` and `cli`. It didn't build `ascii` because there is no build script created for it.
 
-## Affected --target=\*
+## Affected -t \*
 
 You can run any target against the affected projects in the graph like this:
 
 ```shell
-nx affected --target=test
+nx affected -t test
 ```
 
 ## What's Next
diff --git a/docs/shared/mental-model.md b/docs/shared/mental-model.md
index a83e5e1f56..79dee8488f 100644
--- a/docs/shared/mental-model.md
+++ b/docs/shared/mental-model.md
@@ -47,7 +47,7 @@ A task is an invocation of a target. If you invoke the same target twice, you cr
 
 Nx uses the [project graph](#the-project-graph), but the task graph and project graph aren’t isomorphic, meaning they
 aren’t directly connected. In the case above, `app1` and `app2` depend on `lib`, but
-running `nx run-many --target=test --projects=app1,app2,lib`, the created task graph will look like this:
+running `nx run-many -t test -p app1 app2 lib`, the created task graph will look like this:
 {% side-by-side %}
 
 **Project Graph**
@@ -118,21 +118,21 @@ execution time.
 
 When you run `nx test app1`, you are telling Nx to run the `app1:test` task plus all the tasks it depends on.
 
-When you run `nx run-many --target=test --projects=app1,lib`, you are telling Nx to do the same for two
+When you run `nx run-many -t test -p app1 lib`, you are telling Nx to do the same for two
 tasks `app1:test`
 and `lib:test`.
 
-When you run `nx run-many --target=test --all`, you are telling Nx to do this for all the projects.
+When you run `nx run-many -t test --all`, you are telling Nx to do this for all the projects.
 
 As your workspace grows, retesting all projects becomes too slow. To address this Nx implements code change analysis to
 get the min set of projects that need to be retested. How does it work?
 
-When you run `nx affected --target=test`, Nx looks at the files you changed in your PR, it will look at the nature of
+When you run `nx affected -t test`, Nx looks at the files you changed in your PR, it will look at the nature of
 change (what exactly did you update in those files), and it uses this to figure the list of projects in the workspace
 that can be affected by this change. It then runs the `run-many` command with that list.
 
-For instance, if my PR changes `lib`, and I then run `nx affected --target=test`, Nx figures out that `app1` and `app2`
-depend on `lib`, so it will invoke `nx run-many --target=test --projects=app1,app2,lib`.
+For instance, if my PR changes `lib`, and I then run `nx affected -t test`, Nx figures out that `app1` and `app2`
+depend on `lib`, so it will invoke `nx run-many -t test -p app1 app2 lib`.
 
 ![affected](/shared/mental-model/affected.svg)
 
diff --git a/docs/shared/migration/adding-to-monorepo.md b/docs/shared/migration/adding-to-monorepo.md
index 38c6c35656..cade73fd63 100644
--- a/docs/shared/migration/adding-to-monorepo.md
+++ b/docs/shared/migration/adding-to-monorepo.md
@@ -69,7 +69,7 @@ In a package-based monorepo, Nx only manages the scheduling and caching of your
 For example, use Nx to run your builds:
 
 ```shell
-npx nx run-many --target=build
+npx nx run-many -t build
 ```
 
 But instead keep using NPM/Yarn/PNPM workspace commands for your tests and other scripts. Here's an example of using PNPM commands to run tests across packages
diff --git a/docs/shared/migration/lerna-and-nx.md b/docs/shared/migration/lerna-and-nx.md
index 85ec17d650..35a0fb8b8b 100644
--- a/docs/shared/migration/lerna-and-nx.md
+++ b/docs/shared/migration/lerna-and-nx.md
@@ -114,19 +114,19 @@ Here's an overview of some more Lerna commands and the corresponding Nx version:
   "private": true,
   "scripts": {
 -   "build:all": "lerna run build",
-+   "build:all": "nx run-many --target=build",
++   "build:all": "nx run-many -t build",
 -   "build:app1": "lerna run build --scope=app1",
 +   "build:app1": "nx build app1",
 -   "build:since": "lerna run build --since=main",
-+   "build:since": "nx affected --target=build",
++   "build:since": "nx affected -t build",
 -   "test:all": "lerna run test",
-+   "test:all": "nx run-many --target=test",
++   "test:all": "nx run-many -t test",
 -   "test:app1": "lerna run test --scope=app1",
 +   "test:app1": "nx test app1",
 -   "test:since": "lerna run test --since=main",
-+   "test:since": "nx affected --target=test",
++   "test:since": "nx affected -t test",
 -   "dev": "lerna run dev --stream --parallel",
-+   "dev": "nx run-many --target=dev",
++   "dev": "nx run-many -t dev",
 -   "dev:app1": "lerna run dev --stream --scope=app1",
 +   "dev:app1": "nx dev app1"
   },
diff --git a/docs/shared/node-server-tutorial/4-task-pipelines.md b/docs/shared/node-server-tutorial/4-task-pipelines.md
index 1b5aa37a35..26bb3a5db2 100644
--- a/docs/shared/node-server-tutorial/4-task-pipelines.md
+++ b/docs/shared/node-server-tutorial/4-task-pipelines.md
@@ -212,7 +212,7 @@ The change made to the `products-api` project is also affecting the `e2e` projec
 To run the `lint` targets only for affected projects, run the command:
 
 ```shell
-npx nx affected --target=lint
+npx nx affected -t lint
 ```
 
 This can be particularly helpful in CI pipelines for larger repos, where most commits only affect a small subset of the entire workspace.
diff --git a/docs/shared/npm-tutorial/integrated.md b/docs/shared/npm-tutorial/integrated.md
index c19f972a3b..5178b2dfb6 100644
--- a/docs/shared/npm-tutorial/integrated.md
+++ b/docs/shared/npm-tutorial/integrated.md
@@ -195,12 +195,12 @@ Done compiling TypeScript files for project "is-even".
 To run the `build` target for all the packages in the workspace, use:
 
 ```shell
-npx nx run-many --target=build
+npx nx run-many -t build
 ```
 
 What you would get is the following:
 
-```{% command="npx nx run-many --target=build" %}
+```{% command="npx nx run-many -t build" %}
     ✔  nx run is-even:build  [existing outputs match the cache, left as is]
     ✔  nx run is-odd:build (906ms)
 
@@ -216,7 +216,7 @@ Note how on the `is-even:build` it didn't run the build but rather pulled it out
 You can also only run tasks on packages that got changed by using
 
 ```shell
-npx nx affected --target=build
+npx nx affected -t build
 ```
 
 ## Learn More
diff --git a/docs/shared/npm-tutorial/package-based.md b/docs/shared/npm-tutorial/package-based.md
index adc41ceb4b..6f539b5830 100644
--- a/docs/shared/npm-tutorial/package-based.md
+++ b/docs/shared/npm-tutorial/package-based.md
@@ -195,7 +195,7 @@ Note that the cache for the `build` script was already populated when we ran it
 
 To run the `build` target for all the packages in the workspace, use:
 
-```{% command="npx nx run-many --target=build" %}
+```{% command="npx nx run-many -t build" %}
     ✔  nx run is-even:build  [existing outputs match the cache, left as is]
     ✔  nx run is-odd:build  [existing outputs match the cache, left as is]
 
@@ -208,7 +208,7 @@ To run the `build` target for all the packages in the workspace, use:
 
 Notice that both builds are replayed from cache. We can skip the cache by adding the `--skip-nx-cache` option:
 
-```{% command="npx nx run-many --target=build --skip-nx-cache" %}
+```{% command="npx nx run-many -t build --skip-nx-cache" %}
     ✔  nx run is-even:build (1s)
     ✔  nx run is-odd:build (1s)
 
@@ -221,7 +221,7 @@ Notice that using this method, the `is-even` build ran before the `is-odd` build
 
 You can also only run tasks on packages that got changed by using the command:
 
-```{% command="npx nx affected --target=build" %}
+```{% command="npx nx affected -t build" %}
 
  >  NX   Affected criteria defaulted to --base=main --head=HEAD
 
diff --git a/docs/shared/packages/jest/jest-plugin.md b/docs/shared/packages/jest/jest-plugin.md
index ef6e645203..b7eb3dc5a1 100644
--- a/docs/shared/packages/jest/jest-plugin.md
+++ b/docs/shared/packages/jest/jest-plugin.md
@@ -86,7 +86,7 @@ Snapshot files should be checked in with your code.
 
 ### Performance in CI
 
-Typically, in CI it's recommended to use `nx affected --target=test --parallel=[# CPUs] -- --runInBand` for the best performance.
+Typically, in CI it's recommended to use `nx affected -t test --parallel=[# CPUs] -- --runInBand` for the best performance.
 
 This is because each [jest process creates a workers based on system resources](https://jestjs.io/docs/cli#--maxworkersnumstring), running multiple projects via nx and using jest workers will create too many process overall causing the system to run slower than desired. Using the `--runInBand` flag tells jest to run in a single process.
 
diff --git a/docs/shared/packages/storybook/storybook-composition-setup.md b/docs/shared/packages/storybook/storybook-composition-setup.md
index d2970dd7b4..747ba8ee0d 100644
--- a/docs/shared/packages/storybook/storybook-composition-setup.md
+++ b/docs/shared/packages/storybook/storybook-composition-setup.md
@@ -57,7 +57,7 @@ In order to get it working for you, you need to two things:
 1. Make sure your "composed" Storybook instances are running. For that you can do:
 
 ```shell
-nx run-many --target=storybook --projects=one-composed,two-composed,three-composed --parallel=3
+nx run-many -t storybook -p one-composed two-composed three-composed --parallel=3
 ```
 
 2. Start your host Storybook in another tab of your terminal:
@@ -94,7 +94,7 @@ In your project's targets, in the `storybook` target, you will notice that the d
 
 We can keep this port for the project which will serve as the host of our configuration, but we must change the port numbers of the other projects, the projects which will be composed/composed. The reason for that is the following:
 
-- When the `nx run-many --target=storybook --parallel=3` command executes, it will go and look into your `project.json` file to see the port you have assigned for that project's Storybook.
+- When the `nx run-many -t storybook --parallel=3` command executes, it will go and look into your `project.json` file to see the port you have assigned for that project's Storybook.
 - When it finds a port that it is already used, it will change the port number randomly (usually adding `1` until it finds an empty port).
 
 Since we are using the `--parallel` flag, and the commands are executed in parallel, we cannot know for sure the order that the `storybook` command will be executed. So, we cannot be sure which port will correspond to which of the projects.
diff --git a/docs/shared/plugin-features/use-task-executors.md b/docs/shared/plugin-features/use-task-executors.md
index 7cbf8d5eb6..0cb1584e68 100644
--- a/docs/shared/plugin-features/use-task-executors.md
+++ b/docs/shared/plugin-features/use-task-executors.md
@@ -5,7 +5,7 @@ Executors perform actions on your code. This can include building, linting, test
 There are two main differences between an executor and a shell script or an npm script:
 
 1. Executors encourage a consistent methodology for performing similar actions on unrelated projects. i.e. A developer switching between teams can be confident that `nx build project2` will build `project2` with the default settings, just like `nx build project1` built `project1`.
-2. Nx can leverage this consistency to run the same target across multiple projects. i.e. `nx affected --target=test` will run the `test` executor associated with the `test` target on every project that is affected by the current code change.
+2. Nx can leverage this consistency to run the same target across multiple projects. i.e. `nx affected -t test` will run the `test` executor associated with the `test` target on every project that is affected by the current code change.
 3. Executors provide metadata to define the available options. This metadata allows the Nx CLI to show prompts in the terminal and Nx Console to generate a GUI for the executor.
 
 ## Executor definitions
diff --git a/docs/shared/react-standalone-tutorial/4-task-pipelines.md b/docs/shared/react-standalone-tutorial/4-task-pipelines.md
index 030e332de5..eec6eef33c 100644
--- a/docs/shared/react-standalone-tutorial/4-task-pipelines.md
+++ b/docs/shared/react-standalone-tutorial/4-task-pipelines.md
@@ -229,7 +229,7 @@ The change made to the `cart` project is also affecting the `store` project. Thi
 To run the `test` targets only for affected projects, run the command:
 
 ```shell
-npx nx affected --target=test
+npx nx affected -t test
 ```
 
 This can be particularly helpful in CI pipelines for larger repos, where most commits only affect a small subset of the entire workspace.
diff --git a/docs/shared/react-tutorial/4-workspace-optimization.md b/docs/shared/react-tutorial/4-workspace-optimization.md
index 16bb28d50a..75c79c71f9 100644
--- a/docs/shared/react-tutorial/4-workspace-optimization.md
+++ b/docs/shared/react-tutorial/4-workspace-optimization.md
@@ -31,7 +31,7 @@ The change made to the `common-ui` project is also affecting the `admin` and `st
 To run the `test` targets only for affected projects, run the command:
 
 ```shell
-npx nx affected --target=test
+npx nx affected -t test
 ```
 
 This can be particularly helpful in CI pipelines for larger repos, where most commits only affect a small subset of the entire workspace.
diff --git a/docs/shared/recipes/azure-last-successful-commit.md b/docs/shared/recipes/azure-last-successful-commit.md
index 41e7252b62..f8aa79bccf 100644
--- a/docs/shared/recipes/azure-last-successful-commit.md
+++ b/docs/shared/recipes/azure-last-successful-commit.md
@@ -76,7 +76,7 @@ jobs:
       - script: npx nx workspace-lint
       - script: npx nx format:check
 
-      - script: npx nx affected --base=$(BASE_SHA) --target=lint --parallel=3
-      - script: npx nx affected --base=$(BASE_SHA) --target=test --parallel=3 --ci --code-coverage
-      - script: npx nx affected --base=$(BASE_SHA) --target=build --parallel=3
+      - script: npx nx affected --base=$(BASE_SHA) -t lint --parallel=3
+      - script: npx nx affected --base=$(BASE_SHA) -t test --parallel=3 --ci --code-coverage
+      - script: npx nx affected --base=$(BASE_SHA) -t build --parallel=3
 ```
diff --git a/docs/shared/recipes/console-shortcuts.md b/docs/shared/recipes/console-shortcuts.md
index 1d2b7b1c65..54ddd4e356 100644
--- a/docs/shared/recipes/console-shortcuts.md
+++ b/docs/shared/recipes/console-shortcuts.md
@@ -14,7 +14,7 @@ You can also set up custom tasks and assign keyboard shortcuts to them. In `.vsc
 {
   "label": "Test Affected",
   "type": "shell",
-  "command": "nx affected --target=test"
+  "command": "nx affected -t test"
 }
 ```
 
@@ -28,6 +28,6 @@ Then from the Command Palette (`⇧⌘P`) choose `Preferences: Open Keyboard Sho
 }
 ```
 
-Now, pressing `^⌘T` will run `nx affected --target=test`.
+Now, pressing `^⌘T` will run `nx affected -t test`.
 
 Here is more information on [VSCode tasks](https://code.visualstudio.com/docs/editor/tasks) and [keyboard shortcuts](https://code.visualstudio.com/docs/getstarted/keybindings).
diff --git a/docs/shared/reference/nx-json.md b/docs/shared/reference/nx-json.md
index 833d0646a6..39c7b1630c 100644
--- a/docs/shared/reference/nx-json.md
+++ b/docs/shared/reference/nx-json.md
@@ -210,7 +210,7 @@ pass `--buildable=true` when creating new libraries.
 > A task is an invocation of a target.
 
 Tasks runners are invoked when you run `nx test`, `nx build`, `nx run-many`, `nx affected`, and so on. The tasks runner
-named "default" is used by default. Specify a different one like this `nx run-many --target=build --all --runner=another`.
+named "default" is used by default. Specify a different one like this `nx run-many -t build --all --runner=another`.
 
 Tasks runners can accept different options. The following are the options supported
 by `"nx/tasks-runners/default"` and `"@nrwl/nx-cloud"`.
@@ -226,4 +226,4 @@ by `"nx/tasks-runners/default"` and `"@nrwl/nx-cloud"`.
 | selectivelyHashTsConfig | only hash the path mapping of the active project in the `tsconfig.base.json` (e.g., adding/removing projects doesn't affect the hash of existing projects) (defaults to `false`)                                                                                                                                                              |
 
 You can configure `parallel` in `nx.json`, but you can also pass them in the
-terminal `nx run-many --target=test --parallel=5`.
+terminal `nx run-many -t test --parallel=5`.
diff --git a/docs/shared/running-custom-commands.md b/docs/shared/running-custom-commands.md
index 235eba47f5..7a89544229 100644
--- a/docs/shared/running-custom-commands.md
+++ b/docs/shared/running-custom-commands.md
@@ -50,11 +50,11 @@ nx make my-app
 You can also run the `make` command for all projects it has been defined on:
 
 ```shell
-nx run-many --target=make
+nx run-many -t make
 ```
 
 Or just on a subset of projects that are [affected by a given change](/concepts/affected):
 
 ```shell
-nx affected --target=make
+nx affected -t make
 ```
diff --git a/docs/shared/using-nx/affected.md b/docs/shared/using-nx/affected.md
index 199e7caeab..8d7ec3d746 100644
--- a/docs/shared/using-nx/affected.md
+++ b/docs/shared/using-nx/affected.md
@@ -8,20 +8,20 @@ Before reading this guide, [check out the mental model guide](/concepts/mental-m
 
 When you run `nx test app1`, you are telling Nx to run the app1:test task plus all the tasks it depends on.
 
-When you run `nx run-many --target=test --projects=app1,lib`, you are telling Nx to do the same for two tasks app1:test
+When you run `nx run-many -t test -p app1 lib`, you are telling Nx to do the same for two tasks app1:test
 and lib:test.
 
-When you run `nx run-many --target=test --all`, you are telling Nx to do this for all the projects.
+When you run `nx run-many -t test`, you are telling Nx to do this for all the projects.
 
 As your workspace grows, retesting all projects becomes too slow. To address this Nx implements code change analysis to
 get the min set of projects that need to be retested. How does it work?
 
-When you run `nx affected --target=test`, Nx looks at the files you changed in your PR, it will look at the nature of
+When you run `nx affected -t test`, Nx looks at the files you changed in your PR, it will look at the nature of
 change (what exactly did you update in those files), and it uses this to figure the list of projects in the workspace
 that can be affected by this change. It then runs the `run-many` command with that list.
 
-For instance, if my PR changes `lib`, and I then run `nx affected --target=test`, Nx figures out that `app1` and `app2`
-depend on `lib`, so it will invoke `nx run-many --target=test --projects=app1,app2,lib`.
+For instance, if my PR changes `lib`, and I then run `nx affected -t test`, Nx figures out that `app1` and `app2`
+depend on `lib`, so it will invoke `nx run-many -t test -p app1 app2 lib`.
 
 ![affected](/shared/mental-model/affected.svg)
 
diff --git a/docs/shared/workspace/creating-libraries.md b/docs/shared/workspace/creating-libraries.md
index a14217df9b..60d63d4f70 100644
--- a/docs/shared/workspace/creating-libraries.md
+++ b/docs/shared/workspace/creating-libraries.md
@@ -8,7 +8,7 @@ There are three main benefits to breaking your code up into more libraries.
 
 ### 1. Faster Commands
 
-The more granular your libraries are, the more effective `nx affected` and Nx's computation cache will be. For example, if `libraryA` contains 10 tests, but only 5 of them were affected by a particular code change, all 10 tests will be run by `nx affected --target=test`. If you can predict which 5 tests are usually run together, you can split all the related code into a separate library to allow the two groups of 5 tests to be executed independently.
+The more granular your libraries are, the more effective `nx affected` and Nx's computation cache will be. For example, if `libraryA` contains 10 tests, but only 5 of them were affected by a particular code change, all 10 tests will be run by `nx affected -t test`. If you can predict which 5 tests are usually run together, you can split all the related code into a separate library to allow the two groups of 5 tests to be executed independently.
 
 ### 2. Visualizing Architecture
 
diff --git a/packages/nx/src/command-line/examples.ts b/packages/nx/src/command-line/examples.ts
index 68977fc89d..3a765587c8 100644
--- a/packages/nx/src/command-line/examples.ts
+++ b/packages/nx/src/command-line/examples.ts
@@ -16,56 +16,56 @@ export const examples: Record<string, Example[]> = {
         'Print information about the projects affected by the changes between main and HEAD (e.g,. PR)',
     },
     {
-      command: 'print-affected --target=test',
+      command: 'print-affected -t test',
       description:
         'Prints information about the affected projects and a list of tasks to test them',
     },
     {
-      command: 'print-affected --target=build --select=projects',
+      command: 'print-affected -t build --select=projects',
       description:
         'Prints the projects property from the print-affected output',
     },
     {
-      command: 'print-affected --target=build --select=tasks.target.project',
+      command: 'print-affected -t build --select=tasks.target.project',
       description:
         'Prints the tasks.target.project property from the print-affected output',
     },
   ],
   affected: [
     {
-      command: 'affected --target=custom-target',
+      command: 'affected -t custom-target',
       description: 'Run custom target for all affected projects',
     },
     {
-      command: 'affected --target=test --parallel=5',
+      command: 'affected -t test --parallel=5',
       description: 'Run tests in parallel',
     },
     {
-      command: 'affected --target=test --all',
+      command: 'affected -t test --all',
       description: 'Run the test target for all projects',
     },
     {
-      command: 'affected --targets=lint,test,build',
+      command: 'affected -t lint test build',
       description:
         'Run lint, test, and build targets for affected projects. Requires Nx v15.4+',
     },
     {
-      command: 'affected --target=test --files=libs/mylib/src/index.ts',
+      command: 'affected -t test --files=libs/mylib/src/index.ts',
       description:
         'Run tests for all the projects affected by changing the index.ts file',
     },
     {
-      command: 'affected --target=test --base=main --head=HEAD',
+      command: 'affected -t test --base=main --head=HEAD',
       description:
         'Run tests for all the projects affected by the changes between main and HEAD (e.g., PR)',
     },
     {
-      command: 'affected --target=test --base=main~1 --head=main',
+      command: 'affected -t test --base=main~1 --head=main',
       description:
         'Run tests for all the projects affected by the last commit on main',
     },
     {
-      command: 'affected --target=build --tag=$NX_TARGET_TASK_PROJECT:latest',
+      command: 'affected -t build --tag=$NX_TARGET_TASK_PROJECT:latest',
       description: 'Use the currently executing project name in your command.',
     },
   ],
@@ -289,28 +289,28 @@ export const examples: Record<string, Example[]> = {
   ],
   'run-many': [
     {
-      command: 'run-many --target=test',
+      command: 'run-many -t test',
       description: 'Test all projects',
     },
     {
-      command: 'run-many --target=test --projects=proj1,proj2',
+      command: 'run-many -t test -p proj1 proj2',
       description: 'Test proj1 and proj2 in parallel',
     },
     {
-      command: 'run-many --target=test --projects=proj1,proj2 --parallel=5',
+      command: 'run-many -t test -p proj1 proj2 --parallel=5',
       description: 'Test proj1 and proj2 in parallel using 5 workers',
     },
     {
-      command: 'run-many --target=test --projects=proj1,proj2 --parallel=false',
+      command: 'run-many -t test -p proj1 proj2 --parallel=false',
       description: 'Test proj1 and proj2 in sequence',
     },
     {
-      command: 'run-many --target=test --projects=*-app --exclude=excluded-app',
+      command: 'run-many -t test --projects=*-app --exclude excluded-app',
       description:
         'Test all projects ending with `*-app` except `excluded-app`.  Note: your shell may require you to escape the `*` like this: `\\*`',
     },
     {
-      command: 'run-many --target=test --projects=tag:api-*',
+      command: 'run-many -t test --projects=tag:api-*',
       description:
         'Test all projects with tags starting with `api-`.  Note: your shell may require you to escape the `*` like this: `\\*`',
     },
@@ -378,7 +378,7 @@ export const examples: Record<string, Example[]> = {
     },
     {
       command:
-        'watch --projects=app1,app2 --includeDependentProjects -- echo \\$NX_PROJECT_NAME',
+        'watch --projects=app1,app2 --includeDependencies -- echo \\$NX_PROJECT_NAME',
       description:
         'Watch "app1" and "app2" and echo the project name whenever a specified project or its dependencies change',
     },