diff --git a/docs/lint-and-commit-setup/lint-and-commit-setup-flow-diagram.png b/docs/lint-and-commit-setup/lint-and-commit-setup-flow-diagram.png
deleted file mode 100644
index beaa4336..00000000
Binary files a/docs/lint-and-commit-setup/lint-and-commit-setup-flow-diagram.png and /dev/null differ
diff --git a/docs/lint-and-commit-setup/lint-and-commit-setup.md b/docs/lint-and-commit-setup/lint-and-commit-setup.md
deleted file mode 100644
index 10d82f97..00000000
--- a/docs/lint-and-commit-setup/lint-and-commit-setup.md
+++ /dev/null
@@ -1,43 +0,0 @@
-This markdown document provides explanations for how the lint and commit setup works in the project.
-
-![alt text](lint-and-commit-setup-flow-diagram.png)
-
-## Brief overview of git hooks
-- Hooks are named for the event they intercept and use `pre-` or `post-` prefixes to indicate their timing. E.gs are: `pre-commit`, `commit-msg`(after the commit message, but before the commit is created), `pre-push`, and `post-receive` (after successful push).
-
-- Inside any git repo, the hooks are stored in `.git/hooks` directory. The sample hooks can be activated by renaming them and removing the `.sample` extension.
-
-## How does husky work?
-- When we run `npm run prepare`, `husky install` command is executed, which creates a `.husky` directory in the root of the project and sets up the files for managing git hooks in `_` subdirectory. It also sets `git config core.hooksPath .husky` to tell git to look for hooks in the `.husky/_` directory instead of the default `.git/hooks` directory. We can override the default hooks by creating files with the same name as the hook we want to override in the `.husky` directory. For example, if we want to override the `pre-commit` hook, we can create a file named `pre-commit` in the `.husky` directory and add our custom script to it. 
-
-One e.g. commit flow is this:
-```txt
-git commit
-  -> Git notices "pre-commit" should run
-  -> Git looks in core.hooksPath (.husky/_)
-  -> Git executes .husky/_/pre-commit (The command is: . "$(dirname "$0")/h")
-  -> that forwards calls to Husky's  (.husky/_/h) helper script
-  -> Husky's helper runs our real .husky/pre-commit script
-```
-
-## How commiting works in our project?
-- We use a library called `lint-staged` to run linters on the staged files before committing. The configuration for `lint-staged` is defined in the `package.json` file under the `lint-staged` key. It specifies that we want to run `eslint` on all staged JavaScript and TypeScript files.
-
-- Our current pre-commit hook is set up to run `lint-staged` command, which runs `eslint` on the staged files.
-
-- Then, the `commit-msg` hook is set up to run `commitlint` command, which checks the commit message against the defined rules in `commitlint.config.js` file. The rules specify that the commit message should follow the conventional commit format, which includes a type, an optional scope, and a description. If the commit message does not follow the format, the commit will be rejected and an error message will be displayed.
-
-```txt
-git commit
-    ... (the above flow happens)
-    -> `npx lint-staged` is executed in the pre-commit hook
-    -> `lint-staged` looks at the configuration in `package.json` and finds that it needs to run `eslint` on all staged JavaScript and TypeScript files
-    -> `eslint` runs on the staged files and checks for any linting errors
-    -> If there are linting errors, the commit is rejected and an error message is displayed
-    -> If there are no linting errors, the commit proceeds to the next step, which is the `commit-msg` hook
-    -> `npx commitlint --edit $1` is executed in the `commit-msg` hook
-    -> `commitlint` checks the commit message against the rules defined in `commitlint.config.js`
-    -> If the commit message does not follow the conventional commit format, the commit is rejected and an error message is displayed
-    -> If the commit message follows the conventional commit format, the commit is created successfully.
-```
-