git-flowlisted

# git-flow ## Overview A guided workflow that takes changes from the working tree to a pull request, following consistent conventions: branch naming, code review, Conventional Commits, automatic SemVer, and a PR template. **Guided, not blind** — confirm with the user at the review, doc-update, and PR steps. ## When to Use - Changes are done and ready to be committed and shared. - User says "ship this", "commit and open a PR", "create the PR". - A feature or fix is finished and needs a branch + commit + PR. Skip when: the user only wants a quick local commit with no review/PR. ## Conventions | Aspect | Rule | |---|---| | Branch | `type/description`, kebab-case (e.g. `feat/login-form`) | | Commit | [Conventional Commits](https://www.conventionalcommits.org/), in **English** | | Types | `feat`, `fix`, `docs`, `style`, `refactor`, `perf`, `test`, `build`, `ci`, `chore` | | SemVer (≥ 1.0) | `feat` → minor · `fix` → patch · `BREAKING CHANGE` (or `!`) → major | | Other types | `docs`/`style`/`refactor`/`perf`/`test`/`build`/`ci`/`chore` → patch | | SemVer (`0.x`) | `BREAKING` → minor (`0.y`→`0.(y+1)`, resets patch) · everything else → patch | | PR base | `develop` if that branch exists (local or on the remote), else `main` | | Tag | Created **after** the PR merges, and only if that merge's base was `main` — a merge into `develop` is not a release, see step 10 | | PR | Via `gh`, **ask before creating** | ## Rules & tie-breakers - **One authoritative type.** Classify the chan