Refactor CONTRIBUTING.md for improved clarity and consistency in formatting

Author: thought-operator

CONTRIBUTING.md

@@ -1,20 +1,19 @@
-Here is a comprehensive `CONTRIBUTING.md` tailored for your repository. It incorporates the specific tools (Black, Pylint, MyPy, Flake8) and the release workflow we discussed.
-
------
-
 # Contributing to Python Linting Action
 
 First off, thank you for considering contributing to this project\! It's people like you that make the open-source community such an amazing place to learn, inspire, and create. Any contributions you make are **greatly appreciated**.
 
 ## 🚀 Getting Started
 
-1.  **Fork the repository** on GitHub.
-2.  **Clone your fork** locally:
+1. **Fork the repository** on GitHub.
+2. **Clone your fork** locally:
+
     ```bash
     git clone https://github.com/your-username/python-linting.git
     cd python-linting
     ```
-3.  **Create a new branch** for your feature or fix:
+
+3. **Create a new branch** for your feature or fix:
+
     ```bash
     git checkout -b feature/amazing-new-feature
     ```
@@ -25,9 +24,9 @@ First off, thank you for considering contributing to this project\! It's people
 
 We want to keep the codebase clean and consistent. Before submitting your code, please ensure it passes the same quality checks that this Action enforces:
 
-  * **Formatting:** We use [Black](https://github.com/psf/black).
-  * **Linting:** We use [Pylint](https://pylint.pycqa.org/) and [Flake8](https://flake8.pycqa.org/).
-  * **Type Checking:** We use [MyPy](https://mypy-lang.org/).
+* **Formatting:** We use [Black](https://github.com/psf/black).
+* **Linting:** We use [Pylint](https://pylint.pycqa.org/) and [Flake8](https://flake8.pycqa.org/).
+* **Type Checking:** We use [MyPy](https://mypy-lang.org/).
 
 You can run these tools locally to verify your changes:
 
@@ -43,19 +42,21 @@ flake8 .
 
 **Crucial Step:** All substantive changes (features, fixes, breaking changes) must be documented.
 
-  * Open `CHANGELOG.md`.
-  * Add a bullet point describing your change under the `[Unreleased]` section.
-  * Follow the format: `* Description of change (@your-username)`
+* Open `CHANGELOG.md`.
+* Add a bullet point describing your change under the `[Unreleased]` section.
+* Follow the format: `* Description of change (@your-username)`
 
 ## 📮 Submitting a Pull Request
 
-1.  **Push your branch** to GitHub:
+1. **Push your branch** to GitHub:
+
     ```bash
     git push origin feature/amazing-new-feature
     ```
-2.  **Open a Pull Request** against the `main` branch.
-3.  **Fill out the PR Template:** Describe your changes clearly and link to any relevant issues (e.g., `Fixes #123`).
-4.  **Wait for CI:** Ensure all GitHub Actions workflows (Tests, Linting, Changelog Check) pass.
+
+2. **Open a Pull Request** against the `main` branch.
+3. **Fill out the PR Template:** Describe your changes clearly and link to any relevant issues (e.g., `Fixes #123`).
+4. **Wait for CI:** Ensure all GitHub Actions workflows (Tests, Linting, Changelog Check) pass.
 
 -----
 
@@ -67,9 +68,9 @@ This repository uses a specific workflow to handle semantic versioning and "floa
 
 When a PR is merged to `main` with a valid `CHANGELOG.md` entry:
 
-1.  The system automatically detects the version bump.
-2.  A new release is created with notes from the changelog.
-3.  The major version tag (e.g., `v1`) is automatically moved to the new release.
+1. The system automatically detects the version bump.
+2. A new release is created with notes from the changelog.
+3. The major version tag (e.g., `v1`) is automatically moved to the new release.
 
 ### Manual Release / Tag Correction