Commit Changes

Commit and push changes, intelligently splitting into separate commits when changes span multiple domains.

Usage:

• /arc:commit - Auto-analyze and commit (may create multiple commits)
• /arc:commit push - Commit and push

$ARGUMENTS will be either empty or "push".

Current Git State

Status:

!`git status --porcelain 2>/dev/null || echo "(no changes)"`

Changes summary:

!`git diff --stat 2>/dev/null | head -20 || echo "(no diff)"`

Recent commits (for style reference):

!`git log --oneline -5 2>/dev/null || echo "(no commits)"`

Instructions

1. Analyze Changes

Review the git state above. If you need more detail:

2. Determine Commit Strategy

Single commit if:

• All changes are in the same domain/area, OR
• Changes are tightly coupled (e.g., feature + its tests)

Multiple commits if changes span multiple unrelated domains:

• Different packages (e.g., packages/ui, packages/api)
• Different apps (e.g., apps/web, apps/admin)
• Config vs source changes
• Unrelated features or fixes

3. Group Files by Domain

Common groupings:

• packages/<name>/** - Package-specific changes
• apps/<name>/** - App-specific changes
• Root config files (.eslintrc, turbo.json, etc.) - Config
• *.stories.tsx with their component - Same commit as component
• *.test.ts with their source - Same commit as source

4. Create Commits

For each logical group:

1. Stage only files for that group:

   git add [files...]
   

2. Create commit with conventional message format:

   git commit -m "$(cat <<'EOF'
   type(scope): description
   EOF
   )"
   

Commit types:

• feat - New feature
• fix - Bug fix
• refactor - Code refactoring
• chore - Maintenance, deps, config
• docs - Documentation
• test - Tests
• style - Formatting, no code change
• perf - Performance improvement
• ci - CI/CD changes

Commit message rules:

• Use imperative mood: "add" not "added", "fix" not "fixed"
• First line under 72 characters
• Each commit should be atomic (single purpose)
• If you need "and" in the message, consider splitting the commit

5. Handle Pre-commit Hook Failures

If TypeScript or lint errors block the commit:

CRITICAL RULES:

• NEVER use --no-verify or skip hooks
• NEVER use force casting (e.g., as unknown as, as any)
• NEVER use @ts-ignore, @ts-expect-error, or eslint-disable comments
• NEVER use type assertions to bypass errors
• NEVER add empty catch blocks or suppress errors
• Fix the ROOT CAUSE of each error

Fixing Process:

1. Read the error output carefully
2. Identify the exact files and line numbers with issues
3. For TypeScript errors:
   • Read the file and understand the type error
   • Fix the types properly by adding correct type annotations
   • If a type is unclear, use unknown and narrow it with type guards
   • Update interfaces/types as needed
4. For lint errors:
   • Read the file and understand the lint rule violation
   • Fix the code to comply with the rule properly
   • Refactor if needed to follow best practices
5. Stage the fixes with the relevant commit
6. Retry the commit
7. Repeat until all errors are resolved

6. Push Changes (only if push argument provided)

Skip this step unless $ARGUMENTS starts with "push".

If pushing:

git push

If the branch has no upstream:

git push -u origin $(git branch --show-current)

If push fails (e.g., diverged history), report the issue - do NOT force push unless explicitly authorized.

7. Report Results

Tell the user:

• How many commits were created
• Summary of each commit (hash, message)
• Push status (if pushed), or remind them to push when ready

Failure Scenarios

If you cannot fix an error properly:

• Explain why the error exists
• Describe what the proper fix would require (e.g., architectural changes, missing types, etc.)
• Ask for guidance
• Do NOT commit with workarounds