agentleFS
cedaniel200cedaniel200/atlas-template/.agents/skills/git-workflow/SKILL.md

git-workflow

Skill3 starsChanged 20 days agoMITView on GitHub

Git flow for changes: isolated branch/worktree, incremental commits, pull request and post-merge cleanup.

  • Commits and pushes

188 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use squad-commands, ci-cd-pipelines and 10 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.
  • Microsoft AzureSkill

    squad-commands

    Categorized catalog of common Squad operations. Coordinator reads this file and presents it as an interactive menu when the user asks for available commands or help.

    Also in 5 projects that use this

  • 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

  • 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

  • +5 more from Azure
  • +1 more from github

The file

We split this skill into the rules it gives an agent

6 rules. 0 are common, 4 are distinctive, and 2 are very specific to this project.

  • 0

    Common

    Most of the 165 edited versions we read keep these.

  • 4

    Distinctive

    This author's own choices. Worth a look.

  • 2

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Every rule that mentions the default branch refers to $BASE.

    line 19
  2. Distinctive:

    All work for the change (artifacts, code, reports) happens inside that worktree.

    line 39
  3. Distinctive:

    Verify design → code consistency.

    line 48
  4. Distinctive:

    Update documentation if business rules changed.

    line 49
  5. Distinctive:

    When the default branch must stay stable, use an integration branch:

    line 82
  6. Very specific:

    Do not rewrite history of shared branches.

    line 103

“Common” is measured: kept by at least 6 in 10 of the 165 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

Git workflow

Default branch

The examples use main. If the project uses another name (master, develop, trunk…), that name is the default branch. Detect it once instead of assuming:

BASE=$(git symbolic-ref --short refs/remotes/origin/HEAD | sed 's#^origin/##')
echo "$BASE"   # -> main

Every rule that mentions the default branch refers to $BASE.

Start

git checkout "$BASE"
git pull origin "$BASE"

Branches and worktrees are created from an up-to-date default branch.

Change cycle

1. Isolate

git worktree add .worktrees/<change> -b feature/<change>
cd .worktrees/<change>

All work for the change (artifacts, code, reports) happens inside that worktree.

2. Commit

One logical change = one commit (see conventional-commits). An agent commits after each approved step; it never accumulates work.

3. Close

  1. Verify design → code consistency.
  2. Update documentation if business rules changed.
  3. Open the pull request:
gh pr create --base "$BASE" --head feature/<change> --title "<type>: <change>"

gh (GitHub CLI) es opcional: si no está instalado, abre el PR desde la web con los mismos datos (base, head, título y cuerpo). No bloquea el flujo.

  1. The user reviews and approves archive; commit it in the same PR, then the user merges.

4. Post-merge

git branch -d feature/<change>
git worktree remove .worktrees/<change>

Simple branch exception

A feature branch in the main checkout replaces the worktree only when all of these hold:

  • the human asks for it explicitly;
  • the working tree is clean;
  • the change branch is the same in the project and its submodules (no mixed branch state);
  • the exception is recorded in the change;
  • the branch is never the base branch.

Otherwise use a worktree. The pre-commit guard still blocks any commit on the base branch.

Integration branches

When the default branch must stay stable, use an integration branch:

<default branch>
  └── feat/<stage>
        ├── feat/<stage>-part-1
        └── feat/<stage>-part-2

Partial PRs target the integration branch; the merge to the default branch happens once at the end.

Bootstrap exception

The initial setup (.atlas/BOOTSTRAP.md) is the only task that does not use a change worktree. It runs on its own chore/bootstrap branch, with one commit per phase and no push unless the user asks. The user reviews and merges that branch.

Rules

  • The default branch is always clean and up to date.
  • Never commit secrets.
  • Do not rewrite history of shared branches. --force-with-lease only on your own, unmerged branches.
  • Role byline on agent commits: By <role>.
  • A worktree per change; no two changes in the same worktree.

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.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

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.