# Style And Commit

> Ensure code is styled and commits follow Conventional Commits.

- Skill: `firebase/style-and-commit` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add firebase/style-and-commit`
- Raw SKILL.md: https://api.skillmd.com/api/skills/firebase/style-and-commit/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: firebase (https://skillmd.com/u/firebase)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/firebase/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:
1. 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
2. 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.
3. Once the script passes, stage the intended changes (`git add ...`) and
   commit using `git commit -m "..."`.

## Rules
1. **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
2. **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`.
3. **Description**:
   - Use the imperative, present tense: "change" not "changed" nor "changes".
   - Don't capitalize the first letter.
   - No dot (.) at the end.
4. **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.
5. **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.
6. **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.