Files
claude-code-skills-reference/github-contributor/references/pr_checklist.md
daymade 8363750c13 Release v1.22.0: Add skill-reviewer and github-contributor
- Add skill-reviewer v1.0.0 for reviewing Claude Code skills against best practices
  - Self-review mode: validate your own skills before publishing
  - External review mode: evaluate others' skill repositories
  - Auto-PR mode: fork, improve, submit PRs with additive-only changes
  - Auto-install dependencies: automatically installs skill-creator if missing

- Add github-contributor v1.0.0 for strategic open-source contribution
  - Four contribution types: Documentation, Code Quality, Bug Fixes, Features
  - Project selection criteria and red flags
  - PR excellence workflow and reputation building ladder
  - GitHub CLI commands and conventional commit format

- Update marketplace to v1.22.0 with 30 skills
- Update documentation (README, README.zh-CN, CLAUDE.md, CHANGELOG)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-15 23:02:40 +08:00

156 lines
3.2 KiB
Markdown

# PR Quality Checklist
Complete checklist for creating high-quality pull requests.
## Before Starting
- [ ] Read CONTRIBUTING.md thoroughly
- [ ] Check for existing PRs addressing same issue
- [ ] Comment on issue to express interest
- [ ] Wait for maintainer acknowledgment (if required)
- [ ] Understand project's code style
## Environment Setup
- [ ] Fork repository
- [ ] Clone to local machine
- [ ] Set up development environment
- [ ] Run existing tests (ensure they pass)
- [ ] Create feature branch with descriptive name
```bash
# Branch naming conventions
feature/add-yaml-support
fix/resolve-connection-timeout
docs/update-installation-guide
refactor/extract-validation-logic
```
## During Development
- [ ] Make small, focused commits
- [ ] Follow project's commit message format
- [ ] Add tests for new functionality
- [ ] Update documentation if needed
- [ ] Run linter/formatter before committing
## Before Submitting
### Code Quality
- [ ] All tests pass
- [ ] No linter warnings
- [ ] Code follows project style
- [ ] No unnecessary changes (whitespace, imports)
- [ ] Comments explain "why", not "what"
### Documentation
- [ ] README updated (if applicable)
- [ ] API docs updated (if applicable)
- [ ] Inline comments added for complex logic
- [ ] CHANGELOG updated (if required)
### PR Description
- [ ] Clear, descriptive title
- [ ] Summary of changes
- [ ] Motivation/context
- [ ] Testing approach
- [ ] Screenshots (for UI changes)
- [ ] Related issues linked
## PR Title Format
```
<type>(<scope>): <description>
Examples:
feat(api): add support for batch requests
fix(auth): resolve token refresh race condition
docs(readme): add troubleshooting section
refactor(utils): simplify date parsing logic
test(api): add integration tests for search endpoint
chore(deps): update lodash to 4.17.21
```
## PR Description Template
```markdown
## Summary
Brief description of what this PR does.
## Motivation
Why is this change needed? Link to issue if applicable.
Closes #123
## Changes
- Change 1
- Change 2
- Change 3
## Testing
How did you test this change?
- [ ] Unit tests added/updated
- [ ] Manual testing performed
- [ ] Integration tests pass
## Screenshots (if applicable)
| Before | After |
|--------|-------|
| image | image |
## Checklist
- [ ] Tests pass
- [ ] Documentation updated
- [ ] Code follows project style
```
## After Submitting
- [ ] Monitor for CI results
- [ ] Respond to review comments promptly
- [ ] Make requested changes quickly
- [ ] Thank reviewers for their time
- [ ] Don't force push after review starts (unless asked)
## Review Response Etiquette
### Good Responses
```
"Good point! I've updated the implementation to..."
"Thanks for catching that. Fixed in commit abc123."
"I see what you mean. I chose this approach because...
Would you prefer if I changed it to...?"
```
### Avoid
```
"That's just your opinion."
"It works on my machine."
"This is how I always do it."
```
## Common Rejection Reasons
1. **Too large** - Break into smaller PRs
2. **Unrelated changes** - Remove scope creep
3. **Missing tests** - Add test coverage
4. **Style violations** - Run formatter
5. **No issue link** - Create or link issue first
6. **Conflicts** - Rebase on latest main