---
name: cs-github-push
description: "将已完成的本地改动安全提交并推送到 GitHub，或为已提交的改动创建 PR；适用于用户要求推送、同步仓库、发布 skill 或核验远端提交。需要部署网站或应用时使用 cs-ending-time。"
---

<!-- CS Skills · 陈硕 | portable skill entry | https://github.com/ChenShuo2004/cs-skills -->

# CS GitHub Push

把“本地做好了”变成可核验的 GitHub 结果。处理一次明确的仓库交付：确认来源和范围、完成必要检查、提交、推送，并用远端状态证明结果。

## 适用边界

- 适用：推送已有改动、发布新增 skill、同步 README／文档、创建用户要求的 PR、核验某次推送是否真的到达 GitHub。
- 如果实现尚未完成，先完成实现与必要验证，再进入本流程。
- 如果还需要部署网站或应用，用 `$cs-ending-time` 管理完整交付；本 skill 的终点是 GitHub，不把推送等同于上线。
- 用户只是询问如何推送时，解释流程即可；不要因此修改远端。

## 推送流程

1. **确定交付目标。** 找到仓库根目录、`AGENTS.md`、当前分支、远端与默认分支；查看 `git status --short --branch`、近期提交和待推送提交。明确本次要交付哪些文件，保留其他人的改动。
2. **核对真实来源。** 对来自另一个 Agent、工作区或补丁的内容，先找到原文件并核对完整性。对话摘要、生成日志和“已提交”的说法不能代替本地文件或 Git 对象；缺源文件时说明缺口，不凭描述重建后冒充原版。
3. **完成发布前检查。** 运行与改动相关的验证，检查文档链接、示例命令、生成物和敏感文件。新增或修改 CS Skills 时，同步 `README.md`、`cs-run/SKILL.md` 和必要的 `docs/` 清单；README 的入口、用途、安装方式与实际目录一致。不要为一次普通代码推送重写无关文档。
4. **精确提交。** 查看每个待提交文件的 diff；用明确路径暂存，检查 `git diff --cached --check`、`--stat` 和关键内容，再提交。不要用 `git add -A` 把无关文件带入，也不要提交密钥、私有配置、依赖目录或临时产物。
5. **检查远端变化并推送。** 先 `git fetch`，确认目标分支相对远端的状态。远端已前进时，先整合并验证，不能用强制推送覆盖。按用户指定或仓库约定选择分支；需要 PR 时推送工作分支并创建 PR。直接更新默认分支时，确认它是本次明确的目标且没有分支保护阻挡。
6. **核验交付。** 比对本地提交 SHA 与远端分支 SHA；如果创建 PR，记录并打开 PR 地址，核对目标分支和包含的文件。推送命令成功但未完成远端比对时，只报告“推送命令成功，远端未核验”。

## 决策规则

- 用户已明确要求推送本次成果，按该授权执行，不为同一动作重复求确认；新发现的其他仓库或其他任务不自动并入。
- 当前分支、目标分支或 PR 方式不明确时，先按仓库约定与用户此前选择判断；只有不同选择会改变公开结果时才提问。
- 禁止默认使用 `reset --hard`、`push --force`、删除分支或改写历史。遇到冲突、权限不足或远端拒绝，保留现场，给出具体原因与可恢复的下一步。
- 如果 GitHub 推送会触发生产部署，按项目的部署规则处理并验证生产状态；必要时转入 `$cs-ending-time`。

## 交付报告

简洁列出：仓库、目标分支或 PR、提交 SHA、推送到的远端地址、完成的验证，以及尚未交付的文件或阻塞。区分“本地提交”“分支已推送”“PR 已创建”“默认分支已更新”和“部署已验证”。