agentleFS
fusebase-devfusebase-dev/fusebase-flow/.agents/skills/git-workflow/SKILL.md

git-workflow

Skill9 starsChanged 27 days agoMITView on GitHub

General Git workflow for generated apps: safe local commits, clean history, and rollback guidance. Includes strict debug/deploy traceability section when git-debug-commits flag is enabled.

  • Reads credentials
  • Deletes or force-pushes

189 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

Show its rules and text

We split this skill into the rules it gives an agent

14 rules. 0 are common, 11 are distinctive, and 3 are very specific to this project.

  • 0

    Common

    Most of the 166 edited versions we read keep these.

  • 11

    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
  • could be automatic: a setting could enforce it
  1. Distinctive:

    Use this skill for day-to-day Git work in generated apps:

    line 10
  2. Distinctive:

    keep commits focused and understandable,

    line 12
  3. Distinctive:

    Commit with reason-focused message.

    line 22
  4. Distinctive:

    Keep unrelated changes in separate commits.

    line 23
  5. Distinctive:

    Prefer small, scoped commits.

    line 27
  6. Very specific:

    Do not commit .env, credentials, or token files.

    line 29
  7. Distinctive:

    Avoid history rewrite unless explicitly requested.

    line 30
  8. Very specific:

    Use revert by default on shared branches.

    line 48
  9. Distinctive:

    Always review git status --short after these operations.

    line 57
  10. Very specific:

    When git-debug-commits is enabled, apply these stricter rules.

    line 62
  11. Distinctive:

    If tree is dirty, block deploy by default and continue only with explicit user approval.

    line 74
  12. Distinctive:

    Do not batch unrelated fixes.

    line 84
  13. Distinctive:

    Do not continue to the next fix until the current verified fix is committed.

    line 85
  14. Distinctive:

    If a fix was verified but not committed, deploy is blocked until the commit exists.

    line 86

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

Purpose

Use this skill for day-to-day Git work in generated apps:

  • keep commits focused and understandable,
  • avoid committing secrets,
  • keep rollback simple.

Baseline Workflow

  1. Check current state:
    • git status --short
    • git rev-parse --abbrev-ref HEAD
  2. Group related changes.
  3. Commit with reason-focused message.
  4. Keep unrelated changes in separate commits.

Commit Rules

  • Prefer small, scoped commits.
  • Message should explain why.
  • Do not commit .env, credentials, or token files.
  • Avoid history rewrite unless explicitly requested.

Suggested message patterns:

  • feat: <why>
  • fix: <why>
  • chore: <why>

Rollback Guidance

Preferred shared-history rollback:

  • git revert <commit_sha>

Temporary local rollback during active iteration:

  • git reset --hard <commit_sha_before_change>

Use revert by default on shared branches.

Operations That Commonly Need Separate Commits

  • fusebase app create/update (fusebase.json changes)
  • fusebase update --skip-mcp --skip-deps --skip-cli-update --skip-commit (AGENTS.md, .claude/* changes)
  • fusebase config ide / fusebase integrations (IDE MCP config changes)
  • fusebase env create (.env local changes; usually not committed)

Always review git status --short after these operations.

<% if (it.flags?.includes("git-debug-commits")) { %>

Strict Debug/Deploy Traceability (Flag: git-debug-commits)

When git-debug-commits is enabled, apply these stricter rules.

These are mandatory rules (not recommendations).

Deploy Preflight (Required)

Before fusebase deploy:

  • git status --short
  • git rev-parse --abbrev-ref HEAD
  • git rev-parse HEAD

If tree is dirty, block deploy by default and continue only with explicit user approval.

Commit Per Verified Fix (Required)

For each verified debug fix:

  1. git add -A
  2. git commit -m "fix(debug): <why>"
  3. record git rev-parse --short HEAD

Do not batch unrelated fixes. Do not continue to the next fix until the current verified fix is committed. If a fix was verified but not committed, deploy is blocked until the commit exists.

Deploy Trace Marker

After successful deploy:

  • record deployed git rev-parse HEAD in report,
  • optionally add tag:
    • git tag -a deploy/<app-or-app>/<timestamp> -m "Deploy trace marker"

Report Requirements

For each fix:

  • issue summary,
  • verification done,
  • commit SHA,
  • rollback command (git revert <sha>).

For each deploy:

  • target,
  • preflight result (clean or approved-dirty),
  • deployed SHA,
  • optional tag. <% } %>

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.