agentleFS
Sign inStart free
MicrosoftKnown publishermicrosoft/devsquad-copilot/.github/plugins/devsquad/skills/git-commit/SKILL.md

git-commit

Skill50 starsChanged 16 days agoMITView on GitHub

Create standardized git commits with Conventional Commits. Use when the user asks to commit changes, generate a commit message, or at the end of an implementation. Analyzes the actual diff to determine type, scope, and message. Supports logical file grouping and work item references (GitHub Issues and Azure DevOps). Do not use for branch creation (use git-branch), push, or pull requests (use pull-request).

  • Reads credentials

We split this skill into the rules it gives an agent

15 rules. 0 are common, 11 are distinctive, and 4 are very specific to this project.

  • 0

    Common

    Most of the 123 edited versions we read keep these.

  • 11

    Distinctive

    This author's own choices. Worth a look.

  • 4

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    If the diff contains logically distinct changes, group them into separate commits:

    line 83
  2. Distinctive:

    If all changes are part of the same logical unit, stage everything:

    line 94
  3. Distinctive:

    Before committing, check if the current branch is the integration branch:

    line 116
  4. Distinctive:

    If the current branch matches the integration branch:

    line 128
  5. Distinctive:

    If the user chooses [B]:

    line 137
  6. Distinctive:

    After switching, continue the commit flow on the new branch.

    line 144
  7. Distinctive:

    If the user chooses [C], proceed with the commit.

    line 146
  8. Very specific:

    Every agent-generated commit must include the co-authorship trailer as the last -m:

    line 152
  9. Distinctive:

    Always reference the task or issue when available:

    line 174
  10. Very specific:

    NEVER: run --force or reset --hard without explicit user request

    line 200
  11. Very specific:

    NEVER: use --no-verify to skip hooks without explicit user request

    line 201
  12. Very specific:

    If a commit fails due to hooks, fix the issue and create a new commit (do not use --amend automatically)

    line 203
  13. Distinctive:

    If the hook fails repeatedly, inform the user about the error and wait for instructions

    line 204
  14. Distinctive:

    Commit messages like "fix", "update", "misc", or "WIP"

    line 267
  15. Distinctive:

    No work item reference when one is available

    line 270

“Common” is measured: kept by at least 6 in 10 of the 123 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 Commit — Conventional Commits for SDD

Format

<type>[optional scope]: <description>

[optional body]

[optional footer]

References: Conventional Commits and How to Write a Git Commit Message.

Commit Types

TypeUsage
featNew feature
fixBug fix
docsDocumentation-only change
styleFormatting, semicolons, whitespace (no logic change)
refactorRefactoring without behavior change
perfPerformance improvement
testAdding or fixing tests
buildBuild system or external dependencies
ciCI/CD configuration
choreGeneral maintenance (scripts, configs)
revertRevert a previous commit

Mapping to SDD Artifacts

