diff --git a/docs/README.md b/docs/README.md
index 8d44a69..6083718 100644
--- a/docs/README.md
+++ b/docs/README.md
@@ -1,13 +1,12 @@
 # Documentation of mk tool
 
-`mk` is a CLI tool that aims to ease contribution to any open-source project
-by hiding repository implementation details from the casual contributor.
-With it, you can contribute without having to know all the build
-and testing tools that the project team already uses, which often have
-strange requirements.
+`mk` is a CLI tool that aims to ease contribution to any open-source project by
+hiding repository implementation details from the casual contributor. With it,
+you can contribute without having to know all the build and testing tools that
+the project team already uses, which often have strange requirements.
 
-If you ever asked yourself one of the below questions, probably you would
-want to try `mk` and if it can help you
+If you ever asked yourself one of the below questions, probably you would want
+to try `mk` and if it can help you
 
 - How do I run tests locally?
 - Which are the test suites I can run?
@@ -15,22 +14,23 @@ want to try `mk` and if it can help you
 - How can I propose a change for review?
 
 Run `mk` inside any cloned repository to display which options you have. No
-configuration file is needed as the tool will look for
-common tools used by the repository and expose their commands.
+configuration file is needed as the tool will look for common tools used by the
+repository and expose their commands.
 
 `mk` is inspired by the tools listed below, but it does not aim to replace them.
 
 - [make](https://www.gnu.org/software/make/)
 - [waf](https://gitlab.com/ita1024/waf)
-- [tox](https://github.com/tox-dev/tox/) and [nox](https://nox.thea.codes/en/stable/)
+- [tox](https://github.com/tox-dev/tox/) and
+  [nox](https://nox.thea.codes/en/stable/)
 - [npm](https://www.npmjs.com/) and [yarn](https://yarnpkg.com/)
 - [pre-commit](https://pre-commit.com/)
 
 ## Installation
 
-We recommend using [`pipx`](https://pipxproject.github.io/pipx/) to install
-`mk` in order to avoid potential dependency conflicts. You can use
-`pip3 install mk` as well.
+We recommend using [`pipx`](https://pipxproject.github.io/pipx/) to install `mk`
+in order to avoid potential dependency conflicts. You can use `pip3 install mk`
+as well.
 
 ```shell
 pipx install mk
@@ -42,21 +42,21 @@ pipx install mk
 
 ## How it works
 
-`mk` inspects the current core repository and detects build tools used
-by the project, like pre-commit, tox, npm and exposes their commands to
-the user in a **predictable** way.
+`mk` inspects the current core repository and detects build tools used by the
+project, like pre-commit, tox, npm and exposes their commands to the user in a
+**predictable** way.
 
 For example, you should be able to lint any code repository running only
-`mk lint`, regardless of author preference for picking one way to execute
-them or another.
+`mk lint`, regardless of author preference for picking one way to execute them
+or another.
 
-Be assured that `mk` does not make use of AI to guess what needs to
-run. As most projects use relatively similar patterns, it is easy to identify
-the one to execute.
+Be assured that `mk` does not make use of AI to guess what needs to run. As most
+projects use relatively similar patterns, it is easy to identify the one to
+execute.
 
-At this moment, if two tools expose the same command name, the tool will add
-a number to its name. In the future, we may decide to either chain them under
-a single name or allow some tools to shadow others and avoid duplicates.
+At this moment, if two tools expose the same command name, the tool will add a
+number to its name. In the future, we may decide to either chain them under a
+single name or allow some tools to shadow others and avoid duplicates.
 
 ## What are the main benefits
 
@@ -66,43 +66,48 @@ how-to-contribute documentation the author needs to write.
 A considerable amount of maintainer effort can go into producing documentation
 that makes it easier for someone to make a contribution to a project.
 
-Some projects are less affected than others. That is usually related to
-how well do the potential contributors know the practices used by the
-project. Still, if your project has a wide range of uses, you will quickly
-discover that newbie contributors may hit a knowledge wall. Such a barrier will
-likely prevent most of them from becoming active contributors. The remaining
-ones will flood the project with questions, distracting other maintainers from
-doing more advanced tasks.
+Some projects are less affected than others. That is usually related to how well
+do the potential contributors know the practices used by the project. Still, if
+your project has a wide range of uses, you will quickly discover that newbie
+contributors may hit a knowledge wall. Such a barrier will likely prevent most
+of them from becoming active contributors. The remaining ones will flood the
+project with questions, distracting other maintainers from doing more advanced
+tasks.
 
 Unless you want to deter contributions, you should plan to make it as easy as
 possible for people to contribute. That is one area where `mk` aims to help.
 
+## Aliases
+
+Similar to [git aliases](https://git-scm.com/book/en/v2/Git-Basics-Git-Aliases),
+`mk` allows typing as little as possible by automatically aliasing commands. For
+example, you can run `mk lint` just by typing `mk l` as long there is no other
+command starting with the same letter. Aliases are available for one, two and
+three letters prefixes.
+
 ## Using mk to propose changes to projects
 
-Instead of writing long list of tasks to follow, we can use a tool that
-tells him what to do next. For example, `mk` has a build-in command named
-`up(load)` that aims to ease preparing a local change from being
-proposed to the project.
+Instead of writing long list of tasks to follow, we can use a tool that tells
+him what to do next. For example, `mk` has a build-in command named `up(load)`
+that aims to ease preparing a local change from being proposed to the project.
 
-This command detects if it should use GitHub workflow or
-Gerrit and will run the appropriate commands for opening or updating a CR/PR. Users
-will be allowed to upload a change only after passing the minimal set of local
-tests, preventing noisy mistakes or clog CI/CD pipelines.
+This command detects if it should use GitHub workflow or Gerrit and will run the
+appropriate commands for opening or updating a CR/PR. Users will be allowed to
+upload a change only after passing the minimal set of local tests, preventing
+noisy mistakes or clog CI/CD pipelines.
 
-In addition to linting, it will also check that the repository is
-not in dirty status or that the testing did not leave untracked files on disk.
+In addition to linting, it will also check that the repository is not in dirty
+status or that the testing did not leave untracked files on disk.
 
 ## Planned features
 
-- Allow command aliases like git. If you type `mk l` it should directly run
-  lint unless there is another command starting with `l`. (#19)
 - Persistent state of each command run - This means that it will know if a
-  specific command was run and if it failed or not. The state would be linked
-  to the repository state, so modifying a tracked file would reset the state
-  to be unknown. (#20)
+  specific command was run and if it failed or not. The state would be linked to
+  the repository state, so modifying a tracked file would reset the state to be
+  unknown. (#20)
 - Configuration file where additional actions can be added. (#21)
-- Dependencies between commands. While some tools support dependencies,
-  many do not. You should be able to declare that a specific command would
-  run only after another one already passed. (#22)
+- Dependencies between commands. While some tools support dependencies, many do
+  not. You should be able to declare that a specific command would run only
+  after another one already passed. (#22)
 - Ability to generate CI/CD pipelines so the user would spend less time writing
   non-portable configuration. (#23)
diff --git a/src/mk/__main__.py b/src/mk/__main__.py
index 1d6b5ef..5df82ec 100644
--- a/src/mk/__main__.py
+++ b/src/mk/__main__.py
@@ -3,7 +3,7 @@
 import itertools
 import logging
 import os
-from typing import List
+from typing import Any, Dict, List
 
 import typer
 from rich.console import Console
@@ -95,6 +95,7 @@ def cli() -> None:
 
     # command = get_command_from_info(command_info=command_info)
 
+    action_map: Dict[str, Any] = {}
     for action in ctx.runner.actions:
         # Currently we rename action that overlap but in the future we may
         # want to allow one to shadow others or we may want to chain them
@@ -122,7 +123,23 @@ def cli() -> None:
             help=action.description,
             rich_help_panel=panel,
         )(action.run)
+        action_map[action_name] = action
         existing_commands.append(action_name)
+    # Add aliases for 1-3 letter commands
+    for alias_len in (1, 2, 3):
+        for x, action in action_map.items():
+            alias = x[0:alias_len]
+            # pylint: disable=consider-iterating-dictionary
+            if alias in action_map.keys():
+                continue
+            if sum(1 for name in action_map.keys() if name.startswith(alias)) == 1:
+                app.command(
+                    name=alias,
+                    short_help=f"Alias for [dim]mk {x}[/dim]",
+                    rich_help_panel="aliases",
+                    hidden=bool(opt.verbosity < 1),
+                )(action.run)
+
     app()
 
 
diff --git a/test/test_cli.py b/test/test_cli.py
index f2ad7ad..4405348 100644
--- a/test/test_cli.py
+++ b/test/test_cli.py
@@ -51,7 +51,7 @@ def do_complete() -> Optional[int]:
 
     assert result == 0
     assert benchmark.stats["min"] > 0.0001  # seconds
-    assert benchmark.stats["mean"] < 0.005  # seconds
+    assert benchmark.stats["mean"] < 0.01  # seconds
 
 
 @pytest.mark.parametrize(