git-commit

Files (1)

• SKILL.md

SKILL.md (first lines)

# Git commits & PRs

Use this when committing changes or opening a pull request.

## Before committing

- Run `git status` and `git diff --staged` to see exactly what's going in. Never `git add -A` blindly — stage the files that belong to this change.
- Keep one logical change per commit. If the diff does two unrelated things, make two commits.
- Don't commit secrets, large binaries, or generated artifacts. Check `.gitignore` covers them.

## Message format

Conventional Commits:

```
<type>(<optional scope>): <short imperative summary>

<optional body — what changed and WHY, wrapped at ~72 cols>
```

Types: `feat`, `fix`, `docs`, `refactor`, `test`, `chore`, `perf`, `build`, `ci`.

- Summary in the imperative mood ("add", not "added"), ≤72 chars, no trailing period.
- The body explains the reasoning a future reader needs — not a restatement of the diff.

## Pull requests (gh CLI)

- `git push -u origin <branch>` then `gh pr create --fill` (or `--title`/`--body`).
- PR body: what changed, why, and how it was verified (tests run, manual checks).
- Confirm the base branch is correct before creating.

## Conventions to honor

Match the repository's existing style — read recent `git log --oneline` first and follow whatever format the project already uses if it differs from the above.

From spinabot/brigade, MIT.

More from spinabot/brigade