pr-sync

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

PR Sync Skill

PR Sync 技能

Purpose

用途

Sync local changes to GitHub in a single command. Detects current state (main vs feature branch, staged vs unstaged changes, existing PRs), then executes the minimum steps needed: branch, commit, push, and create PR.

通过单个命令将本地变更同步到GitHub。检测当前状态（主分支与功能分支、已暂存与未暂存变更、已存在的PR），然后执行所需的最少步骤：创建分支、提交、推送、创建PR。

Operator Context

操作上下文

This skill operates as an operator for GitHub sync workflows, configuring Claude's behavior for safe, predictable git operations that get local work onto GitHub with a PR.

本技能作为GitHub同步工作流的操作器，配置Claude的行为以实现安全、可预测的Git操作，将本地工作内容同步到GitHub并创建PR。

Hardcoded Behaviors (Always Apply)

硬编码行为（始终生效）

CLAUDE.md Compliance: Read and follow repository CLAUDE.md before any git operations
Over-Engineering Prevention: Execute only the steps needed for the current state. Do not add extra commits, rebase, or reorganize history beyond what is required to sync.
Never force push: All pushes use standard
```
git push
```
, never
```
--force
```
. Exception: the review-fix loop (Step 4b) uses
```
--force-with-lease
```
after amending the tip commit, which is safe because the branch was just pushed by us.
Never modify pushed commits: Commits already on remote are immutable. Exception: the review-fix loop amends only the tip commit it just created, before any external review.
Never commit sensitive files: Block
```
.env
```
, credentials, secrets, API keys
Conventional commit format: All commit messages follow conventional commits
Branch protection: Never commit directly to main/master
Repo-Aware Review Gate: Classify repo before creating PR. For personal repos, run up to 3 iterations of
```
/pr-review
```
→ fix before PR creation. For protected-org repos, every step requires explicit user confirmation.
Organization-Gated Workflow: Repos under protected organizations (configured in
```
scripts/classify-repo.py
```
) require user confirmation before EACH step: commit message review, push, and PR creation. Never auto-execute any of these steps. Present the proposed action and wait for user approval.

CLAUDE.md 合规性：执行任何Git操作前，读取并遵循仓库的CLAUDE.md
防止过度设计：仅执行当前状态所需的步骤。除同步必需的操作外，不添加额外提交、变基或重构提交历史
禁止强制推送：所有推送均使用标准
```
git push
```
，绝不使用
```
--force
```
。例外情况：评审-修复循环（步骤4b）中，在修改最新提交后使用
```
--force-with-lease
```
，这是安全的，因为分支刚由我们推送
绝不修改已推送的提交：已推送到远程的提交不可更改。例外情况：评审-修复循环仅修改刚创建的最新提交，且尚未进行外部评审
禁止提交敏感文件：拦截
```
.env
```
、凭证、密钥、API密钥等文件
规范提交格式：所有提交信息遵循规范提交格式
分支保护：绝不直接提交到main/master分支
仓库感知的评审 gate：创建PR前先对仓库进行分类。对于个人仓库，在创建PR前最多执行3轮
```
/pr-review
```
→ 修复循环。对于受保护组织的仓库，每一步操作都需要用户明确确认
组织 gated 工作流：受保护组织下的仓库（在
```
scripts/classify-repo.py
```
中配置）在执行每一步操作前都需要用户确认：提交信息评审、推送、PR创建。绝不自动执行任何步骤。需向用户展示拟执行的操作，等待用户批准后再执行

Default Behaviors (ON unless disabled)

默认行为（默认开启，可禁用）

Auto-detect branch name: Generate from commit message or changed files when not provided
Auto-detect PR title: Derive from branch name or first commit when not provided
Stage selectively: Prefer staging specific files over
```
git add -A
```
Check for unpushed commits: Include existing unpushed commits in the push
Warn if behind remote: Alert user if branch is behind main before pushing
Show PR URL: Display the PR URL after creation for easy access

自动检测分支名称：未提供分支名称时，从提交信息或变更文件生成
自动检测PR标题：未提供PR标题时，从分支名称或首个提交信息推导
选择性暂存：优先暂存特定文件，而非使用
```
git add -A
```
检查未推送的提交：推送时包含已存在的未推送提交
分支落后远程时发出警告：推送前若分支落后于主分支，向用户发出提醒
显示PR链接：创建PR后展示PR链接，方便访问

