git-kit

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Git Kit

Git 常见操作的统一入口。先按「意图路由」理解用户要做什么，落到一个分支执行，再按该分支的验收标准收尾。

本 skill 采用多文件结构。主文件只含意图路由。 命中某个分支后，按「按需加载」指引读取对应子文件执行其完整流程，避免一次性加载全部内容。

A unified entry point for common Git operations. First understand what the user intends through "Intent Routing," select exactly one route, execute that route, and then finish according to its acceptance criteria.

This skill uses a multi-file structure. The main file contains only intent routing. After matching a route, follow the "Load on Demand" instructions to read the corresponding child file and execute its complete workflow, avoiding loading everything at once.

意图路由（决策树）

Intent Routing (Decision Tree)

从用户消息解析意图，落入唯一分支。不得跳过路由直接执行。

分支 key	命中信号（用户消息中出现）	对应子文件
`commit-push`	提交/推送当前变更（"提交""push""commit""推送"）；起点是稳定分支时自动建工作分支	`references/commit-push.md` （含 `commit-format.md` ）
`commit-message`	只要 commit message 文案（"写个commit消息""生成commit信息"，或用户明确说"不用提交、只要文案"）	`references/commit-message.md` （含 `commit-format.md` ）
`branch`	分支 + 中文描述（"建个分支…""切到新分支…""开个分支做XX"）	`references/branch.md`
`pr-create`	创建/更新 PR/MR（"提PR""创建合并请求""更新MR"）	`references/pr-create.md`
`pr-merge`	合并 PR/MR 并回主干更新（"合并PR""合并MR""merge PR""把PR合掉""合入主干"）；命中后 head 为稳定分支时保留不删	`references/pr-merge.md`
`tag`	只给分支打版本标签并推送（"打tag""打个tag""打标签""release tag""给分支打标签"）	`references/tag.md`
`release`	`pr-merge` 之后的发布段（"发版""发个版本""发布新版本""上线这个版本""走一遍release流程"）；从已合并的稳定分支打 tag → 默认创建 GitHub/GitLab Release → 跟踪其他后效并逐项校验（不假定是 npm）	`references/release.md`
`slim`	仓库瘦身/浅克隆/减小体积（"瘦身""清理git历史""shallow clone"）	`references/slim.md`
`star-classify`	拉取并分类自己 star 的 GitHub 仓库（"分类我的star""把我star的仓库整理成清单"）	`references/star-classify.md`

模糊请求直接按意图覆盖交叉处理：

既说"提交"又说"推送" →
```
commit-push
```
（含生成 message）；只说"信息/文案"或明确"不提交" →
```
commit-message
```
。
PR/MR 相关："合并请求"作 GitLab 术语（名词） →
```
pr-create
```
；"合并"作动词（合并XX/合入XX/merge）→
```
pr-merge
```
。
tag
与
release
的分界：
```
tag
```
只给分支打标签就结束（任意分支、任意时机，不建平台 Release）；
```
release
```
是
```
pr-merge
```
之后的发布段——版本号已在稳定分支上，它负责打 tag、默认创建 GitHub/GitLab Release、跟踪其他后效（发布流水 / npm 等，按探测结果）并出回执。用户要「升版本/开 PR/合并」时不属于
```
release
```
，走
```
commit-push
```
+
```
pr-create
```
+
```
pr-merge
```
。
未命中任何信号 → 停止并询问用户具体要做的 Git 操作，不擅自动手。

参数约定（从用户消息提取，优先于任何上下文）：

```
branch
```
：提取中文描述（候选分支名唯一依据）。
```
pr-create
```
：可选目标分支名；没有则探测目标仓库默认分支。
```
pr-merge
```
：优先取用户显式提供的编号/URL；没有则探测当前分支关联的开放 PR/MR；无论来源，合并前都展示「编号 + 标题 + 目标分支 + head 分支及其去向（将删除 / 稳定分支保留）」并给用户三选项（是 / 否 / 自定义 id）确认；探测不到则要求用户提供编号，不猜测。head 为稳定分支时一律保留不删，判定与覆盖规则见
```
references/stable-branch.md
```
与
```
references/pr-merge.md
```
。
```
release
```
：至少给
```
--version <v> [--version-file <路径>]
```
或
```
--tag <v1.1.0>
```
。哪个文件是版本源由你读仓库判定（脚本不认识任何清单格式；先验与每类现成命令见
```
references/version-conventions.md
```
）：字面常量型用
```
--version
```
+
```
--version-file
```
（边界匹配回查 + 回报行号），派生/注入型（Go ldflags、setuptools-scm、
```
${revision}
```
、Composer）只用
```
--tag
```
；发布流水硬校验版本的仓库加
```
--require-version-match
```
。
```
STATE=NEEDS_TARGET
```
表示还没定目标版本（不是要用户报 tag），
```
STATE=BLOCKED
```
按
```
BLOCKERS
```
处理（含多版本线
```
target-tag-ambiguous
```
：必须显式给完整 tag）；不自行改版本号。
```
tag
```
：可选分支名或 tag 名（
```
$1
```
）；没有则探测最新 tag 与来源分支、候选分支、候选版本号并先展示给用户选择确认，不擅自决定打哪个分支/版本。目标是发布的仓库要额外对齐版本号（tag 版本必须等于版本源文件里的声明值，否则发布流水拒绝发布）——版本源文件由读仓库决定，不一致时先走
```
commit-push
```
+
```
pr-create
```
升版本，见
```
references/tag.md
```
「发版约束」。
```
slim
```
：可选保留天数
```
N
```
；没有则默认
```
30 days ago
```
。

