Token导航 LogoToken导航TokenDH.com
中转站排行榜
研究检索敏感数据github未标认证来源可访问许可证需确认审计提醒

git-workflow（Git 工作流）

Agent Skill

git-workflow 用于查找、检索和筛选相关信息，适合在 Codex、Claude、Cursor、Gemini CLI 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态，以及是否会触发联网、命令执行或文件读写。

总安装

1,392

周安装

58

GitHub Stars

公开资料未说明

下载量

464
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息，不托管安装包，也不代用户安装。

GitHub

来源数

2

许可证

unknown

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手，先确认命令和权限，再让它执行。

请帮我安装这个 Agent Skill：git-workflow（Git 工作流）
来源仓库：https://github.com/blogic-cz/agent-tools
仓库路径：skills/git-workflow
安装命令：
npx skills add https://github.com/blogic-cz/agent-tools --skill git-workflow
安装前请先检查当前环境是否支持对应 CLI，并向我确认将要执行的命令、安装目录、联网范围和文件读写权限；确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill；本站只展示命令，不托管安装包，也不自动执行。

skills.shnpx skills
npx skills add https://github.com/blogic-cz/agent-tools --skill git-workflow

简介

git-workflow 用于自动化 PR 生命周期管理，包括创建、CI 监控、评论回复与合并循环，适合在 Codex、Claude、Cursor、Gemini CLI 中加速协作流程时使用。

  • 它通过 bun gh-tool 命令实现端到端闭环，无需手动分步操作。
  • 使用时触发关键词即启动 aggressive loop，持续直至 CI 通过。
  • 安装前建议确认 GitHub Token 权限范围及分支保护规则兼容性。
  • 适用宿主包括 Codex、Claude、Cursor、Gemini CLI，接入前应确认版本、权限和运行环境要求。

SKILL.md

Git Workflow

PR lifecycle automation. Create PR → watch CI + reviews → fix → address → push → repeat until green.

For full bun gh-tool command reference, run bun gh-tool --help or bun gh-tool pr --help. This skill describes the workflow, not the tool surface.

For push, branch creation, and branch sync recipes, see references/push-branch-sync.md.

PR Workflow

Trigger: user says "pr", "pull request", "create PR", "CI failed", "address review comments", "merge when green", or similar.

The entire PR lifecycle runs as one continuous aggressive loop. There is no separate "fix comments" step — it is all one workflow.

Phase 1: Create or Update PR

First check whether a PR already exists:

bun gh-tool pr status

If no PR exists — create branch, commit, push, and open PR in one chain:

git checkout -b <branch> && git add -A && git commit -m "<msg>" && git push -u origin HEAD && bun gh-tool pr create --base <base> --title "<title>" --body "<body>"

If PR already exists — commit, push, and update metadata:

git add -A && git commit -m "<msg>" && git push origin HEAD
bun gh-tool pr edit --pr <pr_number> --title "<title>" --body "<body>"
  • If already on a feature branch, skip git checkout -b.
  • Base branch: argument provided by user (default: test).
  • Branch naming: feat/, fix/, chore/ based on changes.

PR Body Format

## Summary
<1-2 sentences>

## Changes
- <bullet list>

Commit Message Standard

Every commit MUST use proper conventional commits describing the actual change, not meta-descriptions like "address review feedback" or "fix CI".

Format: <type>(<scope>): <what actually changed>

  • type: fix, feat, refactor, perf, style, chore, etc.
  • scope: the module/area affected (e.g., auth, db, ui, api)
  • message: describe the concrete change, not why you are committing

Good examples:

  • fix(auth): add null check for session token before redirect
  • refactor(api): extract validation logic into shared middleware
  • fix(db): correct JOIN condition in user query

Bad examples (NEVER use these):

  • fix: address review feedback
  • fix: resolve CI check failures
  • chore: fix issues

If a single commit addresses multiple review comments across different scopes, make separate commits per scope rather than one catch-all.

Phase 2: Active Watch Loop

