Git Autopilot

Git Commit and Sync

This skill automates the full git workflow: analyzing changes, generating a commit message, staging, committing, and pushing to GitHub.

When to use this skill

Use this skill when the user asks to:

• Commit changes or "save my work"
• Generate or write a commit message
• Push, sync, or publish to GitHub
• Stage and commit specific files

Commit message format

All commit messages follow the Conventional Commits standard:

type(scope): short description

[optional body for complex changes]

Types:

Scope is the affected module, file area, or component (for example, auth, pipeline, deploy, api). Omit if the change is broad.

Short description rules:

• Lowercase, no period at the end
• 72 characters or less
• Imperative mood ("add feature" not "added feature")

Body (optional): Include when the change is non-obvious, has side effects, or requires context for reviewers. Wrap at 72 characters.

Workflow

Step 1 — Assess current state

Run git status to see the current state of the working tree. Identify:

• Which files are staged (ready to commit)
• Which files are modified but not staged
• Which files are untracked

Step 2 — Review the diff

Run git diff --staged to read what is actually staged. If nothing is staged but there are modified files, run git diff to review unstaged changes.

Use the diff output to determine:

• What changed (additions, deletions, modifications)
• Which files are affected
• The logical grouping of changes

Step 3 — Stage files

If the user specified files in their request, stage only those:

git add <file1> <file2>

If the user said "everything" or did not specify, stage all changes:

git add -A

If files are already staged, skip this step.

Step 4 — Generate commit message

Analyze the staged diff and construct a commit message using the format above.

Guidelines for generating the message:

• Summarize what the code does, not what files changed
• If multiple unrelated changes exist, note that in the body or recommend splitting into separate commits
• Prefer specificity: fix(auth): handle null token on refresh over fix: bug fix
• For new scripts or automation files: feat(scope): add <name> script to <purpose>
• For refactors: describe what was restructured, not that it was restructured
• For config changes: name the config and what changed

Examples:

feat(deploy): add proxmox lxc provisioning script

chore(deps): update pester to v5.6.1

fix(pipeline): correct null check on empty response array

refactor(auth): extract token validation into separate function

docs(api): add endpoint examples for safesend webhook receiver

ci(github-actions): add lint step to pull request workflow

Step 5 — Present message for confirmation

Show the user the generated commit message before executing. Format the output as:

Proposed commit message:

  type(scope): short description

  [body if applicable]

Proceed? (yes to commit, or provide changes)

If the user confirms, proceed. If they request changes, revise the message and confirm again before committing.

Step 6 — Commit

git commit -m "type(scope): short description"

For messages with a body, use a multi-line commit:

git commit -m "type(scope): short description" -m "body text here"

Step 7 — Resolve target branch

Before pushing, determine the target branch using this priority order:

1. Branch explicitly named by the user in their request (e.g. "push to feature/my-branch")
2. Branch passed as an argument (e.g. --branch feature/my-branch)
3. The current branch's tracked upstream
4. The current branch name with no upstream set

If the user named a branch that does not exist locally or remotely, confirm before creating it.

Step 8 — Push

Push to the resolved target branch.

Push to the tracked upstream (default case):

git push

Push to a different remote branch (user specified a target):

git push origin <target-branch>

Push a local branch that has no upstream set:

git push --set-upstream origin <branch-name>

Push the current branch to a different target branch name:

git push origin HEAD:<target-branch>

If the push is rejected due to upstream changes, report this to the user and do not force push. Recommend they pull and resolve conflicts first:

git pull --rebase

Edge cases

• Nothing to commit: Report the clean state and exit. Do not attempt a commit.
• Merge conflicts present: Stop immediately and tell the user to resolve conflicts before committing.
• Detached HEAD state: Warn the user and do not commit until they are on a named branch.
• Large number of changed files: Summarize by directory or module rather than listing every file in the commit body.
• Mixed unrelated changes: Flag this to the user and recommend splitting into multiple focused commits before proceeding.
• Target branch does not exist: Confirm with the user before creating a new remote branch.
• Target branch diverged: Report the divergence and do not force push. Recommend pulling or rebasing the target branch first.
• Pushing to a protected branch: Report that the push was rejected and defer to the user. Do not attempt to bypass branch protection.

Source: mickpletcher/VSCode — distributed by TomeVault.