Pull Request

自动检查并生成高质量 Pull Request，确保符合项目规范。

已扫描

项目

内容

适合谁

开源项目贡献者、团队代码合入负责人

不适合谁

无 Git 项目经验的初学者、不关注代码规范的个人开发者

国内可用性

需网络配置。可能需要网络配置或第三方服务可访问。

安装难度

新手友好（★☆☆）。基于终端操作、依赖、API Key 和本地环境要求的初步判断。

安装与下载

复制命令安装

openclaw skills install @ivangdavila/pull-request

官方 ZIP下载官方 ZIP

Skill 说明

命令、参数、文件名以原文为准

何时使用

在向任何仓库提交或建议拉取请求（Pull Request）之前使用。作为质量过滤器，防止浪费维护者的时间，并避免给贡献者带来尴尬。

快速参考

领域	文件
提交前检查清单	`checklist.md`
应避免的警示信号	`red-flags.md`
获取仓库上下文	`repo-context.md`
拉取请求描述模板	`templates.md`

关键规则

优先阅读 CONTRIBUTING.md — 适应项目的实际工作流程，而非套用固定模式
问题策略取决于变更范围 — 小修复可直接提交 PR；新功能需先讨论
披露 AI 参与情况 — 在标题或描述中明确标注 AI 辅助
尽可能运行检查 — 若无法运行测试，请明确说明
匹配现有风格 — 检查是否存在 .editorconfig、prettier、eslint 等配置文件
保持小而专注 — 每个 PR 只包含一个逻辑上的变更
绝不泄露密钥 — 使用 <PLACEHOLDER> 语法替代敏感信息

问题策略（上下文相关）

并非所有项目都要求先创建问题（Issue）。请先查阅 CONTRIBUTING.md，然后：

变更类型	默认操作
错别字、小 bug 修复	直接提交 PR（除非 CONTRIBUTING.md 有其他规定）
新功能	先开启讨论或创建 Issue，等待批准
架构级变更	需要 RFC 或讨论
不确定时	编码前先在 Issue 中询问

AI 辅助的拉取请求

如果此 PR 是由 AI 辅助生成的，请遵循以下步骤：

明确标记 — 在 PR 标题中添加 [AI-assisted]，或在描述中注明
说明测试程度 — 声明：untested / lightly tested / fully tested
提供上下文 — 如有可用且有助于理解的提示或会话日志，请一并附上
确认理解 — 添加说明：“我已审查此代码，理解其功能”
明确责任人 — 链接到负责指导本次贡献的人类

速率限制（避免垃圾提交）

每个仓库最多同时保留 1 个开放的 PR
同一仓库的两次 PR 之间需间隔至少 24 小时
若连续两次 PR 被拒绝 → 停止并升级至人类处理
提交前先查看仓库的 PR 活跃度（避免向低活跃度项目大量提交）

避免被弃置

必须在 48 小时内响应评审反馈
若无法回应反馈，请关闭 PR 并注明：“我无法继续；@human 请接手或关闭”
永远不要让 PR 长期无人问津

作用域边界 — 遇到以下情况必须停止并先讨论：

修改文件超过 5 个或行数超过 200 行
修改了公共 API
涉及安全、认证或加密相关逻辑
涉及治理、许可协议或行为准则（CoC）
维护者已在 Issue 中要求讨论
对变更是否符合项目理念存疑

需要人工介入的情况

当出现以下任一情况时，应立即升级至人类处理：

审核人对设计意图提出澄清问题
CI 失败原因不明显
遇到超出“修正拼写错误”的反对意见
审核人表现出困惑或情绪化
无法在本地运行测试套件

@ivangdavila

已收录 16 个 Skill