Commit Skill
Create standardized git commits following Terrae's conventions.
Instructions
- •
Check Current State
- •Run
git statusto see changed files - •Run
git diffto see the actual changes
- •Run
- •
Review Changes with User
- •Summarize what files were changed
- •Explain the nature of changes (new feature, bug fix, refactor, etc.)
- •Ask the user if they want to proceed with the commit
- •
Stage Files
- •Stage specific files by name (avoid
git add -Aorgit add .) - •Never stage sensitive files (.env, credentials, etc.)
- •Stage specific files by name (avoid
- •
Commit Message Format Follow conventional commits:
codetype(scope): description
Types:
- •
feat: New feature - •
fix: Bug fix - •
docs: Documentation changes - •
style: Formatting, no code change - •
refactor: Code restructuring - •
test: Adding or updating tests - •
chore: Maintenance tasks
Examples:
- •
feat(marker): add rotation support - •
fix(popup): prevent memory leak on unmount - •
docs(readme): update installation instructions
- •
- •
New Component Convention
When committing a new component, split into 3 separate commits in this order:
- •
feat(map): add {component} component— the source file (src/registry/map/{slug}.tsx) - •
feat(docs): add {component} example components— all example files (src/app/docs/_components/examples/{slug}-*.tsx) - •
feat(docs): add {component} documentation page— the docs page (src/app/docs/{slug}/page.tsx)
Shared file modifications (sidebar, components page, changelog, registry.json, barrel export) should be committed separately since they often contain changes for multiple components.
- •
- •
Important Rules
- •Do NOT add
Co-Authored-Bylines - •Do NOT commit until user approves
- •Do NOT use
--amendunless explicitly requested - •Do NOT push unless explicitly requested
- •Keep commit messages concise (under 72 characters)
- •Do NOT add
- •
Create the Commit
bashgit commit -m "type(scope): description"
- •
Verify
- •Run
git statusto confirm commit succeeded - •Show the commit hash to the user
- •Run