trade-message-center/.agents/skills/publishing-git-branches/SKILL.md

name, description

name	description
publishing-git-branches	准备当前 Git 功能分支并向 origin/main 创建 PR；用于需要按任务或实际改动强制规范分支名称、同步基线及发布变更时。

发布 Git 分支

在不绕过 PR 流程的前提下，将当前分支准备为可评审状态。保持本地和远程 main 不变；只有 PR 可以将当前分支的提交带入 main。

硬停止：rebase 冲突

发生任何 rebase 冲突都必须立刻停止并询问用户。单行、机械生成、看似明显或可以推断的冲突都没有例外。 不要修改冲突文件、暂存、继续、终止，或执行其他推进 rebase 的 Git 命令。报告冲突路径并等待明确的下一步指令。

工作流程

1. 检查当前分支名，以及相对 origin/main 的提交和 diff。
2. 在发布前必须确定并落实分支名。 若当前任务准确覆盖这些改动，按任务命名；否则按当前改动命名。目标名称为 <type>/<short-kebab-topic>。当前名称与目标不完全一致时，必须先使用 git branch -m <目标名称> 重命名本地分支。若旧名称已存在远程，除非用户另行要求，不要删除它。
3. 运行 git fetch origin main；不要用 git pull 更新分支。
4. 使用 git rebase origin/main 将当前分支 rebase 到刚获取的 origin/main。
5. 如果 rebase 有任何冲突，执行上述硬停止规则。
6. 将当前分支推送到 origin。如果 rebase 改写了远程已有的当前分支，只能使用 git push --force-with-lease origin HEAD 更新；绝不能使用普通 --force。
7. 创建 PR 前执行标题硬校验。 从最终分支名提取 type；它必须是下表中的一种。PR 标题必须精确以同一个 ASCII 前缀 <type>: 开头，后接中文描述。标题不符合时，先修正标题；不得执行 gh pr create。
8. 以当前分支为 head、远程 main 为 base 创建 PR。使用仓库配置的 PR 工具，标题和正文均使用中文，并报告 PR URL 和实际创建的标题。

分支命名与 PR 文案

分支名称必须由当前工作事实得出，不能保留临时名、过时名或与改动无关的名称。先按以下优先级决定 short-kebab-topic：

1. 存在且准确覆盖当前改动的活跃任务时，使用该任务的简短主题。
2. 没有适用任务，或当前改动超出任务范围时，根据相对 origin/main 的实际 diff 和提交生成简短主题。

选择反映实际改动的类型：

类型	使用场景
feat	新功能或用户可见能力
fix	缺陷修复
chore	维护、工具或流程变更
docs	文档变更
refactor	不改变预期行为的重构
test	测试覆盖或测试工具变更
ci	持续集成或发布自动化变更

这是发布前的强制步骤，而不是仅在名称“明显不匹配”时才执行的风格建议。若当前名称已经精确等于按上述规则得出的目标名称，不必执行无效的同名重命名，但仍须说明名称来自任务还是实际改动，并给出相应证据。

PR 标题硬门槛

PR 标题不是文案偏好，而是创建 PR 的前置条件。必须从最终分支名复用 type，并使用精确格式 <type>: <中文描述>，例如 fix: 修复 Chrome 消息回调兼容性。允许的前缀仅为 feat:、fix:、chore:、docs:、refactor:、test:、ci:；冒号必须是半角 ASCII :，后面必须有一个空格。

禁止创建没有前缀、使用全角冒号、缺少空格、使用未列出类型，或与最终分支类型不一致的 PR。不能以“标题已是中文”“改动很小”或“PR 工具会补全标题”为由跳过此检查。正文应以中文说明改动、验证以及风险或后续事项。

不变量

• 不要快进、合并或将当前分支推送进本地或远程 main；改动只能经由 PR 进入 main。
• 每次发布都必须完成分支命名决策：优先依据准确覆盖改动的任务，否则依据实际改动；目标名不同就必须重命名。报告名称来源和判断证据。
• gh pr create 之前，PR 标题必须通过硬校验：以最终分支的同一 type 和精确的 <type>: 开头。标题不合规时不得创建 PR；创建后报告实际标题。
• 不要擅自执行无关清理、冲突解决、合并 PR、删除分支，或对当前 rebase 后分支之外的任何分支强制推送。

命令形态

已知或用户要求时，在推送前运行仓库既有的验证步骤。Git 和 PR 操作应遵循以下形态：

git branch --show-current
git log --oneline origin/main..HEAD
git diff --stat origin/main...HEAD
# 基于适用任务或当前实际改动，确定 <type>/<short-kebab-topic>；名称不同则必须重命名
git branch -m <type>/<short-kebab-topic>
git fetch origin main
git rebase origin/main
git push origin HEAD
# 若 rebase 后的当前分支已存在于 origin：
git push --force-with-lease origin HEAD
# 从最终分支复用类型；任一步不满足即退出，禁止创建无前缀或类型不一致的 PR
branch_name="$(git branch --show-current)"
pr_type="${branch_name%%/*}"
case "$pr_type" in
  feat|fix|chore|docs|refactor|test|ci) ;;
  *) printf '无效的分支类型，禁止创建 PR: %s\n' "$pr_type" >&2; exit 1 ;;
esac
pr_title="${pr_type}: <中文标题>"
gh pr create --base main --head "$branch_name" \
  --title "$pr_title" \
  --body "<中文正文：改动、验证、风险或后续事项>"

普通推送成功后，不要再执行 force-with-lease 命令。

红线

• “冲突很简单”或“我能推断应如何解决”仍意味着停止并询问；它依然是 rebase 冲突。
• “只是拼写错误或紧急修复”不能成为保留临时、过时或与改动不符分支名，也不能绕过 PR 流程的理由。
• “merge 更快”不能替代要求的 rebase。
• “标题已是中文”“改动很小”或“PR 工具会处理”不能成为省略 feat:、fix: 等精确类型前缀的理由。
• 英文 PR 标题或正文不符合本项目的 PR 文案约定。