workflow-github

Étoiles5

Forks0

Mis à jour22 mai 2026 à 09:21

GitHub PR 工作流程 skill，使用 gh CLI 管理完整的 Developer/Reviewer 流程。支持两种协作模式：Fork-upstream（有上游仓库）和 Same-repo（直接在主仓库开发）。当用户提到以下场景时必须使用：创建分支、提交代码、创建 PR、review 代码、合并 PR、release、处理 review 反馈、git workflow、代码协作、PR 流程。即使用户只说"帮我提个 PR"或"review 一下这个分支"也要触发。

Installation

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Source

iodone

iodone/philip

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Métiers associésSOC

Basé sur la classification professionnelle SOC

Développeurs de logicielsProfessions informatiques et mathématiques·SOC 15-1252

SKILL.md

readonly

Plus depuis ce dépôt

même dépôt

workflow-llm-wiki

iodone/philip

LLM Wiki vault 操作手册。触发条件： - /ingest <path> — 当用户说「ingest」「把这篇文章加入 wiki」「编译到 wiki」「摄取」时触发 - /query <question> — 当用户说「搜索 wiki」「wiki 中有没有」「查一下 wiki」时触发 - /lint — 当用户说「检查 wiki」「wiki 健康度」「lint」「有没有断链」时触发 - /research <topic> — 当用户说「研究一下」「深度调研」「research」时触发

2026-06-115

spark

iodone/philip

Use when the user wants to brainstorm an idea or design a feature/spec. Explores intent and requirements through dialogue, then writes a spec document to contexts/thought_review/ and STOPS. Does not auto-chain to implementation planning or any other skill.

2026-05-225

analyzer-structural-stability

iodone/philip

结构稳定性分析器。不判断观点对错，只判断一件事：这个结构能不能活下去。对任意观点、系统、模型、制度、人物言论进行五维结构稳定性分析，输出存活概率和失效路径。当用户说「分析这个结构」「这个观点稳不稳」「帮我拆一下」「结构分析」时触发。

2026-05-225

bestpractice-ai-debugging-diagnosis

iodone/philip

AI 辅助开发中遇到“代码改不好”时的诊断思路与决策树

2026-05-225

bestpractice-ai-product-design

iodone/philip

AI 产品设计、交互设计与系统架构中的关键原则与常见陷阱

2026-05-225

bestpractice-ai-programming-mindset

iodone/philip

AI 辅助编程与 Agent 系统设计的核心方法论和判断原则

2026-05-225

name

workflow-github

description

HARD GATE： 本 skill 只做 GitHub PR 工作流程管理。不执行业务代码逻辑，不修改非 git 相关文件，不代替用户做最终决策。所有 push、PR、merge、release 操作必须等待用户确认。

GitHub Workflow Skill (gh)

基于 gh CLI 的 GitHub 协作工作流程，定义 Developer 和 Reviewer 两个角色。

核心原则

原则	实践
人类掌舵，智能体执行	关键决策点（push、PR、merge）等待用户确认
保持历史整洁	使用 rebase 保持线性提交历史
原子性提交	一个逻辑变更对应一个 commit
可追溯性	Commit message 清晰描述意图，PR 关联 Issue

前置检查（Agent 必须执行）

在任何操作前，先完成以下检查：

# 1. 确认 gh 已认证
gh auth status

# 2. 确认当前仓库和 remote 配置
gh repo view
git remote -v

# 3. 判断协作模式（关键！）
git remote get-url upstream 2>/dev/null && echo "FORK-UPSTREAM 模式" || echo "SAME-REPO 模式"

# 4. 确认目标分支（默认为 main，从 AGENTS.md 或用户确认）

协作模式判断：

模式	特征	同步方式
Fork-upstream	有 `upstream` remote	`gh repo sync` 或 `git pull upstream main`
Same-repo	无 `upstream`，只有 `origin`	`git pull origin main` 或 `git fetch origin`

