ISA-Frontend/.claude/commands/commit.md

allowed-tools: Bash(git add:), Bash(git status:), Bash(git commit:), Bash(git diff:), Bash(git log:*) argument-hint: [message] | --no-verify | --amend description: Create well-formatted commits with conventional commit format and emoji

Smart Git Commit

Create well-formatted commit: $ARGUMENTS

Current Repository State

• Git status: !git status --porcelain
• Current branch: !git branch --show-current
• Staged changes: !git diff --cached --stat
• Unstaged changes: !git diff --stat
• Recent commits: !git log --oneline -5

What This Command Does

1. Unless specified with --no-verify, automatically runs pre-commit checks:
   • pnpm lint to ensure code quality
   • pnpm build to verify the build succeeds
   • pnpm generate:docs to update documentation
2. Checks which files are staged with git status
3. If 0 files are staged, automatically adds all modified and new files with git add
4. Performs a git diff to understand what changes are being committed
5. Analyzes the diff to determine if multiple distinct logical changes are present
6. If multiple distinct changes are detected, suggests breaking the commit into multiple smaller commits
7. For each commit (or the single commit if not split), creates a commit message using emoji conventional commit format

Determining the Scope

The scope in commit messages MUST be the name field from the affected library's project.json:

1. Check the file path: libs/ui/label/src/... → Look at libs/ui/label/project.json
2. Read the project name: The "name" field (e.g., "name": "ui-label")
3. Use that as scope: feat(ui-label): ...

Examples:

• File: libs/remission/feature/remission-list/src/... → Scope: remission-feature-remission-list
• File: libs/ui/notice/src/... → Scope: ui-notice
• File: apps/isa-app/src/... → Scope: isa-app

Multi-project changes:

• If changes span 2-3 related projects, use the primary one or list them: feat(ui-label, ui-notice): ...
• If changes span many unrelated projects, split into separate commits

Best Practices for Commits

• Verify before committing: Ensure code is linted, builds correctly, and documentation is updated
• Atomic commits: Each commit should contain related changes that serve a single purpose
• Split large changes: If changes touch multiple concerns, split them into separate commits
• Conventional commit format: Use the format <type>(<scope>): <description> where:
  • scope: The project name from project.json of the affected library (e.g., ui-label, crm-feature-checkout)
  • Determine the scope by checking which library/project the changes belong to
  • If changes span multiple projects, use the primary affected project or split into multiple commits
  • type is one of:
  • feat: A new feature
  • fix: A bug fix
  • docs: Documentation changes
  • style: Code style changes (formatting, etc)
  • refactor: Code changes that neither fix bugs nor add features
  • perf: Performance improvements
  • test: Adding or fixing tests
  • chore: Changes to the build process, tools, etc.
• Present tense, imperative mood: Write commit messages as commands (e.g., "add feature" not "added feature")
• Concise first line: Keep the first line under 72 characters
• Emoji: Each commit type is paired with an appropriate emoji:
  • ✨ feat: New feature
  • 🐛 fix: Bug fix
  • 📝 docs: Documentation
  • 💄 style: Formatting/style
  • ♻️ refactor: Code refactoring
  • ⚡️ perf: Performance improvements
  • ✅ test: Tests
  • 🔧 chore: Tooling, configuration
  • 🚀 ci: CI/CD improvements
  • 🗑️ revert: Reverting changes
  • 🧪 test: Add a failing test
  • 🚨 fix: Fix compiler/linter warnings
  • 🔒️ fix: Fix security issues
  • 👥 chore: Add or update contributors
  • 🚚 refactor: Move or rename resources
  • 🏗️ refactor: Make architectural changes
  • 🔀 chore: Merge branches
  • 📦️ chore: Add or update compiled files or packages
  • ➕ chore: Add a dependency
  • ➖ chore: Remove a dependency
  • 🌱 chore: Add or update seed files
  • 🧑‍💻 chore: Improve developer experience
  • 🧵 feat: Add or update code related to multithreading or concurrency
  • 🔍️ feat: Improve SEO
  • 🏷️ feat: Add or update types
  • 💬 feat: Add or update text and literals
  • 🌐 feat: Internationalization and localization
  • 👔 feat: Add or update business logic
  • 📱 feat: Work on responsive design
  • 🚸 feat: Improve user experience / usability
  • 🩹 fix: Simple fix for a non-critical issue
  • 🥅 fix: Catch errors
  • 👽️ fix: Update code due to external API changes
  • 🔥 fix: Remove code or files
  • 🎨 style: Improve structure/format of the code
  • 🚑️ fix: Critical hotfix
  • 🎉 chore: Begin a project
  • 🔖 chore: Release/Version tags
  • 🚧 wip: Work in progress
  • 💚 fix: Fix CI build
  • 📌 chore: Pin dependencies to specific versions
  • 👷 ci: Add or update CI build system
  • 📈 feat: Add or update analytics or tracking code
  • ✏️ fix: Fix typos
  • ⏪️ revert: Revert changes
  • 📄 chore: Add or update license
  • 💥 feat: Introduce breaking changes
  • 🍱 assets: Add or update assets
  • ♿️ feat: Improve accessibility
  • 💡 docs: Add or update comments in source code
  • 🗃️ db: Perform database related changes
  • 🔊 feat: Add or update logs
  • 🔇 fix: Remove logs
  • 🤡 test: Mock things
  • 🥚 feat: Add or update an easter egg
  • 🙈 chore: Add or update .gitignore file
  • 📸 test: Add or update snapshots
  • ⚗️ experiment: Perform experiments
  • 🚩 feat: Add, update, or remove feature flags
  • 💫 ui: Add or update animations and transitions
  • ⚰️ refactor: Remove dead code
  • 🦺 feat: Add or update code related to validation
  • ✈️ feat: Improve offline support

