Git Kit

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)

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

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

git-kit

NPX Install

Tags

SKILL.md Content (Chinese)

Git Kit

Intent Routing (Decision Tree)

Load on Demand