git-ship

Stars1

Forks0

UpdatedJuly 21, 2026 at 03:14

提交代码 + 推送 + 创建 MR/PR。**触发场景**：用户表达「完成了 / 搞定了 / 做好了 / 提交吧 / 推一下 / 可以提了 / ship 它 / 合并代码 / 收尾了」等完成意图时主动询问；用户输入 /git-ship 时直接执行；plan 已完成且代码改完时主动询问 ship。**禁止直接合并到 master**（必须创建 MR/PR 等待人工 Review）。

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Source

zelixag

zelixag/avatar-work

View GitHub Repository View Creator Repositories

Download

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

name	git-ship
description	提交代码 + 推送 + 创建 MR/PR。触发场景：用户表达「完成了 / 搞定了 / 做好了 / 提交吧 / 推一下 / 可以提了 / ship 它 / 合并代码 / 收尾了」等完成意图时主动询问；用户输入 /git-ship 时直接执行；plan 已完成且代码改完时主动询问 ship。禁止直接合并到 master（必须创建 MR/PR 等待人工 Review）。
argument-hint	["可选补充说明"]
allowed-tools	Bash(git ), Bash(gh ), Bash(test *), Read

git-ship

提交代码、推送、创建 MR/PR。禁止直接合并到 master。

自动触发：完成意图识别

当用户在对话里表达完成 / 提交 / 推送 / 合并语义时，主动确认后跑 git-ship 流程。

触发词（任一）

完成类：「完成了」/「搞定了」/「弄完了」/「做好了」/「OK 了」
提交类：「提交吧」/「推一下」/「可以提了」/「ship 它」
合并类：「合并代码」/「提交代码」/「合到 master」
收尾类：「结束了」/「收尾了」/「打包」

行为

触发词命中
  ↓
AI 主动询问：「我准备 commit 当前改动 → push 到远程 → 创 MR 到 master，确认 yes/no？」
  ↓
yes  → 跑完整 git-ship 流程（下文步骤 1-6）
no   → 询问用户具体期望（要不要先看 diff / 要不要拆 commit / 要不要换 base 分支）

边界规则

场景	处理
首次表达完成	必须确认——防止用户随口说"完成了"但实际未真完成（如还没跑测试 / diff 有未提交残留）
同会话同分支再次完成（已确认过一次）	可不重复确认，直接跑步骤 1-6
破坏性操作（force push / amend 已 push 的 commit / push 到 master）	必须强制确认，不论之前已确认多少次
commit 前置检查失败（如 lint / 测试不过）	不要无脑 ship，告诉用户失败项 + 修复建议
用户语义模糊（如「先看一下」/「再看看」）	不触发，等明确信号

与全局规则的关系

用户全局 ~/.claude/CLAUDE.md 写明：「涉及外部可见动作必须确认（push / 创 PR / 评论 issue）」。本 skill 的"主动确认"环节正好满足这条全局要求——AI 不直接跑 ship，先发"准备 commit + push + 创 MR"询问句让用户拍板。

反模式（禁止）

❌ 用户说「完成了」直接跑 push，不询问
❌ 用户说「完成了」但 git status 有未 stage 的改动，AI 自动 stage 一切（可能带入用户未意图的文件）
❌ 用户说「完成了」但当前在 master 分支（无 feature 分支），AI 直接 push 到 master 不询问
❌ 触发词命中但用户意图不明（如「这个功能完成了吗？」是反问），AI 应理解上下文不要硬触发

参数

$ARGUMENTS — 可选补充说明

步骤

0. swagger-repo 分支前置检查（可跳过）

如果项目根有 swagger-repo.json 且本次将合并到 master/main，先按 check-api-branch skill 的流程跑一遍。原因：开发期为了测后端 feat 分支，swagger-repo.json.branch 容易被改到非 master，忘了切回会让 master 上的 API 类型来自某人本地的 feature 分支。

判断条件（任一成立即触发提示）：

# 仓库里有 swagger-repo.json
test -f swagger-repo.json && echo "has-swagger=true" || echo "has-swagger=false"
# 本次 commit 范围动过 swagger-repo.json
git diff --name-only @{upstream}..HEAD 2>/dev/null | grep -q '^swagger-repo\.json$' && echo "touched=true" || echo "touched=false"

有 swagger-repo.json 且未跑过 check-api-branch -> 提示用户先按 check-api-branch skill 检查后再回来
用户明确说"已确认 / 跳过" -> 继续后续步骤
没有 swagger-repo.json -> 静默跳过本步

