Smart commit and push with auto-splitting across domains. Creates atomic commits. Use when asked to "commit", "push changes", "save my work", or after completing implementation work. Automatically groups changes into logical commits.
Install
npx skillscat add howells/arc/commit Install via the SkillsCat registry.
Check recent work context to inform commit message writing.
</progress_context>
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 changesapps/<name>/**- App-specific changes- Root config files (
.eslintrc,turbo.json, etc.) - Config *.stories.tsxwith their component - Same commit as component*.test.tswith their source - Same commit as source
4. Create Commits
For each logical group:
Stage only files for that group:
git add [files...]Create commit with conventional message format:
git commit -m "$(cat <<'EOF' type(scope): description EOF )"
Commit types:
feat- New featurefix- Bug fixrefactor- Code refactoringchore- Maintenance, deps, configdocs- Documentationtest- Testsstyle- Formatting, no code changeperf- Performance improvementci- 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-verifyor 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:
- Read the error output carefully
- Identify the exact files and line numbers with issues
- 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
unknownand narrow it with type guards - Update interfaces/types as needed
- 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
- Stage the fixes with the relevant commit
- Retry the commit
- 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 pushIf 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
Entry: /arc:commit — [N] commits ([summary])
</arc_log>
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