zhongwei/gh-yanmxa-cc-plugins-plugins-git
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 09:07:33 +08:00
commit 105ed85fd0
14 changed files with 1397 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

35
commands/commit-push.md Normal file
View File

@@ -0,0 +1,35 @@
---
argument-hint: "[--no-push] or leave empty to commit and push"
description: "Commit changes with sign-off and push to origin by default"
allowed-tools: [Bash]
---
Commit staged and unstaged changes with proper sign-off, and push to origin branch by default.
## Implementation Steps
1. **Check Repository Status**: Run git status and git diff to review changes that will be committed
2. **Review Recent Commits**: Check git log to follow existing commit message style
3. **Stage and Commit Changes**: Add relevant files and create signed commit with descriptive message following conventional format
4. **Push to Origin** (unless --no-push specified): Push committed changes to the current origin branch
## Usage Examples
- `/git:commit-push` - Commit with sign-off and push to origin (default)
- `/git:commit-push --no-push` - Commit with sign-off only, skip push
## Implementation Details
The command will:
- Analyze changes with `git status` and `git diff`
- Check recent commits with `git log --oneline -5` for style consistency
- Stage relevant modified and new files (avoiding unnecessary config files)
- Create commit with `-s` flag for sign-off and conventional format
- Push to origin by default unless `--no-push` parameter is provided
## Notes
- Follows conventional commit format with descriptive messages
- Always includes sign-off as per user preferences
- Avoids staging unnecessary files like configuration files
- Verifies commit success before push (unless disabled with --no-push)
- Respects current branch for push operations

23
commands/compact-commits.md Normal file
View File

@@ -0,0 +1,23 @@
---
argument-hint: [pr_number]
description: Compact all commits in a GitHub PR into a single commit with comprehensive message and DCO sign-off
allowed-tools: [Bash]
---
Compact multiple commits in a GitHub Pull Request into a single commit while preserving all changes and creating a comprehensive commit message with proper DCO sign-off.
## Implementation Steps
1. **Examine PR Structure**: View the PR details and commit history to understand what needs to be compacted using `gh pr view $1`
2. **Checkout PR Branch**: Switch to the PR branch using `gh pr checkout $1` to work with the commits locally
3. **Compact Commits**: Use `git reset --soft HEAD~N` (where N is number of commits) to stage all changes from multiple commits, then create a single comprehensive commit with `git commit --signoff`
4. **Force Push Update**: Push the compacted commit back to the PR branch using `git push --force-with-lease` to update the remote PR
5. **Verify Results**: Confirm the PR now shows only one commit with all the original changes preserved and proper DCO sign-off
## Notes
- This command is useful for cleaning up PR history before merging
- Preserves all code changes while creating a clean, single commit
- Includes DCO sign-off required by many projects
- The comprehensive commit message includes all relevant details from the original commits
- Uses `--force-with-lease` for safer force pushing
- Works with any GitHub repository that has PR access

77
commands/create-pr.md Normal file
View File

