feat(skills): add release-version workflow

Add the release-version skill with changelog guidance, agent metadata, and a helper script for collecting release context. Also tighten the git-commit skill so changed submodule pointers must be verified on submodule remotes before the parent repository is committed.
This commit is contained in:
mlogclub
2026-04-16 23:29:42 +08:00
parent e0fe755f95
commit 6c088bf30c
5 changed files with 463 additions and 4 deletions
+18 -4
View File
@@ -7,14 +7,15 @@ description: Review local git changes, write an appropriate commit message, crea
## Overview
Use this skill for repository submission work. Inspect changes first, derive a commit message from the actual diff, commit submodules before the parent repository, then push the current branch to every remote.
Use this skill for repository submission work. Inspect changes first, derive a commit message from the actual diff, ensure submodule commits are already pushed to the submodule remotes, commit submodules before the parent repository when needed, then push the current branch to every remote.
## Workflow
1. Read repository state before changing anything.
2. Detect submodules and handle dirty submodules first.
3. Commit the parent repository only after submodule commits are finished and the parent pointer is updated.
4. Push the current branch to every remote after local commits succeed.
3. If the parent repository contains a changed submodule pointer, verify that the referenced submodule commit is already pushed to the submodule remotes before committing the parent repository.
4. Commit the parent repository only after submodule commits are finished and the parent pointer is updated.
5. Push the current branch to every remote after local commits succeed.
## Inspect Repository State
@@ -41,9 +42,11 @@ If the worktree is clean, report that there is nothing to commit. Do not create
Treat submodules as independent repositories.
- If `git status --short` in the parent repo shows a changed submodule entry, inspect whether the submodule itself has uncommitted work.
- If the parent repository shows a changed submodule pointer, enter the submodule even when its worktree is clean.
- For each dirty submodule, enter the submodule and run the same inspection flow there first.
- Write a commit message for the submodule based on its own diff, not the parent repository diff.
- Commit and push the submodule before committing the parent repository.
- If the submodule worktree is clean but the parent pointer changed, verify that the submodule `HEAD` commit exists on the submodule remotes and push it if needed before committing the parent repository.
- Return to the parent repository and verify that only the submodule pointer changed as expected.
Use commands like:
@@ -53,6 +56,8 @@ git -C <submodule-path> status --short
git -C <submodule-path> diff --stat
git -C <submodule-path> branch --show-current
git -C <submodule-path> remote -v
git -C <submodule-path> rev-parse HEAD
git -C <submodule-path> ls-remote --heads <remote>
git -C <submodule-path> add -A
git -C <submodule-path> commit -m "<message>"
git -C <submodule-path> push <remote> <branch>
@@ -60,6 +65,14 @@ git -C <submodule-path> push <remote> <branch>
If a submodule has multiple remotes, push its current branch to every remote exactly like the parent repository.
Before the parent repository commit, explicitly validate the submodule remote state:
- Read the submodule `HEAD` commit with `git -C <submodule-path> rev-parse HEAD`.
- Read the submodule current branch with `git -C <submodule-path> branch --show-current`.
- Compare against each submodule remote branch with `git -C <submodule-path> rev-list <remote>/<branch>..HEAD`.
- If the branch has outgoing commits, push that submodule branch to every remote before touching the parent repository commit.
- If the submodule is in detached `HEAD`, stop and report it unless the user explicitly asks to push a detached commit reference.
## Write Commit Messages
Base the message on the diff, not on filenames alone.
@@ -112,7 +125,7 @@ If one remote succeeds and another fails, report the partial result clearly and
## Failure Handling
- If authentication or network access fails on a remote, keep the successful pushes and report which remotes still need retry.
- If a submodule push fails, do not commit the parent repository submodule pointer unless the user explicitly asks to proceed with that inconsistent state.
- If a submodule push fails, or if the referenced submodule commit is not confirmed on the submodule remotes, do not commit the parent repository submodule pointer unless the user explicitly asks to proceed with that inconsistent state.
- If the parent repository has no changes after submodule processing, report that explicitly.
- If a command hangs during remote access, retry with a non-interactive or bounded-timeout variant to surface a concrete error.
@@ -120,6 +133,7 @@ If one remote succeeds and another fails, report the partial result clearly and
- Submodule worktrees inspected
- Dirty submodules committed and pushed first
- Changed submodule pointers validated against submodule remotes
- Parent repository diff re-checked after submodule updates
- Parent repository committed with a diff-based message
- Current branch pushed to every remote