git-workflow（Git 工作流） Skills下载安装命令和教程

安装方式

通过对话安装

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

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

命令行安装

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

skills.shnpx skills

npx skills add https://github.com/wyattowalsh/agents --skill git-workflow

简介

用于根据关键词或任务场景快速定位候选结果。

适合在需要检索仓库信息或筛选线索时使用。
可结合来源仓库和原始 README 核验具体用法。
安装命令：npx skills add https://github.com/wyattowalsh/agents --skill git-workflow。
安装前建议确认是否会触发联网或文件读写。

SKILL.md

Git Workflow

Git operations assistant. Lightweight, high-frequency tool for commit messages, PR descriptions, branch strategy, conflict resolution, code archaeology, and bisect debugging.

Scope: Git workflow operations only. NOT for code review (honest-review), CI/CD pipelines (devops-engineer), changelogs or release notes (changelog-writer), or writing application code.

Dispatch

$ARGUMENTS	Mode
`commit`	Generate conventional commit message from staged diff
`pr`	Generate PR description from branch diff
`strategy`	Recommend branch strategy for project
`conflict`	Guide merge conflict resolution
`archaeology <file or function>`	Analyze git history for code understanding
`bisect`	Assist with git bisect to find regression commits
Empty	Show mode menu with examples

Canonical Vocabulary

Use these terms exactly throughout all modes:

Term	Definition
conventional commit	Structured commit format: `type(scope): subject` per Conventional Commits 1.0
commit type	One of: feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert
breaking change	Commit with `!` suffix or `BREAKING CHANGE:` footer requiring major version bump
scope	Optional parenthesized component name after type: `feat(auth):...`
trunk-based	Strategy where all developers commit to main/trunk with short-lived feature branches
git-flow	Strategy with develop, feature, release, and hotfix branches
github-flow	Simplified strategy: main + feature branches with PR-based merging
conflict marker	Git-inserted `<<<<<<<`, `=======`, `>>>>>>>` delimiters in conflicted files
blame	`git blame` annotation showing last modifier per line
archaeology	Using git history commands to understand why code exists
bisect	Binary search through commits to find the one introducing a bug
good/bad commit	Bisect terminology: good = before bug, bad = after bug

Mode 1: Commit

Generate a conventional commit message from the current staged diff.

Commit Steps

Run git diff --cached to get staged changes
If nothing staged, run git diff and report: "No staged changes. Stage files first with git add."
Run uv run python skills/git-workflow/scripts/diff-summarizer.py on the diff output
Analyze the diff to determine:

- Type: feat/fix/docs/style/refactor/perf/test/build/ci/chore/revert - Scope: affected component (from file paths, module names) - Subject: imperative, lowercase, no period, max 72 chars - Body: what changed and why (wrap at 72 chars) - Breaking: whether BREAKING CHANGE: footer is needed

Reference data/conventional-commits.json rules for type selection
Present the commit message. Ask: "Commit with this message? [yes / edit / cancel]"
If approved, run git commit -m "$(cat <<'EOF'\n<message>\nEOF\n)"

Mode 2: PR

Generate a PR description from the branch diff against the base branch.

PR Steps

Detect base branch: git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's@refs/remotes/origin/@@' (fallback: main)
Run git log --oneline <base>..HEAD to list commits
Run uv run python skills/git-workflow/scripts/commit-parser.py on git log output
Run git diff <base>...HEAD --stat for change statistics
Run uv run python skills/git-workflow/scripts/diff-summarizer.py on the diff stat
Generate PR description with:

- Title: short summary under 70 chars - Summary: 1-3 bullet points of what changed - Changes: grouped by commit type from parsed commits - Test plan: checklist of verification steps - Breaking changes: if any commits have breaking changes

Present the description. Ask: "Create PR with this? [yes / edit / skip]"

Mode 3: Strategy

Recommend a branch strategy for the project.

Strategy Steps

Analyze the repository:

- Team size: check git shortlog -sn --all | wc -l - Release cadence: check tags with git tag -l --sort=-creatordate | head -20 - Branch count: git branch -r | wc -l - CI/CD presence: check for .github/workflows/, Jenkinsfile, .gitlab-ci.yml

Reference data/branch-strategies.json for strategy comparison
Score each strategy against the project profile
Present recommendation with:

- Recommended strategy and why - Comparison table showing trade-offs - Migration steps if switching from current approach - Team size and release cadence alignment