Agent 行为：

❌ 若 gh auth status 失败 → 停止，告知用户配置认证
❌ 若 remote 不可达 → 停止，检查 URL 或网络
✅ 自动检测协作模式，后续流程根据模式调整
⏸️ 确认目标分支后继续

STOP。 若前置检查失败，进入完成状态上报 BLOCKED。

逃生舱

快速查看：如果用户只说"看看 diff"或"看看状态" → 只执行 git diff 或 git status，不进入完整流程
跳过确认：如果用户说"直接做"或"跳过确认" → 跳过所有 ⏸️ 确认点，执行完后一次性汇报
处理 review：如果用户只说"处理 review" → 直接跳到 Phase 10

Role: Developer

Phase 1：接收或创建 Issue

# 查看 issue 详情
gh issue view <issue-number>

# （可选）创建新 issue
gh issue create \
  --title "<title>" \
  --body "<body>"

Agent 行为：

✅ 读取 issue 内容，理解需求
📝 记录 issue 编号，后续 PR 需关联

Phase 2：获取代码并同步（关键步骤）

如果本地还没有仓库（初次获取代码）：

# ===== Fork-upstream 模式（推荐）=====
gh repo clone <your-fork-repo>
# gh 会自动检测 fork 关系并配置 upstream remote

# ===== Same-repo 模式 =====
gh repo clone <repo>
# 直接 clone 主仓库

如果本地已有仓库（同步最新代码）：

# ===== Fork-upstream 模式 =====
# 方式 1：使用 gh 自动同步（推荐）
gh repo sync

# 方式 2：手动同步
git checkout <target-branch>
git pull upstream <target-branch>
git push origin <target-branch>

# ===== Same-repo 模式（无 upstream）=====
git checkout <target-branch>
git pull origin <target-branch>
# 或 fetch 后 rebase
git fetch origin
git rebase origin/<target-branch>

同步完成后创建分支：

git checkout -b <type>/<issue-简述>

分支命名规范：

Type	场景
`feat/`	新功能
`fix/`	Bug 修复
`docs/`	文档变更
`refactor/`	重构
`chore/`	构建/工具变更

分支命名示例：

GOOD: fix/config-show-workspaces-null GOOD: feat/user-auth-jwt BAD: my-branch（无 type 前缀，无法识别变更类型） BAD: fix（过于笼统，无具体描述）

Agent 行为：

⏸️ 创建分支前必须确认目标分支（从用户或 AGENTS.md 读取）
❌ 禁止从非目标分支创建
✅ Fork-upstream 模式优先使用 gh repo sync
✅ Same-repo 模式使用 git pull origin <target-branch>

STOP。 确认目标分支后继续。

Phase 3：开发变更

编辑文件，执行必要的操作。

Agent 行为：

✅ 按需修改文件
✅ 运行 lint + 测试验证（参考项目 AGENTS.md）
✅ 修复所有 lint / test 错误后再进入下一步

Phase 4：展示变更（确认点 1）

git diff

Agent 行为：

⏸️ 停止并等待用户确认
📊 展示所有变更的 diff
💬 说明修改意图和影响范围

用户决策：

✅ 确认 → 继续
❌ 拒绝 → 修改后重新展示
🔄 调整 → Agent 根据反馈修改

STOP。 等待用户确认。

Phase 5：Rebase 到最新基线

# ===== Fork-upstream 模式 =====
git fetch upstream
git log HEAD..<target-branch> --oneline
# 如有新提交：
git rebase <target-branch>

# ===== Same-repo 模式 =====
git fetch origin
git log HEAD..<target-branch> --oneline
# 如有新提交：
git rebase <target-branch>
# 或 rebase 到 origin/<target-branch>
git rebase origin/<target-branch>

Agent 行为：

✅ 根据协作模式选择 fetch 来源（upstream 或 origin）
⚠️ 如有冲突 → 立即停止，报告冲突文件，等待用户手动解决

