🇺🇸English

Semantic Git

Manage Git commits using conventional commit format with atomic commits and concise messages.

This skill is zagi-aware and is designed to work well with AI IDEs (Cursor, etc.)

Tooling

• Preferred : zagi (a better git interface for agents).
  • Assume zagi is installed if:
    • git is aliased to zagi in the shell or
    • a zagi binary is available.
  • When in doubt, treat git as if it may be zagi-compatible and avoid using exotic flags.
  • Even when zagi is available, generate plaingit commands and let any git → zagi integration handle them.
• Fallback : plain git when zagi is not available.

When to Use

• Committing changes to git
• Staging files for commit
• Creating commit messages
• Managing atomic commits
• Before pushing changes

Core Principles

• Atomic commits : Stage and commit related changes together. Tests go with implementation code.
• User confirmation : Always confirm with user before committing and before moving to the next commit.
• Conventional format : Use conventional commit message format (feat, fix, etc.) unless directed otherwise.
• Concise messages : Keep messages brief and to the point. Omit description unless change is complicated.
• Command transparency : Always show the exact git commands that will be run (which may be handled by zagi via alias/wrapper), and ask whether the user wants:
  • to run them manually, or
  • to have the agent run them.

Commit Message Format

<type>[optional scope]: <subject>

[optional body]

[optional footer(s)]

Types

• feat: A new feature
• fix: A bug fix
• docs: Documentation only changes
• style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc.)
• refactor: A code change that neither fixes a bug nor adds a feature
• perf: A code change that improves performance
• test: Adding missing tests or correcting existing tests
• build: Changes that affect the build system or external dependencies
• ci: Changes to CI configuration files and scripts
• : Maintenance tasks (updating build tasks, dependencies, etc.; no production code change)

Breaking Changes

Use ! after the type/scope to indicate breaking changes:

• feat!: add new API
• fix(api)!: change response format

Subject Line

• Use imperative mood: "add feature" not "added feature" or "adds feature"
• First letter lowercase (unless starting with proper noun)
• No period at the end
• Keep under 72 characters when possible

Body and Footer

• Omit body unless change is complicated or requires explanation
• When needed, be concise and reference issues, PRs, or documentation
• Use footer for breaking changes: BREAKING CHANGE: <description>

Workflow

1. Implement atomic change : Code + tests together.

   • Use test: for test-only changes.

2. Run CI checks : Verify types, tests, and linting pass before staging.

   • Prefer a single CI command if it exists (e.g., pnpm ci, npm run ci, just ci).
   • If no CI command, run checks individually (typecheck, test, lint).
   • If any check fails, stop and report – do not proceed.

3. Stage atomic changes : Group related files together (implementation + tests).

4. Suggest commit message : Generate a conventional commit message based on changes.

5. Generate commands :

   • Construct explicit shell commands using git (which may be an alias or wrapper such as zagi), for example:

Automation Mode

If user requests "continue to X" or "automate until X":

• Proceed with atomic commits automatically, but still print commands.
• For each commit:
  • Show the staging and commit commands.
  • Optionally execute them automatically, as per the user’s automation request.
• Resume asking for confirmation when X is reached.
• X can be: specific file, feature completion, test passing, etc.

Stop and Ask Protocols

Stop and ask user before:

• Adding type ignores (@ts-ignore, # type: ignore, etc.).
• Adding suppressions (ESLint disable, pylint disable, etc.).
• Using any type or similar type escapes.
• When uncertain how to proceed with implementation.
• When requirements are unclear.
• When a destructive git operation is proposed (reset --hard, checkout ., clean -f, push --force); prefer safer alternatives and explain the risks.

Examples

Simple feature or behaviour change:

feat: add user authentication

Feature with scope:

feat(api): add user endpoint

Bug fix:

fix: resolve memory leak in cache

Breaking change:

feat!: migrate to new API version

Test-only change:

test: improve unit tests for auth service

Refactor (no behavior change):

refactor: extract validation logic into separate function

Complex change (with body):

feat(api): add pagination support

Implements cursor-based pagination for large datasets.
See docs/api/pagination.md for details.

References

For detailed guidance, see:

• references/conventional-commits.md – Commit format and examples
• references/ci-verification.md – CI check patterns and verification
• references/co-authors.md – Handling Co-Authored-By trailers and zagi co-author stripping

Weekly Installs

75

Repository

siviter-xyz/dot-agent

GitHub Stars

7

First Seen

Jan 20, 2026

Security Audits

Gen Agent Trust HubPassSocketPassSnykPass

Installed on

codex51

cursor49

claude-code43

gemini-cli41

opencode40

github-copilot39