@@ -0,0 +1,77 @@
# Create PR to $ARGUMENTS
Create a pull request following Git best practices:
## Steps:
1. **Sync & Branch**: Update main + create feature branch with appropriate prefix
2. **Commit**: Stage relevant files + commit with conventional message and sign-off
3. **Push & PR**: Push branch + create ready PR with detailed description
## Target:
- If $ARGUMENTS provided: use as target repo/branch
- If empty: default to upstream/main
## Commands to execute:
```bash
# Set target
TARGET=${ARGUMENTS:-upstream/main}
# 1. Sync & Branch
CURRENT_BRANCH=$(git branch --show-current)
if [[ "$CURRENT_BRANCH" == "main" || "$CURRENT_BRANCH" == "master" ]]; then
# Sync with upstream first
git fetch origin
git pull origin main
# Create feature branch with prefix
# Choose: feature/, fix/, docs/, chore/, refactor/, test/
git checkout -b feature/descriptive-name
fi
# 2. Stage & Commit with conventional format
git add path/to/relevant/files
git commit -s -m "feat: descriptive title
Detailed description of what and why this change is made.
- List specific changes
- Reference issue numbers if applicable"
# 3. Push & Create PR
git push -u origin $(git branch --show-current)
gh pr create --base ${TARGET#*/} --title "Title" --body "$(cat <<'EOF'
## Summary
Brief description of the change and its purpose
## Changes
- Specific change 1
- Specific change 2
- Reference any related issues
## Test plan
- [ ] Unit tests pass
- [ ] Integration tests pass
- [ ] Manual testing completed
- [ ] Documentation updated if needed
## Checklist
- [ ] Code follows project conventions
- [ ] Tests added/updated
- [ ] Documentation updated
- [ ] Breaking changes documented
🤖 Generated with [Claude Code](https://claude.ai/code)
EOF
)"
```
## Conventional Commit Types:
- **feat**: New features
- **fix**: Bug fixes
- **docs**: Documentation changes
- **style**: Code style changes (formatting, etc.)
- **refactor**: Code refactoring
- **test**: Adding/updating tests
- **chore**: Maintenance tasks

57
commands/create-worktree.md Normal file
View File

@@ -0,0 +1,57 @@
---
argument-hint: [worktree-name-or-description] [source-branch] [--cursor|--code|--tmux]
description: Create a git worktree with intelligent naming and branch creation
allowed-tools: [Bash, TodoWrite]
---
Creates a new git worktree with automatic naming conventions and branch management. Supports optional parameters for customization and integration with editors/tmux.
## Implementation Steps
1. **Plan Worktree Creation**: Create todo list to track worktree creation and navigation tasks
2. **Parse Arguments**:
- Check if arguments contain `--cursor`, `--code`, or `--tmux` flags
- Extract worktree name/description from remaining arguments (filter out flags)
- Extract source branch if provided (second non-flag argument)
3. **Determine Worktree Configuration**:
- If worktree name provided: Use as worktree name/description to generate appropriate directory name and branch name
- If not provided: Analyze current git status and staged changes to auto-generate meaningful worktree and branch names
- Use source branch if provided, otherwise default to current branch
4. **Create Worktree with Smart Naming**:
- Generate worktree directory using format: `../project-name__feature-name` (double underscore separator)
- Create new branch with descriptive name based on the worktree purpose
- Use command: `git worktree add ../worktree-directory -b branch-name source-branch`
5. **Open in Editor/Terminal** (if flag specified):
- If `--cursor` flag: Run `cursor <worktree-absolute-path>` to open in Cursor editor
- If `--code` flag: Run `code <worktree-absolute-path>` to open in VS Code
- If `--tmux` flag: Run `tmux split-window -h -c <worktree-absolute-path>` to split pane in current tmux session and cd to worktree
- If no flag: Skip this step
6. **Complete Task Tracking**: Mark all todo items as completed
## Notes
- Uses double underscore (`__`) separator between project name and feature name for clear visual distinction
- Automatically handles branch name conflicts by generating unique names
- If no parameters provided, analyzes git diff and status to suggest appropriate names
- Worktree is created in parent directory to avoid conflicts with current repository
- Source branch defaults to current branch if not specified
## Editor/Terminal Integration
- `--cursor`: Opens the worktree in Cursor editor after creation
- `--code`: Opens the worktree in VS Code after creation
- `--tmux`: Creates a horizontal split pane in current tmux session and navigates to worktree
- Flags can be placed anywhere in the command arguments
- Only one editor/terminal flag should be used at a time
## Usage Examples
- `/git:create-worktree integration-logs` - Creates worktree for integration log work
- `/git:create-worktree "fix auth bug" develop` - Creates worktree from develop branch for auth fix
- `/git:create-worktree` - Auto-generates name based on current changes
- `/git:create-worktree fix-e2e --cursor` - Creates worktree and opens in Cursor editor
- `/git:create-worktree "add feature" --code` - Creates worktree and opens in VS Code
- `/git:create-worktree refactor develop --tmux` - Creates worktree from develop and opens in new tmux pane
- `/git:create-worktree --cursor bug-fix` - Creates worktree and opens in Cursor (flag can be anywhere)

