Instructions Update

.github/commit-instructions.md

@@ -1,36 +1,86 @@
-# Commit Message Instructions
+# Commit Message Instructions (Conventional Commits)
+
+Commit messages should follow the [Conventional Commits specification](https://www.conventionalcommits.org/en/v1.0.0/). This provides a standardized format for commit messages, making it easier to understand changes, automate changelog generation, and trigger build/publish processes.
 
 ## Format
 
-Each commit message should follow this structure:
-
-1. **Short Summary**: A brief summary of the changes (max 72 characters).
-2. **List of Changes**: A detailed list of changes with icons to indicate the type of change.
-
----
-
-### Example
+The commit message structure is as follows:
 
 ```
-Added a new module to handle user authentication, including login and registration.
+<type>[optional scope]: <description>
 
-- ✨ **Feature**: Implemented user login functionality
-- 🐛 **Fix**: Resolved session timeout issue
-- 🛠️ **Refactor**: Improved error handling in auth service
-- 🧪 **Test**: Added unit tests for login component
+[optional body]
+
+[optional footer(s)]
 ```
 
 ---
 
-## Icons for Change Types
+### Components
 
-- ✨ **Feature**: New features or functionality
-- 🐛 **Fix**: Bug fixes
-- 🛠️ **Refactor**: Code improvements without changing functionality
-- 🧪 **Test**: Adding or updating tests
-- 📚 **Docs**: Documentation updates
-- 🗑️ **Chore**: Maintenance tasks (e.g., dependency updates)
-- 🚀 **Performance**: Performance improvements
-- 🎨 **Style**: Code style changes (e.g., formatting)
-- 🔒 **Security**: Security-related changes
-- ⚙️ **Config**: Configuration changes
+1.  **Type**: Indicates the kind of change introduced by the commit. Must be one of the allowed types (see below).
+2.  **Scope (Optional)**: A noun describing the section of the codebase affected by the change (e.g., `auth`, `ui`, `build`). Enclosed in parentheses.
+3.  **Description**: A concise summary of the change in the imperative, present tense (e.g., "add login feature", not "added login feature" or "adds login feature"). Starts with a lowercase letter and should not end with a period. Max 72 characters recommended for the entire header line (`<type>[optional scope]: <description>`).
+4.  **Body (Optional)**: A more detailed explanation of the changes. Use the imperative, present tense. Explain the _what_ and _why_ vs. _how_. Separate from the description by a blank line. Wrap lines at 72 characters.
+5.  **Footer(s) (Optional)**: Contains additional metadata. Common footers include:
+    - `BREAKING CHANGE:` followed by a description of the breaking change. A `!` can also be appended to the type/scope (`feat!:`) to indicate a breaking change.
+    - Issue references (e.g., `Refs: #123`, `Closes: #456`). Separate from the body by a blank line.
+
+---
+
+### Allowed Types
+
+- **feat**: A new feature for the user.
+- **fix**: A bug fix for the user.
+- **build**: Changes that affect the build system or external dependencies (e.g., gulp, broccoli, npm).
+- **chore**: Other changes that don't modify src or test files (e.g., updating dependencies, build tasks).
+- **ci**: Changes to CI configuration files and scripts (e.g., Travis, Circle, BrowserStack, SauceLabs).
+- **docs**: Documentation only changes.
+- **perf**: A code change that improves performance.
+- **refactor**: A code change that neither fixes a bug nor adds a feature.
+- **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc).
+- **test**: Adding missing tests or correcting existing tests.
+
+---
+
+### Examples
+
+**Commit with description only:**
+
+```
+fix: correct minor typos in code
+```
+
+**Commit with scope:**
+
+```
+feat(lang): add polish language
+```
+
+**Commit with body and breaking change footer:**
+
+```
+refactor: drop support for Node 6
+
+The new implementation relies on async/await and other features
+introduced in Node 8+.
+
+BREAKING CHANGE: refactor to use JavaScript features not available in Node 6.
+```
+
+**Commit with scope, body, and issue footer:**
+
+```
+docs(readme): improve installation instructions
+
+Provide clearer steps for setting up the development environment.
+Add links to prerequisite tools.
+
+Closes: #12
+```
+
+**Commit with `!` for breaking change:**
+
+```
+feat(api)!: send an email to the customer when a product is shipped
+```