Optional Behaviors (OFF unless enabled)

可选行为（默认关闭，可开启）

Draft PR: Create PR as draft instead of ready for review
Auto-assign reviewers: Assign reviewers based on CODEOWNERS
Rebase before push: Rebase on main before pushing to avoid merge conflicts

草稿PR：创建草稿状态的PR，而非待评审状态
自动分配评审人：根据CODEOWNERS分配评审人
推送前变基：推送前在主分支上变基，避免合并冲突

What This Skill CAN Do

本技能可执行的操作

Detect current git state and choose the right workflow
Create feature branches from main/master with conventional naming
Stage, commit, and push changes in sequence
Create GitHub PRs with summary and test plan
Update existing PRs by pushing new commits

检测当前Git状态并选择合适的工作流
从main/master分支创建符合规范命名的功能分支
按顺序执行暂存、提交、推送变更
创建包含摘要和测试计划的GitHub PR
通过推送新提交更新已存在的PR

What This Skill CANNOT Do

本技能不可执行的操作

Force push to shared/upstream branches (force-with-lease on own feature branches during review-fix loop is permitted)
Review PRs (use /pr-review instead)
Clean up merged branches (use pr-cleanup instead)
Run CI checks (use ci instead)
Commit directly to main/master

向共享/上游分支强制推送（在个人功能分支的评审-修复循环中使用force-with-lease是允许的）
评审PR（请使用/pr-review）
清理已合并的分支（请使用pr-cleanup）
运行CI检查（请使用ci）
直接提交到main/master分支

Instructions

操作说明

Usage

使用方式

/pr-sync                           # Auto-detect everything
/pr-sync feature/new-auth          # Specify branch name
/pr-sync fix/bug-123 "Fix login"   # Specify branch and PR title

/pr-sync                           # 自动检测所有内容
/pr-sync feature/new-auth          # 指定分支名称
/pr-sync fix/bug-123 "Fix login"   # 指定分支和PR标题

Step 0: Classify Repo

步骤0：仓库分类

Determine repo type before any git operations.

bash

REPO_TYPE=$(python3 ~/.claude/scripts/classify-repo.py --type-only)

Protected-org repos: Every subsequent step (commit, push, PR creation) requires explicit user confirmation. Present the proposed action, show what will happen, and wait for approval before executing. Never auto-execute.

Personal repos: Run

/pr-review

comprehensive review before creating the PR. Auto-execute steps normally.

执行任何Git操作前，先确定仓库类型。

bash

REPO_TYPE=$(python3 ~/.claude/scripts/classify-repo.py --type-only)

受保护组织的仓库：后续每一步操作（提交、推送、PR创建）都需要用户明确确认。向用户展示拟执行的操作、具体内容，等待用户批准后再执行。绝不自动执行。

个人仓库：创建PR前先运行

/pr-review

进行全面评审。正常自动执行步骤。

Step 1: Detect Current State

步骤1：检测当前状态

Determine the starting point before taking any action.

bash

undefined

执行任何操作前先确定起始状态。

bash

undefined

Get current branch

获取当前分支

CURRENT_BRANCH=$(git branch --show-current)

Detect main branch name

检测主分支名称

MAIN_BRANCH=$(git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's@^refs/remotes/origin/@@' || echo "master")

Check for uncommitted changes

检查是否有未提交的变更

HAS_CHANGES=$(git status --porcelain)

Check for unpushed commits

检查是否有未推送的提交

UNPUSHED=$(git log origin/$CURRENT_BRANCH..$CURRENT_BRANCH --oneline 2>/dev/null)

Determine if on main/master

判断是否在主分支上

ON_MAIN=false if [[ "$CURRENT_BRANCH" == "main" || "$CURRENT_BRANCH" == "master" ]]; then ON_MAIN=true fi

undefined

ON_MAIN=false if [[ "$CURRENT_BRANCH" == "main" || "$CURRENT_BRANCH" == "master" ]]; then ON_MAIN=true fi

undefined

Step 2: Create Branch (if on main)

步骤2：创建分支（若当前在主分支）