1. 检查状态

git status --short
git branch --show-current

在 master 上 → 停止，提示用 /start-task 创建分支
无变更 → 停止

2. 暂存

逐个 git add <文件>，不用 git add -A
排除 .env、node_modules/、dist/、密钥文件
可疑文件警告用户

3. Commit

分析 diff，生成中文 commit message（feat/fix/chore/docs/refactor）
展示给用户确认后提交

git commit -m "<message>

Co-Authored-By: Claude <noreply@anthropic.com>"

hook 失败 → 修复后新建 commit，不 amend

4. 推送

git push origin <branch> -u

rejected → git pull --rebase 后重试
权限错误 → 提示用户 ! ssh-add（密码四个空格）

5. 创建 MR/PR

先检测远程类型：

git remote get-url origin

GitLab（g.echo.tech）：

push 输出中已包含 MR 链接，直接提供给用户
或构造：http://g.echo.tech/<group>/<repo>/-/merge_requests/new?merge_request[source_branch]=<branch>

GitHub：

gh pr create --title "<message>" --body "<body>" --base master

gh 不可用时，提供 Web URL。

6. 输出报告

## Git Ship 完成
| 步骤 | 状态 |
|------|------|
| 提交 | abc1234 -- <message> |
| 推送 | origin/<branch> |
| MR   | <URL> |

等待人工 Review 后合并。

规则

禁止 force push
禁止 --no-verify
禁止直接合并到 master
冲突 → 停止，询问用户

More from this repository

same repository

avatar-agent-builder

zelixag/avatar-work

在任意空目录中从零创建数字人智能体应用。自动识别场景（业务流/纯对话/能力展示），从内置模板复制项目文件，引导用户改配置、本地调通。Use when 用户说"新建数字人应用""开发智能体""做 XX 场景的 Demo""搭一个数字人""创建一个数字人项目"。

2026-07-211

add-biz-message

zelixag/avatar-work

接到"加 Biz 类型 / 加新消息类型 / 加新消息样式 / 发某某卡片 / 想发个表单让用户填 / 消息发出去对端没收到"等需求时触发。引导决策：基础类型 vs 已有 BIZ vs 新增 BIZ；新增 BIZ 必须走后端专属接口 + 前后端共同约定 4 步流程；前端职责仅"调发送接口 + 写展示卡片"。

2026-07-211

check-api-branch

zelixag/avatar-work

合并 master 前检查 swagger-repo.json 是否残留 feat 分支，半自动逐条切回并重跑 gen:api。**触发场景**：准备合并到 master 之前（由 git-ship skill 自动调用）/ 修改过 swagger-repo.json 的 branch 字段 / 拉到陌生分支后想确认 API 类型来源 / 用户输入 /check-api-branch。

2026-07-211

code-review

zelixag/avatar-work

多模型并行 Code Review。**自动触发场景**：用户拍板 plan 后改完代码（中等 / 复杂任务），AI 主动询问「需要 code review 吗？」**手动触发**：用户输入 `/code-review` 或说「review 一下这次改动 / 帮我看看这次提交」。按改动复杂度分级派 SubAgent，**轻量改动只派 1 个 sonnet 兜底，复杂任务才派 3 个含 opus 架构师**——不浪费最强模型在简单任务上。

2026-07-211

coding-standards

zelixag/avatar-work

公司前端通用编码规范（从 11 个项目 + 飞书知识库抽取）。当用户开始编写/修改前端 TS/TSX/Vue/SCSS 代码，或者需要 code review / 检查规范一致性时，**必须**加载本 skill 作为硬性规则基础。

2026-07-211

dev-debug

zelixag/avatar-work

启动开发环境 + 调试。触发场景："看一下效果 / 跑起来看看 / 启动一下 / 打开看看 / 启动 dev / 跑 dev"。本 skill 读 profile.devServer 配置 → 校验前置 → 后台 spawn dev server → 等 ready → 拼带 token 的真实域名 URL → open 浏览器。同时含项目特定的"关键调试场景"片段（按 profile 加载）。

2026-07-211

name	git-ship
description	提交代码 + 推送 + 创建 MR/PR。触发场景：用户表达「完成了 / 搞定了 / 做好了 / 提交吧 / 推一下 / 可以提了 / ship 它 / 合并代码 / 收尾了」等完成意图时主动询问；用户输入 /git-ship 时直接执行；plan 已完成且代码改完时主动询问 ship。禁止直接合并到 master（必须创建 MR/PR 等待人工 Review）。
argument-hint	["可选补充说明"]
allowed-tools	Bash(git ), Bash(gh ), Bash(test *), Read