STOP。 rebase 冲突时必须停止，等待用户手动解决。

Phase 6：提交变更

git add <相关文件>       # 精确暂存，避免 git add .
git commit -m "<type>(<scope>): <description> (#<issue-number>)"

Commit Message 格式：

<type>(<scope>): <subject> (#issue)

[optional body]

Commit Message 示例：

GOOD: fix(config): resolve null pointer when workspace missing (#123) GOOD: feat(auth): implement JWT-based user authentication (#456) BAD: fix bug（无 scope、无 issue 关联、无具体描述） BAD: update code（过于笼统，无法理解变更意图）

Agent 行为：

✅ 自动生成符合规范的 commit message
✅ 只暂存与本次变更相关的文件
📝 Subject 不超过 50 字符
📝 Body 说明变更原因（如需要）

Phase 7：展示提交（确认点 2）

git show HEAD --stat

Agent 行为：

⏸️ 停止并等待用户确认
📊 展示 commit message、变更文件列表

用户决策：

✅ 确认 → 继续推送
❌ 修改 → git commit --amend 调整

STOP。 等待用户确认。

Phase 8：推送到远端（确认点 3）

git push -u origin <branch-name>    # 首次推送
git push origin <branch-name>       # 后续推送

Agent 行为：

⏸️ 停止并展示推送信息：
- 分支名
- 远程仓库 URL
- 即将推送的 commit 数量和 hash
💬 询问："是否确认推送到 origin？"
⏸️ 等待用户明确确认

用户决策：

✅ 确认 → 执行推送
❌ 取消 → 保留本地 commit

STOP。 等待用户确认。

Phase 9：创建 PR（确认点 4）

gh pr create \
  --base <target-branch> \
  --head <branch-name> \
  --title "<type>(<scope>): <description>" \
  --body "$(cat <<'EOF'
## Changes
- 变更点 1
- 变更点 2

## Motivation
变更原因

## Closes
Closes #<issue-number>

## Testing
- [x] 已通过本地测试
- [x] 已通过 lint 检查
EOF
)"

GitHub PR 特有选项（按需使用）：

# 创建 Draft PR（标记为工作进行中）
gh pr create --draft ...

# 指定 reviewer
gh pr create --reviewer <username> ...

# 指定 assignee
gh pr create --assignee <username> ...

# 添加 label
gh pr create --label bug,enhancement ...

Agent 行为：

⏸️ 停止并展示 PR 信息，等待用户最终确认
📊 展示：标题、目标分支、描述、关联 issue
💬 确认 base branch 是否正确

用户决策：

✅ 确认 → 创建 PR
❌ 取消 → 不创建
🔄 调整 → 修改后重新展示

STOP。 等待用户确认。

Phase 10：处理 Review 反馈

收到 review 后的循环：

# 1. 查看 PR 详情和评论
gh pr view
gh pr diff

# 2. 查看 review 评论
gh pr review --list    # 列出所有 review
gh api repos/{owner}/{repo}/pulls/<pr-number>/comments  # 行级评论

# 3. 根据反馈修改代码

# 4. 提交修改（在同一条分支上）
git add <files>
git commit -m "fix: <描述修复内容>"
git push origin <branch-name>

# 5. 回复 review 评论（如需要）
gh pr comment <pr-number> --body "已修复：<说明>"

Agent 行为：

✅ 读取 review 评论并理解修改要求
✅ 在同一分支上修改，保持 commit 历史清晰
⏸️ 每次提交前展示变更，等待用户确认
🔁 持续循环直到 PR 被合并或关闭

Role: Reviewer

Phase 1：Review PR

# 查看 PR 详情
gh pr view <pr-number>

# 查看 diff
gh pr diff <pr-number>

# 查看 PR 中的 commits
gh pr view <pr-number> --json commits

Review 检查清单：

代码是否符合项目规范（lint / format）
测试是否覆盖变更
是否关联了对应 Issue
Commit message 是否清晰
功能是否满足 Issue 需求

Phase 2：给出 Review 建议

# 在 PR 中添加评论
gh pr comment <pr-number> --body "<review 意见>"

# 提交 review（approve / request-changes / comment）
gh pr review <pr-number> --approve --body "LGTM 👍"
gh pr review <pr-number> --request-changes --body "需要修改：<说明>"
gh pr review <pr-number> --comment --body "<一般评论>"

Agent 行为：

⏸️ 展示 review 意见，等待用户确认后再提交
💬 提出具体修改建议

STOP。 等待用户确认。

Phase 3：合并 PR（确认点）

当 PR 符合期望时：

# 查看最终状态
gh pr view <pr-number>

# 合并 PR（支持多种合并方式）
gh pr merge <pr-number>                    # 默认 squash merge
gh pr merge <pr-number> --merge            # 创建 merge commit
gh pr merge <pr-number> --rebase           # rebase 后合并（保持线性）
gh pr merge <pr-number> --delete-branch    # 合并后删除分支

合并前检查：

所有 review 意见已解决
CI checks 通过（如配置了）
无冲突
已获得至少一个 approve

Agent 行为：

⏸️ 展示合并信息和合并方式，等待用户最终确认
💬 建议使用哪种合并方式（squash/merge/rebase）

STOP。 等待用户确认。

Phase 4：Release 流程

合并到目标分支后，执行 release（按项目 AGENTS.md 规范）：

# ===== Fork-upstream 模式 =====
git checkout <target-branch>
git pull upstream <target-branch>
git tag v<version>
git push upstream v<version>

# ===== Same-repo 模式 =====
git checkout <target-branch>
git pull origin <target-branch>
git tag v<version>
git push origin v<version>

# 创建 GitHub Release（两种模式相同）
gh release create v<version> \
  --title "v<version>" \
  --notes "$(cat <<'EOF'
## Changes
- 变更摘要
EOF
)" \
  --draft  # 先创建草稿，确认后再发布

