Agent skill

Git Workflow

by FerroxLabs in FerroxLabs/wayland

Git workflow expert covering branching strategies, commit conventions, interactive rebase, merge vs rebase, conflict resolution, git bisect, hooks, monorepo strategies, and CI integration.

Apache-2.0Auto-check passedDevelopment

Install Git Workflow

skills CLI
$ npx skills add FerroxLabs/wayland --skill git-workflow -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install FerroxLabs/wayland git-workflow --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/FerroxLabs/wayland.git skills-src && mkdir -p .claude/skills && cp -r skills-src/src/process/resources/skills-library/bodies/skills/software-engineering/git-workflow .claude/skills/git-workflow && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
git-workflow
GitHub stars
608
Token cost
~3.5k tokens
SKILL.md length
1,052 words
Files
1
Skills in repo
1,194
Repo updated
First seen
Licence
Apache-2.0

At a glance

Git workflow expert covering branching strategies, commit conventions, interactive rebase, merge vs rebase, conflict resolution, git bisect, hooks, monorepo strategies, and CI integration.

  • Works in 6 steps: Subject line under 72 characters. → Use imperative mood: "Add feature" not… → Do not end the subject with a period. → …
  • The user asks about git workflow
  • SKILL.md covers Branching Strategies, Commit Message Conventions, Merge vs Rebase and Interactive Rebase, plus 4 more sections
  • Calls git and npx

What it does

Git Workflow is an agent skill from FerroxLabs/wayland. Git workflow expert covering branching strategies, commit conventions, interactive rebase, merge vs rebase, conflict resolution, git bisect, hooks, monorepo strategies, and CI integration. Use when the user asks about git workflow, git workflow best practices, or needs guidance on git workflow implementation. Do NOT use when the user needs a different specialized skill or is asking about an unrelated technology domain.

Its SKILL.md is about 3.5k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Development, covering Git workflow. It works with Git. The repository describes itself as: Wayland - The AI Agent That Perceives. Reasons. Acts. Evolves. The licence is Apache-2.0.

When your agent uses it

  • The user asks about git workflow
  • Git workflow best practices
  • Needs guidance on git workflow implementation
  • The user needs a different specialized skill

Example prompts

  • “/git-workflow”

Requirements

  • Node.js

Workflow steps

6 steps, taken from the first numbered list in SKILL.md.

  1. Subject line under 72 characters.
  2. Use imperative mood: "Add feature" not "Added feature" or "Adds feature".
  3. Do not end the subject with a period.
  4. Separate subject from body with a blank line.
  5. Body explains what and why, not how (the diff shows how).
  6. Reference issues in the footer.

What it can do on your machine

Read from SKILL.md and the folder at commit 4c030c7. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • git
    • npx

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use git and npx, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Git Workflow loads about 3.5k tokens when it runs. Until then it costs about 109 tokens; SKILL.md has 1,052 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~109
When it runs · the whole SKILL.md, loaded when a task matches
~3.5k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from FerroxLabs/wayland at commit 4c030c7, republished under its Apache-2.0 licence (© FerroxLabs). 1,052 words, ~3,513 tokens.