Mode 4: Conflict

Guide merge conflict resolution.

Conflict Steps

Run git diff --name-only --diff-filter=U to list conflicted files
If no conflicts: "No merge conflicts detected."
For each conflicted file:

- Read the file to identify conflict markers - Analyze both sides (ours vs theirs) - Check git log --merge -p -- <file> for context on diverging changes - Determine the intent of each side

Present resolution guidance per file:

- What each side changed and why - Recommended resolution (keep ours / keep theirs / merge both / rewrite) - The resolved content

Ask: "Apply this resolution? [yes / edit / skip per file]"
After resolving: remind to git add <files> and continue the merge/rebase

Mode 5: Archaeology

Analyze git history to understand why code exists and how it evolved.

Archaeology Steps

Parse $ARGUMENTS[1] as a file path or function name
For file paths:

- git log --follow --oneline -- <file> for full history - git log --follow --diff-filter=A -- <file> for creation commit - git blame <file> for line-by-line attribution

For function names:

- git log -p --all -S '<function>' -- '*.py' '*.js' '*.ts' (pickaxe search) - git log -L:<function>:<file> if file is known (function-level log)

Analyze the history to answer:

- When was this code introduced and by whom? - What was the original intent? (from commit messages) - How has it evolved? (key modification commits) - Are there related changes in other files?

Present a narrative timeline with key commits and their context

Mode 6: Bisect

Assist with git bisect to find the commit that introduced a regression.

Bisect Steps

Ask for (if not provided):

- Bad commit: where the bug exists (default: HEAD) - Good commit: where the bug did not exist - Test command: how to verify (optional, for git bisect run)

Start bisect: git bisect start <bad> <good>
If test command provided:

- Run git bisect run <command> - Parse output for the first bad commit

If manual:

- At each step, explain the current commit context - Ask: "Is this commit good or bad?" - Run git bisect good or git bisect bad

When bisect identifies the commit:

- Show the full commit with git show <hash> - Explain what the commit changed - Suggest investigation areas

Clean up: git bisect reset

Reference Files

Load ONE reference at a time. Do not preload all references into context.

File	Content	Load When
`references/commit-and-pr-guide.md`	Conventional commit patterns, PR templates, diff analysis	commit or pr mode
`references/branch-strategies.md`	Strategy comparison, migration paths, team sizing	strategy mode
`references/history-and-debugging.md`	Conflict resolution, archaeology techniques, bisect patterns	conflict, archaeology, or bisect mode

Data File	Content	Load When
`data/conventional-commits.json`	Full spec as structured data with type definitions	commit mode (script input)
`data/branch-strategies.json`	Strategy comparison with pros/cons/team size	strategy mode (script input)

Script	When to Run
`scripts/commit-parser.py`	pr mode -- parse git log into structured JSON
`scripts/diff-summarizer.py`	commit or pr mode -- summarize diff statistics

Critical Rules

Never commit without user approval -- always present the message first
Never force-push, reset --hard, or run destructive git commands
Always use conventional commit format per the spec in data/conventional-commits.json
Commit subjects must be imperative, lowercase, no period, max 72 chars
PR descriptions must link changes to evidence from the diff
Never skip git bisect reset after a bisect session
Archaeology mode is read-only -- never modify code or history
Conflict resolution must explain both sides before recommending
Branch strategy must consider actual team size and release cadence, not ideals
Scripts output JSON to stdout -- parse programmatically, never regex
Stage-before-commit: if diff --cached is empty, do not fabricate a commit message
Do not generate changelogs or release notes -- redirect to changelog-writer

适合场景

01

用户想查找某类 Agent Skill 时

02

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

03

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

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

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

能力 4

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

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

平台分布

Codex

37.91%

按下载量换算45

Claude

29.13%

按下载量换算35

Cursor

17.67%

按下载量换算21

Gemini CLI

9.66%

按下载量换算12

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

通过

权限和风险

只读

该 Skill 主要提供规则、说明或参考内容，本身偏只读；真正读写文件、联网或执行命令仍取决于宿主 Agent 的任务。

安装前确认

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

来源信息

GitHub 仓库

github.com

/wyattowalsh/agents

SKILL.md 来源

github.com

/wyattowalsh/agents/tree/main/skills/git-workflow

skills-sh

skills.sh

/wyattowalsh/agents/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 继续核验具体用法。安装前建议确认权限范围、维护状态，以及是否会触发联网、命令执行或文件读写。