Agent 行为：

⏸️ 每个步骤前展示信息，等待用户确认
📝 版本号遵循语义化版本（SemVer）
📝 Release notes 从 commit log 和 Issue 中生成
✅ 根据协作模式选择 push 目标（upstream 或 origin）

STOP。 每个步骤前等待用户确认。

自我调节

连续 3 次 git 操作失败 → STOP，上报用户
PR 创建失败超过 2 次 → STOP，检查 remote 配置
rebase 冲突 → STOP，等待用户手动解决
单次流程超过 15 分钟无进展 → STOP，评估是否需要用户介入

上报格式：

STATUS: BLOCKED
REASON: [1-2 句话]
ATTEMPTED: [已尝试的方法]
RECOMMENDATION: [建议用户下一步]

完整流程示例

Developer 流程（Fork-upstream 模式）

# 前置检查
gh auth status
gh repo view
git remote get-url upstream  # 确认有 upstream

# 1. 读取 issue
gh issue view 1

# 2. 同步并创建分支
gh repo sync
git checkout -b fix/some-bug

# 3. 开发 & 测试
# ... 修改代码 ...
npm run lint
npm test

# 4. 展示变更（确认点 1）
git diff
# 👤 等待用户确认

# 5. Rebase
git fetch upstream && git rebase main

# 6. 提交
git add <files>
git commit -m "fix(scope): description (#1)"

# 7. 展示提交（确认点 2）
git show HEAD --stat
# 👤 等待用户确认

# 8. 推送（确认点 3）
# 👤 等待用户确认
git push -u origin fix/some-bug

# 9. 创建 PR（确认点 4）
# 👤 等待用户确认
gh pr create --base main --title "fix(scope): description" --body "..."

# 10. 处理 review（循环）
# ... 收到反馈 → 修改 → 推送 ...

