git
Commits in Conventional Commits, made when the work is done, and pull requests named like the history they become
Commits without being asked
commit commits when a unit of work is done, not when someone remembers to
ask. Done means all three:
- A complete step: a feature, a fix, a task. Not half a function.
- It builds and the fast tests pass.
- Nothing unrelated is mixed in. If it is, the commit is split first.
It holds off while the approach is still being discussed, or when you said to wait.
<type>[scope][!]: <description>feat · fix · docs · style · refactor · perf · test · build ·
ci · chore · revert. The type comes from the diff, not from how the task
was named. The body says why, and is left out when the change explains itself.
Pushes, but never forces
A commit is pushed right after. These always ask first: --force and
--force-with-lease, a push to a protected branch, anything that rewrites
pushed history.
Pull requests
The title is a Conventional Commit line; the branch follows gitflow.
| Branch | For |
|---|---|
feature/ | a new capability |
fix/ | a bug fix |
hotfix/ | an urgent fix from the production branch |
release/ | release preparation |
chore/ docs/ ci/ refactor/ | maintenance |
fix/123-hook-stop-shape, not fix/123. A working branch like agent/<id>
is renamed before it is published.
Skills
commit
model + userCommit (and push) changes using Conventional Commits. Use this whenever the user explicitly asks to commit, push, save, or check in changes - "commit this", "commit and push", "save my work", "git commit", "faz um commit" - and also proactively, on your own initiative, once a unit of work is genuinely done, not only when explicitly asked. Applies in any project with a git repository. Not for opening a pull or merge request or naming its branch (that is `pr`), not for writing the code that is being committed, and not for rewriting history that is already pushed - that needs the user's word first.
Needs git on PATH, in a repository with at least one commit or a fresh init.
References descriptions.md
Read commit/SKILL.mdpr
model + userOpen, name and describe a pull/merge request (GitHub PR, GitLab MR) and its branch. Use whenever the user asks to open a PR/MR, "abre um PR", "cria o MR", "manda pra revisão", or when finished work on a branch needs to reach the default branch through review - and before publishing a branch for review, to name it right. Applies in any project with a remote and a review flow. Not for committing or pushing work (that is `commit`), not for reviewing someone else's request, and not for merging one - that stays with whoever the repo's convention says.
Needs git, plus the platform's CLI authenticated for this remote - `gh` for GitHub, `glab` for GitLab.
Read pr/SKILL.md