agentsclimarketplace
Sign in

Git workflow

Skill SWEStash/swe-workflow-skills/plugins/ml/skills/git-workflow

Write commit messages, PR descriptions, and manage branching strategy following conventional commits.From its SKILL.md

Install
npx -y skills add SWEStash/swe-workflow-skills --skill git-workflow

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

6.1 KB, ~1.4k tokens by cl100k_base, as published. Nobody here has run it

Git Workflow

Help write clear commit messages, structured PR descriptions, and manage branching conventions. Good git history is documentation — it tells the story of why the codebase evolved the way it did.

Workflow: Commit Messages

Step 1: Analyze the Changes

Currently staged (live at skill load; empty when nothing is staged, this isn't a git repo, or injection is disabled):

!git diff --staged --stat 2>/dev/null || true

If the summary above is empty or not enough to understand the change, run git diff --staged yourself for the full diff.

Identify:

  • What changed? (files modified, functions added/removed, logic altered)
  • Why did it change? (feature, bugfix, refactor, dependency update)
  • Is this one logical change or multiple? If multiple, suggest splitting into separate commits.

Step 2: Write the Commit Message

Use the Conventional Commits format — see references/conventions.md:

<type>(<scope>): <short description>

<body — explain WHY, not WHAT>

<footer — references, breaking changes>

The subject line (first line):

  • Type: feat, fix, refactor, test, docs, chore, perf, ci, build
  • Scope: The module, component, or area affected (optional but recommended)
  • Description: Present tense, lowercase, no period, under 50 characters
  • It should complete the sentence: "If applied, this commit will..."

The body (optional but valuable for non-trivial changes):

  • Explain WHY this change was made, not WHAT changed (the diff shows what)
  • Include context that isn't obvious from the code
  • Wrap at 72 characters

The footer (optional):

  • Reference issues: Closes #123, Fixes #456
  • Breaking changes: BREAKING CHANGE: description
  • Co-authors: Co-authored-by: Name <email>

Commit types are not just style — in automated release flows they drive the version: fix → PATCH, feat → MINOR, feat!/BREAKING CHANGE: → MAJOR. A mislabeled type mis-versions the next release (see release-management).

Step 3: Validate

Before committing, check:

  • Is this a single logical change? (If not, split it)
  • Does the subject line describe the behavior change, not the implementation?
  • Would someone understand why this commit exists 6 months from now?
  • Are related issue numbers referenced?

Workflow: PR Descriptions

Step 1: Analyze the Branch

Branch state vs the default branch (live at skill load; tries main then master):

!git log main..HEAD --oneline 2>/dev/null || git log master..HEAD --oneline 2>/dev/null || true

!git diff main...HEAD --stat 2>/dev/null || git diff master...HEAD --stat 2>/dev/null || true

If the output above is empty or the repo uses a different default branch, run the equivalents against the actual base branch. Understand the full scope of changes across all commits — run the full git diff <base>...HEAD when the stat summary isn't enough.

Step 2: Write the PR Description

Use the template at templates/pull-request.md. Key sections:

  • What: What this PR does (1-2 sentences)
  • Why: Why this change is needed (link to issue/task)
  • How: Brief description of the approach taken and key decisions
  • Testing: How the changes were tested
  • Screenshots: For UI changes (before/after)
  • Checklist: Standard items (tests pass, docs updated, etc.)

The PR description should let a reviewer understand the change without reading every line of code first.

Step 3: Self-Review

Before requesting review:

  • Read through the entire diff one more time
  • Are there any debugging leftovers?
  • Any stray working artifacts (PLAN.md, NOTES.md, scratch files, one-off test scripts) that shouldn't ship?
  • Are there any changes that don't belong in this PR?
  • Is the PR a reasonable size? (Under 400 lines changed is ideal. Over 800 is a red flag.)

If the PR is too large, suggest splitting it into stacked PRs or smaller logical units.

Workflow: Branching Strategy

Help set up or improve branching conventions. Ask about team size and release cadence, then recommend:

For small teams (1-5 devs) or continuous deployment:

  • main — always deployable
  • Branch naming: feat/<description>, fix/<description> — short-lived (1-3 days)
  • Merge to main via PR — squash-merge by default (one clean commit per logical change on main); one approval is the right review bar at this size
  • Deploy from main

For medium teams (5-15 devs) or scheduled releases:

  • main — production
  • develop — integration branch
  • feat/description, fix/description — branch from develop
  • release/x.y.z — stabilization branch before release
  • hotfix/description — urgent fixes branching from main

For large teams or complex release cycles:

  • Consider trunk-based development with feature flags
  • Short-lived branches (< 1 day) merged to main
  • Feature flags control what's visible to users

See references/conventions.md for branch naming conventions.

Principles Applied

  • KISS: One commit = one logical change. Don't bundle unrelated changes.
  • DRY: If you're writing the same commit message pattern repeatedly, you might be making commits too granular or too broad.
  • Functional Independence: Each PR should be independently deployable when possible. Avoid PRs that depend on other unmerged PRs.

Cross-Skill References

  • release-management — cutting the release these commits accumulate into: semver, changelog, tagging, publishing
  • code-reviewing — reviewing the PR the description introduces
  • code-slop-cleanup — tighten the diff (AI artifacts, debug leftovers, stray files) before the self-review
  • verification-before-completion — run the proving commands before pushing or opening the PR

What ships with it: 3 files

9.2 KB alongside SKILL.md

evals/

references/

templates/

Keep looking

Skills are one crate of 325,949. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.