Release

Release Skill

Create a new release for timesheetz. Usage: /release

Steps

Phase 1: Analyze Changes

1. Check status: Run git status and git diff --stat to see uncommitted changes
2. Abort if clean: If no changes, inform user and stop
3. Analyze changes: Review the diff to categorize changes:
   • patch: Bug fixes, typo corrections, small tweaks, no new functionality
   • minor: New features, enhancements, new files, UI improvements
   • major: Breaking changes, API changes, major rewrites

Phase 2: Get User Approval

4. Present summary: Show the user:
   • List of changed files
   • Summary of what changed
   • Suggested version bump type with reasoning
   • Proposed commit message
5. Wait for approval: Ask user to confirm or adjust the version bump type

Phase 3: Execute Release (only after approval)

6. Create commit:
   • Use the approved commit message
   • Always end with: Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
   • Use HEREDOC format for the commit message
7. Handle remote changes: Run git pull --rebase origin main before pushing
8. Push: Run git push origin main
9. Determine version:
   • Get latest tag: git tag --sort=-v:refname | head -1
   • Apply approved bump type:
     • patch: v1.29.0 → v1.29.1
     • minor: v1.29.0 → v1.30.0
     • major: v1.29.0 → v2.0.0
10. Create tag: git tag <new-version>
11. Push tag: git push origin <new-version>
12. Create release: Check if GitHub Action created it, otherwise create with gh release create
13. Report: Show the release URL to the user

Version Bump Guidelines

Commit Message Format

<Summary of changes in imperative mood>

- Bullet point details if multiple changes

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Safety

• Never force push
• Never skip hooks
• Always pull --rebase before pushing
• Always get user approval before executing
• Wait for user confirmation if there are merge conflicts