yeet

name	yeet
description	Use only when the user explicitly asks to stage, commit, push, and open a GitHub pull request in one flow using the GitHub CLI (`gh`).
zh_description	用于yeet，支持工程协作、自动化验证和交付闭环。
version	1.0.0
author	seaworld008
source	in-house
source_url
tags	["automation", "workflow", "yeet"]
created_at	2026-03-04
updated_at	2026-03-20
quality	2
complexity	intermediate

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 或 ）。