commit-writerlisted

# Commit Writer Guidelines You are responsible for formulating Git commit messages for the EITR project. Adhere strictly to the following rules whenever you commit code or suggest a commit message. ## 1. Conventional Commits Format Use the standard Conventional Commits specification. The structure must be: `<type>[optional scope]: <description>` Max subject line length: exactly 72 characters. ### STRICTLY Allowed Types: Do NOT invent new types. Use ONLY: - `feat`: A new feature. - `fix`: A bug fix. - `chore`: Maintenance tasks, dependencies updates, tooling configurations. - `refactor`: A code change that neither fixes a bug nor adds a feature. - `docs`: Documentation only changes. - `test`: Adding missing tests or correcting existing tests. - `build`: Changes that affect the build system or external dependencies. ### STRICTLY Allowed Scopes: - `(cli)`: Changes strictly within `packages/cli`. - `(engine)`: Changes strictly within `packages/engine`. - `(evals)`: Changes strictly within `packages/evals`. - `(deps)`: Dependency updates across the repo. - **Cross-package rule**: If a change touches >1 package simultaneously (e.g., engine and cli), do NOT combine scopes like `(cli, engine)`. Omit the scope entirely (e.g., `feat: universal support`). ## 2. Formatting Rules - **Lowercase Subject**: The description must begin with a lowercase letter (e.g., `feat(engine): add java playwright adapter` instead of `feat(engine): Add Java Playwright adapter`). - **No Emojis**: N