/sync
Sync the current session branch with its upstream branch, or publish the current session branch to a remote. Use when the user asks to sync a branch, pull latest changes, rebase onto upstream, push current branch, publish branch, or set upstream.
$ npx -y skills add microsoft/vscode --skill sync --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/sync
Context preview
The summary Claude sees to decide when to auto-load this skill.
Sync the current session branch with its upstream branch, or publish the current session branch to a remote. Use when the user asks to sync a branch, pull latest changes, rebase onto upstream, push current branch, publish branch, or set upstream.
SKILL.md
sync.SKILL.mdname: sync
description: Sync the current session branch with its upstream branch, or publish the current session branch to a remote. Use when the user asks to sync a branch, pull latest changes, rebase onto upstream, push current branch, publish branch, or set upstream.
<!-- Customize this skill and select save to override its behavior. Delete that copy to restore the built-in behavior. -->
Sync Changes
Sync the current session branch with its upstream branch, or publish the current session branch to a remote. Use when the user asks to sync a branch, pull latest changes, rebase onto upstream, push current branch, publish branch, or set upstream.
Guidelines
- **Never force-push** (`--force`, `--force-with-lease`) without explicit user approval.
- **Never skip pre-push hooks** (do not use `--no-verify`).
- **Never rewrite or drop commits** during rebase without asking the user.
- When in doubt about conflict resolution — ask the user.
Workflow
1. Check for uncommitted changes first. If there are uncommitted changes, use the `/commit` skill to commit them before continuing. 2. Check whether the current session branch has an upstream branch. 3. If the current session branch has an upstream branch: 3.1. Fetch the upstream remote first so tracking refs are up to date.
git fetch <upstream-remote>
3.2. Check ahead/behind counts. If the branch is already in sync (0 ahead, 0 behind), stop and report that no sync is needed.
git rev-list --left-right --count HEAD...@{u}3.3. If behind, rebase onto the upstream tracking branch.
git rebase @{u}3.4. If there are merge conflicts, resolve them by preserving the intent of both sides. Stage the resolved files and continue the rebase.
git add <resolved-files>
git rebase --continueIf conflict resolution is unclear, ask the user how to proceed. If the user wants to stop the rebase, abort it:
git rebase --abort
3.5. If the branch has local commits (ahead > 0), push them to the remote after a successful rebase.
git push
If the push is rejected because the rebase rewrote history, explain the situation to the user and ask for approval before force-pushing. 4. If the current session branch does not have an upstream branch: 4.1. Determine the remote to publish to.
- If there is only one remote, use it.
- If there are multiple remotes, use the #tool:vscode/askQuestions tool to ask which remote to use.
4.2. Publish the current branch and set upstream in one step.
git push -u <remote> HEAD
Validation
After the workflow completes, validate the result with explicit checks:
1. Verify the working tree is clean:
git status --porcelain
2. Verify sync state (ahead/behind counts are both 0):
git rev-list --left-right --count HEAD...@{u}3. If the branch was newly published, verify the upstream branch is configured:
git rev-parse --abbrev-ref --symbolic-full-name @{u}Read more
name: sync description: Sync the current session branch with its upstream branch, or publish the current session branch to a remote. Use when the user asks to sync a branch, pull latest changes, rebase onto upstream, push current branch, publish branch, or set upstream.
<!-- Customize this skill and select save to override its behavior. Delete that copy to restore the built-in behavior. -->
Sync Changes
Sync the current session branch with its upstream branch, or publish the current session branch to a remote. Use when the user asks to sync a branch, pull latest changes, rebase onto upstream, push current branch, publish branch, or set upstream.
Guidelines
- **Never force-push** (`--force`, `--force-with-lease`) without explicit user approval.
- **Never skip pre-push hooks** (do not use `--no-verify`).
- **Never rewrite or drop commits** during rebase without asking the user.
- When in doubt about conflict resolution — ask the user.
Workflow
1. Check for uncommitted changes first. If there are uncommitted changes, use the `/commit` skill to commit them before continuing. 2. Check whether the current session branch has an upstream branch. 3. If the current session branch has an upstream branch: 3.1. Fetch the upstream remote first so tracking refs are up to date.
git fetch <upstream-remote>
3.2. Check ahead/behind counts. If the branch is already in sync (0 ahead, 0 behind), stop and report that no sync is needed.
git rev-list --left-right --count HEAD...@{u}3.3. If behind, rebase onto the upstream tracking branch.
git rebase @{u}3.4. If there are merge conflicts, resolve them by preserving the intent of both sides. Stage the resolved files and continue the rebase.
git add <resolved-files>
git rebase --continueIf conflict resolution is unclear, ask the user how to proceed. If the user wants to stop the rebase, abort it:
git rebase --abort
3.5. If the branch has local commits (ahead > 0), push them to the remote after a successful rebase.
git push
If the push is rejected because the rebase rewrote history, explain the situation to the user and ask for approval before force-pushing. 4. If the current session branch does not have an upstream branch: 4.1. Determine the remote to publish to.
- If there is only one remote, use it.
- If there are multiple remotes, use the #tool:vscode/askQuestions tool to ask which remote to use.
4.2. Publish the current branch and set upstream in one step.
git push -u <remote> HEAD
Validation
After the workflow completes, validate the result with explicit checks:
1. Verify the working tree is clean:
git status --porcelain
2. Verify sync state (ahead/behind counts are both 0):
git rev-list --left-right --count HEAD...@{u}3. If the branch was newly published, verify the upstream branch is configured:
git rev-parse --abbrev-ref --symbolic-full-name @{u}Repo: microsoft/vscode
Other skills on vscode.
- /agent-customization
**WORKFLOW SKILL** — Create, update, review, fix, or debug VS Code agent customization files (.instructions.md, .prompt.md, .agent.md, SKILL.md, copilot-instructions.md, AGENTS.md). USE FOR: saving coding preferences; troubleshooting why instructions/skills/agents are ignored or
Open skill - /chronicle
Analyze Copilot session history for standup reports, usage tips, session search, and session reindexing. Use when the user asks for a standup, daily summary, usage tips, workflow recommendations, wants to search or find past sessions by keyword/file/PR, wants to reindex their
Open skill - /create-agent
Create a custom agent (.agent.md) for a specific job.
Open skill - /create-hook
Create a hook (.json) to enforce policy or automate agent lifecycle events.
Open skill - /create-instructions
Create an instructions file (.instructions.md) for a project rule or convention.
Open skill - /create-prompt
Create a reusable prompt file (.prompt.md) for a common task.
Open skill

