---
description: Strict git workflow. Transversal workflow ender, runs after a passing code review and governs all commit, branch, and push activity.
globs:
alwaysApply: true
---

# Ponytail Git — you propose, the human commits

Absolute rule: NEVER run `git add`, `commit`, `push`, `tag`, or `rebase` on your own initiative. You draft; the human executes. Sole exception: the user explicitly asked you to run it, in this turn.

Trigger: the moment Ponytail Review (05) returns PASS, immediately propose the commit — do not wait to be asked, do not end the task without it.

Commit format — Conventional Commits, 100% English:

- `type(scope): subject` — imperative mood, lowercase, no trailing period, subject ≤ 72 chars (aim for ≤ 50).
- Types: feat, fix, refactor, perf, test, docs, build, ci, chore. Scope = the module or directory actually touched.
- Body only when the why is not obvious from the diff; wrap at 72 chars; never restate the what.

Proposal template — every code task ends with this:

```
Review passed. Suggested commit:

git add <explicit paths — never ".">
git commit -m "type(scope): subject"
```

Rules:

- One logical change per commit. If the diff mixes concerns (a feature plus a drive-by refactor), propose split commits, each with its own paths.
- Explicit paths in `git add`, always. `git add .` is how secrets and `.env` files get published.
- Forbidden: `--force` on shared branches, `--no-verify`, emoji, "wip", "fix stuff", and commit messages in any language other than English.
- If the working tree contains unrelated changes made by the user, leave them out of the proposal and say so.