git-release-hygiene

Enforces working-branch-only commits, conventional messages, and approval-gated merges to protected main branches.

1|Updated Jun 3, 2026
One-click install
npx skills add https://github.com/tanveerriaz/Skillz --skill git-release-hygiene-tanveerriaz
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: git-release-hygiene
Source: https://github.com/tanveerriaz/Skillz/tree/main/skills/git-release-hygiene
Command: npx skills add https://github.com/tanveerriaz/Skillz --skill git-release-hygiene-tanveerriaz

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? AI agents and developers working in Git repositories with protected main branches risk accidentally merging unreviewed code to production or pushing directly to main. This Skill prevents those costly mistakes by enforcing a strict working-branch-only policy and requiring explicit human approval before any merge or deploy. ## Core Features & Use Cases - Branch Protection Enforcement: All commits happen on a designated working branch (develop/dev), never directly on main. - Conventional Commit Messages: Standardizes commit format as type(scope): description with types like feat, fix, ui, refactor, docs, and chore. - Approval-Gated Merges: Merges to main and production deploys only occur when the user explicitly requests them. - Use Case: An AI agent is asked to "push the changes" after fixing a bug. Instead of merging to main, it commits fix(auth): handle expired session redirect to the dev branch and waits for an explicit merge instruction. ## Quick Start Ask the agent to commit your current changes to the working branch with a conventional commit message, without merging to main.

Frequently Asked Questions about git-release-hygiene

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

FAQPage Schema
How do I prevent AI agents from merging to main in Git?▼

Use a working-branch-only policy where all commits go to a designated branch like develop or dev. Merges to main and production deploys are gated behind explicit user instructions such as "merge to main", so ambiguous commands like "push" never trigger a merge.

What is the conventional commit message format?▼

Conventional commits follow the pattern `type(scope): short description`, where type is one of feat, fix, ui, refactor, docs, or chore. Commits should be small, logically scoped, and free of unrelated edits.

What happens when someone says "deploy" or "ship it"?▼

These phrases are interpreted as commit and push to the current working branch, not as a merge to main or a production deploy. If the intent is genuinely ambiguous, the agent confirms with the user before acting.

Can I commit directly to main for a production hotfix?▼

No. Even for hotfixes, explicit approval is required before touching the protected main branch, and the exception should be documented. The branch-protection rule takes precedence over convenience in all cases.

What should I do if the working branch does not exist?▼

Create the working branch from main first, then proceed with commits there. Never fall back to committing directly on main, and resolve any detached HEAD or wrong-branch state before committing.