新機能
- ユーザー認証モジュールを追加
- OAuth2 ログインをサポート
修正
```
Step 5: Group Changes by Skill/Module
Analyze commits since last tag and group by affected skill/module:
- Identify changed files per commit
- Group by skill/module:
- skills//* → Group under that skill
- Root files (CLAUDE.md, etc.) → Group as "project"
- Multiple skills in one commit → Split into multiple groups
- For each group, identify related README updates needed
Example Grouping:
```
baoyu-cover-image:
- feat: add new style options
- fix: handle transparent backgrounds
→ README updates: options table
baoyu-comic:
- refactor: improve panel layout algorithm
→ No README updates needed
project:
- docs: update CLAUDE.md architecture section
```
Step 6: Commit Each Skill/Module Separately
For each skill/module group (in order of changes):
- Check README updates needed:
- Scan README*.md for mentions of this skill/module
- Verify options/flags documented correctly
- Update usage examples if syntax changed
- Update feature descriptions if behavior changed
- Stage and commit:
```bash
git add skills//*
git add README.md README.zh.md # If updated for this skill
git commit -m "(): "
```
- Commit message format:
- Use conventional commit format: ():
-
-
-
Example Commits:
```bash
git commit -m "feat(baoyu-cover-image): add watercolor and minimalist styles"
git commit -m "fix(baoyu-comic): improve panel layout for long dialogues"
git commit -m "docs(project): update architecture documentation"
```
Common README Updates Needed:
| Change Type | README Section to Check |
|-------------|------------------------|
| New options/flags | Options table, usage examples |
| Renamed options | Options table, usage examples |
| New features | Feature description, examples |
| Breaking changes | Migration notes, deprecation warnings |
| Restructured internals | Architecture section (if exposed to users) |
Step 7: Generate Changelog and Update Version
- Generate multi-language changelogs (as described in Step 4)
- Update version file:
- Read version file (JSON/TOML/text)
- Update version number
- Write back (preserve formatting)
Version Paths by File Type:
| File | Path |
|------|------|
| package.json | $.version |
| pyproject.toml | project.version |
| Cargo.toml | package.version |
| marketplace.json | $.metadata.version |
| VERSION / version.txt | Direct content |
Step 8: User Confirmation
Before creating the release commit, ask user to confirm:
Use AskUserQuestion with two questions:
- Version bump (single select):
- Show recommended version based on Step 3 analysis
- Options: recommended (with label), other semver options
- Example: 1.2.3 → 1.3.0 (Recommended), 1.2.3 → 1.2.4, 1.2.3 → 2.0.0
- Push to remote (single select):
- Options: "Yes, push after commit", "No, keep local only"
Example Output Before Confirmation:
```
Commits created:
1. feat(baoyu-cover-image): add watercolor and minimalist styles
2. fix(baoyu-comic): improve panel layout for long dialogues
3. docs(project): update architecture documentation
Changelog preview (en):
## 1.3.0 - 2026-01-22
### Features
- Add watercolor and minimalist styles to cover-image
### Fixes
- Improve panel layout for long dialogues in comic
Ready to create release commit and tag.
```
Step 9: Create Release Commit and Tag
After user confirmation:
- Stage version and changelog files:
```bash
git add
git add CHANGELOG*.md
```
- Create release commit:
```bash
git commit -m "chore: release v{VERSION}"
```
- Create tag:
```bash
git tag v{VERSION}
```
- Push if user confirmed (Step 8):
```bash
git push origin main
git push origin v{VERSION}
```
Note: Do NOT add Co-Authored-By line. This is a release commit, not a code contribution.
Post-Release Output:
```
Release v1.3.0 created.
Commits:
1. feat(baoyu-cover-image): add watercolor and minimalist styles
2. fix(baoyu-comic): improve panel layout for long dialogues
3. docs(project): update architecture documentation
4. chore: release v1.3.0
Tag: v1.3.0
Status: Pushed to origin # or "Local only - run git push when ready"
```
|