Initial commit
This commit is contained in:
Zhongwei Li
0
skills/.gitkeep
Normal file
0
skills/.gitkeep
Normal file
136
skills/commit-writer/SKILL.md
Normal file
136
skills/commit-writer/SKILL.md
Normal file
@@ -0,0 +1,136 @@
|
||||
---
|
||||
name: commit-writer
|
||||
description: Expert at crafting clear, meaningful git commit messages following conventional commit standards and repository conventions. Use when user asks to create commit messages, write commits, or needs help with git commit text. Analyzes git diffs and repository history to generate contextual, well-structured commit messages.
|
||||
allowed-tools: [Bash, Read, Grep, Glob]
|
||||
---
|
||||
|
||||
# Commit Message Writer
|
||||
|
||||
You are an expert at writing clear, meaningful, and conventional git commit messages.
|
||||
|
||||
## Core Principles
|
||||
|
||||
1. **Clarity over Cleverness**: Messages should clearly explain WHAT changed and WHY
|
||||
2. **Conventional Commits**: Follow the Conventional Commits specification by default
|
||||
3. **Repository Style**: Adapt to the existing commit message style in the repository
|
||||
4. **Atomic Focus**: Each commit should represent one logical change
|
||||
5. **Context-Aware**: Use git history and diffs to inform message content
|
||||
|
||||
## Process
|
||||
|
||||
When asked to write a commit message:
|
||||
|
||||
1. **Analyze the Changes**
|
||||
- Run `git status` to see what files are staged
|
||||
- Run `git diff --staged` to see the actual changes
|
||||
- Run `git log --oneline -10` to understand repository commit style
|
||||
|
||||
2. **Determine Commit Type**
|
||||
Use conventional commit types:
|
||||
- `feat`: New feature
|
||||
- `fix`: Bug fix
|
||||
- `docs`: Documentation only
|
||||
- `style`: Code style/formatting (no logic change)
|
||||
- `refactor`: Code restructuring (no behavior change)
|
||||
- `perf`: Performance improvement
|
||||
- `test`: Adding or updating tests
|
||||
- `build`: Build system or dependencies
|
||||
- `ci`: CI/CD configuration
|
||||
- `chore`: Maintenance tasks
|
||||
|
||||
3. **Structure the Message**
|
||||
```
|
||||
<type>(<scope>): <short summary>
|
||||
|
||||
<body - optional but recommended>
|
||||
|
||||
<footer - optional>
|
||||
```
|
||||
|
||||
4. **Follow These Rules**
|
||||
- **Subject line**: 50-72 characters max, imperative mood ("add" not "added")
|
||||
- **Body**: Wrap at 72 characters, explain WHY and provide context
|
||||
- **Separate** subject from body with blank line
|
||||
- **No period** at end of subject line
|
||||
- **Capitalize** first letter of subject
|
||||
|
||||
## Examples
|
||||
|
||||
### Good Commit Messages
|
||||
|
||||
```
|
||||
feat(auth): add JWT refresh token rotation
|
||||
|
||||
Implements automatic refresh token rotation to improve security.
|
||||
Tokens now expire after 15 minutes and are rotated on each refresh.
|
||||
Includes Redis storage for token blacklisting.
|
||||
|
||||
Closes #234
|
||||
```
|
||||
|
||||
```
|
||||
fix(api): prevent race condition in user creation
|
||||
|
||||
The previous implementation didn't properly lock during user
|
||||
creation, leading to duplicate users under high load. Added
|
||||
database-level unique constraint and proper error handling.
|
||||
```
|
||||
|
||||
```
|
||||
refactor(database): extract query builder to separate module
|
||||
|
||||
Improves maintainability by separating query building logic
|
||||
from repository classes. No functional changes.
|
||||
```
|
||||
|
||||
### Poor Commit Messages (Avoid These)
|
||||
|
||||
```
|
||||
❌ "fixed stuff"
|
||||
❌ "WIP"
|
||||
❌ "updates"
|
||||
❌ "changed files"
|
||||
❌ "Fixed bug" (not imperative, no context)
|
||||
```
|
||||
|
||||
## Scope Guidelines
|
||||
|
||||
Scopes should be specific but not too granular:
|
||||
- ✅ `(auth)`, `(database)`, `(api)`, `(ui/dashboard)`
|
||||
- ❌ `(file123)`, `(bugfix)`, `(code)`
|
||||
|
||||
## Special Cases
|
||||
|
||||
### Multiple Changes
|
||||
If changes span multiple concerns, consider suggesting separate commits:
|
||||
"I notice these changes address both authentication and logging. Would you like to split these into separate commits?"
|
||||
|
||||
### Breaking Changes
|
||||
Add `BREAKING CHANGE:` footer to indicate breaking changes:
|
||||
```
|
||||
feat(api): change user endpoint response format
|
||||
|
||||
BREAKING CHANGE: User API now returns `userId` instead of `id`
|
||||
```
|
||||
|
||||
### Repository Style Adaptation
|
||||
If repository uses different conventions (e.g., emojis, different format), detect this from `git log` and adapt accordingly.
|
||||
|
||||
## Output Format
|
||||
|
||||
Present the commit message in a code block for easy copying:
|
||||
|
||||
```
|
||||
Your suggested commit message here
|
||||
```
|
||||
|
||||
Then offer to create the commit directly or ask if adjustments are needed.
|
||||
|
||||
## Tools Usage
|
||||
|
||||
- Use `Bash` for git commands (`git status`, `git diff`, `git log`)
|
||||
- Use `Read` if you need to examine specific changed files for context
|
||||
- Use `Grep` to search for related code patterns if needed
|
||||
- Use `Glob` to understand file structure if scope is unclear
|
||||
|
||||
Remember: A great commit message helps future developers (including the author) understand the history and reasoning behind changes.
|
||||
243
skills/commit-writer/examples.md
Normal file
243
skills/commit-writer/examples.md
Normal file
@@ -0,0 +1,243 @@
|
||||
# Commit Message Examples
|
||||
|
||||
## Feature Commits
|
||||
|
||||
### Adding New Functionality
|
||||
|
||||
```
|
||||
feat(payments): integrate Stripe payment processing
|
||||
|
||||
Add complete Stripe integration including:
|
||||
- Payment intent creation and confirmation
|
||||
- Webhook handling for payment events
|
||||
- Customer portal for subscription management
|
||||
- Proper error handling and retry logic
|
||||
|
||||
Includes comprehensive tests and documentation.
|
||||
|
||||
Refs: #156
|
||||
```
|
||||
|
||||
```
|
||||
feat(search): implement full-text search with Elasticsearch
|
||||
|
||||
Users can now search across all content types with:
|
||||
- Fuzzy matching for typo tolerance
|
||||
- Faceted filtering by category and date
|
||||
- Highlighting of matched terms
|
||||
- Pagination of results
|
||||
|
||||
Performance tested with 1M+ documents.
|
||||
```
|
||||
|
||||
## Bug Fixes
|
||||
|
||||
### Critical Bugs
|
||||
|
||||
```
|
||||
fix(auth): resolve session hijacking vulnerability
|
||||
|
||||
Previous implementation stored session tokens in localStorage,
|
||||
making them accessible to XSS attacks. Moved to httpOnly
|
||||
cookies with SameSite=Strict.
|
||||
|
||||
SECURITY: All users should rotate tokens after deployment.
|
||||
```
|
||||
|
||||
### Standard Bugs
|
||||
|
||||
```
|
||||
fix(ui): correct date picker timezone handling
|
||||
|
||||
Dates were being converted to UTC incorrectly, causing
|
||||
off-by-one-day errors for users in certain timezones.
|
||||
Now preserves local timezone throughout the selection flow.
|
||||
|
||||
Fixes #423, #467
|
||||
```
|
||||
|
||||
## Refactoring
|
||||
|
||||
```
|
||||
refactor(api): migrate from Express to Fastify
|
||||
|
||||
Improves request throughput by ~40% in benchmarks.
|
||||
All endpoints maintain backward compatibility.
|
||||
Updated tests and documentation to reflect new framework.
|
||||
|
||||
Migration guide: docs/fastify-migration.md
|
||||
```
|
||||
|
||||
```
|
||||
refactor(models): extract validation logic to JSON Schema
|
||||
|
||||
Removes ~500 lines of manual validation code.
|
||||
Validation is now declarative and generates API docs automatically.
|
||||
No changes to validation behavior.
|
||||
```
|
||||
|
||||
## Documentation
|
||||
|
||||
```
|
||||
docs(api): add OpenAPI 3.0 specification
|
||||
|
||||
Complete API documentation in OpenAPI format with:
|
||||
- All endpoints documented
|
||||
- Request/response schemas
|
||||
- Authentication flows
|
||||
- Example requests
|
||||
|
||||
Available at /api/docs
|
||||
```
|
||||
|
||||
## Performance
|
||||
|
||||
```
|
||||
perf(database): add indexes for common query patterns
|
||||
|
||||
Analysis of slow query log revealed missing indexes on:
|
||||
- users.email
|
||||
- orders.created_at
|
||||
- products.category_id
|
||||
|
||||
Reduces average query time from 250ms to 12ms.
|
||||
```
|
||||
|
||||
## Chores and Maintenance
|
||||
|
||||
```
|
||||
chore(deps): upgrade React from 17 to 18
|
||||
|
||||
Update React and React DOM to version 18.2.0.
|
||||
All components tested with new concurrent rendering.
|
||||
No breaking changes required in application code.
|
||||
```
|
||||
|
||||
```
|
||||
chore(ci): add automated dependency security scanning
|
||||
|
||||
Configure Dependabot to check for vulnerabilities weekly
|
||||
and create PRs for security updates automatically.
|
||||
```
|
||||
|
||||
## Test Commits
|
||||
|
||||
```
|
||||
test(auth): add integration tests for OAuth flow
|
||||
|
||||
Covers complete OAuth authentication flow:
|
||||
- Authorization code exchange
|
||||
- Token refresh
|
||||
- Revocation
|
||||
- Error scenarios
|
||||
|
||||
Achieves 100% coverage of auth service.
|
||||
```
|
||||
|
||||
## Build and CI
|
||||
|
||||
```
|
||||
build(docker): optimize production image size
|
||||
|
||||
Reduces image from 1.2GB to 180MB:
|
||||
- Use multi-stage build
|
||||
- Switch to Alpine base
|
||||
- Remove dev dependencies
|
||||
- Optimize layer caching
|
||||
|
||||
Faster deployments with no functionality changes.
|
||||
```
|
||||
|
||||
```
|
||||
ci(github): add pull request preview deployments
|
||||
|
||||
PRs now automatically deploy to temporary environments.
|
||||
Preview URL added as comment on each PR.
|
||||
Environments auto-deleted after PR close/merge.
|
||||
```
|
||||
|
||||
## Breaking Changes
|
||||
|
||||
```
|
||||
feat(api): standardize error response format
|
||||
|
||||
BREAKING CHANGE: All API errors now return consistent format:
|
||||
{
|
||||
"error": {
|
||||
"code": "ERROR_CODE",
|
||||
"message": "Human readable message",
|
||||
"details": {}
|
||||
}
|
||||
}
|
||||
|
||||
Previous format used top-level "message" and "status" fields.
|
||||
Clients must update error handling logic.
|
||||
|
||||
Migration guide: docs/error-format-migration.md
|
||||
```
|
||||
|
||||
## Multi-Scope Commits
|
||||
|
||||
```
|
||||
feat(api,ui): add user profile customization
|
||||
|
||||
Backend:
|
||||
- New /users/:id/profile endpoint
|
||||
- Avatar upload with image processing
|
||||
- Bio and social links fields
|
||||
|
||||
Frontend:
|
||||
- Profile editor component
|
||||
- Image cropping interface
|
||||
- Real-time preview
|
||||
|
||||
Closes #234
|
||||
```
|
||||
|
||||
## Style/Formatting
|
||||
|
||||
```
|
||||
style: apply Prettier formatting to entire codebase
|
||||
|
||||
No functional changes. Configures Prettier with:
|
||||
- 2 space indentation
|
||||
- Single quotes
|
||||
- Trailing commas
|
||||
- 80 character line width
|
||||
|
||||
Pre-commit hook added to enforce formatting.
|
||||
```
|
||||
|
||||
## Dependency Updates
|
||||
|
||||
```
|
||||
chore(deps): update dependencies to latest stable versions
|
||||
|
||||
Major updates:
|
||||
- typescript: 4.9 → 5.3
|
||||
- vite: 4.5 → 5.0
|
||||
- vitest: 0.34 → 1.0
|
||||
|
||||
All tests passing. No breaking changes in usage.
|
||||
```
|
||||
|
||||
## Reverts
|
||||
|
||||
```
|
||||
revert: "feat(search): implement full-text search"
|
||||
|
||||
This reverts commit a1b2c3d4e5f6.
|
||||
|
||||
Elasticsearch integration causing memory issues in production.
|
||||
Reverting to investigate and optimize before re-deploying.
|
||||
|
||||
Refs: #789
|
||||
```
|
||||
|
||||
## Tips for Choosing Examples
|
||||
|
||||
- Use these examples as templates, but always adapt to the actual changes
|
||||
- Match the level of detail to the complexity of the change
|
||||
- Include issue/PR references when available
|
||||
- Explain WHY, not just WHAT
|
||||
- Think about what future developers need to know
|
||||
197
skills/commit-writer/reference.md
Normal file
197
skills/commit-writer/reference.md
Normal file
@@ -0,0 +1,197 @@
|
||||
# Commit Message Reference
|
||||
|
||||
## Standards and Specifications
|
||||
|
||||
### Conventional Commits
|
||||
- **Website**: https://www.conventionalcommits.org/
|
||||
- **Specification**: v1.0.0
|
||||
- **Key Points**:
|
||||
- Structured format: `<type>(<scope>): <description>`
|
||||
- Types: feat, fix, docs, style, refactor, perf, test, build, ci, chore
|
||||
- Optional body and footer
|
||||
- Breaking changes marked with `BREAKING CHANGE:` footer
|
||||
|
||||
### Git Commit Messages Best Practices
|
||||
- **Subject line**: 50 characters (hard limit 72)
|
||||
- **Body**: Wrap at 72 characters
|
||||
- **Imperative mood**: "Add feature" not "Added feature"
|
||||
- **Separate subject from body**: With blank line
|
||||
- **Explain what and why**: Not how (code shows how)
|
||||
|
||||
## Commit Types Reference
|
||||
|
||||
| Type | Description | Example |
|
||||
|------|-------------|---------|
|
||||
| `feat` | New feature for the user | Adding OAuth login |
|
||||
| `fix` | Bug fix | Fixing null pointer exception |
|
||||
| `docs` | Documentation changes only | Update README |
|
||||
| `style` | Code style/formatting changes | Run Prettier |
|
||||
| `refactor` | Code restructuring, no behavior change | Extract method |
|
||||
| `perf` | Performance improvements | Add database index |
|
||||
| `test` | Adding or updating tests | Add unit tests |
|
||||
| `build` | Build system or dependencies | Update webpack config |
|
||||
| `ci` | CI/CD changes | Update GitHub Actions |
|
||||
| `chore` | Maintenance tasks | Update dependencies |
|
||||
| `revert` | Revert previous commit | Revert "Add feature" |
|
||||
|
||||
## Scope Guidelines
|
||||
|
||||
Scopes represent the area of the codebase affected:
|
||||
|
||||
### Good Scopes
|
||||
- **Component/Module**: `auth`, `database`, `api`, `ui`
|
||||
- **Feature Area**: `payments`, `notifications`, `search`
|
||||
- **Package Name**: `@company/utils`, `core`
|
||||
- **Subsystem**: `parser`, `compiler`, `renderer`
|
||||
|
||||
### Avoid
|
||||
- **Too Generic**: `code`, `files`, `app`
|
||||
- **Too Specific**: `UserController.ts`, `line-42`
|
||||
- **Redundant**: `bugfix`, `update` (these are types, not scopes)
|
||||
|
||||
## Footer References
|
||||
|
||||
### Issue/PR References
|
||||
```
|
||||
Closes #123
|
||||
Fixes #456
|
||||
Resolves #789
|
||||
Refs #100, #200
|
||||
See also: #150
|
||||
```
|
||||
|
||||
### Breaking Changes
|
||||
```
|
||||
BREAKING CHANGE: Changed API response format.
|
||||
Clients must update to new schema.
|
||||
```
|
||||
|
||||
### Co-authors
|
||||
```
|
||||
Co-authored-by: Name <email@example.com>
|
||||
```
|
||||
|
||||
### Sign-offs
|
||||
```
|
||||
Signed-off-by: Developer Name <dev@example.com>
|
||||
```
|
||||
|
||||
## Repository-Specific Conventions
|
||||
|
||||
### Emoji Commits (if repo uses them)
|
||||
Some projects use emojis as visual commit type indicators:
|
||||
- ✨ `:sparkles:` - New feature
|
||||
- 🐛 `:bug:` - Bug fix
|
||||
- 📝 `:memo:` - Documentation
|
||||
- ♻️ `:recycle:` - Refactoring
|
||||
- ⚡️ `:zap:` - Performance
|
||||
- ✅ `:white_check_mark:` - Tests
|
||||
- 🔧 `:wrench:` - Configuration
|
||||
|
||||
**Important**: Only use if the repository already uses this convention.
|
||||
|
||||
### Angular Commit Convention
|
||||
Some projects follow Angular's strict convention:
|
||||
- Subject must be lowercase
|
||||
- No period at end
|
||||
- Specific type list
|
||||
- Mandatory scope for certain types
|
||||
|
||||
**Check repo's CONTRIBUTING.md for specific conventions.**
|
||||
|
||||
## Semantic Versioning Connection
|
||||
|
||||
Commits drive semantic versioning in automated release systems:
|
||||
- `fix`: Patch version (0.0.x)
|
||||
- `feat`: Minor version (0.x.0)
|
||||
- `BREAKING CHANGE`: Major version (x.0.0)
|
||||
|
||||
## Common Anti-Patterns
|
||||
|
||||
### 1. Vague Messages
|
||||
❌ "Fix bug"
|
||||
✅ "fix(auth): resolve token expiration race condition"
|
||||
|
||||
### 2. Too Much in One Commit
|
||||
❌ "Add feature X, fix bug Y, update docs, refactor Z"
|
||||
✅ Split into 4 separate commits
|
||||
|
||||
### 3. Implementation Details in Subject
|
||||
❌ "Changed variable name from x to userId"
|
||||
✅ "refactor(user): improve variable naming clarity"
|
||||
|
||||
### 4. Missing Context
|
||||
❌ "Update config"
|
||||
✅ "build(webpack): enable tree shaking for production builds"
|
||||
|
||||
### 5. Personal Notes
|
||||
❌ "Finally got this working!"
|
||||
✅ "fix(parser): handle edge case with nested brackets"
|
||||
|
||||
## Tools and Automation
|
||||
|
||||
### Commitlint
|
||||
Validates commit messages against rules:
|
||||
```bash
|
||||
npm install --save-dev @commitlint/cli @commitlint/config-conventional
|
||||
```
|
||||
|
||||
### Conventional Changelog
|
||||
Generates changelogs from commits:
|
||||
```bash
|
||||
npm install --save-dev conventional-changelog-cli
|
||||
```
|
||||
|
||||
### Husky + Commitlint
|
||||
Enforces conventions with git hooks:
|
||||
```json
|
||||
{
|
||||
"husky": {
|
||||
"hooks": {
|
||||
"commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Reading List
|
||||
|
||||
1. **"How to Write a Git Commit Message"** by Chris Beams
|
||||
- The seven rules of great commit messages
|
||||
- https://chris.beams.io/posts/git-commit/
|
||||
|
||||
2. **Conventional Commits Specification**
|
||||
- Official spec with detailed examples
|
||||
- https://www.conventionalcommits.org/
|
||||
|
||||
3. **Angular Commit Guidelines**
|
||||
- Comprehensive enterprise-level conventions
|
||||
- https://github.com/angular/angular/blob/main/CONTRIBUTING.md
|
||||
|
||||
4. **Linux Kernel Git Commit Standards**
|
||||
- High-quality examples from large project
|
||||
- https://www.kernel.org/doc/html/latest/process/submitting-patches.html
|
||||
|
||||
## Quick Decision Tree
|
||||
|
||||
```
|
||||
Is this a new feature? → feat
|
||||
Is this fixing a bug? → fix
|
||||
Is this only docs? → docs
|
||||
Is this refactoring with no behavior change? → refactor
|
||||
Is this a performance improvement? → perf
|
||||
Is this only test changes? → test
|
||||
Is this build/tooling? → build or ci
|
||||
Is this dependency update or maintenance? → chore
|
||||
```
|
||||
|
||||
## Context Questions to Ask
|
||||
|
||||
When analyzing changes, consider:
|
||||
1. **What** changed? (files, functionality)
|
||||
2. **Why** did it change? (motivation, issue reference)
|
||||
3. **How** does it impact users? (breaking change?)
|
||||
4. **What** should reviewers focus on? (body content)
|
||||
5. **What** testing was done? (confidence level)
|
||||
|
||||
Remember: A commit message is a letter to your future self and teammates.
|
||||
Reference in New Issue
Block a user