git-ship

提交代码、推送、创建 MR/PR。禁止直接合并到 master。

自动触发：完成意图识别

当用户在对话里表达完成 / 提交 / 推送 / 合并语义时，主动确认后跑 git-ship 流程。

触发词（任一）

完成类：「完成了」/「搞定了」/「弄完了」/「做好了」/「OK 了」
提交类：「提交吧」/「推一下」/「可以提了」/「ship 它」
合并类：「合并代码」/「提交代码」/「合到 master」
收尾类：「结束了」/「收尾了」/「打包」

行为

触发词命中
  ↓
AI 主动询问：「我准备 commit 当前改动 → push 到远程 → 创 MR 到 master，确认 yes/no？」
  ↓
yes  → 跑完整 git-ship 流程（下文步骤 1-6）
no   → 询问用户具体期望（要不要先看 diff / 要不要拆 commit / 要不要换 base 分支）

边界规则

场景	处理
首次表达完成	必须确认——防止用户随口说"完成了"但实际未真完成（如还没跑测试 / diff 有未提交残留）
同会话同分支再次完成（已确认过一次）	可不重复确认，直接跑步骤 1-6
破坏性操作（force push / amend 已 push 的 commit / push 到 master）	必须强制确认，不论之前已确认多少次
commit 前置检查失败（如 lint / 测试不过）	不要无脑 ship，告诉用户失败项 + 修复建议
用户语义模糊（如「先看一下」/「再看看」）	不触发，等明确信号

与全局规则的关系

反模式（禁止）

❌ 用户说「完成了」直接跑 push，不询问
❌ 用户说「完成了」但 git status 有未 stage 的改动，AI 自动 stage 一切（可能带入用户未意图的文件）
❌ 用户说「完成了」但当前在 master 分支（无 feature 分支），AI 直接 push 到 master 不询问
❌ 触发词命中但用户意图不明（如「这个功能完成了吗？」是反问），AI 应理解上下文不要硬触发

参数

$ARGUMENTS — 可选补充说明

步骤

0. swagger-repo 分支前置检查（可跳过）

判断条件（任一成立即触发提示）：

# 仓库里有 swagger-repo.json
test -f swagger-repo.json && echo "has-swagger=true" || echo "has-swagger=false"
# 本次 commit 范围动过 swagger-repo.json
git diff --name-only @{upstream}..HEAD 2>/dev/null | grep -q '^swagger-repo\.json$' && echo "touched=true" || echo "touched=false"

有 swagger-repo.json 且未跑过 check-api-branch -> 提示用户先按 check-api-branch skill 检查后再回来
用户明确说"已确认 / 跳过" -> 继续后续步骤
没有 swagger-repo.json -> 静默跳过本步

1. 检查状态

git status --short
git branch --show-current

在 master 上 → 停止，提示用 /start-task 创建分支
无变更 → 停止

2. 暂存

逐个 git add <文件>，不用 git add -A
排除 .env、node_modules/、dist/、密钥文件
可疑文件警告用户

3. Commit

分析 diff，生成中文 commit message（feat/fix/chore/docs/refactor）
展示给用户确认后提交

git commit -m "<message>

Co-Authored-By: Claude <noreply@anthropic.com>"

hook 失败 → 修复后新建 commit，不 amend

4. 推送

git push origin <branch> -u

rejected → git pull --rebase 后重试
权限错误 → 提示用户 ! ssh-add（密码四个空格）

5. 创建 MR/PR

先检测远程类型：

git remote get-url origin

GitLab（g.echo.tech）：

push 输出中已包含 MR 链接，直接提供给用户
或构造：http://g.echo.tech/<group>/<repo>/-/merge_requests/new?merge_request[source_branch]=<branch>

GitHub：

gh pr create --title "<message>" --body "<body>" --base master

gh 不可用时，提供 Web URL。

6. 输出报告

## Git Ship 完成
| 步骤 | 状态 |
|------|------|
| 提交 | abc1234 -- <message> |
| 推送 | origin/<branch> |
| MR   | <URL> |

等待人工 Review 后合并。

规则

禁止 force push
禁止 --no-verify
禁止直接合并到 master
冲突 → 停止，询问用户