git
Conventional Commits written proactively, and pull requests named like the history they will become
Two skills covering the two moments a change becomes part of a project's history: the commit, and the request to merge it.
- Skills
- commit · pr
- Carries
- skills
- Keywords
- git · commit · conventional-commits · workflow
on this machine, for every project
$ uze plugin install git@aiin this project only, written to agents.lock
$ uze git@aiThe 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.
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.
Read pr/SKILL.mdCommits happen without being asked
commit is written to fire on its own initiative. Waiting for someone to say
"commit this" is the failure mode the skill exists to prevent. Finished work
sitting uncommitted is worse than a commit you can amend.
A unit of work is finished when all three hold:
- It is a complete, coherent step: a feature implemented, a bug fixed, a checklist task done. Not a half-written function, not a mid-task detour.
- It builds or typechecks, and fast relevant tests pass. Unverified code does not get committed.
- The tree does not mix that finished unit with unrelated work in progress, otherwise it splits first.
And it explicitly holds off when the conversation has not converged on an approach, when the state is an intermediate one mid-task, or when you have said to wait, which overrides the skill until you say otherwise.
The format
<type>[optional scope][!]: <description>
[optional body]
[optional footer(s)]feat · fix · docs · style · refactor · perf · test · build ·
ci · chore · revert.
The type comes from the diff, not the request: what changed, not what
someone called it. Description is imperative, lowercase, no trailing period.
The body says why, never restating the diff, and is omitted entirely for
self-explanatory changes. ! or a BREAKING CHANGE: footer only when it is
genuinely breaking.
Push, and the line it will not cross
Pushing follows the commit by default: git push, or -u origin <branch> for
a new branch. A rejected push means git pull --rebase and retry.
What stays outside the proactive default, always requiring confirmation:
force-push (--force/--force-with-lease), pushing to a shared or protected
branch, and anything that rewrites already-pushed history. "Fix the commit
message" on a pushed commit is not blanket authorization to force-push.
Branches and titles
A PR is the unit of review, so it is named like the unit of history it becomes: title is a Conventional Commit line, branch follows gitflow.
| Prefix | For |
|---|---|
feature/ | a new capability or change set |
fix/ | a bug fix that is not urgent |
hotfix/ | an urgent fix cut from the production branch |
release/ | release preparation |
chore/ docs/ ci/ refactor/ | maintenance-only branches |
One topic per branch, lowercase kebab-case, no ticket-only names. fix/123
says nothing, fix/123-hook-stop-shape does.
Agent-isolation branches (agent/<id>, the ones UZE's workspace creates) are
working names, not review names. Rename before publishing; never open a PR
from one.
The body carries what a reviewer needs and nothing a diff already says: what changes (by behaviour, not by file), why, verification with actual numbers, review points the author wants confirmed or overturned, and refs.