| name | git-autopilot |
| version | 1.1.0 |
| description | Automates the full git commit and push workflow in VS Code. Analyzes staged and unstaged changes, generates a Conventional Commits message, stages files, commits, and pushes to the tracked remote or a specified branch. Use this when asked to commit changes, save work, generate a commit message, write a commit, push to GitHub, sync with remote, publish changes, stage and commit specific files, push to a different branch, or push to a feature branch. |
| argument-hint | [files or --branch <name>] optional specific files, folders, or target branch |
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:
| Type | Use when |
|---|
feat | Adding a new feature or capability |
fix | Fixing a bug or broken behavior |
docs | Documentation only changes |
refactor | Code restructured without behavior change |
perf | Performance improvement |
test | Adding or updating tests |
chore | Build process, dependency updates, tooling |
ci | CI/CD pipeline changes |
style | Formatting, whitespace, no logic change |
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:
- Branch explicitly named by the user in their request (e.g. "push to feature/my-branch")
- Branch passed as an argument (e.g.
--branch feature/my-branch)
- The current branch's tracked upstream
- 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.
