commit-hygiene

Analyze Git changes to recommend atomic commit boundaries and conventional messages.

Updated Jun 19, 2026
One-click install
npx skills add https://github.com/lciacci/tessera --skill commit-hygiene-lciacci
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: commit-hygiene
Source: https://github.com/lciacci/tessera/tree/main/skills/commit-hygiene
Command: npx skills add https://github.com/lciacci/tessera --skill commit-hygiene-lciacci

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill prevents oversized, unfocused commits and pull requests that are difficult to review, test, revert, or maintain.

Core Features & Use Cases

  • Commit Size Guidance: Tracks file and line-change thresholds to identify when work should be committed or split.
  • Atomic Commit Practices: Encourages one logical change per commit with clear, conventional commit messages.
  • PR and Branching Strategy: Recommends manageable pull request sizes, partial staging, and stacked PRs for larger features.
  • Use Case: When a feature spans multiple layers and exceeds reviewable limits, use this Skill to separate schema, API, frontend, and test changes into focused commits or stacked pull requests.

Quick Start

Ask the commit-hygiene skill to review the current Git changes and recommend whether to commit now or split the work.

Frequently Asked Questions about commit-hygiene

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
What is an atomic commit in Git and why does it matter for code review?

Atomic commits isolate a single logical change, making Git history easier to review, test, and revert. Mixed-purpose changes complicate pull requests and increase the risk of destabilizing the branch.

How do I split oversized Git commits before opening a pull request?

To split oversized commits, use partial staging to separate schema, API, frontend, and test changes. Apply file and line thresholds to identify boundaries and generate focused, conventional commit messages.

When should I use stacked pull requests for a large feature?

Use stacked pull requests when a feature spans multiple layers and exceeds reviewable limits. Stacking separates schema, API, and frontend changes into focused branches that reviewers can process sequentially.

What is the best way to structure a branching strategy for manageable code review?

A manageable branching strategy keeps pull requests small and focused. Track file and line-change thresholds to enforce atomic commits, establishing clear boundaries and conventional commit messages for reviewers.

Does this approach work for mixed-purpose changes involving refactoring and bug fixes?

Yes, it identifies mixed-purpose changes involving refactoring and bug fixes, then recommends clear commit boundaries. This separates concerns into distinct, reviewable atomic commits rather than leaving them combined.

What are the limitations of enforcing strict commit size thresholds?

Strict commit size thresholds may struggle with tightly coupled schema and API changes that cannot be logically separated. In these cases, you might accept slightly larger commits or use stacked pull requests.