| name | git-workflow |
| description | Use when a task will edit a Git repository or the user asks to inspect or change Git state. Do not use solely because a read-only task happens inside a repository. |
Generated from blueprint.yaml. Do not edit this block by hand.
Used Interfaces: none
Branch safety (always check first)
Before editing files in any repo, verify it is on a named branch:
git symbolic-ref HEAD
If this fails, the repo is in detached HEAD — check out a named branch before doing anything. Do not edit and then discover the work can't land.
At session start: run this in both the skills repo and the CWD repo (if any). If either is detached, check out the default branch first.
Commit rules
- Never create commits, amend, or push unless explicitly asked.
- When a stable checkpoint is reached (completed subsection, resolved issue, passing tests, finished feature), note that it may be a good time to commit — but do not act without approval.
- When approved: help with staging specific files, drafting the commit message, and exact steps.
Change ownership
- Unless the user explicitly says otherwise, interpret "changes" as the changes made in the current assistant session.
- Before staging, committing, restoring, stashing, or otherwise modifying git state, distinguish current-session changes from pre-existing or unrelated dirty work.
- Tell the user when unrelated dirty state exists, including the affected paths or areas at a useful level of detail.
- Do not stage, commit, restore, revert, stash, or otherwise touch unrelated dirty state unless the user explicitly asks for that scope.
- If ownership is ambiguous, ask before acting on the ambiguous paths.
Commit hygiene
- Stage specific files by name; avoid
git add -A or git add . (risk of including .env, credentials, or large binaries).
- Never use
--no-verify or --no-gpg-sign unless explicitly asked.
- Never force-push to
main/master; warn if asked.
- Prefer new commits over amending, especially after a hook failure.
