Initial commit

This commit is contained in:
Zhongwei Li
2025-11-29 18:22:52 +08:00
commit ba1e6370e1
7 changed files with 399 additions and 0 deletions

View File

@@ -0,0 +1,14 @@
{
"name": "git-workflow",
"description": "Git and GitHub workflow commands for commits and pull requests",
"version": "1.0.0",
"author": {
"name": "David Lopes"
},
"skills": [
"./skills"
],
"commands": [
"./commands"
]
}

3
README.md Normal file
View File

@@ -0,0 +1,3 @@
# git-workflow
Git and GitHub workflow commands for commits and pull requests

39
commands/commit.md Normal file
View File

@@ -0,0 +1,39 @@
---
name: commit
description: Create git commits with user approval and no Claude attribution
---
# Committing Work
## Overview
**Core principle:** Analyze changes → Plan commits → Execute.
## The Process
**IMPORTANT:** use skill `committing-work` to learn how to draft good commit messages and how to organize commits.
### Step 1: Think about what changed
1. Review the conversation history and understand what was accomplished
2. Run `git status` to see current changes
3. Run `git diff` to understand the modifications
4. Consider whether changes should be one commit or multiple logical commits
### Step 2: Plan your commit(s)
1. Identify which files belong together
2. Draft clear, descriptive commit messages
3. Use imperative mood in commit messages
4. Focus on why the changes were made, not just what
### Step 3: Present your plan to the user
> **IMPORTANT** this step can be skipped if the user explicitely allowed.
1. List the files you plan to add for each commit
2. Show the commit message(s) you'll use
3. Ask: "I plan to create [N] commit(s) with these changes. Shall I proceed?"
### Step 4: Execute planned commits
1. Use `git add` with specific files (never use `-A` or `.`)
- Create commits with your planned messages
- Show the result with `git log --oneline -n [number]`

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

@@ -0,0 +1,38 @@
---
name: create-pr
description: Create a new branch, push to remote, and create a pull request on GitHub
---
You are helping create a GitHub pull request. Follow these steps:
**ASSUMPTIONS:**
- All changes are already committed locally
- The current branch is the one with the changes
**STEPS:**
1. **Analyze the commits:**
- Run `git log origin/main..HEAD` (or appropriate base branch) to see all commits that will be included
- Run `git diff origin/main...HEAD` to see the full diff
2. **Create a new branch:**
- Generate a descriptive branch name based on the changes (use kebab-case, e.g., `feature/add-user-auth` or `fix/memory-leak`)
- Create and checkout the new branch: `git checkout -b <branch-name>`
3. **Push to remote:**
- Push the new branch to origin with tracking: `git push -u origin <branch-name>`
4. **Create the pull request:**
- Analyze ALL commits (not just the latest) to understand the full scope of changes
- Generate a clear, concise title (max 72 characters) that describes what the PR does
- Create a PR body with:
- Brief summary of changes (2-3 sentences)
- Why these changes were made
- Any relevant context or notes
**IMPORTANT:**
- DO NOT use the TodoWrite tool
- Be concise and focused
- Return the PR URL when done
- If $ARGUMENTS is provided, use it as context or as the target base branch
- Use the GH cli tool to interact with GitHub

57
plugin.lock.json Normal file
View File

