一键导入
git-tag
// Create semantic version git tags with changelog. Analyzes changes since last tag, suggests version bump, updates CHANGELOG.md, commits, and tags. Triggers on "release", "git tag", "new version", "bump version", "changelog".
// Create semantic version git tags with changelog. Analyzes changes since last tag, suggests version bump, updates CHANGELOG.md, commits, and tags. Triggers on "release", "git tag", "new version", "bump version", "changelog".
Hotwire, Turbo, and Stimulus patterns for Rails. Use when implementing JavaScript interactions, Turbo Frames/Streams, or Stimulus controllers. Triggers on "stimulus controller", "turbo frame", "turbo stream", "hotwire", "rails javascript".
Ruby and Rails best practices following POODR and Refactoring Ruby. Use for Rails development guidance, code quality, dependency injection, small methods, and OOP principles. Triggers on "rails best practice", "poodr", "refactoring", "ruby oop", "code quality".
Write technical blog posts, tutorials, and documentation in Flatiron School's engaging style. Use for explaining code patterns, debugging stories, or turning complex topics into clear narratives. Triggers on "write a blog post", "tutorial about", "explain how", "technical writing".
| name | git-tag |
| description | Create semantic version git tags with changelog. Analyzes changes since last tag, suggests version bump, updates CHANGELOG.md, commits, and tags. Triggers on "release", "git tag", "new version", "bump version", "changelog". |
Create semantic version git tags with automatic changelog generation.
git tag --sort=-v:refname | head -1
Parse the latest tag (e.g. v0.2.3 → {major: 0, minor: 2, patch: 3}).
If no tags exist, assume 0.0.0.
git log --oneline <last_tag>..HEAD
If HEAD is at the last tag (no new commits), inform the user that there are no changes to release and stop.
Review each commit message to understand the scope and nature of changes.
Based on conventional commit types in the log:
| Commit type | Bump |
|---|---|
feat! or BREAKING CHANGE | major (x.0.0) |
feat | minor (0.x.0) |
fix, build, ci, perf, refactor | patch (0.0.x) |
docs, style, test, chore | patch (0.0.x) |
Use the highest bump level found. If commits contain both feat and fix, use minor.
Use the question tool to present the suggested version and ask for confirmation:
Example question:
Changes since v0.2.3:
- feat: add user dashboard
- fix: correct rating calculation
Suggested version: v0.3.0 (minor bump) Do you want to proceed with this version?
Options: the suggested version, and alternative bumps (major, minor, patch).
Read the current CHANGELOG.md and insert a new version section at the top (after the header).
Format follows Keep a Changelog:
## [X.Y.Z] - YYYY-MM-DD
### Added
- Description of new features
### Changed
- Description of changes
### Fixed
- Description of fixes
### Removed
- Description of removed features
Group commits by category:
feat commitsrefactor, behavior-changing build/ci commitsfix commitsrevert or explicitly removed featuresRules:
git add CHANGELOG.md
git commit -m "docs: add CHANGELOG for v<X.Y.Z>"
git tag v<X.Y.Z>
git log --oneline -3
git tag --sort=-v:refname | head -3
Show the user the resulting commit and tag.