Yeet

Yeet (The Ultimate Git Flow)

"Yeet" 是一种极致效率的开发哲学：当一项修改已经完成并通过验证，无需反复确认，直接执行“暂存 -> 提交 -> 推送 -> 创建 PR”的一键流水线。本技能通过 gh CLI 和原生 git 命令，帮助开发者在秒级完成从本地代码到 GitHub 评审页面的流转。

安装与前提条件

# 确保已安装 GitHub CLI
gh --version
# 验证登录状态与权限 (repo, workflow)
gh auth status

• 如果 gh 缺失，Agent 应主动提示用户安装。
• 如果未登录，执行 gh auth login。

命名规范 (Naming Conventions)

• 分支 (Branch)：如果当前在 main/master，自动创建 codex/{feature-description}。
• 提交 (Commit)：遵循 Conventional Commits（如 feat: add auth 或 fix: resolve race condition）。
• PR 标题：[codex] {description}，需简明扼要概括全量 Diff。

触发条件 / When to Use

• 功能开发闭环：当用户说“帮我提交这些改动并开个 PR”时。
• 紧急修复 (Hotfix)：需要以最快速度将补丁推送到上游分支进行 CI 验证。
• 文档零碎更新：修改了 README 或注释，不需要复杂的评审流程。
• 多仓库协同：在一个 Monorepo 的多个子包中同步执行 Yeet。
• 代码重构后：当重构规模大但逻辑变动小时，使用 Yeet 快速建立基准。

核心能力 / Core Capabilities

1. 智能分支与环境感知 (Environment Sensing)

• 操作步骤：
  1. 运行 git status -sb 检查当前状态是否干净。
  2. 获取默认分支名称（通常为 main 或 master）。
  3. 若在默认分支，基于 description 生成合规的分支名并切出：git checkout -b "codex/$(echo $DESC | slugify)"。
• 最佳实践：分支名应尽可能短小（Slugified），避免包含空格或特殊字符。

2. 自动化变更打包 (Atomic Staging)

• 操作步骤：
  1. 运行 git add -A 或针对特定目录 git add src/。
  2. 结合 git diff --cached --stat 预览待提交的内容，防止误传大文件。
• 最佳实践：如果发现敏感文件（如 .env），Agent 应自动发出警报并中止 Yeet。

3. CI 预检与健壮性保障 (Pre-push Checks)

• 操作步骤：
  1. 尝试运行本地定义的检查脚本（如 npm run lint 或 go test ./...）。
  2. 若检查失败，Agent 尝试自动修复（例如运行 prettier --write）并重新运行。
• 最佳实践：如果本地环境缺失工具链，Agent 应尝试一次性安装依赖。

4. 幂等推送与冲突处理 (Robust Push)

• 操作步骤：
  1. 执行带有跟踪信息的推送：git push -u origin $(git branch --show-current)。
  2. 若因上游领先导致推送失败，执行 git pull --rebase 并重新推送。
• 最佳实践：在极少数情况下使用 --force-with-lease，但必须在 PR 描述中注明。

5. 语义化 PR 描述生成 (Rich PR Content)

• 操作步骤：
  1. 提取全量 Diff 摘要。
  2. 自动生成 Markdown 格式的 PR Body，包含：背景、根本原因、修复方案、测试证明。
  3. 使用 gh pr create --draft --fill 创建 PR。
• 最佳实践：将 PR 设为 Draft (草稿) 状态，给用户最后一次人工复核的机会。

常用命令/模板 / Common Patterns

一键 Yeet 完整流 (Full Flow Template)

### 🚀 Yeet 开始执行
1. **[Branch]**: 从 `main` 切换到 `codex/fix-login-typo`。
2. **[Stage]**: 暂存 `src/auth.py` 的改动。
3. **[Commit]**: `fix: correct typo in login error message`。
4. **[Pre-Check]**: 运行 `pytest` ... **PASSED**.
5. **[Push]**: 推送至 `origin/codex/fix-login-typo`。
6. **[PR]**: 创建 PR #456 并生成描述。

### 📄 自动生成的 PR Body 预览
> **Title**: [codex] fix login typo
> **Description**: This PR addresses a UI issue where the error message showed 'Invalid credentails'.
> **Root Cause**: Spelling error in string literal.
> **Fix**: Updated L45 in `auth.py`.
> **Tests**: Ran unit tests and verified manually.

快速创建 PR 示例 (CLI)

# 生成临时 Body 文件并创建 PR
echo "## Summary\n$(git log -1 --pretty=%B)" > /tmp/pr-body.md
gh pr create --title "[codex] feature-x" --body-file /tmp/pr-body.md --draft

进阶应用场景 / Advanced Use Cases

1. 无缝集成 CI 修复 (Auto-Fixer)

• 当 gh-fix-ci 技能发现错误并修复后，自动衔接 yeet 技能，将修复代码推回 PR。

2. 定期代码同步 (Sync Upstream)

• 使用 cron 技能，每周五下午自动将本地所有的 WIP (Work In Progress) 分支执行一次 Yeet 到远程备份。

边界与限制 / Boundaries

• 认证安全：Yeet 严重依赖 gh 和 git 的本地配置。如果环境不安全，严禁在包含明文密钥的项目中使用。
• 合并冲突 (Merge Conflicts)：在 rebase 过程中如果遇到复杂冲突，Yeet 流程必须停止，交给人类解决。
• Commit History 污染：Yeet 倾向于“单次大提交”，对于要求原子提交（Atomic Commits）的严苛项目，建议在 PR 评审阶段进行 Squash。
• 权限限制：用户可能对该仓库没有 Push 权限（如 Fork 的原始库），此时应提醒用户进行 Fork 或推送到自己的仓库。
• 构建开销：如果本地 pre-push 检查非常耗时（如编译 C++ 项目），Yeet 会显著变慢。

最佳实践总结

1. 预览第一：在 git add 后，Agent 必须打印出变更文件的列表。
2. Body 为王：PR 描述质量直接决定了评审速度，必须通过 LLM 生成高质量的 Prose。
3. 追踪日志：在 Yeet 执行过程中，所有命令输出必须可见，方便排查。
4. 清理临时文件：Yeet 结束后，自动删除生成的 /tmp/pr-body.md 等中间文件。
5. 状态反馈：任务完成时，Agent 必须返回 PR 的 Web URL 链接。
6. 防误操作：如果检测到改动超过 100 个文件，必须强制进行二次确认。