If on main/master with changes, create a feature branch first.

Branch naming conventions:

Change Type	Prefix	Example
New feature	`feature/`	`feature/add-auth`
Bug fix	`fix/`	`fix/login-error`
Documentation	`docs/`	`docs/update-readme`
Refactoring	`refactor/`	`refactor/cleanup-utils`
Chore/maintenance	`chore/`	`chore/update-deps`

bash

undefined

若当前在main/master分支且有变更，先创建功能分支。

分支命名规范：

变更类型	前缀	示例
新功能	`feature/`	`feature/add-auth`
Bug修复	`fix/`	`fix/login-error`
文档	`docs/`	`docs/update-readme`
重构	`refactor/`	`refactor/cleanup-utils`
日常维护	`chore/`	`chore/update-deps`

bash

undefined

If no branch name provided, generate from changes or commit message

若未提供分支名称，从变更内容或提交信息生成

Create and switch to new branch

创建并切换到新分支

git checkout -b "$BRANCH_NAME"


If already on a feature branch, skip this step.

git checkout -b "$BRANCH_NAME"


若当前已在功能分支上，跳过此步骤。

Step 3: Stage and Commit

步骤3：暂存并提交

Stage changes selectively and create a conventional commit.

bash

undefined

选择性暂存变更，创建规范格式的提交。

bash

undefined

Stage specific files (prefer over git add -A)

暂存特定文件（优先于git add -A）

git add path/to/changed/files

Create commit with conventional format

创建规范格式的提交

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


If no uncommitted changes exist, skip to Step 4.

**Protected-org repos**: Before executing the commit, present the proposed commit message and list of files to the user. Wait for explicit approval before committing.

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


若无未提交的变更，跳至步骤4。

**受保护组织的仓库**：执行提交前，向用户展示拟使用的提交信息和文件列表。等待用户明确批准后再提交。

Step 4: Push to Remote

步骤4：推送到远程

bash

undefined

bash

undefined

Push with upstream tracking (CLAUDE_GATE_BYPASS=1 bypasses the git-submission-gate hook)

推送并设置上游跟踪（CLAUDE_GATE_BYPASS=1 绕过git-submission-gate钩子）

CLAUDE_GATE_BYPASS=1 git push -u origin "$CURRENT_BRANCH"


**Protected-org repos**: Before executing the push, present the branch name, remote, and commits that will be pushed. Wait for explicit approval before pushing.

CLAUDE_GATE_BYPASS=1 git push -u origin "$CURRENT_BRANCH"


**受保护组织的仓库**：执行推送前，向用户展示分支名称、远程仓库、将推送的提交。等待用户明确批准后再推送。

Step 4b: Review-Fix Loop (personal repos only)

步骤4b：评审-修复循环（仅适用于个人仓库）

Iteratively review and fix issues before creating the PR. Up to 3 iterations of:

/pr-review

→ fix → amend → push.

Skip if:

REPO_TYPE == "protected-org"

(protected-org repos use their own review gates).

Loop (max 3 iterations):

Run
```
/pr-review
```
comprehensive review
If clean → exit loop, proceed to Step 5
Fix all reported issues

git add [fixes] && git commit --amend --no-edit && CLAUDE_GATE_BYPASS=1 git push --force-with-lease

Report iteration:

REVIEW-FIX [N/3]: X found, Y fixed, Z remaining

After 3 iterations, proceed to Step 5 with any remaining issues documented in the PR body.

创建PR前迭代评审并修复问题。最多执行3轮：

/pr-review

→ 修复 → 修改提交 → 推送。

跳过条件：

REPO_TYPE == "protected-org"

（受保护组织的仓库使用自身的评审gate）。

循环（最多3轮）：

运行
```
/pr-review
```
进行全面评审
若无问题 → 退出循环，进入步骤5
修复所有发现的问题

git add [fixes] && git commit --amend --no-edit && CLAUDE_GATE_BYPASS=1 git push --force-with-lease

报告迭代情况：

REVIEW-FIX [N/3] — [X个问题被发现，Y个已修复]

3轮迭代后，进入步骤5，PR正文中需记录剩余未修复的问题。

Step 5: Create or Update PR

步骤5：创建或更新PR

bash

undefined

bash

undefined

