写代码、提 Issue、开 PR、做 Code Review——这些开发者每天都在重复的操作，现在都可以用一句话交给 Openclaw 自主完成。
下面这些都是真实发生的场景。你不需要懂 git 命令，不需要先查文档，直接说你想要什么，Openclaw 会帮你搞定。
你对 Openclaw 说
"帮我把 main 分支里登录页的那个空指针 bug 修掉，改完帮我提一个 PR，标题写清楚修了什么。"
Openclaw 做了什么
Openclaw 读取了出错文件，定位了问题代码，创建了新分支，修改代码后提交，并自动在 GitHub 上生成了一条描述清晰的 Pull Request。
你对 Openclaw 说
"按照 Issue #42 的需求，帮我给用户设置页面加一个「删除账号」功能，写完测试后提 PR。"
Openclaw 做了什么
它把 Issue 读了一遍，理解了需求，写了组件代码、后端接口和对应的测试，最后在 PR 描述里附上了功能说明和测试截图。
你对 Openclaw 说
"帮我把今天新来的 5 个 PR 快速过一遍，重点看有没有安全问题和明显的逻辑 bug，给我一个总结。"
Openclaw 做了什么
Openclaw 拉取了所有 PR 的 diff，逐一分析代码变更，标出了 2 处潜在越权风险和 1 处空值未校验问题，并按优先级整理成回顾报告。
你对 Openclaw 说
"帮我把产品经理发过来的这段需求描述拆解成 3 个 GitHub Issue，每个加上合适的 label 和 milestone。"
Openclaw 做了什么
它把模糊的需求文本分解为「前端 UI 改动」「API 接口变更」「数据库迁移」三个独立 Issue，分别写了详细的 Acceptance Criteria 并打上了标签。
你对 Openclaw 说
"读取 v1.3.0 到 v1.4.0 之间合并的所有 PR，帮我生成一份对外发布的 changelog，按功能、修复、破坏性变更分类。"
Openclaw 做了什么
Openclaw 查询了 GitHub 上这个时间段的所有已合并 PR，把 commit 和 PR 描述整合起来，生成了一份格式规范、对用户友好的发版说明，直接可以粘贴到 Release 页面。
你对 Openclaw 说
"帮我把过去一周新进来的 Issue 按 bug / feature / question / docs 分好类，加上标签，把一眼看起来重复的标记出来。"
Openclaw 做了什么
它读取了 38 个 Issue 的标题和描述，自动分组，贴上了 label，并标出了 4 个重复问题，同时建议把其中 2 个合并处理。
GitHub Skill 给了 Openclaw 一套完整的"工具箱"，覆盖了开发者在 GitHub 上的主要操作场景。
读取、创建、修改文件；查看目录结构；搜索代码；查看提交历史和文件变更记录。
创建分支、提交代码、开 PR、添加 Review 评论、合并 PR、列出所有待处理的 Pull Request。
新建 Issue、添加评论、贴 label、分配 milestone、批量关闭，甚至根据 Issue 自动写代码。
在整个仓库里全文搜索函数名、变量、注释；读取 PR diff；理解代码上下文并给出优化建议。
根据 PR 历史生成 changelog；打 Tag；在 GitHub Release 页面发布新版本说明，全程不用手动操作。
不只是查数据，而是真正读懂代码、理解需求并自主执行，把你从重复操作里解放出来。
要让 Openclaw 真正"接管"GitHub 操作，需要 5 个核心模块协同工作。
GitHub Skill 是整个方案的入口。它通过 ClawHub 安装，相当于给 Openclaw 装上了一套「GitHub 工具箱」——告诉 AI 它可以对 GitHub 做哪些操作，以及每种操作应该怎么调用。Skill 不会凭空运行，它必须依赖底层的工具（比如 gh CLI）才能把意图变成真实的 GitHub 操作。
GitHub 官方的命令行工具 gh 是和 GitHub API 交互的实际执行层。Openclaw 通过自己的 exec 工具调用 gh 命令，完成创建 PR、修改文件、查看 diff 等一系列真实操作。它不是在「模拟」，而是像一个真实开发者一样，在终端里直接操控 GitHub。
Openclaw 不会直接用你的 GitHub 密码，而是通过 OAuth 授权流程获得一个有限权限的访问令牌。你可以精确控制它能读哪些仓库、能不能写、能不能合并 PR。GitHub Skill 的官方文档里明确指出，这套授权机制设计上就是为了做到「可控权限」，而不是让 AI 拿到完全访问权。
「提一个 PR」这件事背后有很多步：读文件 → 理解逻辑 → 找到 bug → 改代码 → 创建分支 → 提交 → 写 PR 描述。普通 AI 对话只能做一步，但 Openclaw 的规划能力让它能把这链条串起来，自主完成每一个子步骤，中间出问题了还会自动重试和调整策略。
对于「帮我读 50 个 PR 然后生成报告」这类任务，单次对话的上下文远远不够。Openclaw 的任务编排层可以让它持续工作——分批读取数据、积累中间结果、最终整合输出——完全不需要你盯着它一步一步操作。这让 AI 开发助手从「一次性帮手」变成了「持续工作的成员」。
接入之后，这些句子可以直接发给 Openclaw，改改仓库名和 Issue 编号就能用。
在 [仓库名] 的 main 分支里，找到 [文件路径] 中关于 [问题描述] 的 bug，在新分支里修好后提一个 PR，写清楚改了什么和为什么这样改。
读取 Issue #[编号] 的需求，帮我在 [仓库名] 里实现这个功能，写好之后提 PR，在 PR 描述里附上测试方法。
帮我审查一下 PR #[编号]，重点看安全问题、边界处理、代码风格是否符合项目规范，给我一个审查意见列表。
读取 [仓库名] 从 [v1.x.x] 到 [v1.y.y] 之间所有已合并的 PR，生成一份分类清晰的 changelog，按功能新增、Bug 修复、破坏性变更分类。
拒绝千篇一律的机械化回复，通过三大核心配置文件为你的 AI 注入有趣的灵魂。
通过 Gmail API 和 OAuth 授权，让 Openclaw 读邮件、筛重点、起草回复。
使用 Bird Skill 复用浏览器登录态，把 Openclaw X 变成发帖、回复、监控提及、阅读帖子串和自动化运营的一体化工作流。
把 GPT、Gemini、Claude 的现有订阅接进 Openclaw，让 Openclaw Codex、Openclaw Gemini 和 Openclaw Claude 尽量避开额外 API 计费。
了解怎么把重复任务封装成可复用的 Skills，让 AI 按固定步骤、规则和边界稳定执行。
了解 Openclaw Browser 的两条上手路线：Playwright MCP 和 browser-use，以及它们分别该怎么安装。
学习如何安装和配置 OpenClaw 自动化系统，覆盖了从环境准备检查、安装到常用的控制台指令。
了解 OpenClaw 如何自己查库存、联系经销商，并跨浏览器、邮件和消息渠道多轮谈价，最终帮用户省下 4200 美元。
了解如何用 Openclaw 全网搜集岗位、定制简历求职信、批量发送，并整理收件箱回复，把求职最耗时的重复劳动全部交给 AI。
了解如何用 Openclaw 全网抓取租房信息、跨平台比价、批量发送询盘，并帮你和房东多轮沟通谈价，把租房最耗时的部分全部交给 AI。