Run any Skill in Manus with one click

Get Started

commit-conventions

Stars0

Forks0

UpdatedJuly 9, 2026 at 07:09

Commit hygiene and structuring guidelines. Use whenever the agent creates git commits.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

SRachamim

SRachamim/etc-nixos

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

name	commit-conventions
description	Commit hygiene and structuring guidelines. Use whenever the agent creates git commits.

Commit Conventions

Apply the objective-communication skill to all commit messages.

Structure

Each commit is independently valid -- the codebase compiles and passes tests after each one.
Each commit is focused -- one logical change per commit.
The sequence tells a story -- a reviewer reading the commits in order can follow the reasoning.
Prefer fewer commits -- don't split artificially. One commit is valid if the change is cohesive.

Ordering

Refactors go in a separate, preceding commit -- if the change requires restructuring existing code, commit the refactoring on its own before committing the new fix or feature. This lets reviewers (and Git history readers) evaluate each change without the noise of the other.
Tests belong with the code they test -- unless there's a good reason to separate (e.g., adding test infrastructure first).

Hygiene

No empty or trivial commits -- every commit should deliver meaningful progress.

Authoring only

The following rules govern the agent's own commit workflow. They do not apply when reviewing other authors' commits.

No AI trailers -- never include "Generated by Cursor", "Co-authored-by: cursor", or any other trailer or tag that reveals AI involvement. If the IDE appends one automatically, strip it before committing.
Working tree must be clean when done -- run git status to confirm there are no uncommitted changes.
If validation steps (linters, formatters, tests) produced auto-fixed modifications, amend the commit that introduced those files or create a fixup commit targeting the appropriate earlier commit.
If any other staged or unstaged modifications remain, commit them following the established commit structure.

More from this repository

same repository

work-item-context

SRachamim/etc-nixos

Deeply gather context from an Azure DevOps work item by following its relations, linked PRs, hyperlinks, and comments. Use whenever a command needs the full picture behind a work item -- planning features, reviewing PRs, triaging, or estimating.

2026-07-160

create-work-item

SRachamim/etc-nixos

Common steps for creating a new Azure DevOps work item in the FundGuard project, including iteration assignment, parent linking, and triage. Called by create-task, create-bug, and request-environment-access skills — not invoked directly by the user.

2026-07-160

triage-transition

SRachamim/etc-nixos

Mechanical estimate-and-transition of an Azure DevOps work item to the Triaged state. Called programmatically by skills that create or triage work items -- not invoked directly by the user. For user-initiated triage, use the triage skill instead.

2026-07-160

activate-work-item

SRachamim/etc-nixos

Transitions an Azure DevOps work item to the Active state. Use when starting work on a work item, given an explicit ID or one inferred from the current feature branch.

2026-07-160

block-work-item

SRachamim/etc-nixos

Marks an Azure DevOps work item as Blocked and links it to its predecessor blocker. Use when a work item cannot proceed until another work item is completed.

2026-07-160

debug

SRachamim/etc-nixos

Investigates bugs to find root cause, designs a TDD-based fix plan, and implements after approval. Use when given a bug ticket or description of defective behaviour that needs investigation and fixing in the codebase.

2026-07-160

name	commit-conventions
description	Commit hygiene and structuring guidelines. Use whenever the agent creates git commits.

Commit Conventions

Apply the objective-communication skill to all commit messages.

Structure

Each commit is independently valid -- the codebase compiles and passes tests after each one.
Each commit is focused -- one logical change per commit.
The sequence tells a story -- a reviewer reading the commits in order can follow the reasoning.
Prefer fewer commits -- don't split artificially. One commit is valid if the change is cohesive.

Ordering

Refactors go in a separate, preceding commit -- if the change requires restructuring existing code, commit the refactoring on its own before committing the new fix or feature. This lets reviewers (and Git history readers) evaluate each change without the noise of the other.
Tests belong with the code they test -- unless there's a good reason to separate (e.g., adding test infrastructure first).

Hygiene

No empty or trivial commits -- every commit should deliver meaningful progress.

Authoring only

The following rules govern the agent's own commit workflow. They do not apply when reviewing other authors' commits.

No AI trailers -- never include "Generated by Cursor", "Co-authored-by: cursor", or any other trailer or tag that reveals AI involvement. If the IDE appends one automatically, strip it before committing.
Working tree must be clean when done -- run git status to confirm there are no uncommitted changes.
If validation steps (linters, formatters, tests) produced auto-fixed modifications, amend the commit that introduced those files or create a fixup commit targeting the appropriate earlier commit.
If any other staged or unstaged modifications remain, commit them following the established commit structure.