Immediately after PR creation/update, enter the active watch loop. No pause, no waiting for user input.

Inform user: "PR created/updated. Entering active watch loop — monitoring CI and reviews. (say 'stop' to exit)"

LOOP START

Step 1: Take a snapshot and decide what to do next

LOOP CONTRACT — mandatory behavior, not a suggestion:

  • After PR creation/update, stay inside this loop until LOOP EXIT.
  • After every fix + push, immediately return to Step 1.
  • After every reply/resolve pass, immediately return to Step 1.
  • If CI is still running, the loop is not done.
  • If visible-open review feedback still exists, the loop is not done.
  • Do not stop after one pass just because one category is clean.
  • Do not ask the user whether to continue unless the user said stop or the max-iteration guard is hit.

Always start Step 1 with a snapshot:

bun gh-tool pr review-triage --pr <pr_number>

This returns info, unresolvedThreads, visibleOpenThreads, summary, and checks in one call. Use it as the single source of truth for branching.

After the snapshot, branch immediately:

  • Checks failed → go to Step 2
  • Checks passed AND visible-open feedback exists → go to Step 3
  • Checks passed AND no visible-open feedback → go to LOOP EXIT
  • Checks still running AND visible-open feedback exists → go to Step 3 (work on feedback while CI runs)
  • Checks still running AND no feedback → block on CI:
bun gh-tool pr checks --pr <pr_number> --watch

When --watch completes, return to Step 1 for a fresh snapshot.

Do NOT build ad-hoc sleep polling loops around bun gh-tool. If work remains, handle it and then explicitly re-enter Step 1. If nothing remains except CI, use --watch.

Step 2: Handle CI failure

  1. First, decide: flaky or real?

- If the failure looks flaky (timeout, infra/network issue, unrelated service), rerun and return to Step 1: bun gh-tool pr rerun-checks --pr <pr_number> → Go back to LOOP START - If the failure looks real, continue below.

  1. Get failed check details: bun gh-tool pr checks-failed --pr <pr_number>
  2. If the output includes a workflow run and job name, fetch logs: bun gh-tool workflow job-logs --run <run_id> --job "<job_name>" --failed-steps-only
  3. Analyze the error, fix locally — do not ask, just fix.
  4. Run validation: bun run check
  5. Commit and push: git add -A && git commit -m "<type>(<scope>): <what changed>" && git push origin HEAD
  6. → Go back to LOOP START

Step 3: Check for reviews and triage feedback

The snapshot from Step 1 already contains threads and summary. Drill into details:

3.1 Inline review threads that still need attention:

Use --visible-open-only — it includes unresolved threads and resolved threads that still have no reply:

bun gh-tool pr threads --pr <pr_number> --visible-open-only

3.2 AI reviewer issue comments (Claude bot, Sentry Seer, etc.):

bun gh-tool pr issue-comments --pr <pr_number> --author claude --body-contains "Claude Code Review"
bun gh-tool pr issue-comments --pr <pr_number> --author sentry-io --body-contains "Sentry"

AI reviewers post findings as general PR comments with severity-tagged items (Critical, Major, Minor), file paths, and line numbers. Parse each comment body to extract actionable items.

3.3 Decision:

  • If NO visible-open threads AND NO actionable AI comments → PR is clean. → Go to LOOP EXIT
  • If ANY feedback found → proceed to Step 4

Step 4: Address every comment immediately

Before changing code, create one todo item per actionable comment/finding (use the todo-list tool if available, otherwise maintain an explicit numbered checklist in conversation).

  • One comment/finding = one tracked item.
  • Use a short label that identifies the source and problem.
  • Mark in_progress only while actively handling that single comment.
  • Mark completed only after the code change and the reply/resolve are both done.

For each comment/finding:

  1. Read the file at the specific line mentioned.
  2. Understand the suggestion — what change is being requested?
  3. Evaluate and act:

- Auto-apply (no confirmation): typos, style fixes, missing types, import cleanup, obvious bugs, performance improvements, security fixes matching CLAUDE.md conventions. - Apply with judgment: refactoring suggestions that improve clarity, error handling, naming improvements. - Ask user first: removing functionality, changing public API signatures, contradicting existing patterns, unclear suggestions.

  1. Make the fix immediately — track what was changed and why.

Step 5: Reply to comments and resolve threads

CRITICAL: Every thread MUST have a reply before being resolved.

For inline threads — reply and resolve in one step:

bun gh-tool pr reply-and-resolve --pr <pr_number> --comment-id <comment_id> --thread-id <thread_id> --body "<response>"

For general PR comments — post a reply:

bun gh-tool pr comment --pr <pr_number> --body "<response>"

Response format:

  • If fixed: "Addressed - [brief description of what was changed]"
  • If not applicable: "Not applicable - [brief explanation why]"
  • If positive feedback: "Thanks for the feedback!" or similar acknowledgment
  • If needs discussion: "Question: [ask for clarification]"

If reply fails with a pending-review validation error: submit the pending review first with bun gh-tool pr submit-review --pr <pr_number>, then retry. If it must be dismissed instead, dismiss it in GitHub first.

Do NOT resolve threads where you asked a question.

Step 6: Validate and push

bun run check

Fix any new issues. Then commit and push:

git add -A && git commit -m "<type>(<scope>): <what changed>" && git push origin HEAD

→ Go back to LOOP START

LOOP EXIT

When reaching here (all checks pass + no visible-open feedback):

Before the final success message, print a comment resolution summary list.

Use a numbered list with one item per handled comment/finding and this fixed structure:

1. Source: inline thread | general PR comment | AI review
   Identifier: <thread_id / comment_id / reviewer label>
   Problem: <short summary of the concern>
   Resolution: <what changed, or why it was not applicable>
   Changed files: <file A>, <file B> | none
   Replied: yes | no | n/a
   Resolved: yes | no | n/a
   Link: <comment or PR URL if available>

If no comments were found, say so explicitly instead of printing an empty structure.

Inform user: "All CI checks passed. All review comments addressed. PR is ready for review!"

Loop exit conditions

Exit the watch loop when:

  • All checks pass AND no visible-open feedback — natural exit.
  • User says "stop" or requests to exit.
  • Maximum 20 iterations reached — ask user if they want to continue.

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明，方便继续核验

能力 4

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用；具体调用方式请以来源页面和 README 为准。

平台分布

Codex

34.08%
按下载量换算158

Claude

30.3%
按下载量换算141

Cursor

18.12%
按下载量换算84

Gemini CLI

8.62%
按下载量换算40

安全审计

Gen Agent Trust Hub

通过

Socket

可疑

Snyk

可疑

权限和风险

敏感数据

该 Skill 可能接触密钥、Token、环境变量或敏感配置，应进入高风险复核队列，默认不自动发布。

安装前确认

本站仅展示第三方公开信息，不托管安装包，不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。来源安全扫描存在 warning/failed 结果，不能写成本站确认安全。当前只有一个来源，正式发布前建议补源仓库或其他目录站核验。

来源信息

GitHub 仓库

github.com

/blogic-cz/agent-tools

SKILL.md 来源

github.com

/blogic-cz/agent-tools/tree/main/skills/git-workflow

skills-sh

skills.sh

/blogic-cz/agent-tools/git-workflow

继续浏览同类 Skills

更多研究检索 Skills（73,675）返回 Skills 目录

上一个 Skill

git-workflow（Git 工作流）

git-workflow 用于查找、检索和筛选相关信息，适合在 Codex、Claude、Cursor、Gemini CLI 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态，以及是否会触发联网、命令执行或文件读写。

下一个 Skill

git-workflow（Git 工作流）

git-workflow 用于查找、检索和筛选相关信息，适合在 Codex、Claude、Cursor、Gemini CLI 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态，以及是否会触发联网、命令执行或文件读写。