<progress_context> Use Read tool: docs/arc/progress.md (first 50 lines)

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 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:

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 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:

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 unknown and 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 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

<arc_log> After completing this skill, append to the activity log. See: references/arc-log.md

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

commit