118
commands/rebase-pr.md Normal file
View File

@@ -0,0 +1,118 @@
---
argument-hint: [pr_number] [remote] - PR number (optional, defaults to all PRs) and remote name (optional, defaults to PR's target remote)
description: Rebase a PR or all open PRs against their target base branch and force push updates
allowed-tools: [Bash, TodoWrite, Read, Edit]
---
Rebase a pull request against its target base branch (from the PR's merge target) and force push the updates. If no PR number is specified, rebases all open PRs.
## Usage
### Rebase All Open PRs
```bash
/git:rebase-pr [remote]
```
### Rebase Single PR
```bash
/git:rebase-pr <pr_number> [remote]
```
## Implementation Steps
### Determine Mode
1. **Parse Arguments**: Check if first argument is a PR number or a remote name
- If first argument is numeric: Single PR mode
- If first argument is non-numeric or empty: Batch mode (all PRs)
- Extract remote name from appropriate position (optional)
### Single PR Mode (when pr_number is provided)
1. **Get PR Information**: Use `gh pr view <pr_number> --json baseRefName,headRepository,isCrossRepository` to get:
- `baseRefName`: The target branch this PR will merge into (e.g., "main", "develop")
- `headRepository`: The source repository info
- `isCrossRepository`: Whether this is a fork PR
2. **Determine Remote and Base Branch**:
- If `remote` argument is provided: Use `<remote>/<baseRefName>`
- If PR is cross-repository (fork): Use `upstream/<baseRefName>`
- Otherwise: Use `origin/<baseRefName>`
3. **Fetch Latest Changes**: Run `git fetch <remote>` to ensure we have the latest commits from the target remote
4. **Checkout PR Branch**: Switch to the PR branch using `gh pr checkout <pr_number>`
5. **Rebase Against Target Base**: Rebase current branch against `<remote>/<baseRefName>`
6. **Handle Conflicts**: If conflicts occur, stop and report to user for manual resolution
7. **Force Push Updates**: Push the rebased branch with `--force-with-lease` to update the PR safely
### Batch Mode (when no pr_number is provided)
1. **Create Todo List**: Create a todo list to track all PRs that need rebasing
2. **List All Open PRs**: Use `gh pr list --author "@me" --state open --json number,headRefName,baseRefName,isCrossRepository` to get all user's open PRs with their target branches
3. **Check Worktrees**: Use `git worktree list` to identify which PRs are in worktrees vs main directory
4. **Process Each PR Sequentially**:
- Update todo status to "in_progress" for current PR
- Get PR's `baseRefName` and `isCrossRepository` from the PR list
- Determine remote: Use provided remote, or `upstream` for forks, or `origin` for same-repo PRs
- Fetch latest changes: `git fetch <remote>`
- For worktree branches: Navigate to worktree directory and run `git rebase <remote>/<baseRefName>`
- For non-worktree branches: Use `gh pr checkout <pr_number>` then rebase against `<remote>/<baseRefName>`
- If rebase succeeds and branch is up-to-date: Mark as completed, continue to next PR
- If rebase succeeds with changes: Force push with `--force-with-lease`, mark as completed
- If rebase has conflicts:
- Read the conflicted files
- Resolve conflicts using Edit tool
- Stage resolved files with `git add`
- Continue rebase with `git rebase --continue`
- Force push after successful resolution
- Mark PR as completed in todo list
- Handle push failures (e.g., network issues) with retry logic
5. **Summary Report**: Display final status of all PRs (success/failed/skipped)
## Parameters
- `pr_number`: The GitHub PR number to rebase (optional, if not provided will rebase all open PRs)
- `remote`: The remote name to fetch and rebase against (optional, defaults to `upstream` for fork PRs or `origin` for same-repo PRs)
## Examples
```bash
# Rebase all open PRs against their target branches (auto-detects upstream/origin)
/git:rebase-pr
# Rebase all open PRs, explicitly using upstream remote
/git:rebase-pr upstream
# Rebase all open PRs using origin remote
/git:rebase-pr origin
# Rebase single PR #2067 against its target branch (auto-detects remote)
/git:rebase-pr 2067
# Rebase single PR #2067 using upstream remote
/git:rebase-pr 2067 upstream
# Rebase single PR #2067 using origin remote
/git:rebase-pr 2067 origin
```
## Notes
- **Automatic Mode Detection**: The command automatically detects whether to rebase a single PR or all PRs based on whether a numeric PR number is provided
- **Target Branch Detection**: Each PR is rebased against its actual target branch (from `baseRefName`) rather than a hardcoded branch. For example:
- PR targeting `main` → rebases against `upstream/main` or `origin/main`
- PR targeting `develop` → rebases against `upstream/develop` or `origin/develop`
- PR targeting `release-1.0` → rebases against `upstream/release-1.0` or `origin/release-1.0`
- **Remote Selection**:
- For fork PRs (`isCrossRepository: true`): Defaults to `upstream` remote
- For same-repo PRs: Defaults to `origin` remote
- User can override by providing explicit remote name
- **Conflict Handling**: When conflicts occur in batch mode, the tool will attempt to resolve simple conflicts automatically using the Edit tool. For complex conflicts, it will stop and ask user for guidance
- **Worktree Support**: The command automatically detects and handles PRs in git worktrees by navigating to the worktree directory before rebasing
- **Force Push Safety**: Uses `--force-with-lease` for safer force pushing that prevents overwriting unexpected changes
- **Todo Tracking**: Uses TodoWrite tool to track progress when rebasing multiple PRs
- **Network Issues**: If push fails due to network issues, the command will retry once before reporting failure
- **Skip Up-to-date PRs**: PRs that are already up-to-date with the base branch are quickly marked as completed without requiring a push
- **Prerequisites**:
- GitHub CLI (`gh`) must be authenticated
- Must have appropriate permissions to push to PR branch
- The appropriate remote (`upstream` or `origin`) must be configured
- **Sign-off**: Remember to sign-off commits if making any new commits during the conflict resolution process

49
commands/review-pr.md Normal file
View File

@@ -0,0 +1,49 @@
# Review PR $ARGUMENTS
```bash
# Show open PRs if no argument
[[ -z "$ARGUMENTS" ]] && gh pr list --state open && exit 0
PR_NUMBER="$ARGUMENTS"
REPO_INFO=$(gh repo view --json owner,name --jq '.owner.login + "/" + .name')
COMMIT_SHA=$(gh api repos/$REPO_INFO/pulls/$PR_NUMBER --jq '.head.sha')
# Quick overview
gh pr view $PR_NUMBER
gh pr checks $PR_NUMBER
gh pr diff $PR_NUMBER
```
## What to Look For
🔒 **Security first**: Auth, input validation, secrets, injection attacks
🐛 **Logic bugs**: Edge cases, race conditions, error handling
🏗️ **Code quality**: Patterns, duplication, naming, complexity
~~ 🧪 **Tests**: Coverage, meaningful scenarios, integration tests ~~
📝 **Docs**: Clear code, comments where needed, breaking changes
## Leave Comments
**For issues (blocking):**
```bash
gh api repos/$REPO_INFO/pulls/$PR_NUMBER/comments --method POST \
--field body="🔒 Security risk: [issue]. Fix: [solution]" \
--field commit_id="$COMMIT_SHA" --field path="file.js" --field line=42 --field side="RIGHT"
```
**For suggestions:**
```bash
gh api repos/$REPO_INFO/pulls/$PR_NUMBER/comments --method POST \
--field body="💡 Consider [improvement] for [benefit]" \
--field commit_id="$COMMIT_SHA" --field path="file.js" --field line=42 --field side="RIGHT"
```
## Final Decision
```bash
# Block it
gh pr review $PR_NUMBER --request-changes --body "Security/bug issues found"
# Ship it
gh pr review $PR_NUMBER --approve --body "LGTM"
```