commit_message_rule.md

Commit Message Rule

This project follows the Conventional Commits specification for all commit messages. This ensures a clear, readable, and structured git history.

Format

Every commit message must follow this simple structure: :

• Note: The type and description must be in lowercase. The description should be written in English, starting with a verb in the imperative mood (e.g., "add", "fix", "improve", not "added" or "fixes").

Allowed Types

feat

• Use case: A new feature for the user or system.
• Example: feat: parse pdf to markdown

fix

• Use case: A bug fix.
• Example: fix: resolve memory leak in langchain agent

chore

• Use case: Regular maintenance, build tasks, package updates, or tool configurations that do not modify source code or test files.
• Example: chore: migrate package and environment management to uv

docs

• Use case: Documentation updates only (e.g., README, contributing guide, inline code comments).
• Example: docs: add contributing guide for environment setup

ci

• Use case: Changes to CI/CD configuration files and scripts (e.g., GitHub Actions, GitLab CI).
• Example: ci: add github actions workflow for automated linting

refactor

• Use case: A code change that neither fixes a bug nor adds a feature, but improves code structure or quality.
• Example: refactor: simplify image processing logic

style

• Use case: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc.).
• Example: style: format code with black and ruff

perf

• Use case: A code change that improves performance.
• Example: perf: optimize pdf parsing speed

Rules & Best Practices

1. Use the imperative mood in the description (e.g., "add feature" instead of "added feature" or "adds feature").
2. Do not capitalize the first letter of the description.
3. Do not end the description with a period (.).
4. Keep the entire message concise and under 72 characters.