@@ -0,0 +1,57 @@
{
"$schema": "internal://schemas/plugin.lock.v1.json",
"pluginId": "gh:dnlopes/claude-code-plugins:git-workflow",
"normalized": {
"repo": null,
"ref": "refs/tags/v20251128.0",
"commit": "fcbf08c8665382b0d330d60945bd2de384d44090",
"treeHash": "1c22e0a6defd57c68d8b100f3099f335cf5ecc023f33f8d66768d698ce491fcf",
"generatedAt": "2025-11-28T10:16:32.266506Z",
"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-workflow",
"description": "Git and GitHub workflow commands for commits and pull requests",
"version": "1.0.0"
},
"content": {
"files": [
{
"path": "README.md",
"sha256": "73515100b8e49aaa69859daff7979e01e7e94f751d31aecb91549f294ba045d7"
},
{
"path": ".claude-plugin/plugin.json",
"sha256": "d1ced03ae936f2d2d3380daa3e30090c5b6184e8c72478413517082ca6b589a2"
},
{
"path": "commands/create-pr.md",
"sha256": "5057cada9774ce3eb0850f219d42b4d44d8e6411fb7c39dffdcdf1b803acfafd"
},
{
"path": "commands/commit.md",
"sha256": "2402876f3eb313ce8c56236ba6a33f4b230d6ada4aa6d719933cffd61ca49fbd"
},
{
"path": "skills/creating-pull-requests/SKILL.md",
"sha256": "74971c2a1a1a162d95fc9dd3ed2c32f7eb2366207e31dbf566ec354e7c2ebf20"
},
{
"path": "skills/committing-work/SKILL.md",
"sha256": "f4ca71ff698b535376c488fae63e0fa28dbaea11b02807dc8a4459226b896170"
}
],
"dirSha256": "1c22e0a6defd57c68d8b100f3099f335cf5ecc023f33f8d66768d698ce491fcf"
},
"security": {
"scannedAt": null,
"scannerVersion": null,
"flags": []
}
}

View File

