diff --git a/README.md b/README.md
index 52d0915..bafa7f4 100644
--- a/README.md
+++ b/README.md
@@ -1,43 +1,89 @@
-# ci-template
+# CI Template
 
+A template repository for setting up continuous integration and automatic semantic versioning with Gitea.
 
-Setup first make sure to add yourself to the whitelisted users on the release branch protection rule(you can undo this after the setup)
+## Features
 
-![1](images/1.png)
+- Automated semantic versioning with [semantic-release](https://github.com/semantic-release/semantic-release)
+- Integration with Gitea for releases
+- Changelog generation
+- Pull request workflows
 
-After that make sure to save
+## Setup Instructions
 
-![2](images/2.png)
+Follow these steps to set up the CI pipeline and release process:
 
-The you can go ahead and create the release branch
+### 1. Configure Branch Protection
 
-![3](images/3.png)
+Add yourself to the whitelist in the release branch protection rule.
 
-After that you will see that the pipeline for release has started. This will fail and is normal when creating the release branch
+![Branch protection settings](images/1.png)
 
-![4](images/4.png)
+Don't forget to save your changes.
 
-After that you should push the first version tag (v0.1.0).
+![Save changes](images/2.png)
 
-To do this run the following:
+### 2. Create the Release Branch
+
+Create a new branch named `release`.
+
+![Create release branch](images/3.png)
+
+The pipeline for release will start automatically but will fail on the first run. This is expected behavior.
+
+![Initial pipeline failure](images/4.png)
+
+### 3. Create the Initial Version Tag
+
+Run the following commands to create and push the first version tag:
+
+```bash
 git tag v0.1.0
 git push origin tag v0.1.0
+```
 
+### 4. Configure Pull Request Settings
 
-next you should set up the pull request settings like this
+Set up your repository's pull request settings as shown:
 
-![5](images/5.png)
+![Pull request settings](images/5.png)
 
-Next you will want to create a deploy ssh key. this will be used for the automatic releases.
-For this you can generate an ssh public and private key locally or however you like
-Once you have the key you should set up the public key in deploy keys and name it release. Make sure to enable write access.
+### 5. Set Up Deploy Keys
 
+1. Generate an SSH key pair (public and private)
+2. Add the public key to deploy keys named "release" with write access enabled
 
-![6](images/6.png)
+![Deploy key setup](images/6.png)
 
-next you should put the private part in the runner secret DEPLOY_KEY
+3. Add the private key to the runner secret as `DEPLOY_KEY`
 
-![7](images/7.png)
+![Runner secret](images/7.png)
 
-Now you should be done.
-You can now also delete all the images and this readme
+## Release Process
+
+This template uses semantic versioning through conventional commits. When changes are merged to the release branch, a new version is automatically:
+
+1. Determined based on commit messages
+2. Tagged in Git
+3. Published as a release
+4. Added to the changelog
+
+### Commit Message Format
+
+Follow the [Conventional Commits](https://www.conventionalcommits.org/) specification:
+
+- `feat: add new feature` (triggers MINOR version bump)
+- `fix: resolve bug` (triggers PATCH version bump)
+- `BREAKING CHANGE: redesign API` (triggers MAJOR version bump)
+
+## Getting Started
+
+After setup, you can:
+1. Create a feature branch from main
+2. Make changes and commit using conventional commit format
+3. Create a pull request to main
+4. After approval, changes will be merged to release automatically
+
+## License
+
+See the [LICENSE](LICENSE) file for details.
\ No newline at end of file