Agent skill
git-commit
Use when asked to commit, save, or persist changes to Git. Handles atomic commits, branch safety, Conventional Commits format, and project style matching. Do NOT use for pushing, creating PRs, or branch management beyond safety checks.
Install this agent skill to your Project
npx add-skill https://github.com/sortie-ai/sortie/tree/main/.github/skills/git-commit
Metadata
Additional technical details for this skill
- version
- 1775952000
SKILL.md
Git Commit
Workflow
Step 1: Identify changes and group atomically
git status --short
git diff
git diff --cached
Each commit = one logical change. Split unrelated changes into separate commits.
| Situation | Commits |
|---|---|
| New service + its tests | 1 commit |
| New feature + unrelated config fix | 2 commits |
| Multiple files for one feature | 1 commit |
- If user says "commit all" — group into logical atomic commits
- If ambiguous — ask which files and grouping
Step 2: Check branch safety (BLOCKING)
git branch --show-current
Protected branches: main, master, develop, release/*, hotfix/*.
STOP if on a protected branch. Do not commit. Do not proceed to Step 3. Instead:
- Inform the user: "Cannot commit to
<branch>— it is a protected branch." - Create a feature branch:
git checkout -b <type>/<kebab-description> - Only then continue to Step 3.
If on a feature branch: proceed.
Branch naming convention
Format: <type>/<kebab-case-description>
| Type | Use Case | Example |
|---|---|---|
feat |
New feature | feat/bill-reminders |
fix |
Bug fix | fix/null-amount-validation |
refactor |
Code restructuring | refactor/extract-payment-service |
chore |
Maintenance tasks | chore/update-dependencies |
docs |
Documentation | docs/api-reference |
test |
Test additions | test/payment-service-coverage |
Step 3: Match project commit style
git log --format="%s" -20
Identify vocabulary, detail level, scope patterns. Mimic the project's phrasing while following Conventional Commits format.
See references/commit-format.md for type table, rules, and anti-patterns.
Step 4: Stage and commit
git add <files>
git commit -m "<type>[scope]: <description>"
For multi-line messages:
git commit -m "<subject>" -m "<body>"
Subject line: imperative mood, under 72 chars, no period, English only. Body (if needed): wrap at 72 chars, explain what and why.
Do not reference docs/architecture.md, docs/decisions/, section numbers,
or ADR numbers in commit messages. Those belong in specs and plans,
not in the git history.
Step 5: Verify
git log --oneline -1
git show --stat HEAD
Report: commit hash, files changed, insertions/deletions.
Error Recovery
| Error | Fix |
|---|---|
| "nothing to commit" | Check git status, verify files have changes |
| Pre-commit hook fails | Read the error, fix the issue, create a NEW commit (do not amend) |
| Wrong files committed | git reset --soft HEAD~1, re-stage correctly, commit again |
Handoff
If the user also asked to create a PR, invoke the creating-pr skill after
committing. Do not hand-roll gh pr create — the skill has a required template.
Recommended Agent Skills
Expand your agent's capabilities with these related and highly-rated skills.
managing-adrs
Create, update, and validate Architecture Decision Records (ADRs) following MADR 4.0 format. Use when the user mentions ADR, architecture decision, decision record, or asks to document a technical decision. Also use when creating new files in docs/decisions/. Handles numbering, frontmatter, section structure, and README index updates. Do NOT use for general documentation or non-architectural decisions.
context-files
Create or validate project context files (AGENTS.md, CLAUDE.md, GEMINI.md). Use when bootstrapping a new project, initializing agent configuration, writing a context file, or when asked to create, review, audit, or validate an existing context file. Handles codebase archaeology, user interviews, golden-rule validation, and platform-specific formatting. Do NOT use for creating Agent Skills (use creating-agent-skills instead) or .instructions.md files (use agent-customization instead).
jira-syntax
Use when writing Jira issue descriptions, comments, or work logs. Also use when converting Markdown to Jira wiki markup, when the user says "format for Jira", "Jira markup", "wiki notation", or asks to create, update, or validate Jira ticket content. Handles bug report and feature request templates. Do NOT use for Jira API operations, JQL queries, or workflow transitions.
creating-agent-skills
Use when creating, improving, comparing, evaluating or packaging Agent Skills following the agentskills.io specification. Also use when deciding whether a skill is the right solution vs MCP servers, custom instructions, AGENTS.md, or Cursor Rules. Handles SKILL.md authoring, frontmatter optimization, description writing, progressive disclosure, cross-platform compatibility, and distribution.
diataxis-documentation
Create, edit, and validate technical documentation using the Diataxis framework. Use when writing tutorials, how-to guides, reference docs, or explanations. Use when reviewing or auditing existing documentation for structural correctness. Use when deciding what type of document to write. Also use when the user mentions Diataxis, documentation quality, documentation types, or asks to write 'deep dive' articles, onboarding guides, API docs, or architectural explanations. Do NOT use for code comments, commit messages, changelogs, or README generation.
managing-github-issues
Create, edit, search, close, and triage GitHub issues for this project using gh CLI. Use when asked to file a bug, request a feature, create a task, report a problem, search the backlog, triage issues, or manage the issue tracker. Also use when the user says "create an issue", "file a bug", "open a ticket", "add to backlog", "search issues", "close issue", or mentions GitHub Issues in any task-management context. Handles label/milestone assignment, duplicate detection, and project board integration. Do NOT use for pull requests (use creating-pr) or changelog entries (use changelog-maintenance).
Didn't find tool you were looking for?