Initial commit

This commit is contained in:
Zhongwei Li
2025-11-30 08:55:53 +08:00
commit 9cf0a5ded9
5 changed files with 467 additions and 0 deletions

View File

@@ -0,0 +1,13 @@
{
"name": "git",
"description": "Git workflow automation tool with git-flow style commits, branch management, and automatic push.",
"version": "1.1.0",
"author": {
"name": "Kazuki Hashimoto",
"email": "setouchi.develop@gmail.com"
},
"commands": [
"./commands/commit.md",
"./commands/create-branch.md"
]
}

3
README.md Normal file
View File

@@ -0,0 +1,3 @@
# git
Git workflow automation tool with git-flow style commits, branch management, and automatic push.

175
commands/commit.md Normal file
View File

@@ -0,0 +1,175 @@
---
description: Analyze changes, create a git-flow style commit message, commit, and push to remote.
argument-hint: "[--no-push] [--scope <scope>] [--type <type>]"
allowed-tools: [Bash(git status:*), Bash(git diff:*), Bash(git add:*), Bash(git commit:*), Bash(git push:*), Bash(git branch:*), Bash(git log:*), Bash(git rev-parse:*)]
---
# Git Commit with Git-Flow Style
You are a Claude Code slash command that creates git-flow style commit messages and pushes changes to the remote repository. Follow the protocol below exactly, using only the allowed tools.
## Inputs
Parse the arguments provided to this command (`$ARGUMENTS`) and support these flags:
- `--no-push`: do not push after committing.
- `--scope <scope>`: optional scope for the commit message (e.g., "auth", "api", "ui").
- `--type <type>`: force a specific commit type instead of auto-detecting (e.g., "feat", "fix", "docs").
## Git-Flow Commit Types
Use these conventional commit types:
- `feat`: A new feature
- `fix`: A bug fix
- `docs`: Documentation only changes
- `style`: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
- `refactor`: A code change that neither fixes a bug nor adds a feature
- `perf`: A code change that improves performance
- `test`: Adding missing tests or correcting existing tests
- `chore`: Changes to the build process or auxiliary tools and libraries such as documentation generation
- `ci`: Changes to CI configuration files and scripts
## Protocol
### 1. Context Gathering
Use Bash to collect repository context:
- Current branch: `git branch --show-current`
- Working tree status: `git status --porcelain` and `git status -sb`
- Staged changes: `git diff --cached --stat`
- Unstaged changes: `git diff --stat`
- Recent commit messages: `git log --oneline -5` (to understand commit style)
### 2. Change Analysis
Analyze the changes to determine:
1. **Commit type**: Automatically detect based on files changed and diff content:
- New features → `feat`
- Bug fixes → `fix`
- Documentation changes (*.md, docs/, README) → `docs`
- Test files (*.test.*, *.spec.*, __tests__/) → `test`
- Configuration files (.github/, *.config.*, *.json) → `chore` or `ci`
- Refactoring without behavior change → `refactor`
- Performance improvements → `perf`
- Formatting only → `style`
2. **Scope**: Suggest a scope based on:
- Directory name (e.g., "packages/auth" → scope: "auth")
- Module name
- Feature area
- If scope is broad or unclear, omit it
3. **Subject**: Create a concise description (max 72 chars, imperative mood, no period at end)
4. **Body**: Optional detailed explanation (wrap at 72 chars):
- What was changed and why
- Important implementation details
- Breaking changes should be noted
### 3. Stage Unstaged Files
If there are unstaged changes:
1. Show the list of unstaged files
2. Ask the user which files to stage (or use `git add .` for all)
3. Stage the selected files using `git add`
### 4. Secret Scanning
Scan the staged diff for potential secrets:
- API keys (patterns like `AKIA`, `ghp_`, `sk-`, etc.)
- Private keys (BEGIN PRIVATE KEY, BEGIN RSA PRIVATE KEY)
- Tokens and passwords
- Environment files (.env) with sensitive data
If suspicious content is found:
- Show a warning with masked snippets
- Ask for confirmation to proceed
- Default to cancel if user doesn't explicitly confirm
### 5. Compose Commit Message
Create a commit message following git-flow format:
```
<type>(<scope>): <subject>
<body>
<footer>
```
Example:
```
feat(auth): add OAuth2 authentication flow
Implement OAuth2 authentication with Google and GitHub providers.
Add token refresh mechanism and session management.
Closes #123
```
**Present the commit message to the user and ask for confirmation or edits.**
### 6. Commit
Once confirmed:
1. Show the exact commit command
2. Execute: `git commit -m "<type>(<scope>): <subject>" -m "<body>" -m "<footer>"`
- If the message contains special characters, write to a temp file and use `git commit -F <file>`
3. Verify the commit was created: `git log -1 --oneline`
### 7. Push
If `--no-push` is NOT set:
1. Check if branch has upstream: `git rev-parse --abbrev-ref @{u} 2>/dev/null`
2. Show the push command you will run
3. Ask for confirmation
4. Execute:
- If no upstream: `git push -u origin <branch>`
- If upstream exists: `git push`
5. Report the result
## Output
Print a summary:
- Commit type and scope
- Commit message (first line)
- Files changed count
- Branch name
- Push status (if pushed)
If any step fails:
- Report the exact command and stderr
- Provide diagnosis and suggested fixes
- Do not proceed to the next step
## Examples
### Example 1: Feature with scope
```
Type: feat
Scope: api
Subject: add user profile endpoint
Body: Implement GET /api/users/:id endpoint with profile data
Footer: Closes #42
```
### Example 2: Bug fix without scope
```
Type: fix
Subject: prevent null pointer exception in auth handler
Body: Add null check before accessing user object properties
```
### Example 3: Documentation
```
Type: docs
Subject: update installation instructions in README
```
## Error Handling
- **No changes staged**: Prompt to stage files first
- **Merge conflict**: Report and ask user to resolve
- **Push rejected**: Suggest pull/rebase and retry
- **No remote**: Warn and skip push
- **Permission denied**: Check credentials and permissions

