agentleFS
MicrosoftKnown publishermicrosoft/waza/.github/skills/git-workflow/SKILL.md

git-workflow

Skill1.5k starsChanged 5 months agoMITView on GitHub

Squad branching model: dev-first workflow with insiders preview channel

  • Deletes or force-pushes
  • Installs packages
  • Commits and pushes

188 other projects use a version of this, 6 of them edited.

Trending

Less talk lately.about the whole repository

Dec 2025: 0 mentionsJan 2026: 0 mentionsFeb 2026: 0 mentionsMar 2026: 6 mentionsApr 2026: 5 mentionsMay 2026: 5 mentionsJun 2026: 4 mentionsJul 2026: 7 mentionsAug 2026: 8 mentionsSep 2026: 1 mentionOct 2026: 11 mentionsNov 2026: 3 mentions
Dec 2025Jun 2026Nov 2026
Mentions a month of the microsoft/waza repository that our weekly crawl found. There is no adoption data for this file yet.

Most recently taken up by

Who's talking about microsoft/waza

The biggest 5 of 50 mentions linking to the repository that our crawl found. Each line is their own headline.

See all 50

Talked about on GitHub and Bluesky (50 times).

On GitHub · 48

43 more on GitHub

On Bluesky · 2

Used with

Projects with it also use ci-cd-pipelines, architectural-proposals and 9 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • harrissohail6Skill

    ci-cd-pipelines

    CI/CD pipeline design and implementation. Auto-activates when discussing deployment, automation, or pipelines.

    Also in 6 projects that use this

  • Microsoft AzureSkill

    architectural-proposals

    How to write comprehensive architectural proposals that drive alignment before code is written

    Also in 4 projects that use this

  • Microsoft AzureSkill

    ci-validation-gates

    Defensive CI/CD patterns: semver validation, token checks, retry logic, draft detection — earned from v0.8.22

    Also in 4 projects that use this

  • GitHubSkill

    e2e-template-testing

    End-to-end validation of coordinator and agent template changes

    Also in 3 projects that use this

  • GitHubSkill

    notification-routing

    Route agent notifications to specific channels by type — prevent alert fatigue from single-channel flooding

    Also in 3 projects that use this

  • frostneySkill

    native-nostalgia-stack

    Applies the user's FreePascal toolchain and its build, formatting, hook, and test contracts while leaving project-specific mechanics local. Use when scaffolding or working in a FreePascal project that follows this toolchain.

    Also in 3 projects that use this

  • +4 more from Azure
  • +1 more from github

The file

We split this skill into the rules it gives an agent