SDD ArtifactLikely type
docs/features/**/spec.mddocs
docs/architecture/decisions/*.md (ADR)docs
tasks.md, work itemsdocs or chore
Implementation codefeat, fix, refactor, perf
Teststest
Agents, skills, instructions (.github/)chore or ci

Breaking Changes

# ! marker after type/scope
feat!: remove deprecated endpoint

# Or BREAKING CHANGE footer
feat(api): allow extensible configuration

BREAKING CHANGE: behavior of the `extends` key changed

Workflow

1. Analyze Diff

# If there are staged files, use staged diff
git diff --staged --stat
git diff --staged

# If nothing is staged, use working tree
git diff --stat
git diff

# Check overall status
git status --porcelain

Determine from the diff:

  • Type: What kind of change is this? (see table above)
  • Scope: Which module/area was affected? (e.g., auth, api, docs, spec)
  • Description: One-line summary of what changed

2. Group and Stage (if needed)

If the diff contains logically distinct changes, group them into separate commits:

# Group by logical area
git add src/auth/*.ts          # commit 1: feat(auth)
git add tests/auth/*.test.ts   # commit 2: test(auth)
git add docs/features/login/   # commit 3: docs(login)

Principle: one commit = one coherent logical change.

If all changes are part of the same logical unit, stage everything:

git add -A

3. Pre-Commit Checks

Before committing, verify:

# Does .gitignore exist?
test -f .gitignore && echo "OK" || echo "⚠ .gitignore missing"

# No secrets being committed?
git diff --staged --name-only | grep -iE '\.(env|pem|key|credentials|secret)' && echo "⚠ POSSIBLE SECRET" || echo "OK"

Never commit: .env, private keys, tokens, credentials, credentials.json.

3b. Integration Branch Guard

Before committing, check if the current branch is the integration branch:

CURRENT_BRANCH=$(git branch --show-current)

Resolve the integration branch in this order:

  1. Integration Branch from .memory/git-config.md (if it exists)
  2. Repository default branch via git symbolic-ref refs/remotes/origin/HEAD
  3. Fallback: match against main, master, or develop

If the current branch matches the integration branch:

You are about to commit directly to `[branch]`. Direct commits to the integration branch bypass code review and are difficult to revert safely.

[B] Create a feature branch first (recommended)
[C] Continue on [branch] (I understand the risks)

If the user chooses [B]:

Current stateRecovery action
Changes are staged but not committedRun git switch -c <feature-branch> (preserves working tree and index)
Changes are unstagedRun git switch -c <feature-branch> (preserves working tree)

After switching, continue the commit flow on the new branch.

If the user chooses [C], proceed with the commit. Log the override in the reasoning log (if active).

Never commit to the integration branch without explicit user confirmation.

4. Generate Message and Commit

Every agent-generated commit must include the co-authorship trailer as the last -m:

Co-authored-by: GitHub Copilot <noreply@github.com>

This keeps the developer as the primary author and records Copilot's participation in a traceable way.

# Without body
git commit -m "<type>(<scope>): <description> (#<issue>)" \
  -m "" \
  -m "Co-authored-by: GitHub Copilot <noreply@github.com>"

# With body
git commit -m "<type>(<scope>): <description> (#<issue>)" \
  -m "<body with additional context>" \
  -m "Co-authored-by: GitHub Copilot <noreply@github.com>"

5. Work Item References

Always reference the task or issue when available:

# GitHub Issues
feat(auth): add OAuth login (#42)
fix(api): fix timeout on long-running requests (Closes #87)

# Azure DevOps
feat(auth): add OAuth login (AB#1234)
fix(api): fix timeout on long-running requests (AB#5678)

Message Rules

RuleCorrect exampleIncorrect example
Imperative, present tenseadd validationadded validation
Lowercase first letter in descriptionfix: fix date parsingfix: Fix date parsing
No period at end of descriptionfeat: add filterfeat: add filter.
Description ≤ 72 characters——
Body separated by blank line——
Body explains the why, not the what——

Git Security Protocol

  • NEVER change global git config
  • NEVER run --force or reset --hard without explicit user request
  • NEVER use --no-verify to skip hooks without explicit user request
  • NEVER force push to main/master
  • If a commit fails due to hooks, fix the issue and create a new commit (do not use --amend automatically)
  • If the hook fails repeatedly, inform the user about the error and wait for instructions

Complete Examples

All examples below omit the Co-authored-by trailer for brevity. It is required as per section 4.

Simple commit (feature)

feat(auth): add JWT authentication (#42)

Commit with body (complex fix)

fix(api): fix race condition in session cache (#87)

The shared cache between workers did not have proper locking,
causing inconsistent data under high load (>100 req/s).

Replaced Map with ConcurrentMap with configurable TTL.

SDD documentation commit

docs(login): create login feature specification

Includes user scenarios, functional requirements (FR-001 to FR-005),
success criteria, and compliance criteria.

ADR commit

docs(adr): add ADR 0003 — cache strategy

Documents decision to use Redis as distributed cache.
Alternatives evaluated: Memcached, local in-memory cache.

Breaking change

feat(api)!: migrate endpoints from v1 to v2 (#120)

BREAKING CHANGE: all /api/v1/* endpoints have been removed.
Clients must migrate to /api/v2/* per the migration guide.

Common Rationalizations

RationalizationReality
"I will commit when the feature is done"One giant commit is impossible to review, debug, or revert. Commit each logical slice.
"The message does not matter"Messages are documentation. Future developers and agents need to understand what changed and why.
"I will squash it all later"Squashing destroys the development narrative. Prefer clean incremental commits from the start.
"These changes are too small to commit separately"Small commits are free. Large commits hide bugs and make rollbacks painful.
"Formatting changes can go with behavior changes"Mixed concerns make review harder, reverts riskier, and history less useful. Separate them.

Red Flags

  • Large uncommitted changes accumulating across multiple files
  • Commit messages like "fix", "update", "misc", or "WIP"
  • Formatting changes mixed with behavior changes in the same commit
  • Secrets or credentials appearing in the staged diff
  • No work item reference when one is available

Download now (ZIP)

  • Other versions161 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 161

    1. github/awesome-copilot★ 41ksame name
    2. doocs/leetcode★ 37ksame name
    3. tisfeng/Easydict★ 15ksame name
    4. doocs/md★ 13ksame name
    5. spinabot/brigade★ 11ksame name
    6. GitTools/GitVersion★ 3.1ksame name
    7. igorescodro/alkaa★ 1.6ksame name
    8. microsoft/hve-core★ 1.6ksame name
    9. rohaquinlop/complexipy★ 890same name
    10. decebals/claude-code-java★ 763same name

    151 more not listed

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • Used alongsideProjects with it also use git-pr, github-pr-create 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.
    • klauswgSkill

      git-pr

      Prepare, review, publish, or update a complete GitHub pull request for the current repository, including local commit readiness, safe push strategy, semantic title validation, repository-native PR templates, issue linking, and checks verification. Use when the user asks to draft, create, submit, publish, open, or update a pull request. Always require the user to review and explicitly approve the exact final PR before any push or GitHub write.

      Also in 8 projects that use this

    • mjun0812Skill

      github-pr-create

      Pull Requestを作成するSkill。現在のbranchからpull requestを作成する。言語指定可能。 ユーザーが「PR作って」「pull request作成して」のように依頼したら使うこと。

      Also in 3 projects that use this

    • klauswgSkill

      git-issue

      Prepare, review, create, or update evidence-based GitHub issues for the current repository with duplicate detection, repository-native templates, valid labels, and post-publication verification. Use when the user asks to draft, file, submit, publish, edit, or refine a GitHub issue, bug report, feature request, performance issue, or technical proposal. Always require the user to review and explicitly approve the exact final issue before any GitHub write.

      Also in 3 projects that use this

    • MicrosoftSkill

      git-merge

      Integrate branches with merge or rebase, resolve conflicts, and execute an ordinary push when explicitly authorized. Use for guided integration with optional conflict-review pauses.

      Also in 3 projects that use this

    • gologo13Skill

      git-push

      Push current branch to origin and sync with remote updates; keywords: git, rebase. Use only on explicit request; before execution, review diffs and list impact scope.

      Also in 4 projects that use this

    • GoogleSkill

      github-pr-review

      Review a GitHub pull request and leave inline comments in a natural human reviewing voice, indistinguishable from comments typed by hand on the GitHub web UI. Deliberately bounded to defects a reader can settle by looking at the anchored line, rather than a deep audit, so every comment is cheap for the author to check. Scales to 2-20 comments by PR size, parallelises analysis across sub-agents, drafts for approval, then posts individually with human pacing. Use when the user says "review this PR", "review PR 123", pastes a github.com/.../pull/N link, or asks for comments on a pull request. Don't use for reviewing local uncommitted changes or a diff against a branch (use the `review` skill for that).

      Also in 4 projects that use this

  • In this repository26 other files it gives its agents.

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