yeet

yeet 技能概览

yeet 的用途

yeet 是一个聚焦型 GitHub skill，只做一件事：把预期修改暂存起来，写出简洁的 commit，推送分支，然后用 gh 打开 GitHub pull request。它最适合那些已经明确知道自己要让别人 review 什么的人，用来稳定地完成 Git 工作流的最后一公里。yeet skill 不是通用的 Git 教程，而是把一个已经准备好的分支整理成可 review PR 的执行助手。

谁适合使用它

当你已经在本地 repo 里完成了代码修改、可以通过 GitHub CLI 认证，并且希望有一套可重复的“准备 review”流程时，就该用 yeet。它适合开发者、agent 和自动化场景，帮助它们从 work-in-progress 到 PR 之间走一条低摩擦的 Git Workflows 路径，而不是每次都临场发挥去决定分支、commit 和 push 的步骤。

它有什么不同

它的核心价值在于约束：yeet 依赖 gh，会检查认证状态，并按既定顺序处理分支命名、暂存、提交、推送和打开 draft PR。这样可以减少猜测，避免漏步骤。代价也很明确：它只在仓库已经处于值得 review 的状态、且你的环境支持 GitHub CLI 时才真正有用。

如何使用 yeet skill

安装并验证前置条件

要进行 yeet install，先把 skill 加进来，并确认本地机器真的能把整套流程跑通：

npx skills add openai/skills --skill yeet

在真正依赖它之前，先检查 gh --version 和 gh auth status。如果 gh 没装，或者没有完成认证，先停下来把这一步补齐；这个 skill 依赖的是 GitHub CLI，而不是只靠浏览器创建 PR。这个通常是最大的采用门槛，所以在让 skill 接手某个分支之前，值得先确认清楚。

给它一个完整、可 review 的目标

yeet usage 最有效的方式，不是只说“use yeet”，而是直接说明你想要的结果。一个好的请求应该包含改动范围、仓库上下文，以及对 commit 或 PR 的限制。例如：“Prepare this branch for review: stage only the API and test changes, commit with a focused message, push to origin, and open a draft PR.”

如果改动里包含杂项，就明确说明哪些该保留、哪些不该包含。这个 skill 会用 git add -A 来暂存，所以在调用之前，你要先确保未跟踪文件和已修改文件都已经是有意为之，而不是碰巧留在工作区里。

按顺序走完工作流

yeet 的流程是按固定顺序设计的：先检查分支状态，再暂存改动，然后简洁提交，必要时运行检查，接着带 tracking 推送，最后创建 PR。如果你当前在 main、master 或默认分支上，它会先创建 feature branch。若检查失败是因为依赖缺失，skill 允许先安装一次再重跑，这对首次运行的环境尤其重要。

为了获得更好的结果，建议先读这些文件：

• SKILL.md：精确的保护规则和命令顺序
• agents/openai.yaml：默认 prompt 和产品定位
• LICENSE.txt：仅在你需要了解复用或再分发背景时查看

写出能提升输出质量的输入

好的 yeet invocation 要直接点明 review 意图，比如“修复登录重定向”、“清理失败的测试覆盖”或“准备仅文档更新”。更好的 prompt 还会说明分支是否是新建的、仓库是否已有现成的测试命令，以及你是否希望生成 draft PR。这样可以帮助 skill 生成与真实 diff 相匹配的 commit 和 PR 描述，而不是泛泛而谈的摘要。

yeet skill 常见问题

yeet 只是一个花哨的 git 提示词吗？

不是。普通 prompt 只能建议步骤，而 yeet 把一套由 gh、认证检查、分支处理、暂存、提交、推送和 PR 创建组成的具体流程编码了进去。它的价值不在“聊天式指导”，而在于为 Git Workflows 提供一条稳定、可执行的操作路径。

什么情况下不该用 yeet？

如果你还不能通过 gh 完成认证、还没准备好提交，或者你需要与 git add -A 相冲突的选择性暂存，就不该用 yeet。它也不适合探索性分支、rebase 场景，或者你希望在任何 commit 发生之前先手动检查 diff 的情况。

yeet 适合新手吗？

只有在使用者已经能判断哪些文件属于这次改动，并且理解基本的 Git 分支状态时，它才算对新手友好。这个 skill 能减少 PR 摩擦，但不能替代 Git 基础，也不是用来逐条讲解命令的学习工具。

yeet 能脱离 GitHub CLI 工作流使用吗？

基本不能。仓库材料的重心就是 gh，所以 yeet 最适合 GitHub 体系中的 repo，在那里 CLI 认证、分支推送和 PR 创建本来就是日常流程的一部分。如果你的团队用的是其他托管平台，或者不接受 CLI 认证，这个 skill 的适配度就会比较弱。

如何改进 yeet skill

从更清晰的输入开始

提升 yeet 结果最直接的方法，就是把 scope 说清楚。告诉它目标 issue、预期文件，以及 review 意图。例如：“Prepare this branch for review; include src/auth/andtests/auth/, exclude generated files, and write a PR body that explains the auth fix and validation steps.”

防范常见失败模式

最常见的失败模式是暂存过多、commit message 过于模糊，以及在 gh 还没准备好之前就启动 skill。另一个常见问题是，分支里还混着无关修改，却已经开始要求它走完整流程。如果 diff 很乱，先整理干净；当分支已经只代表一个可 review 的改动时，yeet 的效果最好。

在第一次执行后继续迭代

当 yeet 生成了 commit 或 draft PR 之后，检查一下消息质量和包含的文件。如果 PR body 太泛，就把实际问题、用户影响，以及希望写进去的测试证据反馈给它。以后再次使用 yeet 时，可以保留一个简短的 prompt 模板，固定写明改动内容、分支状态和任何不应暂存的内容。

利用仓库上下文把 prompt 说得更准

agents/openai.yaml 里的默认 prompt 已经表明了它希望采取的姿态：“prepare this branch for review.” 你可以在这个基础上继续补充仓库里的具体信息，比如子系统、测试命令或发布风险。这样 yeet 就能在不增加多余流程感的前提下，产出更精准的 commit 和 PR。