Agent Skills › ownpilot/OwnPilot › git-workflow

git-workflow

GitHub

提供Git版本控制最佳实践指导，涵盖提交规范、分支策略、冲突解决及常用命令操作。

packages/gateway/data/example-skills/git-workflow/SKILL.md ownpilot/OwnPilot

Trigger Scenarios

用户询问Git操作或版本控制规范需要解决合并冲突或管理分支

Install

npx skills add ownpilot/OwnPilot --skill git-workflow -g -y

More Options

Non-standard path

npx skills add https://github.com/ownpilot/OwnPilot/tree/main/packages/gateway/data/example-skills/git-workflow -g -y

Use without installing

npx skills use ownpilot/OwnPilot@git-workflow

指定 Agent (Claude Code)

npx skills add ownpilot/OwnPilot --skill git-workflow -a claude-code -g -y

安装 repo 全部 skill

npx skills add ownpilot/OwnPilot --all -g -y

预览 repo 内 skill

npx skills add ownpilot/OwnPilot --list

SKILL.md

Frontmatter

{
    "name": "git-workflow",
    "license": "MIT",
    "metadata": {
        "author": "ownpilot",
        "version": "1.0.0"
    },
    "description": "Guides you through Git workflows — branching strategies, commit conventions, merge conflict resolution, and release management. Use when working with Git repositories or when the user asks about version control best practices.",
    "allowed-tools": "Bash(git:*)"
}

Git Workflow

You are an expert in Git version control. Follow these guidelines when helping with Git operations.

Commit Messages

Use Conventional Commits format:

<type>(<scope>): <description>

[optional body]

[optional footer]

Types: feat, fix, refactor, docs, test, chore, perf, ci, build

Examples:

feat(auth): add JWT refresh token rotation
fix(api): handle null response from payment gateway
refactor(db): extract repository base class

Branching Strategy

Default: GitHub Flow (simple, PR-based)

main — always deployable
feature/<name> — short-lived feature branches
fix/<name> — bug fix branches
release/<version> — release prep (if needed)

Merge Conflict Resolution

Understand both sides — read the conflicting changes before resolving
Keep both changes when they modify different things
Choose the newer logic when they modify the same thing
Test after resolving — conflicts in logic can introduce subtle bugs
Never blindly accept one side — "accept theirs" / "accept ours" loses work

Pull Request Checklist

Before submitting a PR:

Descriptive title (imperative: "Add feature" not "Added feature")
Summary of what and why (not how — the code shows how)
Tests added/updated for new behavior
No unrelated changes mixed in
No console.log / debug code left behind
Self-reviewed the diff one more time

Common Operations

When the user asks you to:

Create a branch: git checkout -b feature/<name>
Stage changes: Prefer git add <specific-files> over git add .
Amend last commit: git commit --amend (only if not pushed)
Squash commits: git rebase -i HEAD~N (only on local branches)
Undo last commit: git reset --soft HEAD~1 (keeps changes staged)
Cherry-pick: git cherry-pick <hash> (apply specific commit to current branch)