Menu
定义了 GitHub 贡献指南的相关规则和行为模式。当需要在 GitHub 上进行贡献时，此技能将被启用。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | github-contribution-guidelines |
| description | 定义了 GitHub 贡献指南的相关规则和行为模式。当需要在 GitHub 上进行贡献时，此技能将被启用。 |
本 skill 定义了在 GitHub 上进行贡献的一般最佳实践和行为模式。请根据以下指南进行操作，以确保高效且有条理的贡献。
为了方便描述，后续内容中假设你已经具备一个 GitHub 账户，并且已经配置好了本地的 Git 环境，并通过 GitHub CLI（gh）进行身份验证。
如果上述条件尚未满足，请先提醒用户完成这些准备工作。
你可以通过以下命令检查 GitHub CLI 是否已配置：
❯ gh auth status
github.com
✓ Logged in to github.com account ShigureNyako (keyring)
- Active account: true
- Git operations protocol: https
- Token: gho_************************************
- Token scopes: 'gist', 'read:org', 'repo', 'workflow'
当出现类似上述输出时，表示 GitHub CLI 已正确配置。
为了方便后续描述，假设你的 GitHub 用户名为 ShigureNyako，请根据实际情况替换为你的用户名；同时假设贡献的上游仓库为 ShigureLab/python-lib-starter。
当你在 GitHub 上进行贡献时，请确保先将仓库从上游（upstream）仓库 fork 到你的个人账户，然后克隆到本地工作区。
cd /path/to/your/workspace/
gh repo list ShigureNyako # Check existing repositories under your account
# If the repository does not exist, fork it from upstream
gh repo fork ShigureLab/python-lib-starter
# Clone the forked repository to your local workspace
gh repo clone ShigureNyako/python-lib-starter ShigureLab/python-lib-starter
# Navigate to the cloned repository
cd ShigureLab/python-lib-starter
请确保你的本地仓库配置了正确的远程仓库（remotes），包括 origin 指向你的个人 fork 仓库，upstream 指向上游仓库。 你可以通过以下命令检查和配置远程仓库：
❯ git remote -v
origin https://github.com/ShigureNyako/python-lib-starter.git (fetch)
origin https://github.com/ShigureNyako/python-lib-starter.git (push)
upstream https://github.com/ShigureLab/python-lib-starter.git (fetch)
upstream https://github.com/ShigureLab/python-lib-starter.git (push)
如果你是通过 gh 克隆的仓库，origin 和 upstream 通常会自动配置好。如果没有，请手动添加：
# Add upstream remote if not present
git remote add upstream https://github.com/ShigureLab/python-lib-starter.git
# Set origin remote to your fork if not correct
git remote set-url origin https://github.com/ShigureNyako/python-lib-starter.git
请根据情况替换上述 URL，一般情况下我们只需维护 origin 和 upstream 两个远程仓库，以保持与上游仓库的同步和贡献。
在每次开始新的工作之前，请确保将默认开发分支（通常为 main，视仓库而定）更新到上游的最新状态：
# Ensure you are on the main branch
git switch main
# Fetch the latest changes from upstream
git fetch upstream main
# Merge the changes into your local main branch
git merge upstream/main
# Push the updated main branch to your fork
git push origin main
请确保默认分支保持最新，以避免合并冲突，且该分支仅用于同步上游仓库，不进行任何开发工作。
此时，你可以基于最新的开发分支创建新的功能分支（feature branch）来进行开发工作：
# Create and switch to a new feature branch
git switch -c feature/your-feature-name
后续开发工作均在该功能分支上进行。
在完成后，直接提交并推送到你的 fork：
# After making changes, stage and commit them
# Then push to your fork
gh pr create --base main --head feature/your-feature-name --title 'Your PR Title' --body 'Description of your changes'
[!NOTE]
值得注意的是，当命令中使用字符串时，如非需要执行命令，请使用单引号
'包裹字符串内容，以避免将`误认为是命令执行符号。
每个功能分支应对应一个独立的 PR，以便于代码审查和合并。
后续如需更新该功能分支对应的 PR，直接在该分支上 commit 并 push 即可。
在提交 PR 之后，请务必立刻进行自我审查，确保所有更改符合项目的代码规范和质量标准。你可以通过以下步骤进行自我审查：
当 PR 创建后，请密切关注 CI/CD 流水线的检查结果。如果检查失败，请根据错误信息进行修复，并将更改推送到同一功能分支，CI/CD 检查会自动重新运行。
请在每次提交 PR 完成后等待该 PR 1min 左右后及时检查 CI/CD 检查结果，以便尽快发现和修复问题。以免一些能够及时发现和解决的问题积累到下次循环。
如果你不确定如何修复某个 CI/CD 错误，请优先阅读相关文档，或者向项目维护者寻求帮助。
在 PR 描述中，请提及相关的开发者或维护者，以便他们能够及时审查你的贡献。例如：
@SigureMo Please review this PR when you have time. Thanks!
如果一个 PR 长时间（超过 3 天）没有得到审查，请在 PR 下方留言提醒相关维护者，或者在项目的讨论区寻求帮助。
如果在合并上游分支时遇到冲突，请按照以下步骤解决：
# Switch back to default branch
git switch main
# Fetch latest changes from upstream
git fetch upstream main
# Merge upstream changes
git merge upstream/main
# Push updated main branch to your fork
git push origin main
# Switch back to your feature branch
git switch feature/your-feature-name
# Merge updated main into your feature branch
git merge main
# Resolve any merge conflicts manually
# After resolving conflicts, stage the changes and commit
# ... add / commit commands ...
# Push the updated feature branch to your fork
git push origin feature/your-feature-name
当 PR 被合并后，请删除本地和远程的功能分支，以保持仓库整洁：
# Delete local feature branch
git branch -d feature/your-feature-name
# Delete remote feature branch
git push origin --delete feature/your-feature-name
为方便管理和识别，请遵循以下命名约定：
分支命名应遵循以下格式：
<type>/<short-description>
比如：
feature/add-login-functionalitybugfix/fix-null-pointer-exceptiondocs/add-contribution-guidelines一般是 PR 标题的简短版本，使用小写字母和连字符 - 分隔单词。
视具体项目而定，但一般建议遵循以下格式：
<type>(<scope>): <short description>
# For example:
feat(auth): add OAuth2 login support
fix: resolve data serialization bug
部分项目可能会使用如下格式（如 PaddlePaddle、TVM、PyTorch 等）：
# If only one type is used
[<type>] <Short description>
# If multiple types are used
[<type1>][<type2>][<type3>] <Short description>
# For example:
[Dynamo][3.14] Add bytecode `BUILD_TEMPLATE` and `BUILD_INTERPOLATION` support for `torch.compile`
其中 <short description> 应简洁明了地概括所做的更改，但不要过于笼统或模糊。
错误示例：
Update code to fix bugs and improve performanceVarious fixes and improvementsFixUpdate正确示例：
Fix null pointer exception in user login flowAdd unit tests for payment processing moduleImprove performance of data serialization具体项目可以参考其贡献指南中的要求，如无特别要求，请分析该项目中已有的 commit message 风格并保持一致。
PR 标题同样遵循 commit message 的命名规范，因为 PR 标题通常会被用作合并时的 commit message。
PR 标题应简洁明了，概括所做的更改。请确保所有修改都包含在标题中，当 PR 发生改动时，务必更新标题以反映最新内容。
PR 标题应当描述你在当前仓库所做的更改以及要解决的问题，例如：
Add user authentication module to handle login and registrationFix memory leak in data processing pipelineUpdate documentation for API endpoints and usage examplesFix double free bug in resource cleanup logic而不是在标题中直接说明解决的具体业务问题，例如：
Fix login issueFix model loading error in Swin Transformer（比如当前仓库是底层核心代码库 PaddlePaddle/PyTorch，而不是上层模型库，那么标题应聚焦于底层代码的更改，而不是上层模型的问题，上层模型问题应该在 PR 描述中说明）Fix documentation typos（这种过于笼统的标题应具体说明修正了哪些文档中的错误）PR 描述应详细说明所做的更改、解决的问题以及任何相关背景信息。请确保描述清晰且易于理解，便于审查者快速了解 PR 的内容和目的。
当上游仓库有 PR 模板（.github/PULL_REQUEST_TEMPLATE.md）时，请务必遵循模板中的要求填写 PR 描述。
当 PR 解决了特定 issue 时，请在描述中引用相关 issue，issue 中包含了最丰富的上下文信息，可以帮助审查者理解问题背景。例如：
This PR fixes #123 by implementing the following changes...