zhongwei/gh-mixomat-claude-plugins-plugins-git-workflow
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial commit

Browse Source
This commit is contained in:
Zhongwei Li
2025-11-30 08:40:41 +08:00
commit 00a502a8ad
5 changed files with 407 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

106
skills/clean-gone-branches/SKILL.md Normal file
View File

@@ -0,0 +1,106 @@
---
name: clean-gone-branches
description: Clean up local git branches marked as [gone] (deleted on remote but still exist locally). Use when the user wants to clean up stale branches, remove gone branches, or delete branches that no longer exist on remote.
allowed-tools: Bash
---
# Clean Gone Branches
Automatically clean up all local git branches that have been deleted from the remote repository (marked as `[gone]`).
## Instructions
### Step 1 - List Branches to Identify [gone] Status
Execute this command to see all local branches and their status:
```bash
git branch -v
```
**What to look for:**
- Branches marked with `[gone]` have been deleted from the remote
- Branches with a `+` prefix have associated worktrees and will be skipped (must be cleaned up manually)
- Branches without a `+` prefix can be safely deleted
- If no branches show `[gone]`, inform the user that no cleanup is needed and STOP
### Step 2 - Delete [gone] Branches (Skip Those with Worktrees)
Execute this command to clean up [gone] branches without worktrees:
```bash
git branch -v | grep '\[gone\]' | while read line; do
if [[ $line =~ ^[+] ]]; then
branch=$(echo "$line" | awk '{print $1}' | sed 's/^+//')
echo "Skipping $branch (has worktree - remove worktree first)"
else
branch=$(echo "$line" | sed 's/^[* ]//' | awk '{print $1}')
echo "Deleting branch: $branch"
git branch -D "$branch"
fi
done
```
**What this does:**
1. Finds all branches marked as `[gone]`
2. For each branch:
- If it has a `+` prefix (worktree exists), skip it and warn the user
- Otherwise, delete the branch using `-D` (force delete)
3. Provides clear feedback about which branches were deleted and which were skipped
### Step 3 - Report Results
After execution, inform the user:
- How many branches were deleted
- How many branches were skipped (with worktrees)
- If any branches were skipped, suggest they need manual worktree cleanup
- Confirmation that cleanup is complete
If no branches were marked as `[gone]`, report that no cleanup was needed.
## Important Rules
- **DO NOT** attempt to delete branches with worktrees - skip them and warn the user
- Use `git branch -D` (force delete) because [gone] branches are already merged/deleted remotely
- Show clear feedback for each operation (deleted vs skipped)
- Inform users that skipped branches require manual worktree cleanup first
## Expected Output
**Example with branches to clean:**
```
Deleting branch: fix/obsolete-fix
Skipping feature/old-feature (has worktree - remove worktree first)
Deleting branch: chore/cleanup-task
Cleanup complete:
- Deleted 2 branches marked as [gone]
- Skipped 1 branch with worktree
Note: Branches with worktrees must be cleaned up manually using 'git worktree remove' before the branch can be deleted.
```
**Example with no cleanup needed:**
```
No branches marked as [gone] found. Your local repository is already clean.
```
**Example with only worktree branches:**
```
Skipping feature/old-feature (has worktree - remove worktree first)
Skipping fix/another-branch (has worktree - remove worktree first)
Cleanup complete:
- Deleted 0 branches marked as [gone]
- Skipped 2 branches with worktrees
Note: Branches with worktrees must be cleaned up manually using 'git worktree remove' before the branch can be deleted.
```
## Error Handling
If any command fails:
- Show the error message to the user
- Explain what went wrong
- Continue processing other branches if possible
- Report which branches were successfully cleaned and which failed

236
skills/squash-commits/SKILL.md Normal file
View File