Check if PR already exists for this branch

检查当前分支是否已存在PR

EXISTING_PR=$(gh pr list --head "$CURRENT_BRANCH" --json number --jq '.[0].number' 2>/dev/null)

if [[ -z "$EXISTING_PR" ]]; then # Create new PR CLAUDE_GATE_BYPASS=1 gh pr create --title "$PR_TITLE" --body "$(cat <<'EOF'

EXISTING_PR=$(gh pr list --head "$CURRENT_BRANCH" --json number --jq '.[0].number' 2>/dev/null)

if [[ -z "$EXISTING_PR" ]]; then # 创建新PR CLAUDE_GATE_BYPASS=1 gh pr create --title "$PR_TITLE" --body "$(cat <<'EOF'

Summary

摘要

[Description of changes]

[变更描述]

Test Plan

测试计划

Tested locally
Tests pass EOF )" else
PR exists, just pushed updates
echo "PR #$EXISTING_PR updated with new commits" gh pr view "$EXISTING_PR" --web fi

undefined

本地测试通过
所有测试用例通过 EOF )" else
PR已存在，仅推送更新
echo "PR #$EXISTING_PR 已更新新提交" gh pr view "$EXISTING_PR" --web fi

undefined

Decision Tree

决策树

/pr-sync invoked
       |
       v
  Classify repo (Step 0)
       |
       v
  Has changes?
   /        \
 YES         NO
  |           |
  v           v
On main?    PR exists?
 / \         / \
YES  NO    YES  NO
 |    |     |    |
 v    v     v    v
Create  Stage  Show  Create
branch  commit link  PR
  |      |
  v      v
Stage & commit
  |
  v
protected-org? ──YES──> Confirm commit msg with user
  |                    |
  NO                   v
  |              Confirm push with user
  v                    |
Push to remote  <──────┘
  |
  v
protected-org? ──YES──> Confirm PR creation with user
  |                    |
  NO                   v
  |              Create PR, STOP (no merge)
  v
┌─> Run /pr-review (iteration N/3)
|     |
|     v
|   Issues found?
|    / \
|  YES  NO ──────> Create PR
|   |
|   v
|  Fix issues
|   |
|   v
|  Amend commit, push
|   |
|   v
|  N < 3? ──YES──┐
|   |             |
|   NO            |
|   |             |
|   v             |
|  Create PR      |
|  (note remaining)|
└─────────────────┘

/pr-sync 被调用
       |
       v
  仓库分类（步骤0）
       |
       v
  是否有变更？
   /        \\
 是         否
  |           |
  v           v
是否在主分支?    PR是否存在?
 / \\         / \\
是  否    是  否
 |    |     |    |
 v    v     v    v
创建  暂存  展示  创建
分支  提交  链接  PR
  |      |
  v      v
暂存并提交
  |
  v
是否为受保护组织仓库? ──是──> 向用户确认提交信息
  |                    |
  否                   v
  |              向用户确认推送操作
  v                    |
推送至远程  <──────┘
  |
  v
是否为受保护组织仓库? ──是──> 向用户确认PR创建
  |                    |
  否                   v
  |              创建PR，停止操作（不合并）
  v
┌─> 运行 /pr-review（第N/3轮）
|     |
|     v
|   是否发现问题?
|    / \\
|  是  否 ──────> 创建PR
|   |
|   v
|  修复问题
|   |
|   v
|  修改提交，推送
|   |
|   v
|  N < 3? ──是──┐
|   |             |
|   否            |
|   |             |
|   v             |
|  创建PR      |
|  （记录剩余问题）|
└─────────────────┘

Output Format

输出格式

Personal repos:

PR SYNC COMPLETE

Status: [on main -> created branch | on feature branch]
Changes: [N files modified]
Review: /pr-review [N iterations] — [X issues found, Y fixed]

Actions:
  - Created branch: feature/your-feature (if from main)
  - Staged N files
  - Committed: "your commit message"
  - Pushed to origin/feature/your-feature
  - Review-fix loop: [N/3 iterations]
    - Iteration 1: [X found, Y fixed]
    - Iteration 2: [X found, Y fixed] (if needed)
    - Iteration 3: [X found, Y fixed] (if needed)
  - Created PR #123: "PR Title"
    https://github.com/owner/repo/pull/123

