Initial commit
This commit is contained in:
14
.claude-plugin/plugin.json
Normal file
14
.claude-plugin/plugin.json
Normal 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
3
README.md
Normal file
@@ -0,0 +1,3 @@
|
||||
# git-workflow
|
||||
|
||||
Git and GitHub workflow commands for commits and pull requests
|
||||
39
commands/commit.md
Normal file
39
commands/commit.md
Normal 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
38
commands/create-pr.md
Normal 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
57
plugin.lock.json
Normal 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": []
|
||||
}
|
||||
}
|
||||
134
skills/committing-work/SKILL.md
Normal file
134
skills/committing-work/SKILL.md
Normal 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
|
||||
114
skills/creating-pull-requests/SKILL.md
Normal file
114
skills/creating-pull-requests/SKILL.md
Normal 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
|
||||
Reference in New Issue
Block a user