commit

Pre-Commit Security Check

1. Check for Husky setup: Look for

   .husky/pre-commit

2. Verify GitLeaks integration: Check if

   gitleaks protect

   is in the pre-commit hook
3. Auto-configure if missing:
   • If

     .husky/

     exists but GitLeaks is missing, add

     gitleaks protect --staged --verbose

     before any

     lint-staged

     command
   • If

     .husky/

     doesn't exist, run

     npx husky init

     first, then configure GitLeaks

.husky/pre-commit

#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"

# Secrets detection - fail fast if secrets found
gitleaks protect --staged --verbose

# Lint staged files (if present)
npx lint-staged

Language Conventions

• Analyze existing commit messages, documentation, and code comments to detect the project's language variant (US English, UK English, etc.)
• Match the spelling conventions found in the project (e.g., "organize" vs "organise", "color" vs "colour")
• Maintain consistency with the project's established language style throughout commit messages

1. Pull latest changes from remote to ensure branch is up to date (git pull)
2. Show current git status and analyse all changes
3. Check conversation context for GitHub issue references:
   • If a GitHub issue is mentioned in the conversation, determine if changes close the issue (complete implementation) or relate to it (partial work)
   • Add appropriate footer: "Closes #123" or "Relates to #123"
   • If no issue is mentioned in context, proceed without issue reference
4. Assess the scope of changes:
   • Small to medium changes: Keep related changes in a single commit
   • Large changes: Only split when the changeset is potentially huge and mixing unrelated functionality
5. For normal commits:
   • Stage all related changes together
   • Create ONE short, descriptive commit message (max 50 characters)
   • Focus on the main purpose of the change
   • Add GitHub issue footer if applicable (from step 3)
6. For huge changesets only:
   • Group by major functional areas
   • Stage files by logical groups
   • Create separate commits for distinct features/fixes

• Maximum 50 characters - no exceptions
• Use present tense verbs (add, fix, update, remove, refactor)
• Be specific but concise (e.g., "fix auth redirect bug", "add user search")
• Prefer cohesive commits over artificially split ones