@@ -0,0 +1,236 @@
---
name: squash-commits
description: Squash all commits in a feature branch into a single commit with an AI-generated summary message. Use when the user wants to clean up their git history before merging, combine multiple commits, or create a single commit from a feature branch.
allowed-tools: Bash, AskUserQuestion
---
# Squash Git Commits
Squash all commits in a feature branch into a single commit with a well-structured, AI-generated commit message.
## Instructions
### Step 1 - Safety Checks
First, perform these safety checks:
1. **Check for uncommitted changes:**
```bash
git status
```
- If there are uncommitted changes, inform the user and STOP
- Suggest they commit or stash changes before proceeding
2. **Get current branch name:**
```bash
git branch --show-current
```
- Store this for later use
3. **Create backup branch:**
```bash
git branch backup/<current-branch-name>-$(date +%Y%m%d-%H%M%S)
```
- Inform the user that a backup branch has been created for safety
### Step 2 - Detect Base Branch
Auto-detect the base branch by checking which exists (in priority order):
1. `main`
2. `master`
3. `develop`
Check each with:
```bash
git rev-parse --verify <branch-name> 2>/dev/null
```
If none exist, ask the user to specify the base branch.
### Step 3 - Determine Commit Type from Branch Name
Parse the current branch name to determine the commit type prefix:
**Priority 1: JIRA Ticket Pattern**
- Pattern: `<prefix>/<TICKET-NUMBER>` or `<prefix>/<TICKET-NUMBER>-description`
- Examples: `feature/TVFUS-12345`, `fix/JIRA-999-bug-fix`
- Regex pattern: `^(feature|chore|fix)/([A-Z]+-\d+)`
- **Commit type:** Use the ticket number (e.g., `TVFUS-12345:`)
**Priority 2: Branch Prefix Mapping**
- `feature/` → `feat:`
- `chore/` → `chore:`
- `fix/` → `fix:`
**Fallback:**
- If no pattern matches, ask the user what commit type to use
### Step 4 - Analyze Changes
Gather comprehensive information about all changes:
1. **Get commit history:**
```bash
git log <base-branch>..HEAD --oneline
git log <base-branch>..HEAD --format="%B"
```
2. **Get code changes:**
```bash
git diff <base-branch>...HEAD --stat
git diff <base-branch>...HEAD
```
3. **Analyze the changes:**
- Review both commit messages AND the actual code diff
- Identify **functional changes** (what the code does differently)
- Focus on:
- User-facing changes
- New features or capabilities
- Bug fixes and their impact
- Refactoring and improvements
- Configuration or dependency changes
- **DO NOT** just list commit messages - synthesize the actual functional impact
### Step 5 - Generate Commit Message
Create a commit message in this **exact format**:
```
<commit-type>: A brief summary line of the change
- functional change 1
- functional change 2
- functional change 3
```
**Guidelines:**
- **First line (summary):**
- Concise summary (ideally under 72 characters)
- Captures the overall purpose of the changes
- Use imperative mood (e.g., "Add feature" not "Added feature")
- **Blank line:** Required separator between summary and body
- **Body (bullet points):**
- Each bullet describes ONE functional change
- Describe WHAT changed functionally, not implementation details
- Focus on user-visible or behavioral changes
- Be concise but descriptive
- Use imperative mood and present tense
**Example:**
```
feat: Add user profile management
- Add user profile page with editable fields
- Implement avatar upload functionality
- Add email verification workflow
- Include profile deletion with confirmation dialog
```
**Example with JIRA ticket:**
```
TVFUS-12345: Implement shopping cart feature
- Add cart UI with item list and quantity controls
- Implement cart persistence across sessions
- Add checkout button with price calculation
- Include empty cart state with call-to-action
```
### Step 6 - Present for Approval by User
Show the user:
- The generated commit message (in a code block for easy review)
- Number of commits that will be squashed
- The base branch being used
- Reminder that a backup branch was created
Use the AskUserQuestion tool to present choices to proceed:
Question: Proceed with this commit message?
1. Yes
3. Edit the message? (if yes, ask for the edited version)
2. No, cancel
**DO NOT** proceed without the confirmation by the user.
### Step 7 - Execute Squash (Only After Approval by User)
Once the user approves the commit message:
1. **Perform the squash:**
```bash
git reset --soft <base-branch>
git commit -m "<approved-message>"
```
Note: Use a heredoc for multi-line messages:
```bash
git commit -m "$(cat <<'EOF'
<approved-message>
EOF
)"
```
2. **Verify success:**
```bash
git log --oneline -5
```
3. **Inform the user:**
- Squash completed successfully
- Show the new commit hash and message
- Ask the user if the backup branch should be deleted now
## Important Rules
- **DO NOT** push to remote automatically - let the user decide
- **DO NOT** proceed if there are uncommitted changes
- **ALWAYS** create a backup branch before squashing
- **ALWAYS** wait for user approval before executing the squash
- **ALWAYS** use heredoc format for multi-line commit messages
- Focus on **functional changes** in the commit body, not implementation details
## Error Handling
If any command fails:
- Show the error message to the user
- Explain what went wrong in plain language
- Suggest recovery steps
- **DO NOT** proceed with the squash if there are errors
- Remind them that the backup branch exists if they need to recover
## Examples
### Example 1: Feature branch with JIRA ticket
```
Branch: feature/TVFUS-12345-user-auth
Base: main
Commits: 8
Generated message:
TVFUS-12345: Add user authentication system
- Add login and registration forms
- Implement JWT-based authentication
- Add password reset functionality
- Include session management with auto-refresh
```
### Example 2: Simple fix branch
```
Branch: fix/navbar-mobile
Base: main
Commits: 3
Generated message:
fix: Resolve navigation menu issues on mobile
- Fix hamburger menu not closing after selection
- Correct menu positioning on small screens
- Add smooth scroll behavior to anchor links
```