feat: add claude commands

dot_claude/commands/check.md

@@ -0,0 +1,27 @@
+# Check
+
+Perform comprehensive code quality checks and tests.
+Do not make any code changes during this process.
+
+Exception: Fixing lint errors, type errors, formatting issues and failing unit tests.
+
+## Common Checks Include
+
+1. **Linting**: Code style and syntax errors
+2. **Type Checking**: Type errors
+3. **Unit Tests**: Unit and integration tests
+4. **Security Scan**: Vulnerability scan
+5. **Code Formatting**: Style consistency
+6. **Build Verification**: Compilation errors
+
+## Process
+
+1. Run the check command.
+2. Analyze output for errors and warnings
+3. Fix issues in priority order:
+   - Build-breaking errors first
+   - Test failures
+   - Linting and type errors
+   - Warnings
+4. Re-run checks after applying a fix
+5. Continue until all checks pass

dot_claude/commands/codereview.md

@@ -0,0 +1,60 @@
+# Review
+
+Do a comprehensive code review from multiple perspectives.
+Do not create any new files or change the code unless explicitly requested.
+For testing, you may run the code or unit tests locally if it is safe and applicable.
+
+## Review Roles:
+
+### 1. Developer Review
+
+- **Code Quality**: Is code clean and maintainable?
+- **Standards**: Does it follow coding conventions?
+- **Performance**: Are there efficiency concerns?
+- **Scalability**: Will it handle growth?
+- **Refactoring**: Any code that needs improvement?
+- **Action**: Suggest specific code improvements
+
+### 2. Quality Engineer Review
+
+- **Test Coverage**: Are all paths tested?
+- **Edge Cases**: Are boundary conditions handled?
+- **Regression Risk**: Could this break existing features?
+- **Action**: Identify missing tests and scenarios
+
+### 3. Security Engineer Review
+
+- **Vulnerabilities**: Any security risks?
+- **Data Handling**: Is sensitive data protected?
+- **Authentication**: Are auth checks proper?
+- **Input Validation**: Is user input sanitized?
+- **Compliance**: Does it meet security standards?
+- **Action**: Flag security concerns immediately
+
+### 4. DevOps Review
+
+- **CI/CD Integration**: Will builds succeed?
+- **Configuration**: Are configs properly managed?
+- **Infrastructure**: Any deployment concerns?
+- **Monitoring**: Are metrics and logs adequate?
+- **Rollback**: Can changes be safely reverted?
+- **Action**: Ensure smooth deployment
+
+### 5. UI/UX Designer Review
+
+- **Visual Consistency**: Does it match design system?
+- **Usability**: Is it intuitive to use?
+- **Accessibility**: Is it accessible to all users?
+- **Responsive**: Does it work on all devices?
+- **Polish**: Any rough edges to smooth?
+- **Action**: Ensure delightful user experience
+
+## Review Process:
+
+1. The user provides you with a description of what the code is intended to do.
+2. Find the relevant code changes from the uncommited code with `git`.
+3. Review code changes systematically.
+4. Test functionality locally if applicable
+5. Consider each perspective above if it is relevant for the change.
+6. Leave constructive feedback
+7. Approve or request changes

dot_claude/commands/commit.md

@@ -0,0 +1,23 @@
+# Commit
+
+Create commits with a well-formatted commit messages
+using conventional commit messages.
+
+## Process
+
+1. Check for changes (`git status`). If something is staged, consider only staged changes.
+Otherwise, review and stage appropriate files.
+2. Determine the commit type (e.g. feat, fix, docs, refactor, ...).
+3. Generate descriptive commit message using conventional commit standards.
+Include scope if applicable: `type(scope): description`.
+5. Add body for complex changes explaining the why.
+6. Execute commit
+
+## Best Practices
+
+- Keep commits atomic and focused
+- Write in imperative style (use "Add feature" not "Added feature")
+- Explain why, not just what
+- Reference issues/PRs when relevant
+- Split unrelated changes into separate commits.
+- Do not add Claude Code as co-author to the commit.

dot_claude/commands/fix.md

@@ -0,0 +1,19 @@
+# Fix Bug
+
+Fix a given bug or broken feature described by the user.
+
+## Process
+
+1. Reproduce the issue
+2. Write failing test that demonstrates the bug
+3. Implement the fix
+4. Verify test passes
+5. Run full test suite
+6. Review code changes
+
+## Best Practices
+
+- Keep changes focused on the specific bug
+- Include regression tests
+- Update documentation if behavior changes
+- Consider edge cases and related issues

dot_claude/commands/write-tests.md

@@ -0,0 +1,22 @@
+# Test Implementation
+
+Implement or update the tests for the code changes.
+
+## Implementing Tests
+
+1. Check for staged changes with (`git status`).
+If no changes are staged, review appropriate files.
+2. Review existing unit tests for changed functionality.
+3. Identify the functionality that needs testing.
+4. Write new tests or update existing ones to cover the changes.
+5. Ensure tests are comprehensive, covering edge cases and error handling.
+6. Run the tests to verify they pass with the current code.
+
+## Best practices
+
+- Test folder structure should mirror the source code structure
+- Write tests that cover both positive and negative cases
+- Ensure tests are isolated and do not depend on external state
+- Use descriptive names for test functions
+- Keep tests small and focused on a single functionality
+- Use fixtures or setup methods to prepare the test environment