メニュー
处理基于 git 和 GitHub 的真实协作工作流。当任务涉及仓库同步、分支管理、修复 bug、提交代码、创建或更新 PR、处理 review、解决冲突、检查 GitHub 认证与权限、或需要通过 fork 与用户仓库协作时使用，强调安全、干净、可审计的协作流程。**必须在需要时使用该 Skill 并严格遵守相关规范!!!**
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/KroMiose/nekro-agent --skill git-github-workflowコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
SOC 職業分類に基づく
SKILL.md を表示中
| name | git-github-workflow |
| description | 处理基于 git 和 GitHub 的真实协作工作流。当任务涉及仓库同步、分支管理、修复 bug、提交代码、创建或更新 PR、处理 review、解决冲突、检查 GitHub 认证与权限、或需要通过 fork 与用户仓库协作时使用，强调安全、干净、可审计的协作流程。**必须在需要时使用该 Skill 并严格遵守相关规范!!!** |
| version | 3.1.0 |
| allowed-tools | Read,Write,Bash |
在真实仓库协作中，优先遵守仓库状态、远端关系、权限边界、测试要求和用户意图。将 gh 作为 GitHub 交互工具使用，不要把任务退化为命令演示或命令罗列。
在不污染用户仓库历史、不破坏远端分支、不制造脏 PR 的前提下完成以下任务：
git 与 gh 检查认证、权限、远端和 PR 状态除非用户明确要求跳过，按下面顺序执行：
origin、上游仓库、当前分支、工作区是否干净。gh 是否可用、是否已认证、当前账号是谁、token 是否足以执行当前任务。GH_TOKEN（或等价环境变量）；不要伪造身份信息、提交人信息或远端归属。git diff，并尽可能运行与改动相关的静态检查、测试或最小验证，清理无关改动。开始任何 GitHub 协作任务前，至少确认这些事实：
origin 指向谁，是否已存在 upstreamgh 是否可执行gh auth status 是否成功，当前登录身份是谁任一关键事实不清楚时，先查清楚再行动。
不要复用上一轮对话中的仓库状态、PR 状态、分支状态或权限判断。每次新任务开始前都重新验证。
gh 已安装或已登录。先检查。GH_TOKEN。必要时提示重新执行认证检查。创建新分支时，必须同时指定分支名和起始点：
# ✅ 正确：从远端 main 最新状态创建
git fetch <远端名> <分支名>
git checkout -b <新分支名> <远端名>/<分支名>
# ❌ 错误：只指定分支名，不指定起始点
git checkout -b <新分支名> # 会从当前 HEAD 创建，继承所有历史 commit！
实际场景示例（假设 origin 指向用户主仓库）：
# 第一步：确认远端和当前分支
git remote -v && git branch -vv
# 第二步：从 origin/main 最新状态创建新分支
git fetch origin main
git checkout -b fix/this-bug origin/main
# 第三步：验证新分支基于正确的起点
git log --oneline -1 # 应与 origin/main 最新提交一致
远端确认规则：如果 origin 指向个人 fork 而非用户主仓库（可通过 git remote -v 判断），必须从 origin/main（用户主仓库）的最新 commit 创建分支，不能从 fork 的本地分支创建。
push --force、改写共享历史、删除远端分支、直接合并、关闭 PR。当任务需要通过 GitHub 提交修改，而当前身份对用户仓库没有直接写权限时，默认使用 fork 工作流：
不要只在自己的仓库里创建与用户仓库无关的 PR。目标应是从自己的 fork 向用户仓库提交 PR。
fork 的作用是承载代码分支和推送权限，不是替代用户仓库的协作现场。除非用户明确要求，否则不要在自己的 fork 上：
需要发起正式协作时，默认应落在用户仓库可见的对象上：用户仓库的 Issue、用户仓库的 PR、或从自己 fork 指向用户仓库的 PR。
以下都是 AI 在真实 Git/GitHub 协作中常见且不可接受的错误，默认必须规避：
错误示例：工作区里还残留上一个任务的改动、调试文件、格式化噪音或用户未提交修改，就直接继续开发并一起提交。 规避要求：开始工作前和提交前都检查工作区是否干净；若存在无关改动，不要混入当前提交，先告知用户或明确隔离。
错误示例：看到本地能提交，就默认这些改动都属于当前任务，没有审查 diff 就直接 commit。 规避要求：提交前重新检查 staged diff，确认提交内容只包含本次任务需要的修改，避免把历史残留或顺手改动一起带上。
错误示例：在自己的工作 fork 上创建 Issue、PR、review comment 或讨论串，然后把它当成对用户仓库的正式协作结果。 规避要求：正式协作对象必须落在正确的目标仓库；fork 默认只用于承载代码分支和推送权限，不替代用户仓库中的协作现场。
错误示例：本应向用户仓库提 Issue 或发起 PR，却误发到自己的 fork、错误组织、同名镜像仓库或历史测试仓库。 规避要求：执行远端写操作前，逐项确认 repo owner、repo name、base repo、head repo、base branch、head branch，确认链接和归属都正确后再提交。
错误示例：声称“已经同步到最新代码”，实际上只是对自己的 fork 执行了 git pull，而 fork 早已落后于原始仓库。
规避要求：同步最新基线时，必须确认原始仓库是谁，并从原始仓库默认分支或目标基线分支获取最新状态；不能把 fork 自己的最新状态误当成上游最新状态。
错误示例：只检查 origin，没有核实它其实指向自己的 fork，就基于过期基线分析问题、开发、提 PR。
规避要求：每次新任务开始时都重新核对 origin、upstream 和默认分支；如果 origin 指向 fork，必须显式确认原始仓库并从其同步。
错误示例：为了省事，在错误分支、旧分支或已经服务过别的 PR 的分支上继续开发，再把新旧任务混在一起推上去。 规避要求：默认从最新基线新建独立工作分支；只有在明确确认上下文连续且分支仍然干净可复用时，才继续使用旧分支。
错误示例：用户让 AI “修一下这个 PR”，AI 没有确认权限和 PR 来源，就直接尝试往别人的 PR 分支推送。 规避要求：先确认当前身份是否对原 PR head 分支有写权限；没有权限时，改为在自己的分支复现修复，并向正确目标仓库重新发起可审计的 PR。
错误示例：明明没有完成验证，却在 Issue/PR/comment 中写“已修复”“已验证通过”“可以合并”。 规避要求：对外协作文本必须区分“已确认”“已尝试但未完成”“尚未验证”“推测原因”，不要把未证实状态写成既成事实。
错误示例：为了保留上下文，在错误的 Issue/PR 里追加评论，导致用户和维护者看到混乱、不相关或过期的信息。 规避要求：评论前先确认对象仍然有效且与当前任务直接相关；如果原对象已关闭、已过时或已被替代，应切换到当前正确对象，而不是机械沿用旧线程。
错误示例：把 AI 内部推理、未经证实的怀疑、与任务无关的长篇分析直接贴到 Issue/PR，增加沟通噪音。 规避要求：外部协作内容只保留对用户和维护者有用、可验证、可执行的信息；内部思考不应直接外发。
错误示例：完成本地修改后没有重新检查远端状态，结果在用户已关闭 Issue、替换 PR、更新默认分支后，仍对过期对象继续操作。 规避要求：在 push、创建/更新 PR、创建/更新 Issue 前重新验证相关远端对象当前状态，避免对过期对象继续写入。
错误示例：在 PR 或 Issue 中以 本地路径 的形式附加相关文件或图片，导致参与者无法实际访问。 规避要求：如果需要提供补充文件、日志、截图等信息，必须使用 GitHub 支持的附件功能，确保内容对真实的参与者可见，严禁直接编写任何本地文件路径。
完成仓库协作任务后，回复应尽量覆盖这些信息：
只在需要时使用 gh。常见用途：
gh auth status 检查认证状态gh repo view、gh pr view、gh pr create 查询或创建 PRgh api 补足 gh 高层命令不方便表达的 GitHub 信息如果 gh 不可用，再读取本目录下的 install.md。