Skip to content

Commit 893cfe2

Browse files
committed
chore: add release-version skill
1 parent 2ad22ce commit 893cfe2

1 file changed

Lines changed: 156 additions & 0 deletions

File tree

Lines changed: 156 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,156 @@
1+
---
2+
name: release-version
3+
description: Use when releasing a new version - guides through version bump, changelog generation, commit grouping, tagging, and GitHub CI tracking. Triggers on "发布新版本", "release", "发版", or version release requests.
4+
---
5+
6+
# Release Version Workflow
7+
8+
## Overview
9+
10+
A complete release workflow for Gemini-Subtitle-Pro that handles version bumping, changelog generation from git history, grouped commits, tagging, and GitHub CI monitoring.
11+
12+
## When to Use
13+
14+
- User says "发布新版本", "release", "发版"
15+
- User requests a version release
16+
- Before publishing a new release to GitHub
17+
18+
## Workflow Steps
19+
20+
### Step 0: Pre-flight Questions
21+
22+
Ask the user:
23+
24+
1. **Version number** - What version to release? (e.g., 2.12.0)
25+
2. **Pre-release?** - Is this a pre-release version? (affects GitHub release settings)
26+
27+
### Step 1: Check and Commit Uncommitted Changes
28+
29+
1. Run `git status` to check for uncommitted changes
30+
2. If changes exist:
31+
- Analyze the changes by topic/feature
32+
- Group related changes together
33+
- Create separate commits for each topic group
34+
- Use conventional commit messages (feat:, fix:, chore:, etc.)
35+
36+
### Step 2: Generate Changelog
37+
38+
1. Find the previous version tag:
39+
40+
```bash
41+
git describe --tags --abbrev=0
42+
```
43+
44+
2. Get all commits since last tag:
45+
46+
```bash
47+
git log <previous-tag>..HEAD --oneline
48+
```
49+
50+
3. Read each commit's details to categorize:
51+
- **Features** - New functionality (feat:)
52+
- **Fixes** - Bug fixes (fix:)
53+
- **Refactor** - Code improvements (refactor:)
54+
- **Chore** - Maintenance tasks (chore:)
55+
- **Documentation** - Doc updates (docs:)
56+
- **Performance** - Performance improvements (perf:)
57+
58+
4. Update `CHANGELOG.md`:
59+
- Add new version section at the top (after header)
60+
- Format: `## [X.X.X] - YYYY-MM-DD` (no 'v' prefix)
61+
- Group entries by category (Keep a Changelog format)
62+
63+
5. Update `package.json`:
64+
- Change `"version": "X.X.X"` to new version (no 'v' prefix)
65+
66+
### Step 3: Commit Release Files
67+
68+
```bash
69+
git add CHANGELOG.md package.json
70+
git commit -m "Release vX.X.X"
71+
```
72+
73+
Note: Commit message uses 'v' prefix, but version strings in files do not.
74+
75+
### Step 4: Tag and Push
76+
77+
```bash
78+
git tag vX.X.X
79+
git push origin main
80+
git push origin vX.X.X
81+
```
82+
83+
Note: Tag uses 'v' prefix (e.g., v2.12.0).
84+
85+
### Step 5: Monitor GitHub CI
86+
87+
1. Track the GitHub Actions workflow:
88+
89+
```bash
90+
gh run list --workflow=release.yml --limit=1
91+
gh run watch <run-id>
92+
```
93+
94+
2. Report build status to user:
95+
- Success: Provide release URL
96+
- Failure: Show error details
97+
98+
## Quick Reference
99+
100+
| Step | Command | Purpose |
101+
| ------------ | -------------------------------- | -------------------------- |
102+
| Check status | `git status` | Find uncommitted changes |
103+
| Previous tag | `git describe --tags --abbrev=0` | Get last release tag |
104+
| Commit log | `git log <tag>..HEAD --oneline` | List changes since release |
105+
| Create tag | `git tag vX.X.X` | Create version tag |
106+
| Push tag | `git push origin vX.X.X` | Trigger CI build |
107+
| Watch CI | `gh run watch` | Monitor build progress |
108+
109+
## Version Format Rules
110+
111+
| Location | Format | Example |
112+
| -------------- | --------------- | -------------------------- |
113+
| Git tag | With 'v' prefix | `v2.12.0` |
114+
| Commit message | With 'v' prefix | `Release v2.12.0` |
115+
| CHANGELOG.md | No 'v' prefix | `## [2.12.0] - 2026-01-06` |
116+
| package.json | No 'v' prefix | `"version": "2.12.0"` |
117+
118+
## CHANGELOG Format
119+
120+
```markdown
121+
## [X.X.X] - YYYY-MM-DD
122+
123+
### Features
124+
125+
- **Component**: Description of new feature.
126+
127+
### Fixes
128+
129+
- **Component**: Description of bug fix.
130+
131+
### Refactor
132+
133+
- **Component**: Description of refactoring.
134+
135+
### Chore
136+
137+
- **Component**: Maintenance description.
138+
```
139+
140+
## Common Mistakes
141+
142+
| Mistake | Fix |
143+
| ----------------------------- | ----------------------------------------------------------- |
144+
| Forgetting to push the tag | CI only triggers on tag push, not commit push |
145+
| Wrong version in package.json | Version must match tag (without 'v' prefix) |
146+
| Changelog in wrong position | New version goes after the header, before previous versions |
147+
| Not grouping commits | Related changes should be in one commit for cleaner history |
148+
| Inconsistent 'v' prefix | Tag and commit use 'v', files don't |
149+
150+
## Pre-release Handling
151+
152+
For pre-release versions:
153+
154+
- Use version format: `X.X.X-beta.1`, `X.X.X-rc.1`
155+
- Tag format: `vX.X.X-beta.1`
156+
- Note: Current CI workflow sets `prerelease: false` - may need manual adjustment in GitHub release

0 commit comments

Comments
 (0)