@@ -0,0 +1,134 @@
---
name: committing-work
description: Use this skill before committing changes on the repository.
---
# Committing Work
## Overview
**Announce at start:** "🟢 I'm using the committing-work skill to complete this work."
## Key Principles
- **Commit message**: commit messages must be constructed based on the changes detected
- **Atomic commits**: Each commit should contain related changes that serve a single purpose
- **Split large changes**: If changes touch multiple concerns, split them into separate commits
- **Conventional commit format**: Use the format `<type>(<ticket>): <description>`:
- `<ticket>` section is optional
- `<type>` section is one of:
- `feat`: A new feature
- `fix`: A bug fix
- `docs`: Documentation changes
- `style`: Code style changes (formatting, etc)
- `refactor`: Code changes that neither fix bugs nor add features
- `perf`: Performance improvements
- `test`: Adding or fixing tests
- `chore`: Changes to the build process, tools, etc.
- **Present tense, imperative mood**: Write commit messages as commands (e.g., "add feature" not "added feature")
- **Ignore not relevant changes**: Changed files unrelated to the work done should be ignored (e.g., temporary files). If unsure, ask the user for guidance.
- **Concise first line**: Keep the first line under 72 characters
- **Use emojis**: Each commit type **MUST** be paired with an appropriate emoji:
-`feat`: New feature
- 🐛 `fix`: Bug fix
- 📝 `docs`: Documentation
- 💄 `style`: Formatting/style
- ♻️ `refactor`: Code refactoring
- ⚡️ `perf`: Performance improvements
-`test`: Tests
- 🔧 `chore`: Tooling, configuration
- 🚀 `ci`: CI/CD improvements
- 🗑️ `revert`: Reverting changes
- 🧪 `test`: Add a failing test
- 🚨 `fix`: Fix compiler/linter warnings
- 🔒️ `fix`: Fix security issues
- 👥 `chore`: Add or update contributors
- 🚚 `refactor`: Move or rename resources
- 🏗️ `refactor`: Make architectural changes
- 🔀 `chore`: Merge branches
- 📦️ `chore`: Add or update compiled files or packages
- `chore`: Add a dependency
- `chore`: Remove a dependency
- 🌱 `chore`: Add or update seed files
- 🧑‍💻 `chore`: Improve developer experience
- 🧵 `feat`: Add or update code related to multithreading or concurrency
- 🔍️ `feat`: Improve SEO
- 🏷️ `feat`: Add or update types
- 💬 `feat`: Add or update text and literals
- 🌐 `feat`: Internationalization and localization
- 👔 `feat`: Add or update business logic
- 📱 `feat`: Work on responsive design
- 🚸 `feat`: Improve user experience / usability
- 🩹 `fix`: Simple fix for a non-critical issue
- 🥅 `fix`: Catch errors
- 👽️ `fix`: Update code due to external API changes
- 🔥 `fix`: Remove code or files
- 🎨 `style`: Improve structure/format of the code
- 🚑️ `fix`: Critical hotfix
- 🎉 `chore`: Begin a project
- 🔖 `chore`: Release/Version tags
- 🚧 `wip`: Work in progress
- 💚 `fix`: Fix CI build
- 📌 `chore`: Pin dependencies to specific versions
- 👷 `ci`: Add or update CI build system
- 📈 `feat`: Add or update analytics or tracking code
- ✏️ `fix`: Fix typos
- ⏪️ `revert`: Revert changes
- 📄 `chore`: Add or update license
- 💥 `feat`: Introduce breaking changes
- 🍱 `assets`: Add or update assets
- ♿️ `feat`: Improve accessibility
- 💡 `docs`: Add or update comments in source code
- 🗃️ `db`: Perform database related changes
- 🔊 `feat`: Add or update logs
- 🔇 `fix`: Remove logs
- 🤡 `test`: Mock things
- 🥚 `feat`: Add or update an easter egg
- 🙈 `chore`: Add or update .gitignore file
- 📸 `test`: Add or update snapshots
- ⚗️ `experiment`: Perform experiments
- 🚩 `feat`: Add, update, or remove feature flags
- 💫 `ui`: Add or update animations and transitions
- ⚰️ `refactor`: Remove dead code
- 🦺 `feat`: Add or update code related to validation
- ✈️ `feat`: Improve offline support
### Guidelines for Splitting Commits
When analyzing the diff, consider splitting commits based on these criteria:
1. **Different concerns**: Changes to unrelated parts of the codebase
2. **Different types of changes**: Mixing features, fixes, refactoring, etc.
3. **File patterns**: Changes to different types of files (e.g., source code vs documentation)
4. **Logical grouping**: Changes that would be easier to understand or review separately
6. **Size**: Very large changes that would be clearer if broken down
### Examples
Good commit messages:
- ✨ feat: add user authentication system
- 🐛 fix: resolve memory leak in rendering process
- 📝 docs: update API documentation with new endpoints
- ♻️ refactor: simplify error handling logic in parser
- 🚨 fix: resolve linter warnings in component files
- 🧑‍💻 chore: improve developer tooling setup process
- 👔 feat: implement business logic for transaction validation
- 🩹 fix: address minor styling inconsistency in header
- 🚑️ fix: patch critical security vulnerability in auth flow
- 🎨 style: reorganize component structure for better readability
- 🔥 fix: remove deprecated legacy code
- 🦺 feat: add input validation for user registration form
- 💚 fix: resolve failing CI pipeline tests
- 📈 feat: implement analytics tracking for user engagement
- 🔒️ fix: strengthen authentication password requirements
- ♿️ feat: improve form accessibility for screen readers
Example of splitting commits:
- First commit: ✨ feat: add new solc version type definitions
- Second commit: 📝 docs: update documentation for new solc versions
- Third commit: 🔧 chore: update package.json dependencies
- Fourth commit: 🏷️ feat: add type definitions for new API endpoints
- Fifth commit: 🧵 feat: improve concurrency handling in worker threads
- Sixth commit: 🚨 fix: resolve linting issues in new code
- Seventh commit: ✅ test: add unit tests for new solc version features
- Eighth commit: 🔒️ fix: update dependencies with security vulnerabilities

View File