两类消息的上下文约束：

命中
```
commit-message
```
或
```
branch
```
分支时，只处理用户提供的话术/描述，忽略任何代码、文件、git diff、git status 等上下文。
命中
```
commit-push
```
、
```
pr-create
```
、
```
pr-merge
```
、
```
tag
```
、
```
release
```
、
```
slim
```
分支时，主动读取 git 状态是必要的（diff/remote/历史）。

Parse the user's intent from the message and route it to exactly one branch. Do not skip routing and execute an operation directly.

Route key	Matching signals (present in the user's message)	Corresponding child file
`commit-push`	Commit or push current changes ("commit," "push," "commit," or "push"); if the starting point is a stable branch, automatically create a working branch	`references/commit-push.md` (includes `commit-format.md` )
`commit-message`	Only needs commit message copy ("write a commit message," "generate commit information," or the user explicitly says "do not commit, just give me the text")	`references/commit-message.md` (includes `commit-format.md` )
`branch`	A branch plus a Chinese description ("create a branch…," "switch to a new branch…," "create a branch to do XX")	`references/branch.md`
`pr-create`	Create or update a PR/MR ("open a PR," "create a merge request," "update the MR")	`references/pr-create.md`
`pr-merge`	Merge a PR/MR and update the main branch ("merge the PR," "merge the MR," "merge PR," or "merge it into the main branch"); after matching, retain and do not delete the head when it is a stable branch	`references/pr-merge.md`
`tag`	Only tag a branch with a version and push it ("create a tag," "tag it," "add a tag," "release tag," or "tag the branch")	`references/tag.md`
`release`	The release phase after `pr-merge` ("publish a release," "publish a version," "release a new version," "put this version live," or "run the release process"); tag an already merged stable branch → create a GitHub/GitLab Release by default → track other downstream effects and verify them one by one (do not assume it is npm)	`references/release.md`
`slim`	Slim down the repository, perform a shallow clone, or reduce repository size ("slim it down," "clean up Git history," or "shallow clone")	`references/slim.md`
`star-classify`	Pull and categorize the user's starred GitHub repositories ("categorize my starred repositories" or "organize my starred repositories into a list")	`references/star-classify.md`

For ambiguous requests, directly handle overlaps according to the matched intent:

Both "commit" and "push" →
```
commit-push
```
(including message generation); only "information/text" or an explicit "do not commit" →
```
commit-message
```
.
For PR/MR-related requests: "merge request" used as a GitLab noun →
```
pr-create
```
; "merge" used as a verb (merge XX, merge into XX, or merge) →
```
pr-merge
```
.
The boundary between
tag
and
release
:
```
tag
```
only tags a branch and then ends (any branch, at any time, with no platform Release creation);
```
release
```
is the phase after
```
pr-merge
```
—the version is already present on a stable branch, and it is responsible for creating a tag, creating a GitHub/GitLab Release by default, tracking other downstream effects (release workflows, npm, etc., based on detection results), and producing a receipt. When the user wants to "bump the version/open a PR/merge," this does not belong to
```
release
```
; use
```
commit-push
```
+
```
pr-create
```
+
```
pr-merge
```
.
If no signal matches → stop and ask the user which Git operation they want; do not take action without explicit intent.

Parameter conventions (extracted from the user's message and taking priority over any context):

```
branch
```
: extract the Chinese description (the sole basis for candidate branch names).
```
pr-create
```
: the target branch name is optional; if absent, detect the target repository's default branch.
```
pr-merge
```
: prioritize an explicitly provided number or URL; if absent, detect an open PR/MR associated with the current branch. Regardless of the source, before merging, display the "number + title + target branch + head branch and its destination (will be deleted / retained because it is a stable branch)" and ask the user to confirm using three options (yes / no / custom ID). If nothing can be detected, require the user to provide a number and do not guess. When the head is a stable branch, always retain it and do not delete it; see
```
references/stable-branch.md
```
and
```
references/pr-merge.md
```
for detection and override rules.
```
release
```
: provide at least
```
--version <v> [--version-file <path>]
```
or
```
--tag <v1.1.0>
```
. Determine which file is the version source by reading the repository (the script does not recognize any manifest format; first identify the applicable existing commands for each convention in
```
references/version-conventions.md
```
): for literal constant versions, use
```
--version
```
+
```
--version-file
```
(perform boundary-match verification and report the line number); for derived or injected versions (Go ldflags, setuptools-scm,
```
${revision}
```
, Composer), use only
```
--tag
```
; for repositories whose release workflows strictly validate versions, add
```
--require-version-match
```
.
```
STATE=NEEDS_TARGET
```
means the target version has not yet been determined (this does not mean asking the user for a tag). Handle
```
STATE=BLOCKED
```
according to
```
BLOCKERS
```
(including the multi-version-line
```
target-tag-ambiguous
```
: a complete tag must be provided explicitly). Do not change version numbers on your own.
```
tag
```
: the branch name or tag name (
```
$1
```
) is optional; if absent, detect the latest tag and its source branch, candidate branches, and candidate version numbers, then display them for the user to select and confirm before deciding which branch or version to tag. For repositories where the target is a release, additionally align the version number (the tag version must exactly match the value declared in the version source file; otherwise the release workflow will reject the release). Determine the version source file by reading the repository. If they do not match, first follow
```
commit-push
```
+
```
pr-create
```
to bump the version; see the "Release Constraints" section in
```
references/tag.md
```
.
```
slim
```
: the retention period
```
N
```
is optional; if absent, default to
```
30 days ago
```
.

Context constraints for the two message types:

When matching the
```
commit-message
```
or
```
branch
```
route, process only the wording or description provided by the user and ignore all code, files, Git diffs, Git status, and other context.
When matching
```
commit-push
```
,
```
pr-create
```
,
```
pr-merge
```
,
```
tag
```
,
```
release
```
, or
```
slim
```
, proactively reading Git status is necessary (diff, remote, and history).

按需加载

Load on Demand

确认分支后，执行以下子文件的完整流程：

commit-push

或

commit-message

：先

read references/commit-format.md

，再

read references/<对应分支>.md

，最后按该文件执行。

commit-push

另需先

read references/stable-branch.md

（起点是稳定分支时自动建分支，发版升版本不例外）。

```
branch
```
：
```
read references/branch.md
```
。

pr-create

：先

read references/repo-id.md

（gh/glab 的仓库参数规则），再

read references/pr-create.md

。

pr-merge

：先

read references/stable-branch.md

（判定 head 是否保留）与

read references/repo-id.md

（gh/glab 的仓库参数规则），再

read references/pr-merge.md

。

```
tag
```
：先
```
read references/stable-branch.md
```
（候选分支的稳定分支偏好），再
```
read references/tag.md
```
（含「发版约束」：版本号对齐与升版本顺序），并用
```
scripts/changelog.sh --link-to <tag>
```
生成注记正文（推送前让用户确认）。
```
release
```
：先
```
read references/ask-options.md
```
（决策点一律用选项式提问，不打印现状等人用自然语言回答），再
```
read references/version-conventions.md
```
（先认出仓库属于哪类版本约定，照该类命令取证），再
```
read references/release.md
```
（发布段流程与计划卡），再
```
read references/tag.md
```
「发版约束」（版本对齐与注记 tag），运行
```
scripts/release-preflight.sh
```
做只读预检（版本源要自己读仓库声明：
```
--version <v> --version-file <路径>
```
或
```
--tag <tag>
```
，脚本只回查「声明的文件里有没有这个版本」；返回
```
STATE
```
决定是打 tag、只验证、还是先定版本源；同时给出
```
RELEASE_PLATFORM
```
/
```
RELEASE_CLI_READY
```
/
```
RELEASE_EXISTS
```
决定 Release 是创建还是只校验，
```
EFFECT_HINTS
```
给出发布步骤原文；
```
BLOCKERS
```
非空即停，
```
WARN
```
只如实报告），用
```
scripts/changelog.sh --link-to <tag>
```
生成并落盘变更说明（
```
BODY
```
进 tag 注记与 Release body，推送前过目；之后不再重算）；Release 默认由流程创建（
```
EFFECT_RELEASE=workflow
```
时只校验，不重复建）。打 tag 与创建/校验 Release 后，用
```
scripts/release-verify.sh --platform <p> --tag <tag> [--probe-url <产物 URL>]
```
等流水 + 验 Release + 验产物（一次出
```
KEY=VALUE
```
回执；产物无公开地址就不传，以流水结论为准；npm 仓可用
```
--npm-pkg <包名>
```
别名；默认 3 分钟 / 5 秒，
```
VERIFY_REASONS
```
给出失败/未知原因）。若用户选择把变更写进
```
CHANGELOG.md
```
：
```
changelog.sh --from <上个 tag> --to <BASE_REF> --version <tag> --link-to <tag> --write CHANGELOG.md
```
→ 开
```
docs/changelog-<tag>
```
分支 →
```
pr-create
```
→
```
pr-merge
```
→ 重新预检，再打 tag（正文仍用先前冻结那份）。
```
slim
```
：
```
read references/slim.md
```
，按其中指引运行
```
scripts/git-slim.sh
```
（脚本为单一真源，与
```
/git/slim
```
命令共用）。

star-classify

：

read references/star-classify.md

，按其中指引运行

scripts/git-star.sh

。

After confirming the route, execute the complete workflow in the corresponding child file:

```
commit-push
```
or
```
commit-message
```
: first
```
read references/commit-format.md
```
, then
```
read references/<corresponding route>.md
```
, and finally execute the instructions in that file.
```
commit-push
```
additionally requires
```
read references/stable-branch.md
```
first (automatically create a branch when the starting point is a stable branch, including when bumping a version for a release).
```
branch
```
:
```
read references/branch.md
```
.

pr-create

: first

read references/repo-id.md

(repository parameter rules for gh/glab), then

read references/pr-create.md

```
pr-merge
```
: first
```
read references/stable-branch.md
```
(determine whether to retain the head) and
```
read references/repo-id.md
```
(repository parameter rules for gh/glab), then
```
read references/pr-merge.md
```
.
```
tag
```
: first
```
read references/stable-branch.md
```
(stable branch preference for candidate branches), then
```
read references/tag.md
```
(including "Release Constraints": version alignment and version bump order), and use
```
scripts/changelog.sh --link-to <tag>
```
to generate the annotation body (have the user review it before pushing).
```
release
```
: first
```
read references/ask-options.md
```
(always ask questions at decision points using options, rather than printing the current state and waiting for a natural-language answer), then
```
read references/version-conventions.md
```
(first identify the repository's version convention and collect evidence using the corresponding commands), then
```
read references/release.md
```
(release phase workflow and plan card), then the "Release Constraints" section of
```
references/tag.md
```
(version alignment and annotation tag). Run
```
scripts/release-preflight.sh
```
for a read-only preflight check (read the version source from the repository's declarations:
```
--version <v> --version-file <path>
```
or
```
--tag <tag>
```
; the script only verifies whether the declared file contains that version). The returned
```
STATE
```
determines whether to create a tag, perform verification only, or first identify the version source;
```
RELEASE_PLATFORM
```
/
```
RELEASE_CLI_READY
```
/
```
RELEASE_EXISTS
```
determine whether the Release should be created or only verified, and
```
EFFECT_HINTS
```
provides the original publishing steps. If
```
BLOCKERS
```
is non-empty, stop; report
```
WARN
```
items honestly. Use
```
scripts/changelog.sh --link-to <tag>
```
to generate and persist the release notes (the
```
BODY
```
is used for both the tag annotation and the Release body, and must be reviewed before pushing; do not recalculate it afterward). The Release is created by default as part of the workflow (when
```
EFFECT_RELEASE=workflow
```
, only verify it and do not create it again). After creating the tag and creating or verifying the Release, use
```
scripts/release-verify.sh --platform <p> --tag <tag> [--probe-url <artifact URL>]
```
and other workflows to verify the Release and artifacts (produce a
```
KEY=VALUE
```
receipt in one pass; if an artifact has no public URL, do not pass the option and use the workflow result as authoritative; for npm repositories, the
```
--npm-pkg <package name>
```
alias is available; defaults are 3 minutes / 5 seconds, and
```
VERIFY_REASONS
```
explains failures or unknown outcomes). If the user chooses to write the changes into
```
CHANGELOG.md
```
:
```
changelog.sh --from <previous tag> --to <BASE_REF> --version <tag> --link-to <tag> --write CHANGELOG.md
```
→ create a
```
docs/changelog-<tag>
```
branch →
```
pr-create
```
→
```
pr-merge
```
→ run the preflight check again, then create the tag (the body remains the previously frozen version).
```
slim
```
:
```
read references/slim.md
```
and follow its instructions to run
```
scripts/git-slim.sh
```
(the script is the single source of truth and is shared with the
```
/git/slim
```
command).

star-classify

read references/star-classify.md

and follow its instructions to run

scripts/git-star.sh