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 | | Tag | Created **after** the PR merges to `main`, not on the branch | | PR | Via `gh`, **ask before creating** | ## Rules & tie-breakers - **One authoritative type.** Classify the change ONCE (step 2). That type drives the branch name, the commit, and the SemVer bump. They must agree. - **Mixed changes:** pick the highest-impact typ