agentleFS
Sign inStart free
rcdelfinrcdelfin/agentkit/skills/software-development/spatie-version-control/SKILL.md

spatie-version-control

Skill2 starsChanged 3 months agoMITView on GitHub

Use when choosing Git branch, commit, merge, repository, or pull-request conventions based on Spatie guidelines.

2 other projects use a version of this, 2 of them edited.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

10 rules. About 0 are common, 7 are distinctive, and 3 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈7

    Distinctive · estimate

    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. Very specific:

    Use the main domain name in lowercase, without www:

    line 30
  2. Very specific:

    Commit through develop, not directly to main.

    line 54
  3. Very specific:

    Delete the develop branch.

    line 59
  4. Distinctive:

    All commits to main must come through feature branches.

    line 60
  5. Distinctive:

    Prefer squashing commits on merge.

    line 61
  6. Distinctive:

    Use lowercase letters and hyphens only.

    line 65
  7. Distinctive:

    Always use present tense.

    line 73
  8. Distinctive:

    Prefer small, focused commits over large ones.

    line 79
  9. Distinctive:

    Use git add -p for interactive staging to create granular commits.

    line 80
  10. Distinctive:

    If push is denied: use git rebase (not merge).

    line 86

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “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

Spatie Version Control Guidelines

Overview

Apply Spatie's Git and version control conventions for consistent repository management.

When to Activate

  • Activate this skill when creating commits, branches, or pull requests.
  • Activate this skill when naming new repositories.
  • Activate this skill when deciding on branching or merging strategies.

Scope

  • In scope: Git operations, repository naming, branch naming, commit messages, merge strategies.
  • Out of scope: Code style, deployment pipelines, CI/CD configuration.

Repository Naming

Site source code

Use the main domain name in lowercase, without www:

  • Good: spatie.be
  • Bad: https://www.spatie.be, www.spatie.be, Spatie.be

Subdomains

Include the subdomain in the repo name:

  • Good: guidelines.spatie.be
  • Bad: spatie.be-guidelines

Packages and other projects

Use kebab-case:

  • Good: laravel-backup, spoon
  • Bad: LaravelBackup, Spoon

Branches

Initial development

  • Maintain main and develop branches.
  • Commit through develop, not directly to main.
  • Feature branches are optional; if used, branch from develop.

Live projects

  • Delete the develop branch.
  • All commits to main must come through feature branches.
  • Prefer squashing commits on merge.

Branch naming

  • Use lowercase letters and hyphens only.
  • Good: feature-mailchimp, fix-deliverycosts, updates-june-2016
  • Bad: feature/mailchimp, random-things, develop

Commits

Message format

  • Always use present tense.
  • Good: Update deps, Fix vat calculation in delivery costs
  • Bad: wip, commit, a lot, solid

Granularity

  • Prefer small, focused commits over large ones.
  • Use git add -p for interactive staging to create granular commits.

Merging

  • Rebase regularly to reduce merge conflicts.
  • For deploying feature branches: use git merge <branch> --squash.
  • If push is denied: use git rebase (not merge).

Pull Requests

  • Optional but useful for peer review, merge validation, and historical reference.

Source: https://spatie.be/guidelines/version-control

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.

Check your setup, free