Manage Git commits and branches for AI-generated code

A skill treating git as a safety net for AI-agent-speed code changes: commits as save points, branches as sandboxes, history as documentation. It recommends trunk-based development as the default - main always deployable, short-lived feature branches merging back within 1-3 days, since long-lived branches accumulate merge risk (DORA research correlates trunk-based development with high-performing teams); release branches are acceptable for stabilization, and feature flags are preferred over keeping incomplete work on a branch for weeks. Five commit disciplines: commit early and often (each successful increment gets its own commit rather than one giant commit at the end); atomic commits where each does one logical thing (separate commits for an API endpoint, its form component, wiring, and tests, rather than one commit mixing a feature with a sidebar fix and dependency updates); descriptive messages explaining why not just what, following a <type>: <short description> format with types feat/fix/refactor/test/docs/chore; keeping concerns separate (refactors and features are different changes, submitted separately, though small cleanups like a rename can ride along with a feature commit at reviewer discretion); and sizing changes to roughly 100 lines per commit/PR (up to ~300 acceptable for a single logical change, anything over ~1000 lines should be split, per the code-review-and-quality skill's splitting strategies). Branching strategy: branch from main, name branches feature/<description>, fix/<description>, chore/<description>, or refactor/<description>, keep them short-lived, and delete after merge. For parallel AI agent work, git worktrees let multiple branches run simultaneously in separate directories with no branch-switching needed - if one experiment fails, deleting the worktree loses nothing, and changes stay isolated until explicitly merged. The save-point pattern formalizes this: after each change, a passing test triggers a commit and continuation, while a failing test triggers a revert to the last commit before investigating - so an agent going off the rails is recoverable with git reset --hard HEAD back to the last successful state, never losing more than one increment of work. After any modification, the skill calls for a structured change summary to make review easier, document scope discipline, and surface unintended changes.

Always - every code change flows through git under this skill's discipline, whether working solo, in a team, or driving AI agents that generate code at high speed.

Given a code change, it produces a disciplined git history: atomic, appropriately-sized commits with descriptive type-prefixed messages, on short-lived feature branches (or isolated worktrees for parallel agent work), plus a structured change summary after each modification.

Pure git workflow discipline - trunk-based branching, conventional commit message types, and git worktree for parallel isolated work - no external tooling beyond git itself.

Developers and AI agents generating code at high speed who need version control that keeps changes manageable, reviewable, and reversible - trunk-based development, atomic commits, and worktree-based parallelism instead of long-lived branches and giant, hard-to-review commits.