git-workflowlisted

# Git Workflow This skill governs the default Git shape of implementation work: which branch to use, how to name it, how to cut commits, and when it is safe to push or open a PR. It is intentionally lighter than the `/git-commit-split` custom command, which is for taking an already-dirty working tree and splitting it into commits or PRs. ## Operating Rules - Inspect Git state before edits: current branch, `git status --porcelain=v1`, and recent commit style when commit messages will be written. - Never overwrite, reset, clean, or discard user changes unless the user explicitly asked for that exact destructive action. - Do not force-push, merge PRs, or push directly to the default / protected branch. - For implementation work, deliver through a feature branch and pull request unless the user explicitly asks for local-only work. - Prefer one coherent VCS unit per applicable TSDD path. Both paths end Green. If the task is too small for multiple cycles, one commit is enough. - Keep branch names and commit subjects aligned with the primary intent of the change, not with filenames. ## Branch Policy Prefer a feature branch in the current checkout for a single active task. Create a separate worktree only in the cases listed below. Choose the workspace in this order: 1. If the user explicitly asks for a worktree, parallel work, isolated work, or another simultaneous task, create a sibling worktree. 2. If the user explicitly asks to avoid worktrees or continue in the current che