用途：为向自己并不维护的开源项目提交代码提供指导，重点在于清理个人开发残留、撰写规范的 PR 描述、遵循项目约定并保持专业沟通，从而提高 PR 被接受的概率。触发场景包括为公开仓库创建 PR、参与社区项目、首次向新项目贡献代码，以及需要 PR 最佳实践建议时。
主要能力：
- 明确列出不应进入 PR 的内容，如 SESSION.md、NOTES.md、TODO.md、planning/、调试截图、临时测试脚本、node_modules/、dist/、.vscode/、.env、密钥文件、日志与临时目录等；同时说明应包含的内容，如源码改动、测试、文档更新、配置与迁移脚本。
- 提供提交前清理流程：运行 ./scripts/pre-pr-check.sh 扫描个人文档、未引用截图、临时测试文件、大于 1MB 的文件、潜在密钥、PR 体积（超过 400 行会警告）及未提交改动；再用 git status、git diff --stat 检查，并用 git rm --cached 或 ./scripts/clean-branch.sh 清理，最后把个人模式写入 .git/info/exclude。
- 推荐 What/Why/How 结构的 PR 描述模板，并给出标题遵循 Conventional Commits 的格式 <type>(<scope>): <description>，以及提交信息规范（主题行 50 字符内、祈使语气、正文 72 字符换行、页脚引用 issue）。
- 给出 PR 体积建议：理想约 50 行，良好 200 行以内，上限 400 行；并说明拆分方式，如一次改动一个 PR、重构与功能分离、使用功能开关、按层拆分。
- 说明如何遵循项目约定：先读 CONTRIBUTING.md，检查 .eslintrc、.prettierrc、.editorconfig、STYLE.md 等风格文件，运行 npm run lint、npm run lint:fix、npm run format，并匹配已有代码模式。
- 提供沟通建议：开工前在 issue 下评论说明方案，提交与回复评审时保持礼貌，处理拒绝与催促维护者的时机（小 PR 一周后、大 PR 两周后）。
使用方式：该技能以文档与脚本形式提供，核心命令包括 ./scripts/pre-pr-check.sh、./scripts/clean-branch.sh、git status、git diff --stat、git rm --cached 等；测试命令按项目类型使用 npm test、cargo test、pytest、go test ./...。
适用场景：向公开仓库提交 PR、参与社区开源项目、首次贡献新项目、希望提升 PR 接受率时。
限制：资料未提供该技能的安装方式、收费模式、支持平台及具体效果数据；其内容为流程与规范建议，不保证 PR 一定被合并。