Style And Commit

Style & Commit Skill

When you are asked to commit changes, you MUST use the [Conventional

Commits](https://www.conventionalcommits.org/) specification.

Format

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Pre-commit Workflow

Before staging and committing files, you MUST ensure that all repository

formatting and styling guidelines are met by running the unified pre-commit

script:

• Locate and run the pre_commit.sh script. Depending on where this skill is

installed, it will be at one of these paths:

• ./.agents/skills/style_and_commit/scripts/pre_commit.sh (Local Repo)
• ~/.gemini/config/skills/style_and_commit/scripts/pre_commit.sh (Global)

Execute the path that exists. This script automatically:

• Formats code (Swift, Obj-C, etc.)
• Checks and adds copyright headers
• Wraps markdown text at 80 characters and removes trailing whitespace
• Runs shellcheck on any modified shell scripts
• If the script fails (e.g., shellcheck reports an error), you MUST read the

error, fix the issues, and re-run the script until it succeeds.

• Once the script passes, stage the intended changes (git add ...) and

commit using git commit -m "...".

Rules

• Types: Use one of the following 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

(example scopes: gulp, broccoli, npm)

• ci: Changes to our CI configuration files and scripts (example scopes:

Travis, Circle, BrowserStack, GitHub Actions)

• chore: Other changes that don't modify src or test files
• revert: Reverts a previous commit
• Scope: A scope may be provided to a commit's type, to provide additional

contextual information and is contained within parenthesis, e.g.,

feat(parser): add ability to parse arrays.

• Description:
• Use the imperative, present tense: "change" not "changed" nor "changes".
• Don't capitalize the first letter.
• No dot (.) at the end.
• Body:
• Just as in the description, use the imperative, present tense.
• The body should include the motivation for the change and contrast this

with previous behavior.

• Separate logical changes: If the user's working directory has multiple

unrelated changes (e.g. CI changes and Dependency updates), you should

create separate commits for each logical change unless the user explicitly

asks for a single commit.

• CI Fixes: When making fixes to CI configuration files or workflows (e.g.

GitHub Actions), use fix as the commit type and ci as the scope (e.g.

fix(ci): <description>), rather than using ci as the type.