用途：帮助开发者向开源项目提交高质量、维护者友好的 Pull Request，并规避常见的 16 种导致 PR 被拒的错误。触发词包括“submit PR to”“contribute to”“pull request for”“open source contribution”等。
主要能力：明确列出不应包含的内容，包括个人开发产物（如 SESSION.md、NOTES.md、TODO.md、planning/* 等笔记与计划文档）、调试与临时截图/录屏、手动或临时测试脚本、构建产物与依赖（node_modules、dist、build、.cache）、IDE 与系统文件（.vscode、.idea、.DS_Store、Thumbs.db、.swp）、密钥与敏感数据（.env、credentials.json、.key、.pem、secrets/）、临时与调试文件（temp/、.log、dump.sql、core、*.prof）。应包含的内容为：源代码改动、对应测试、文档更新、必要配置变更、迁移脚本、package.json 更新、schema 变更及 CI/CD 更新。
使用方式：提交前运行检查脚本 ./scripts/pre-pr-check.sh 扫描产物，使用 ./scripts/clean-branch.sh 清理个人产物，通过 git status、git diff --stat 复核改动；将个人模式加入 .git/info/exclude。采用 What/Why/How 结构撰写 PR 描述，遵循 Conventional Commits（如 feat(auth): add OAuth2 support for Google and GitHub）。PR 规模建议理想 50 行、良好 <200 行、上限 400 行。贡献前阅读 CONTRIBUTING.md，运行 npm run lint、npm run format，并执行 npm test && npm run lint && npm run build。
关键规则：始终使用功能分支（禁止在 main 上工作）；提交前完整测试并留存证据；保持 PR 聚焦单一改动（违反即为第 3 条错误）。其他规则涵盖阅读 CONTRIBUTING、避免巨型 PR、不抢已分配议题、大改动先讨论、不忽略 CI 失败、不提交密钥、评审开始后避免强制推送等。提供 scripts/、references/、assets/ 等配套资源，包括 PR 模板、检查清单、提交信息指南与正反示例。
限制：资料未提供具体安装命令、价格或适用平台等信息；效果依赖项目实际约定与维护者反馈。