Protected-org repos:

PR SYNC COMPLETE (protected-org repo — human-gated)

Status: [on feature branch]
Changes: [N files modified]

Actions (each confirmed by user):
  - Committed: "your commit message" (user confirmed)
  - Pushed to origin/feature/your-feature (user confirmed)
  - Created PR #123: "PR Title" (user confirmed)
    https://github.com/your-org/your-repo/pull/123

Next steps: Review and merge handled by org CI gates and human reviewers.

个人仓库:

PR 同步完成

状态: [从主分支创建了分支 | 当前在功能分支]
变更: [N个文件被修改]
评审: /pr-review [N轮迭代] — [X个问题被发现，Y个已修复]

执行的操作:
  - 创建分支: feature/your-feature（若从主分支创建）
  - 暂存了N个文件
  - 提交信息: "your commit message"
  - 推送到origin/feature/your-feature
  - 评审-修复循环: [N/3轮迭代]
    - 第1轮: [X个问题被发现，Y个已修复]
    - 第2轮: [X个问题被发现，Y个已修复]（若需要）
    - 第3轮: [X个问题被发现，Y个已修复]（若需要）
  - 创建PR #123: "PR Title"
    https://github.com/owner/repo/pull/123

受保护组织仓库:

PR 同步完成（受保护组织仓库 — 人工 gated）

状态: [当前在功能分支]
变更: [N个文件被修改]

执行的操作（每一步均经用户确认）:
  - 提交: "your commit message"（用户已确认）
  - 推送到origin/feature/your-feature（用户已确认）
  - 创建PR #123: "PR Title"（用户已确认）
    https://github.com/your-org/your-repo/pull/123

下一步: 评审和合并由组织的CI gate和人工评审处理。

Error Handling

错误处理

Error: "Push rejected - branch behind remote"

错误："Push rejected - branch behind remote"

Cause: Remote branch has commits not present locally (teammate pushed, or previous rebase). Solution:

Run

git pull --rebase origin $CURRENT_BRANCH

Resolve any conflicts if they arise
Retry the push
If conflicts are complex, inform the user and show the conflicting files

原因：远程分支包含本地未有的提交（队友已推送，或之前进行过变基）。解决方案:

运行

git pull --rebase origin $CURRENT_BRANCH

若出现冲突，解决冲突
重试推送
若冲突复杂，告知用户并展示冲突文件

Error: "gh: not authenticated"

错误："gh: not authenticated"

Cause: GitHub CLI is not authenticated or token expired. Solution:

Run
```
gh auth status
```
to confirm
Instruct user to run
```
gh auth login
```
Do not proceed with PR creation until auth is confirmed

原因：GitHub CLI未认证或令牌已过期。解决方案:

运行
```
gh auth status
```
确认状态
指导用户运行
```
gh auth login
```
认证完成前不继续创建PR

Error: "No changes to commit"

错误："No changes to commit"

Cause: All changes are already committed, or working tree is clean. Solution:

Check for unpushed commits with
```
git log origin/$BRANCH..$BRANCH
```
If unpushed commits exist, skip to push step
If no unpushed commits, check if PR exists and show its status
If nothing to do, report clean state to user

原因：所有变更已提交，或工作区干净。解决方案:

使用
```
git log origin/$BRANCH..$BRANCH
```
检查是否有未推送的提交
若有未推送的提交，跳至推送步骤
若无未推送的提交，检查PR是否存在并展示其状态
若无任何操作可执行，向用户报告工作区干净

Error: "Branch name already exists"

错误："Branch name already exists"

Cause: A branch with the generated name already exists locally or on remote. Solution:

Check if user is already on that branch (
```
git branch --show-current
```
)
If different branch, append a suffix (e.g.,
```
-v2
```
) or ask user for alternative name
Never silently overwrite an existing branch

原因：生成的分支名称已在本地或远程存在。解决方案:

检查用户是否已在该分支上（
```
git branch --show-current
```
）
若当前在不同分支，添加后缀（如
```
-v2
```
）或询问用户替代名称
绝不静默覆盖已存在的分支

Error: "Cannot delete branch used by worktree"

错误："Cannot delete branch used by worktree"

