git-ship

Estrellas1

Forks0

Actualizado21 de julio de 2026 a las 03:14

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

Instalación

Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.

Fuente

zelixag

zelixag/avatar-work

Abrir repositorio de GitHub Ver repositorios del creador

Descarga

Ocupaciones relacionadasSOC

Basado en la clasificación ocupacional SOC

Desarrolladores de softwareOcupaciones informáticas y matemáticas·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
冲突 → 停止，询问用户

Más de este repositorio

mismo repositorio

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
冲突 → 停止，询问用户