branchlisted

# Branch Create a new git branch named for the work it's about to hold, following this org's [branch naming convention](https://wiki.dndmapp.nl.eu.org/development-conventions/branch-naming): `<type>/<slug>`, or `<type>/<issue-number>-<slug>` when the branch is for a tracked GitHub issue. ## 1. Determine type and slug Prefer, in order: 1. **The diff.** If the working tree already has staged or unstaged changes, derive the type and slug from `git diff` and `git diff --staged` together, reading the actual change rather than just file names. If the diff clearly mixes unrelated intents (the kind the `commit` skill would split into separate commits), don't guess at a dominant one: ask what the branch is for. 2. **A known issue.** If a GitHub issue number was given in conversation or at invocation, use its title to inform word choice for the slug. 3. **A description.** If there's no diff and no issue, ask what the branch is for and derive the type and slug from the answer. The `<type>` is one of the [Conventional Commits](https://www.conventionalcommits.org/) types (`feat`, `fix`, `docs`, `style`, `refactor`, `perf`, `test`, `build`, `ci`, `chore`, `revert`), the same vocabulary the `commit` skill uses. The `<slug>` follows the same quality bar as a commit subject: lowercase, kebab-case, specific enough to distinguish this branch from another of the same type (`add-login-flow`, not `fix-bug`). ## 2. Determine the base branch Detect the repo's default branch (`main` or `maste