Cause: A git worktree references the branch, blocking deletion during PR merge or cleanup. Solution:

Run
```
git worktree list
```
to identify the worktree using the branch
Run
```
git worktree remove <path>
```
to detach the worktree
Retry the branch deletion or PR merge with
```
--delete-branch
```
This commonly happens when worktree agents (
```
isolation: "worktree"
```
) created the branch

原因：git worktree引用了该分支，导致PR合并或清理时无法删除分支。解决方案:

运行
```
git worktree list
```
识别使用该分支的worktree
运行
```
git worktree remove <path>
```
解除worktree关联
重试删除分支或使用
```
--delete-branch
```
合并PR
这种情况通常在worktree agent（
```
isolation: "worktree"
```
）创建分支时发生

Error: "git push says up-to-date but changes are missing on remote"

错误："git push says up-to-date but changes are missing on remote"

Cause:

git push origin master

reports "up-to-date" when HEAD is on a different branch. Git pushes the named remote ref, not the current branch, so feature branch commits are never pushed. Solution:

Always push the current branch:

git push -u origin $(git branch --show-current)

Never hardcode branch names in push commands
Verify after push:
```
git log origin/$(git branch --show-current)..HEAD
```
should show 0 commits Graduated from learning.db — multi-agent-coordination/worktree-push-from-wrong-branch

原因：当HEAD在不同分支时，

git push origin master

报告"up-to-date"。Git推送的是指定的远程引用，而非当前分支，因此功能分支的提交从未被推送。解决方案:

始终推送当前分支：

git push -u origin $(git branch --show-current)

绝不推送命令中硬编码分支名称
推送后验证：
```
git log origin/$(git branch --show-current)..HEAD
```
应显示0个提交 来自learning.db — multi-agent-coordination/worktree-push-from-wrong-branch

Anti-Patterns

反模式

Anti-Pattern 1: Committing Everything with git add -A

反模式1：使用git add -A提交所有内容

What it looks like: Running

git add -A

without checking what will be staged. Why wrong: Catches unintended files -- build artifacts,

.env

files, editor configs, large binaries. These pollute the repository and may leak secrets. Do instead: Review

git status

, stage specific files by name, verify with

git diff --cached

before committing.

表现：运行

git add -A

而不检查将暂存的内容。问题：会包含意外文件——构建产物、

.env

文件、编辑器配置、大二进制文件。这些会污染仓库，甚至可能泄露密钥。 正确做法：查看

git status

，按名称暂存特定文件，提交前使用

git diff --cached

验证。

Anti-Pattern 2: Force Pushing to Resolve Conflicts

反模式2：强制推送解决冲突

What it looks like: Push fails, so running

git push --force

to override. Why wrong: Destroys remote history. Teammates lose work. PRs become inconsistent. Do instead: Pull with rebase, resolve conflicts, push normally. If the situation is complex, inform the user rather than forcing.

表现：推送失败后，运行

git push --force

覆盖远程。问题：会破坏远程提交历史。队友的工作内容会丢失。PR会变得不一致。 正确做法：变基拉取、解决冲突、正常推送。若情况复杂，告知用户而非强制推送。

Anti-Pattern 3: Creating PR with Empty Description

反模式3：创建无描述的PR

What it looks like:

gh pr create --title "Updates" --body ""

Why wrong: Reviewers have no context. PR purpose is unclear. Test plan is missing. Do instead: Generate a summary from the diff and commit messages. Include a test plan section. Even a brief description is better than none.

表现：

gh pr create --title "Updates" --body ""

问题：评审人员没有上下文。PR的用途不明确。缺少测试计划。 正确做法：从diff和提交信息生成摘要。包含测试计划部分。即使简短的描述也比空描述好。

Anti-Pattern 4: Skipping State Detection

反模式4：跳过状态检测

What it looks like: Immediately creating a branch and committing without checking current state. Why wrong: May create nested branches, commit to wrong branch, or duplicate work already done. Do instead: Always run Step 1 first. Detect branch, changes, and PR state before taking any action.

表现：不检查当前状态就直接创建分支并提交。问题：可能创建嵌套分支、提交到错误分支，或重复已完成的工作。 正确做法：始终先执行步骤1。执行任何操作前先检测分支、变更、PR状态。

