git-workflow-and-versioning

Enforce conventional commits, atomic save-point commits, and short-lived branches.

Updated Mar 8, 2026
One-click install
npx skills add https://github.com/luyzkk/Anti-Vibe-Coding --skill git-workflow-and-versioning-luyzkk
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: git-workflow-and-versioning
Source: https://github.com/luyzkk/Anti-Vibe-Coding/tree/main/skills/git-workflow-and-versioning
Command: npx skills add https://github.com/luyzkk/Anti-Vibe-Coding --skill git-workflow-and-versioning-luyzkk

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

It prevents “vibe coding” by ensuring code changes land in Git as reviewable, searchable, and reversible history rather than as opaque mega-commits that break debugging and post-deploy iteration.

Core Features & Use Cases

  • Conventional commits with clear intent: enforces meaningful commit types and vetoes vague messages like “Fix bug” to keep git log --grep and git bisect usable.
  • Atomic “save point” commits: guides you to commit after each verified slice (implement → test → verify → commit) so you can revert safely and incrementally.
  • Branch hygiene and PR as a contract: promotes short-lived branches (1–3 days) and a structured PR description that documents scope, rationale, and expected outcomes.
  • Supports post-deploy workflows: establishes the commit discipline required for /iterate and /incident-response to work reliably with clean commit history.

Quick Start

Ask: “Prepare my branch and commits for this change using conventional commits, atomic slices, and a PR description contract; avoid commit messages like 'Fix bug' and ensure history supports bisect and post-mortems.”

Frequently Asked Questions about git-workflow-and-versioning

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

FAQPage Schema
How do I enforce conventional commits to keep my git history clean?

Conventional commits require meaningful commit types and veto vague messages like 'Fix bug', keeping your git history clean. This ensures changes remain reviewable, searchable, and reversible for reliable debugging and iteration.

What's the best way to structure atomic Git commits for feature development?

The best way to structure atomic Git commits is to commit after each verified slice: implement, test, verify, and commit. These atomic save-point commits ensure you can safely and incrementally revert changes during feature development or bug fixes.

How do I write a PR description contract for short-lived branches?

A PR description contract documents the scope, rationale, and expected outcomes of your short-lived branches. Keeping branches short-lived for 1 to 3 days with structured PR descriptions ensures changes remain reviewable and acts as a clear contract for reviewers.

Why does git bisect require a clean commit history?

Git bisect requires a clean commit history because opaque mega-commits break debugging and incident analysis. Atomic commits with conventional commit messages allow you to systematically narrow down and identify the exact change that introduced a bug.

Can I use post-deploy workflows and incident analysis without atomic commits?

Post-deploy workflows and incident analysis cannot work reliably without atomic commits. Opaque mega-commits break debugging, whereas establishing commit discipline with atomic save-point commits ensures changes are reversible and searchable for post-mortems.