Guidelines for Splitting Commits

When analyzing the diff, consider splitting commits based on these criteria:

1. Different concerns: Changes to unrelated parts of the codebase
2. Different types of changes: Mixing features, fixes, refactoring, etc.
3. File patterns: Changes to different types of files (e.g., source code vs documentation)
4. Logical grouping: Changes that would be easier to understand or review separately
5. Size: Very large changes that would be clearer if broken down

Examples

Good commit messages (scope = project name from project.json):

• ✨ feat(auth-feature-login): add user authentication system
• 🐛 fix(ui-renderer): resolve memory leak in rendering process
• 📝 docs(crm-api): update API documentation with new endpoints
• ♻️ refactor(shared-utils): simplify error handling logic in parser
• 🚨 fix(ui-label): resolve linter warnings in component files
• 🧑‍💻 chore(dev-tools): improve developer tooling setup process
• 👔 feat(checkout-feature): implement business logic for transaction validation
• 🩹 fix(ui-header): address minor styling inconsistency in header
• 🚑️ fix(auth-core): patch critical security vulnerability in auth flow
• 🎨 style(ui-components): reorganize component structure for better readability
• 🔥 fix(legacy-module): remove deprecated legacy code
• 🦺 feat(user-registration): add input validation for user registration form
• 💚 fix(ci-config): resolve failing CI pipeline tests
• 📈 feat(analytics-feature): implement analytics tracking for user engagement
• 🔒️ fix(auth-password): strengthen authentication password requirements
• ♿️ feat(ui-forms): improve form accessibility for screen readers

Example of splitting commits:

• First commit: ✨ feat(ui-label): add prio-label component with variant styles
• Second commit: 📝 docs(ui-label): update README with usage examples
• Third commit: 🔧 chore(ui-notice): scaffold new notice library
• Fourth commit: 🏷️ feat(shared-types): add type definitions for new API endpoints
• Fifth commit: ♻️ refactor(pickup-shelf): update components to use new label
• Sixth commit: 🚨 fix(remission-list): resolve linting issues in new code
• Seventh commit: ✅ test(ui-label): add unit tests for prio-label component
• Eighth commit: 🔒️ fix(deps): update dependencies with security vulnerabilities

Command Options

• --no-verify: Skip running the pre-commit checks (lint, build, generate:docs)
• --amend: Amend the previous commit (RESTRICTED - see rules below)

Amend Rules (CRITICAL)

ONLY use --amend in these specific cases:

1. Adding pre-commit hook fixes: If a pre-commit hook modified files (formatting, linting auto-fixes), you may amend to include those changes.

2. Before amending, ALWAYS verify:

   # Check authorship - NEVER amend another developer's commit
   git log -1 --format='%an %ae'
   
   # Check not pushed - NEVER amend pushed commits
   git status  # Should show "Your branch is ahead of..."
   

3. If either check fails:

   • Create a NEW commit instead
   • Never amend commits authored by others
   • Never amend commits already pushed to remote

Example workflow for pre-commit hook changes:

# 1. Initial commit triggers pre-commit hook
git commit -m "feat(scope): add feature"
# Hook modifies files...

# 2. Verify safe to amend
git log -1 --format='%an %ae'  # Your name/email
git status                      # "Your branch is ahead..."

# 3. Stage hook changes and amend
git add .
git commit --amend --no-edit

Important Notes

• By default, pre-commit checks (pnpm lint, pnpm build, pnpm generate:docs) will run to ensure code quality
• If these checks fail, you'll be asked if you want to proceed with the commit anyway or fix the issues first
• If specific files are already staged, the command will only commit those files
• If no files are staged, it will automatically stage all modified and new files
• The commit message will be constructed based on the changes detected
• Before committing, the command will review the diff to identify if multiple commits would be more appropriate
• If suggesting multiple commits, it will help you stage and commit the changes separately
• Always reviews the commit diff to ensure the message matches the changes