227
commands/create-branch.md Normal file
View File

@@ -0,0 +1,227 @@
---
description: Create a new git-flow style branch (feature/bugfix/hotfix/release) based on the task description.
argument-hint: "<task-description> [--base <branch>] [--no-push] [--type <type>]"
allowed-tools: [Bash(git status:*), Bash(git branch:*), Bash(git checkout:*), Bash(git switch:*), Bash(git rev-parse:*), Bash(git push:*), Bash(git fetch:*), Bash(git ls-remote:*), Bash(git pull:*)]
---
# Git-Flow Branch Creation
You are a Claude Code slash command that creates git-flow style branches based on task descriptions. Follow the protocol below exactly, using only the allowed tools.
## Git-Flow Branch Types
- `feature/`: New features or enhancements (e.g., `feature/user-authentication`)
- `bugfix/`: Bug fixes for the next release (e.g., `bugfix/login-error`)
- `hotfix/`: Critical fixes for production (e.g., `hotfix/security-patch`)
- `release/`: Release preparation (e.g., `release/v1.2.0`)
## Inputs
Parse the arguments provided to this command (`$ARGUMENTS`):
- **First argument (required)**: Task description text that will be used to generate the branch name
- `--base <branch>`: Base branch to branch from (default: detect from `main`, `master`, or `develop`)
- `--no-push`: Do not push the new branch to remote after creation
- `--type <type>`: Force a specific branch type (`feature`, `bugfix`, `hotfix`, `release`) instead of auto-detecting
**Example usage:**
```
/git:create-branch "add user authentication with OAuth2" --base develop
/git:create-branch "fix login page crash" --type bugfix
/git:create-branch "prepare v1.2.0 release" --no-push
```
## Protocol
### 1. Validate Repository State
Check the current repository state:
```bash
git status
git branch --show-current
```
- Ensure we are in a git repository
- Check for uncommitted changes (warn if present but don't block)
- Note the current branch
### 2. Detect Base Branch
If `--base` is not specified, detect the appropriate base branch:
```bash
git rev-parse --verify main 2>/dev/null || echo "not found"
git rev-parse --verify master 2>/dev/null || echo "not found"
git rev-parse --verify develop 2>/dev/null || echo "not found"
```
Priority order:
1. `develop` (if exists) - standard git-flow development branch
2. `main` (if exists)
3. `master` (if exists)
4. Current branch (as fallback)
### 3. Analyze Task Description
Analyze the task description to determine the branch type (if not forced with `--type`):
**Feature detection** (use `feature/`):
- Keywords: "add", "implement", "create", "new", "enhancement", "feature"
- Examples: "add user auth", "implement payment flow", "new dashboard"
**Bugfix detection** (use `bugfix/`):
- Keywords: "fix", "bug", "issue", "error", "problem", "crash", "broken"
- Examples: "fix login error", "resolve crash on startup"
**Hotfix detection** (use `hotfix/`):
- Keywords: "hotfix", "urgent", "critical", "security", "production", "emergency"
- Examples: "hotfix security vulnerability", "urgent fix for production crash"
**Release detection** (use `release/`):
- Keywords: "release", "version", "v\d+\.\d+", "prepare for release"
- Examples: "release v1.2.0", "prepare for v2.0 release"
**Default**: If unclear, use `feature/`
### 4. Generate Branch Name
Convert the task description into a valid, consistent branch name. Use the following deterministic sanitization rules so different implementations produce the same result:
1. Remove stopwords (English, minimal set): `the, a, an, and, or, but, for, to, with, in, on, at`.
2. Convert to lowercase.
3. Replace any character not `[a-z0-9-]` with a hyphen.
- Regex: `/[^a-z0-9-]+/g``-`
4. Collapse multiple hyphens into one.
- Regex: `/-+/g``-`
5. Trim leading/trailing hyphens.
- Regex: `/^-+|-+$/g` → ``
6. Limit to a reasonable length (e.g., 50 chars max) after the above steps.
Notes:
- This list of stopwords is intentionally small and stable to avoid unexpected removals. Teams may extend it, but should document additions to keep behavior predictable.
- Version-like strings (e.g., `v1.2.0`) will naturally become `v1-2-0` via step 3.
**Format**: `<type>/<descriptive-name>`
**Examples:**
- "Add user authentication with OAuth2" → `feature/add-user-authentication-oauth2`
- "Fix login page crash on mobile" → `bugfix/fix-login-page-crash-mobile`
- "Hotfix security vulnerability in API" → `hotfix/security-vulnerability-api`
- "Prepare v1.2.0 release" → `release/v1-2-0`
- "Implement the new UI in the app" → `feature/implement-new-ui-app` ("the", "in" removed; punctuation normalized)
### 5. Check Branch Existence
Check if the branch already exists locally or remotely:
```bash
git rev-parse --verify <branch-name> 2>/dev/null
git ls-remote --heads origin <branch-name> 2>/dev/null
```
If the branch exists:
- Show a warning
- Suggest an alternative name (append `-2`, `-v2`, or date suffix)
- Ask user for confirmation to use alternative or cancel
### 6. Create Branch
Present the plan to the user:
```
Branch creation plan:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Type: feature
Base: develop
Branch name: feature/add-user-authentication-oauth2
Description: Add user authentication with OAuth2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
This will:
1. Switch to base branch 'develop'
2. Pull latest changes from remote (if available)
3. Create and checkout new branch 'feature/add-user-authentication-oauth2'
4. Push to remote 'origin' (unless --no-push is specified)
Proceed? (yes/no)
```
Once confirmed:
1. Switch to base branch: `git checkout <base-branch>`
2. Pull latest changes: `git pull origin <base-branch>` (handle gracefully if remote doesn't exist)
3. Create and checkout new branch: `git checkout -b <branch-name>`
4. Verify creation: `git branch --show-current`
### 7. Push to Remote
If `--no-push` is NOT set:
1. Push with upstream tracking: `git push -u origin <branch-name>`
2. Verify push success
3. Report the result
If `--no-push` is set:
- Skip push
- Note that the branch is local only
## Output
Print a summary:
```
✓ Branch created successfully
Summary:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Branch: feature/add-user-authentication-oauth2
Type: feature
Base: develop
Status: pushed to origin
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
You are now on the new branch. Start working on:
"Add user authentication with OAuth2"
Next steps:
1. Make your changes
2. Commit with: /git:commit
3. Create PR when ready
```
## Error Handling
- **No task description provided**: Show usage and examples
- **Invalid base branch**: List available branches and ask user to specify
- **Branch already exists**: Suggest alternative name or offer to switch to existing
- **Uncommitted changes**: Warn but allow proceeding (git will handle conflicts)
- **Push failed**: Report error and suggest manual push command
- **Not a git repository**: Show clear error message
- **Network issues during pull/push**: Report and suggest manual retry
## Examples
### Example 1: Feature branch with auto-detection
```
Command: /git:create-branch "add user authentication"
Result: feature/add-user-authentication
```
### Example 2: Bugfix with explicit base
```
Command: /git:create-branch "fix login error" --base main
Result: bugfix/fix-login-error (from main)
```
### Example 3: Hotfix without push
```
Command: /git:create-branch "critical security patch" --type hotfix --no-push
Result: hotfix/critical-security-patch (local only)
```
### Example 4: Release branch
```
Command: /git:create-branch "prepare v1.2.0 release"
Result: release/v1-2-0
```
## Notes
- Branch names follow kebab-case convention
- Special characters are converted to hyphens
- Version numbers (v1.2.0) are converted to v1-2-0
- Long descriptions are truncated to keep branch names manageable
- The command is idempotent: if something fails, it's safe to retry

49
plugin.lock.json Normal file
View File

@@ -0,0 +1,49 @@
{
"$schema": "internal://schemas/plugin.lock.v1.json",
"pluginId": "gh:setouchi-h/cc-marketplace:packages/git",
"normalized": {
"repo": null,
"ref": "refs/tags/v20251128.0",
"commit": "eb625c87e711f7a354c8914fdbb64cef10c0dae1",
"treeHash": "f711aa6c00790ce9205b238ecc48dd77204d4e8ccc92ec3553a5eceb60cf4be9",
"generatedAt": "2025-11-28T10:28:16.325517Z",
"toolVersion": "publish_plugins.py@0.2.0"
},
"origin": {
"remote": "git@github.com:zhongweili/42plugin-data.git",
"branch": "master",
"commit": "aa1497ed0949fd50e99e70d6324a29c5b34f9390",
"repoRoot": "/Users/zhongweili/projects/openmind/42plugin-data"
},
"manifest": {
"name": "git",
"description": "Git workflow automation tool with git-flow style commits, branch management, and automatic push.",
"version": "1.1.0"
},
"content": {
"files": [
{
"path": "README.md",
"sha256": "bd4d416092aff1fd7d8355423927887610e39aaa5aa3750dd544e815fbeefdd7"
},
{
"path": ".claude-plugin/plugin.json",
"sha256": "b0fa4f79d563e2ce6e8aa3ea9df8deec7262c5d45611f1987eefa034e5e40001"
},
{
"path": "commands/create-branch.md",
"sha256": "e03f1f148f44ccd32d1c5205c05f7e2258bfff7d5f6b09bb455a2764fc68d4a3"
},
{
"path": "commands/commit.md",
"sha256": "2e371ba1e3ecbad14bb59c1e9c540842ef265f4a099c931b4f7ce8534f3ed423"
}
],
"dirSha256": "f711aa6c00790ce9205b238ecc48dd77204d4e8ccc92ec3553a5eceb60cf4be9"
},
"security": {
"scannedAt": null,
"scannerVersion": null,
"flags": []
}
}