Download SKILL.mdSave it as .claude/skills/git-workflow/SKILL.md (or your agent's skills folder).
name
git-workflow
description
Git workflow expert covering branching strategies, commit conventions, interactive rebase, merge vs rebase, conflict resolution, git bisect, hooks, monorepo strategies, and CI integration. Use when the user asks about git workflow, git workflow best practices, or needs guidance on git workflow implementation. Do NOT use when the user needs a different specialized skill or is asking about an unrelated technology domain.
license
Apache-2.0
metadata.author
foundry-skills
metadata.version
1.0.0
metadata.tags
best-practices version-control guide
metadata.category
software-engineering
metadata.subcategory
developer-tools
metadata.disclaimer
none
metadata.difficulty
intermediate

Git Workflow

You are an expert in Git workflows. Design and execute Git strategies that keep history clean, enable collaboration, and support CI/CD. Git is a tool for communication between developers across time. Every commit, branch, and merge tells a story.

Branching Strategies

main ─────●─────●─────●─────●─────●─────●─────
           \   /       \   /       \   /
            ●           ●           ●
        (short-lived feature branches, < 2 days)

Rules:

  • main is always deployable.
  • Feature branches live less than 2 days.
  • Use feature flags for incomplete features.
  • CI runs on every push. Broken builds are fixed immediately.
  • Release from main using tags or short-lived release branches.

Best for: Teams with CI/CD, experienced developers, frequent releases.

GitHub Flow
main ─────●─────────●─────────●─────
           \       /           \
            ●──●──●             ●──●
          (feature/xyz)      (fix/abc)
                |
            Pull Request

Rules:

  • main is always deployable.
  • Create a branch from main for every change.
  • Open a PR for review.
  • Merge via PR after approval and CI pass.
  • Deploy from main after merge.

Best for: Open-source projects, small-to-medium teams, web applications.

GitFlow
main ────────●───────────────●───── (releases only)
              \             /
develop ──●──●──●──●──●──●──●──── (integration)
           \     /   \     /
            ●──●      ●──●
         (feature)  (feature)
                              \
                     release/1.0 ──●──●
                                       \
                                    hotfix/1.0.1

Rules:

  • main tracks production releases.
  • develop is the integration branch.
  • Feature branches merge to develop.
  • Release branches stabilize the release.
  • Hotfix branches patch production directly.

Best for: Products with scheduled releases, mobile apps, enterprise software with support contracts.

When to Use Which
FactorTrunk-BasedGitHub FlowGitFlow
Release frequencyContinuousDaily-weeklyScheduled
Team sizeAnySmall-mediumMedium-large
CI/CD maturityHighMediumAny
Feature flagsRequiredOptionalNot needed
ComplexityLowLowHigh

Commit Message Conventions

Conventional Commits
<type>(<scope>): <subject>

<body>

<footer>
Types
TypeWhen
featNew feature
fixBug fix
docsDocumentation only
styleFormatting, missing semicolons (not CSS)
refactorCode change that neither fixes a bug nor adds a feature
perfPerformance improvement
testAdding or correcting tests
buildBuild system or external dependency changes
ciCI configuration changes
choreOther changes that do not modify src or test files
Examples
feat(auth): add OAuth2 login with Google

Implement Google OAuth2 flow using the authorization code grant.
Users can now sign in with their Google accounts.

Closes #234
fix(payments): prevent duplicate charges on retry

The payment service was not checking for existing charges before
retrying, causing duplicate charges when the initial request
timed out but actually succeeded.

Fixes #567
Commit Message Rules
  1. Subject line under 72 characters.
  2. Use imperative mood: "Add feature" not "Added feature" or "Adds feature".
  3. Do not end the subject with a period.
  4. Separate subject from body with a blank line.
  5. Body explains what and why, not how (the diff shows how).
  6. Reference issues in the footer.
What Makes a Good Commit
  • Atomic: One logical change per commit. Not "fix bug and add feature and update docs".
  • Complete: The codebase compiles and tests pass after every commit.
  • Meaningful: Each commit tells a story. Squash "WIP" and "fix typo" before merging.

Merge vs Rebase

Merge
main:    A──B──C────────M──
              \        /
feature:       D──E──F
  • Preserves complete history and branch topology.
  • Creates a merge commit.
  • Non-destructive: never rewrites history.
Rebase
Before:
main:    A──B──C
              \
feature:       D──E──F

After rebase:
main:    A──B──C
                 \
feature:          D'──E'──F'
  • Produces a linear history.
  • Rewrites commit hashes (D, E, F become D', E', F').
  • Must NOT be used on shared/public branches.
Decision Framework
SituationUse
Updating a personal feature branch with latest mainRebase
Merging a feature branch into mainMerge (or squash merge)
Shared branch with multiple contributorsMerge (never rebase shared branches)
Cleaning up local commits before PRInteractive rebase
Preserving detailed development historyMerge
Creating a clean, linear historyRebase + merge
Squash Merge
shell
git merge --squash feature/xyz
git commit -m "feat(auth): add OAuth2 login"

Collapses all feature branch commits into one. Good for clean main history, but loses granular commit information.

Interactive Rebase

Use interactive rebase to clean up commits before pushing or merging.

shell
# Rebase last 4 commits
git rebase -i HEAD~4

Editor shows:

pick a1b2c3d feat: add user model
pick e4f5g6h fix: typo in user model
pick i7j8k9l feat: add user controller
pick m0n1o2p fix: missing import in controller

Clean up:

pick a1b2c3d feat: add user model
fixup e4f5g6h fix: typo in user model        # fold into previous, discard message
pick i7j8k9l feat: add user controller
fixup m0n1o2p fix: missing import in controller  # fold into previous
Rebase Commands
CommandEffect
pickKeep the commit as-is
rewordKeep the commit but change the message
editStop at this commit to amend it
squashFold into previous commit, combine messages
fixupFold into previous commit, discard this message
dropRemove the commit entirely
reorderChange the order of commits by moving lines

Conflict Resolution

Process
  1. Understand the conflict. Read both sides. Do not blindly accept one.
  2. Check the intent. Look at the original commits on each side to understand the purpose.
  3. Resolve semantically, not textually. The correct resolution may not be either version or a simple combination.
  4. Test after resolution. Compile and run tests.
  5. Do not introduce new changes in a conflict resolution commit.
Conflict Markers
<<<<<<< HEAD
const timeout = 5000;
=======
const timeout = 10000;
>>>>>>> feature/increase-timeout
Show full SKILL.md (425 more words)Show less
Reducing Conflicts
  • Keep branches short-lived (< 2 days).
  • Merge/rebase from main frequently.
  • Avoid formatting-only commits that touch many lines.
  • Avoid moving code unless necessary.
  • Communicate about large refactorings before starting.

Git Bisect

Binary search through commits to find the one that introduced a bug.

shell
# Start bisecting
git bisect start

# Mark current commit as bad (has the bug)
git bisect bad

# Mark a known-good commit
git bisect good v1.2.0

# Git checks out the midpoint. Test it.
# If this commit has the bug:
git bisect bad
# If this commit is fine:
git bisect good

# Repeat until the first bad commit is identified
# Git reports: "abc1234 is the first bad commit"

# Return to original state
git bisect reset
Automated Bisect
shell
# Run a test script at each step
git bisect start HEAD v1.2.0
git bisect run npm test
# Git automatically finds the first commit where tests fail

Git Hooks

Useful Hooks
HookRuns whenUse for
pre-commitBefore commit is createdLint, format, type check
commit-msgAfter message is writtenValidate commit message format
pre-pushBefore push to remoteRun tests, prevent force push to main
prepare-commit-msgBefore editor opensPopulate template
post-mergeAfter merge completesInstall deps, run migrations
post-checkoutAfter branch switchInstall deps, clear caches
Managing Hooks with Tools
shell
# Husky (Node.js)
npx husky init
echo "npx lint-staged" > .husky/pre-commit

# pre-commit (Python)
# .pre-commit-config.yaml
repos:
  - repo: [reference URL]
    rev: v4.5.0
    hooks:
      - id: trailing-whitespace
      - id: end-of-file-fixer
      - id: check-yaml
  - repo: [reference URL]
    rev: 24.1.0
    hooks:
      - id: black
lint-staged Configuration
json
{
  "lint-staged": {
    "*.{ts,tsx}": ["eslint --fix", "prettier --write"],
    "*.{css,scss}": ["stylelint --fix", "prettier --write"],
    "*.{json,md}": ["prettier --write"]
  }
}

Monorepo Git Strategies

Sparse Checkout

Check out only the directories you need:

shell
git sparse-checkout init --cone
git sparse-checkout set packages/my-package packages/shared
Shallow Clone

Reduce clone time by fetching limited history:

shell
git clone --depth 1 --filter=blob:none <url>
# Get more history later if needed
git get --unshallow
CODEOWNERS

Automatically assign reviewers based on file paths:

# .github/CODEOWNERS
packages/auth/**        @auth-team
packages/payments/**    @payments-team
packages/shared/**      @platform-team
*.md                    @docs-team

CI Integration

Branch Protection Rules
  • Require PR review before merge.
  • Require status checks to pass (CI, linting, tests).
  • Require up-to-date branch before merge.
  • Prevent force push to main.
  • Require signed commits (optional, for high-security projects).
CI Pipeline Triggers
yaml
# GitHub Actions
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
    paths-ignore:
      - '**.md'
      - 'docs/**'
Optimizing CI for Git
  • Use shallow clones in CI: get-depth: 1.
  • Cache dependencies between runs.
  • Run only affected tests on PRs (use git diff --name-only to detect changed files).
  • Use merge queue to batch PRs and reduce CI runs.

Essential Git Commands

Recovery Commands
shell
# Undo last commit, keep changes staged
git reset --soft HEAD~1

# Undo last commit, keep changes unstaged
git reset HEAD~1

# Recover a deleted branch
git reflog                  # find the commit hash
git checkout -b recovered-branch abc1234

# Recover a dropped stash
git fsck --unreachable | grep commit
git show <hash>

# Undo a pushed merge (creates a revert commit)
git revert -m 1 <merge-commit-hash>
Investigation Commands
shell
# Who changed this line and when?
git blame -L 10,20 src/auth.ts

# When was a string introduced?
git log -S "secretFunction" --oneline

# What changed between two branches?
git diff main...feature/xyz --stat

# Show the full history of a file, including renames
git log --follow -p -- path/to/file
Cleanup Commands
shell
# Remove branches merged into main
git branch --merged main | grep -v main | xargs git branch -d

# Remove remote tracking branches that no longer exist
git remote prune origin

# Reduce repo size by cleaning up unreachable objects
git gc --aggressive --prune=now

When to Use

Use this skill when:

  • Designing or implementing git workflow solutions
  • Reviewing or improving existing git workflow approaches
  • Making architectural or implementation decisions about git workflow
  • Learning git workflow patterns and best practices
  • Troubleshooting git workflow-related issues

Do NOT use this skill when:

  • The question is about a fundamentally different technology domain
  • A more specific sibling skill covers the exact topic needed
  • The user needs a complete hands-on tutorial rather than expert guidance

Output Format

markdown
# Git Workflow Analysis

## Context Assessment
[Situation summary and constraints]

## Recommended Approach
[Primary recommendation with rationale]

## Implementation Steps
1. [Step with specific details]
2. [Step with specific details]
3. [Step with specific details]

## Trade-offs and Considerations
- [Key trade-off 1]
- [Key trade-off 2]

## Next Steps
- [Immediate action item]
- [Follow-up action item]

Example

Input: "Help me implement git workflow for a medium-scale production application"

Output: A structured analysis covering current state assessment, recommended git workflow approach with specific patterns, implementation roadmap with milestones, and risk mitigation strategies tailored to the application scale and constraints.

Edge Cases

  • Legacy system integration: When git workflow must coexist with legacy approaches, provide a gradual migration path rather than a complete rewrite
  • Scale mismatch: When the solution complexity exceeds the project scale, recommend a simpler approach and note when to revisit
  • Team skill gaps: When the team lacks experience with the recommended approach, include learning resources and simpler alternatives
  • Conflicting requirements: When constraints conflict (e.g., performance vs. maintainability), explicitly state the trade-off and recommend based on stated priorities

© FerroxLabs, Apache-2.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in src/process/resources/skills-library/bodies/skills/software-engineering/git-workflow of FerroxLabs/wayland.

Open the folder on GitHubat commit 4c030c7

Compare with similar skills

Git Workflow next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Git Workflow compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Git Workflow this skillFerroxLabs/wayland608—~3.5kAutomated safety check: PassApache-2.0
Finishing a Development Branchobra/superpowers296k5 repos~1.9kAutomated safety check: PassMIT
Code Design Rationale Investigatorcursor/plugins10k9 repos~2.6kAutomated safety check: PassNone
Contributor-First PR MergeHKUDS/OpenHarness16k1 repos~847Automated safety check: PassMIT
Migrate Internal Package into GhostTryGhost/Ghost55k—~3.8kAutomated safety check: PassMIT
Create Pull Requestcline/cline70k1 repos~1.6kAutomated safety check: PassApache-2.0

Similar skills

  • Walks the last step of a branch: confirm tests pass, detect the git environment, ask how to integrate, carry out your choice and clean up the worktree.

    296k GitHub starsUsed in 5 repos~1.9k tokens
    DevelopmentAuto-check passed
  • Official

    Digs into why code is shaped the way it is by checking git history, pull requests and connected tools in parallel, then reporting a cited read on the tradeoffs.

    10k GitHub starsUsed in 9 repos~2.6k tokens
    DevelopmentAuto-check passed
  • Merges external GitHub pull requests while keeping the original author credited, and fixes conflicts after the merge instead of rewriting the contribution.

    16k GitHub starsUsed in 1 repo~847 tokens
    DevelopmentAuto-check passed
  • Moves a package from another TryGhost repository into Ghost as an internal workspace package while keeping its Git history, with checkpoints for the steps that need an administrator.

    55k GitHub stars~3.8k tokensUpdated today
    DevelopmentAuto-check passed
  • Opens a GitHub pull request from your current branch with the gh CLI, after reviewing the commits and diff and gathering the details the PR needs.

    70k GitHub starsUsed in 1 repo~1.6k tokens
    DevelopmentAuto-check passed
  • Git Merge Conflict Resolver

    tailcallhq/forgecode

    Resolves Git merge conflicts with a plan-first workflow that keeps both sides' intent, regenerates lock files and backs up deleted-but-modified files.

    7.6k GitHub starsUsed in 1 repo~4.5k tokens
    DevelopmentAuto-check passed

More from FerroxLabs/wayland

All 1,194 skills in this repo
  • Star Office Helper

    FerroxLabs/wayland

    Install, start, connect, and troubleshoot visualization companion projects for Aion/OpenClaw, with Star-Office-UI as the default recommendation.

    608 GitHub stars~2.2k tokensUpdated yesterday
    Auto-check: notes
  • Openclaw Setup

    FerroxLabs/wayland

    OpenClaw usage expert: Helps you install, deploy, configure, and use OpenClaw personal AI assistant.

    608 GitHub stars~1.9k tokensUpdated yesterday
    Auto-check passed
  • Tvcontrol Setup

    FerroxLabs/wayland

    Set up TVControl end to end: install the connector, start TradingView Desktop with its control port open, load a watchlist export, add the indicators they use, and leave a working chart.

    608 GitHub stars~5.7k tokensUpdated yesterday
    Auto-check passed
  • Ab Testing Specialist

    FerroxLabs/wayland

    End-to-end guide for designing, running, and analyzing A/B tests including experiment design, statistical significance, sample size calculation, common pitfalls, and advanced testing patterns.

    608 GitHub stars~3.7k tokensUpdated yesterday
    Auto-check passed
  • Academic Writer

    FerroxLabs/wayland

    Complete academic writing guide covering thesis and dissertation structure, journal article format using IMRaD, literature review methodology, citation management, the peer review process, and…

    608 GitHub stars~4.5k tokensUpdated yesterday
    Auto-check passed
  • Accessibility Auditor

    FerroxLabs/wayland

    Web accessibility expertise covering WCAG 2.2 conformance, audit methodology, ARIA patterns, keyboard navigation, screen reader testing, focus management, form accessibility, and automated vs manual…

    608 GitHub stars~4.1k tokensUpdated yesterday
    Auto-check passed

Works with

Categories

Questions about Git Workflow

What does Git Workflow do?

Git workflow expert covering branching strategies, commit conventions, interactive rebase, merge vs rebase, conflict resolution, git bisect, hooks, monorepo strategies, and CI integration. Git Workflow is an agent skill from FerroxLabs/wayland. Git workflow expert covering branching strategies, commit conventions, interactive rebase, merge vs rebase, conflict resolution, git bisect, hooks, monorepo strategies, and CI integration.

When should I use Git Workflow?

Git Workflow fits situations like: the user asks about git workflow; Git workflow best practices; needs guidance on git workflow implementation; the user needs a different specialized skill.

How do I install Git Workflow in Claude Code?

Run `npx skills add FerroxLabs/wayland --skill git-workflow -a claude-code`. Or copy the skill folder (src/process/resources/skills-library/bodies/skills/software-engineering/git-workflow in FerroxLabs/wayland) into .claude/skills/git-workflow in your project. Claude Code loads it when a task matches its description.

How do I install Git Workflow in Codex?

Run `npx skills add FerroxLabs/wayland --skill git-workflow -a codex`. Or copy the skill folder (src/process/resources/skills-library/bodies/skills/software-engineering/git-workflow in FerroxLabs/wayland) into .agents/skills/git-workflow in your project. Codex loads it when a task matches its description.

Can I use Git Workflow in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add FerroxLabs/wayland --skill git-workflow -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/git-workflow, .gemini/skills/git-workflow, .github/skills/git-workflow and .opencode/skills/git-workflow in your project.

What does Git Workflow need to run?

Going by SKILL.md and its folder, Git Workflow needs the command-line tools its instructions call (git and npx). Our summary lists: Node.js.

Does Git Workflow access the network?

SKILL.md contains no URLs. Its commands use git and npx, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Git Workflow safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Git Workflow use?

Git Workflow is published under the Apache-2.0 licence (declared in SKILL.md). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Git Workflow use?

About 3.5k tokens (SKILL.md is roughly 14k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Git Workflow?

Skills that share tags, products or a category with Git Workflow: Finishing a Development Branch (obra/superpowers, 296k stars), Code Design Rationale Investigator (cursor/plugins, 10k stars), Contributor-First PR Merge (HKUDS/OpenHarness, 16k stars) and Migrate Internal Package into Ghost (TryGhost/Ghost, 55k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Git Workflow?

FerroxLabs (a GitHub user) maintains it in FerroxLabs/wayland, which has 608 GitHub stars. The repository holds 1,194 skills in this directory. The repository was last updated on October 6, 2026.

Source: FerroxLabs/wayland on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.