9 rules. 0 are common, 6 are distinctive, and 3 are very specific to this project.

  • 0

    Common

    Most of the 164 edited versions we read keep these.

  • 6

    Distinctive

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    When the coordinator routes multiple issues simultaneously (e.g., "fix bugs X, Y, and Z"), use git worktree to give each agent an isolated …

    line 64
  2. Very specific:

    All PRs target dev independently.

    line 112
  3. Very specific:

    Rule: Never rewrite or reorder .squad/ files in a worktree — append only

    line 119
  4. Distinctive:

    After a worktree's PR is merged to dev:

    line 123
  5. Distinctive:

    If a worktree was deleted manually (rm -rf), git worktree prune recovers the state.

    line 133
  6. Distinctive:

    When work spans multiple repositories (e.g., squad-cli changes need squad-sdk changes, or a user's app depends on squad):

    line 139
  7. Distinctive:

    Create PRs in each repo independently

    line 156
  8. Distinctive:

    Before pushing, verify cross-repo changes work together:

    line 167
  9. Very specific:

    Important: Remove local links before committing.

    line 182

“Common” is measured: kept by at least 6 in 10 of the 164 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Context

Squad uses a three-branch model. All feature work starts from dev, not main.

BranchPurposePublishes
mainReleased, tagged, in-npm code onlynpm publish on tag
devIntegration branch — all feature work lands herenpm publish --tag preview on merge
insidersEarly-access channel — synced from devnpm publish --tag insiders on sync

Branch Naming Convention

Issue branches MUST use: squad/{issue-number}-{kebab-case-slug}

Examples:

  • squad/195-fix-version-stamp-bug
  • squad/42-add-profile-api

Workflow for Issue Work

  1. Branch from dev:
    git checkout dev
    git pull origin dev
    git checkout -b squad/{issue-number}-{slug}
  2. Mark issue in-progress:
    gh issue edit {number} --add-label "status:in-progress"
  3. Create draft PR targeting dev:
    gh pr create --base dev --title "{description}" --body "Closes #{issue-number}" --draft
  4. Do the work. Make changes, write tests, commit with issue reference.
  5. Push and mark ready:
    git push -u origin squad/{issue-number}-{slug}
    gh pr ready
  6. After merge to dev:
    git checkout dev
    git pull origin dev
    git branch -d squad/{issue-number}-{slug}
    git push origin --delete squad/{issue-number}-{slug}

Parallel Multi-Issue Work (Worktrees)

When the coordinator routes multiple issues simultaneously (e.g., "fix bugs X, Y, and Z"), use git worktree to give each agent an isolated working directory. No filesystem collisions, no branch-switching overhead.

When to Use Worktrees vs Sequential

ScenarioStrategy
Single issueStandard workflow above — no worktree needed
2+ simultaneous issues in same repoWorktrees — one per issue
Work spanning multiple reposSeparate clones as siblings (see Multi-Repo below)

Setup

From the main clone (must be on dev or any branch):

# Ensure dev is current
git fetch origin dev

# Create a worktree per issue — siblings to the main clone
git worktree add ../squad-195 -b squad/195-fix-stamp-bug origin/dev
git worktree add ../squad-193 -b squad/193-refactor-loader origin/dev

Naming convention: ../{repo-name}-{issue-number} (e.g., ../squad-195, ../squad-pr-42).

Each worktree:

  • Has its own working directory and index
  • Is on its own squad/{issue-number}-{slug} branch from dev
  • Shares the same .git object store (disk-efficient)

Per-Worktree Agent Workflow

Each agent operates inside its worktree exactly like the single-issue workflow:

cd ../squad-195

# Stage only the files changed for this issue, then inspect the commit contents
git add -- path/to/intentionally-changed-file
git diff --cached --stat
git diff --cached
git commit -m "fix: stamp bug (#195)"
git push -u origin squad/195-fix-stamp-bug

# Create PR targeting dev
gh pr create --base dev --title "fix: stamp bug" --body "Closes #195" --draft

All PRs target dev independently. Agents never interfere with each other's filesystem.

.squad/ State in Worktrees

The .squad/ directory exists in each worktree as a copy. This is safe because:

  • .gitattributes declares merge=union on append-only files (history.md, decisions.md, logs)
  • Each agent appends to its own section; union merge reconciles on PR merge to dev
  • Rule: Never rewrite or reorder .squad/ files in a worktree — append only

Cleanup After Merge

After a worktree's PR is merged to dev:

# From the main clone
git worktree remove ../squad-195
git worktree prune          # clean stale metadata
git branch -d squad/195-fix-stamp-bug
git push origin --delete squad/195-fix-stamp-bug

If a worktree was deleted manually (rm -rf), git worktree prune recovers the state.


Multi-Repo Downstream Scenarios

When work spans multiple repositories (e.g., squad-cli changes need squad-sdk changes, or a user's app depends on squad):

Setup

Clone downstream repos as siblings to the main repo:

~/work/
  squad-pr/          # main repo
  squad-sdk/         # downstream dependency
  user-app/          # consumer project

Each repo gets its own issue branch following its own naming convention. If the downstream repo also uses Squad conventions, use squad/{issue-number}-{slug}.

Coordinated PRs

  • Create PRs in each repo independently
  • Link them in PR descriptions:
    Closes #42
    
    **Depends on:** squad-sdk PR #17 (squad-sdk changes required for this feature)
  • Merge order: dependencies first (e.g., squad-sdk), then dependents (e.g., squad-cli)

Local Linking for Testing

Before pushing, verify cross-repo changes work together:

# Node.js / npm
cd ../squad-sdk && npm link
cd ../squad-pr && npm link squad-sdk

# Go
# Use replace directive in go.mod:
# replace github.com/org/squad-sdk => ../squad-sdk

# Python
cd ../squad-sdk && pip install -e .

Important: Remove local links before committing. npm link and go replace are dev-only — CI must use published packages or PR-specific refs.

Worktrees + Multi-Repo

These compose naturally. You can have:

  • Multiple worktrees in the main repo (parallel issues)
  • Separate clones for downstream repos
  • Each combination operates independently

Anti-Patterns

  • ❌ Branching from main (branch from dev)
  • ❌ PR targeting main directly (target dev)
  • ❌ Non-conforming branch names (must be squad/{number}-{slug})
  • ❌ Committing directly to main or dev (use PRs)
  • ❌ Switching branches in the main clone while worktrees are active (use worktrees instead)
  • ❌ Using worktrees for cross-repo work (use separate clones)
  • ❌ Leaving stale worktrees after PR merge (clean up immediately)

Promotion Pipeline

  • dev → insiders: Automated sync on green build
  • dev → main: Manual merge when ready for stable release, then tag
  • Hotfixes: Branch from main as hotfix/{slug}, PR to dev, cherry-pick to main if urgent

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.