Repo Publish 是一个把本地仓库发布到远程的端到端流水线技能，目标是完成从“我做了改动”到“已在远程上线”的全过程：运行质量门禁、生成智能的多提交历史、推送并验证部署。
适用场景 当用户说“publish”“release”“ship it”“push to remote”“deploy this”时使用；当项目累积了需要干净落地的本地改动时使用；当需要切版本号或发布时使用；当用户明确要求运行完整的 landing-the-plane 工作流时使用。 不适用于：用户自己完成的单次快速提交；纯文档编辑（使用项目自身的文档工作流）；任何涉及密钥或凭据的内容（脚本会跳过这些文件）。
工作流决策树 根据用户意图选择路径：用户想发布——有本地改动吗？没有则只推送或升版本；要发布吗？是则进入发布模式；只是常规提交则进入推送模式。
推送模式 适用于需要落地的普通提交。 第一步：登记剩余工作。运行问题跟踪器步骤：bd ready 查看待处理项，bd show <id> 查看阻塞项，bd update <id> --status in_progress 认领工作。如果你无法使用 bd，询问用户该项目如何跟踪问题。不要静默跳过——问题卫生是门禁的一部分。 第二步：运行质量门禁。检查 package.json、pyproject.toml、Makefile 或项目中存在的文件，并运行项目定义的“测试 + 检查 + 构建”：Node 用 npm test && npm run lint && npm run build；Python 用 pytest && ruff check . && mypy .；Go 用 go test ./... && go vet ./...；Rust 用 cargo test && cargo clippy -- -D warnings；Makefile 驱动用 make test lint build。若某个门禁失败，停止，报告哪个门禁失败及相关错误。不要在同一发布流程中尝试修代码——先开修复 PR。对于没有明显测试命令的项目，运行 ls 找到最接近的脚本并询问用户。 第三步：智能暂存与提交。使用 scripts/intelligent_commit.sh 辅助脚本，它按变更类型（功能、修复、文档、杂务）对文件分组，并为每组生成一个提交：~/.agents/skills/repo-publish/scripts/intelligent_commit.sh。其启发式规则见 references/commit-grouping.md。如果用户偏好单次提交，合并前须明确询问。 第四步：拉取变基、推送、验证。执行 git pull --rebase 在推送前解决变基冲突；执行 git push 推送工作分支；执行 git status 必须显示“Your branch is up to date”。如果推送被拒绝，说明远程侧有变更，再次拉取变基、解决、重试。绝不在未经用户明确同意的情况下使用 --force。
发布模式 用于切版本。在推送前增加三个额外步骤。 R1 选择版本升级类型。询问用户：patch（x.y.Z → x.y.(Z+1)）、minor（X.Y → X.(Y+1)）或 major。除非用户另有说明，默认 patch。阅读变更日志以确认。 R2 升级版本。Node 用 npm version <patch|minor|major>（更新 package.json 并创建标签）；Python（使用 bumpversion 或类似工具）用 bumpversion <patch|minor|major>；手动方式为手工编辑 pyproject.toml / VERSION / package.json，然后执行 git tag -a v<VERSION> -m "Release v<VERSION>"。 R3 生成或更新 CHANGELOG。如果项目有 CHANGELOG.md，为其追加本版本的新章节，用要点总结 git log --oneline v<PREV>..HEAD 中的提交。如果没有，跳过——不要创建空的变更日志。 R4 提交发布。执行 git add package.json CHANGELOG.md（或对应文件）；执行 git commit -m "release: v<VERSION>"；执行 git push --follow-tags。--follow-tags 会把新标签随提交一起推送。 R5 发布后验证。执行 git tag --list "v<VERSION>" 查看标签是否出现；执行 git ls-remote --tags origin 验证远程有该标签。对于具备部署自动化（Vercel、npm publish 等）的项目，用户通常有手动推送后步骤。询问，不要假设。
常见陷阱 绝不在未经用户明确同意且有明确理由的情况下 --force 推送，它会重写共享历史。不要在无法读取输出的发布流程中运行测试；如果运行器不透明，把 URL 或命令展示给用户。不要提交密钥。暂存前检查 git status 中的 .env、*.pem、id_rsa 等文件。如果 bd（或所用跟踪器）有未关闭问题，在推送前把剩余工作登记为新问题并在提交中引用其 ID。如果多个分支分叉，正确做法是 bd sync 后重新执行 git pull --rebase，不要试图用强制推送摆脱不同步。
环境变量 无需环境变量。该技能使用 git 已配置的推送方式。如果用户需要特定的远程凭据，其已在 git 配置中设置。
相关工作流 单提交热修复 → 跳过 intelligent_commit.sh，使用 git add -p 加单次 git commit。二分定位回归 → 不是发布技能的职责；直接使用 git bisect。预发布测试 → 在调用本技能前使用项目自身的预发环境。