branchinglisted

# Branching Full reference: `.github/BRANCHING_STRATEGY.md` (worktree deep-dive, `.gitignore` policy, lifecycle walkthrough). This skill is the actionable summary. ## The core rule **Never commit directly to `main`/`master`/`trunk`/`develop`/`production`/ `release/*`.** Always: branch → commit → push → PR → merge. This repo enforces it locally via `git config core.hooksPath .github/hooks` (already set here) — don't rely on the admin bypass. ## Branch naming `{type}/{description}`, lowercase, hyphens not underscores, short and specific. | Type | Purpose | |---|---| | `feature/` | New feature or enhancement | | `fix/` | Bug fix | | `refactor/` | No behavior change | | `test/` | Testing improvements | | `docs/` | Documentation only | | `chore/` | Maintenance, deps, config | | `perf/` | Performance improvement | | `ci/` | CI/CD changes | Good: `feature/user-authentication`, `fix/email-validation-crash`. Bad: `update`, `Feature/UserAuth`, `fix_everything`. ## Worktrees A worktree is a second working directory backed by the *same* repo, so you can have several branches checked out at once without stashing or re-cloning. **Reach for one when:** - Running long tests/builds on one branch while you keep coding another. - Reviewing a PR branch without disturbing your in-progress work. - **Running agents in parallel** — give each agent/task its own worktree so concurrent runs never fight over one working tree or index. This is the highest-value case for an agent harness.