This project uses Conventional Commits (semver-based) for commit messages.
<type>(<scope>): <subject>
<body>
<footer>
feat: A new feature (increments MINOR version)fix: A bug fix (increments PATCH version)docs: Documentation only changesstyle: Code style changes (formatting, missing semi colons, etc.)refactor: Code refactoring without feature changes or bug fixesperf: Performance improvementstest: Adding or updating testsbuild: Changes to build system or external dependenciesci: Changes to CI configuration files and scriptschore: Other changes that don't modify src or test files (e.g., project setup)revert: Reverts a previous commit
feat: add user authentication command
fix: resolve parsing error in config file
chore: initial project setup
docs: update README with installation instructions
refactor: extract command handlers into separate modules
The scope should be the area of the codebase affected:
cli: CLI-related changesconfig: Configuration changesdeps: Dependency updates
For breaking changes, add ! after the type/scope and include BREAKING CHANGE: in the footer:
feat!: change command API structure
BREAKING CHANGE: The command structure has been redesigned. Old commands are no longer supported.
After completing a task, agents must:
- Format code: Run
npm run formatto format all code files with Prettier - Verify lint errors: Run
npm run lintto check for any ESLint errors after formatting - Build the code: Run
npm run buildto compile TypeScript and verify the build succeeds - Fix build issues: If the build fails, fix any TypeScript compilation errors or other build issues
- Ensure clean state: The task is only considered complete when there are no lint errors, all files are properly formatted, and the build succeeds without errors
This ensures consistent code quality, formatting, and that the code compiles successfully across the project.
When implementing features or fixing bugs, agents must:
- Identify duplicate logic: If the same logic or functionality appears in more than one place, it should be extracted into a reusable function or utility
- Create library modules: Extract shared logic into appropriate files in the
src/lib/directory - Follow DRY principles: Don't Repeat Yourself - avoid code duplication by creating reusable utilities
- Maintain consistency: When refactoring, ensure all places using the duplicated logic are updated to use the new shared function
Example: If URL validation logic appears in multiple command files, extract it into src/lib/command-utils.ts or a dedicated utility module.
This promotes maintainability, reduces bugs from inconsistent implementations, and makes the codebase easier to understand and modify.