Developer 流程（Same-repo 模式）

# 前置检查
gh auth status
gh repo view
git remote -v  # 确认只有 origin，无 upstream

# 1. 读取 issue
gh issue view 1

# 2. 同步并创建分支
git checkout main
git pull origin main
git checkout -b fix/some-bug

# 3. 开发 & 测试
# ... 修改代码 ...
npm run lint
npm test

# 4. 展示变更（确认点 1）
git diff
# 👤 等待用户确认

# 5. Rebase
git fetch origin && git rebase origin/main

# 6. 提交
git add <files>
git commit -m "fix(scope): description (#1)"

# 7. 展示提交（确认点 2）
git show HEAD --stat
# 👤 等待用户确认

# 8. 推送（确认点 3）
# 👤 等待用户确认
git push -u origin fix/some-bug

# 9. 创建 PR（确认点 4）
# 👤 等待用户确认
gh pr create --base main --title "fix(scope): description" --body "..."

# 10. 处理 review（循环）
# ... 收到反馈 → 修改 → 推送 ...

Reviewer 流程

# 1. 查看 PR
gh pr view 3
gh pr diff 3

# 2. 给出意见或合并
# 👤 确认后执行
gh pr review 3 --approve --body "LGTM"
gh pr merge 3 --squash --delete-branch

# 3. Release（按协作模式选择）
# Fork-upstream:
git checkout main && git pull upstream main
git tag v0.1.1 && git push upstream v0.1.1

# Same-repo:
git checkout main && git pull origin main
git tag v0.1.1 && git push origin v0.1.1

gh release create v0.1.1 --title "v0.1.1" --notes "..."

异常处理

Push 失败（认证问题）

# 检查认证
gh auth status

# 重新认证
gh auth login

# 或使用 token
gh auth login --with-token < token.txt

PR 目标分支错误

# 关闭错误的 PR
gh pr close <wrong-pr-number>

# 重新创建正确的 PR
gh pr create --base <correct-branch> ...

Merge 冲突

# 根据协作模式 fetch
git fetch upstream  # Fork-upstream 模式
# 或
git fetch origin    # Same-repo 模式

git rebase <target-branch>
# 👤 用户手动解决冲突后
git add <resolved-files>
git rebase --continue
git push origin <branch-name> --force-with-lease

PR 更新（补充提交）

# 在已有分支上继续提交
git add <files>
git commit -m "fix: <补充说明>"
git push origin <branch-name>   # PR 自动更新

# 修改最后一次 commit message
git commit --amend -m "fix(scope): updated message"
git push origin <branch-name> --force-with-lease

Checklist：Agent 自检清单

执行 Git 操作前，Agent 必须确认：

前置检查：gh auth status 通过
协作模式：检测并确认是 Fork-upstream 还是 Same-repo 模式
Remote 配置：remote URL 可访问
目标分支：明确 PR 应 target 哪个分支
分支起点：分支从目标分支的最新 HEAD 创建
Issue 关联：commit message 和 PR 描述中关联 Issue
确认节点：识别需要用户确认的关键步骤（push、PR、merge、release）
回滚方案：知道如何撤销操作

完成状态

DONE — 流程全部完成（代码已合并或 PR 已创建）
DONE_WITH_CONCERNS — 完成但有待确认（如 CI 未通过、review 未完成）
BLOCKED — 无法继续（认证失败、冲突未解决）
NEEDS_CONTEXT — 缺少信息（目标分支、issue 编号、repo 路径）

Philosophy

Git 历史是团队协作的因果记录。每一次 PR 都应该是清晰、原子、可追溯的状态转换。

Developer 负责实现，Reviewer 负责把关。两者协同，保证代码质量。

Skill Version: 1.1.0 Author: Meta42 Status: Active & Enforced Last Updated: 2026-03-30 Modes: Fork-upstream + Same-repo