@@ -0,0 +1,114 @@
---
name: creating-pull-requests
description: Use this skill before creating pull requests
---
# Committing Work
## Overview
**Announce at start:** "🟢 I'm using the creating-pull-requests skill to complete this work."
## Key Principles
- Pull-request titles must follow all the commit message rules as described in skill `committing-work`
- **Conventional commit format**: Use the format `<type>(<ticket>): <description>`:
- `<ticket>` section is optional
- `<type>` section is one of:
- `feat`: A new feature
- `fix`: A bug fix
- `docs`: Documentation changes
- `style`: Code style changes (formatting, etc)
- `refactor`: Code changes that neither fix bugs nor add features
- `perf`: Performance improvements
- `test`: Adding or fixing tests
- `chore`: Changes to the build process, tools, etc.
- **Language**: Always use English for PR titles and descriptions
- **Use emojis**: Each commit type **MUST** be paired with an appropriate emoji:
-`feat`: New feature
- 🐛 `fix`: Bug fix
- 📝 `docs`: Documentation
- 💄 `style`: Formatting/style
- ♻️ `refactor`: Code refactoring
- ⚡️ `perf`: Performance improvements
-`test`: Tests
- 🔧 `chore`: Tooling, configuration
- 🚀 `ci`: CI/CD improvements
- 🗑️ `revert`: Reverting changes
- 🧪 `test`: Add a failing test
- 🚨 `fix`: Fix compiler/linter warnings
- 🔒️ `fix`: Fix security issues
- 👥 `chore`: Add or update contributors
- 🚚 `refactor`: Move or rename resources
- 🏗️ `refactor`: Make architectural changes
- 🔀 `chore`: Merge branches
- 📦️ `chore`: Add or update compiled files or packages
- `chore`: Add a dependency
- `chore`: Remove a dependency
- 🌱 `chore`: Add or update seed files
- 🧑‍💻 `chore`: Improve developer experience
- 🧵 `feat`: Add or update code related to multithreading or concurrency
- 🔍️ `feat`: Improve SEO
- 🏷️ `feat`: Add or update types
- 💬 `feat`: Add or update text and literals
- 🌐 `feat`: Internationalization and localization
- 👔 `feat`: Add or update business logic
- 📱 `feat`: Work on responsive design
- 🚸 `feat`: Improve user experience / usability
- 🩹 `fix`: Simple fix for a non-critical issue
- 🥅 `fix`: Catch errors
- 👽️ `fix`: Update code due to external API changes
- 🔥 `fix`: Remove code or files
- 🎨 `style`: Improve structure/format of the code
- 🚑️ `fix`: Critical hotfix
- 🎉 `chore`: Begin a project
- 🔖 `chore`: Release/Version tags
- 🚧 `wip`: Work in progress
- 💚 `fix`: Fix CI build
- 📌 `chore`: Pin dependencies to specific versions
- 👷 `ci`: Add or update CI build system
- 📈 `feat`: Add or update analytics or tracking code
- ✏️ `fix`: Fix typos
- ⏪️ `revert`: Revert changes
- 📄 `chore`: Add or update license
- 💥 `feat`: Introduce breaking changes
- 🍱 `assets`: Add or update assets
- ♿️ `feat`: Improve accessibility
- 💡 `docs`: Add or update comments in source code
- 🗃️ `db`: Perform database related changes
- 🔊 `feat`: Add or update logs
- 🔇 `fix`: Remove logs
- 🤡 `test`: Mock things
- 🥚 `feat`: Add or update an easter egg
- 🙈 `chore`: Add or update .gitignore file
- 📸 `test`: Add or update snapshots
- ⚗️ `experiment`: Perform experiments
- 🚩 `feat`: Add, update, or remove feature flags
- 💫 `ui`: Add or update animations and transitions
- ⚰️ `refactor`: Remove dead code
- 🦺 `feat`: Add or update code related to validation
- ✈️ `feat`: Improve offline support
- Use GitHub CLI to create pull-requests:
```bash
gh pr create --base main --head <branch> --title "<pr-title>" --body "<pr-body>"
```
### Examples
Good pull request titles:
- ✨ feat: add user authentication system
- 🐛 fix: resolve memory leak in rendering process
- 📝 docs: update API documentation with new endpoints
- ♻️ refactor: simplify error handling logic in parser
- 🚨 fix: resolve linter warnings in component files
- 🧑‍💻 chore: improve developer tooling setup process
- 👔 feat: implement business logic for transaction validation
- 🩹 fix: address minor styling inconsistency in header
- 🚑️ fix: patch critical security vulnerability in auth flow
- 🎨 style: reorganize component structure for better readability
- 🔥 fix: remove deprecated legacy code
- 🦺 feat: add input validation for user registration form
- 💚 fix: resolve failing CI pipeline tests
- 📈 feat: implement analytics tracking for user engagement
- 🔒️ fix: strengthen authentication password requirements
- ♿️ feat: improve form accessibility for screen readers