Anti-Pattern 5: Committing Directly to Main

反模式5：直接提交到主分支

What it looks like: Staging and committing on main/master instead of creating a feature branch. Why wrong: Violates branch protection conventions. Makes rollback harder. Skips code review. Do instead: Always create a feature branch from main before committing. The only exception is if the user explicitly authorizes a direct commit.

表现：在main/master分支上暂存并提交，而非创建功能分支。问题：违反分支保护规范。回滚更困难。跳过了代码评审。 正确做法：提交前始终从主分支创建功能分支。唯一例外是用户明确授权直接提交。

References

参考

This skill uses these shared patterns:

Anti-Rationalization - Prevents shortcut rationalizations
Verification Checklist - Pre-completion checks

本技能使用以下共享模式：

Anti-Rationalization - 防止捷径合理化
Verification Checklist - 完成前检查

Domain-Specific Anti-Rationalization

领域特定的Anti-Rationalization

Rationalization	Why It's Wrong	Required Action
"Quick push to main, I'll branch later"	Main commits skip review and break CI	Create branch first, always
"git add -A is fine, nothing sensitive"	Assumption without checking	Review status, stage selectively
"PR description can wait"	Reviewers need context now, not later	Write summary before creating PR
"Force push fixes the conflict"	Destroys teammate work on remote	Pull, rebase, resolve, push normally

合理化借口	问题所在	要求的操作
"先快速推送到主分支，之后再创建分支"	直接提交到主分支会跳过评审并破坏CI	始终先创建分支
"git add -A没问题，没有敏感内容"	未检查就做出假设	查看状态，选择性暂存
"PR描述可以稍后再写"	评审人员现在就需要上下文，而不是之后	创建PR前先编写摘要
"强制推送可以解决冲突"	会破坏队友在远程的工作内容	拉取、变基、解决冲突、正常推送
",

pr-sync

Original

Translation

PR Sync Skill

PR Sync 技能

Purpose

用途

Operator Context

操作上下文

Hardcoded Behaviors (Always Apply)

硬编码行为（始终生效）

Default Behaviors (ON unless disabled)

默认行为（默认开启，可禁用）

Optional Behaviors (OFF unless enabled)

可选行为（默认关闭，可开启）

What This Skill CAN Do

本技能可执行的操作

What This Skill CANNOT Do

本技能不可执行的操作

Instructions

操作说明

Usage

使用方式

Step 0: Classify Repo

步骤0：仓库分类

Step 1: Detect Current State

步骤1：检测当前状态

Get current branch

获取当前分支

Detect main branch name

检测主分支名称

Check for uncommitted changes

检查是否有未提交的变更

Check for unpushed commits

检查是否有未推送的提交

Determine if on main/master

判断是否在主分支上

Step 2: Create Branch (if on main)

步骤2：创建分支（若当前在主分支）

If no branch name provided, generate from changes or commit message

若未提供分支名称，从变更内容或提交信息生成

Create and switch to new branch

创建并切换到新分支

Step 3: Stage and Commit

步骤3：暂存并提交

Stage specific files (prefer over git add -A)

暂存特定文件（优先于git add -A）

Create commit with conventional format

创建规范格式的提交

Step 4: Push to Remote

步骤4：推送到远程

Push with upstream tracking (CLAUDE_GATE_BYPASS=1 bypasses the git-submission-gate hook)

推送并设置上游跟踪（CLAUDE_GATE_BYPASS=1 绕过git-submission-gate钩子）

Step 4b: Review-Fix Loop (personal repos only)

步骤4b：评审-修复循环（仅适用于个人仓库）

Step 5: Create or Update PR

步骤5：创建或更新PR

Check if PR already exists for this branch

检查当前分支是否已存在PR

Summary

摘要

Test Plan

测试计划

PR exists, just pushed updates

PR已存在，仅推送更新

Decision Tree

决策树

Output Format

输出格式

Error Handling

错误处理

Error: "Push rejected - branch behind remote"

错误："Push rejected - branch behind remote"

Error: "gh: not authenticated"

错误："gh: not authenticated"

Error: "No changes to commit"

错误："No changes to commit"

Error: "Branch name already exists"

错误："Branch name already exists"

Error: "Cannot delete branch used by worktree"