branch-strategy

Enforce deterministic branching, commit message, and push strategies across repositories.

Updated Apr 27, 2026
One-click install
npx skills add https://github.com/MichielDean/LLMem --skill branch-strategy-michieldean
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: branch-strategy
Source: https://github.com/MichielDean/LLMem/tree/main/skills/branch-strategy
Command: npx skills add https://github.com/MichielDean/LLMem --skill branch-strategy-michieldean

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Inconsistent branching, commit messages, and push practices derail collaboration; this skill enforces deterministic rules to keep repositories orderly and auditable.

Core Features & Use Cases

  • Deterministic Branching: Classifies repositories into Personal Config Repos vs Project/Shared Repos and prescribes the exact branch strategy.
  • Commit Hygiene: Enforces conventional commit messages and avoids ambiguous changes.
  • PR & Push Governance: Provides guidance on when to push directly versus via PRs, including automerge considerations.

Quick Start

Determine and apply the appropriate branching, commit, and push strategy for this repository before starting work.

Frequently Asked Questions about branch-strategy

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

FAQPage Schema
What is a deterministic git branching strategy and why do I need it?

A deterministic git branching strategy applies fixed rules for branch naming, commit messages, and PR workflows. It keeps repositories orderly and auditable by preventing inconsistent practices that derail team collaboration.

How do I enforce conventional commit messages and branch naming across project repositories?

You enforce conventional commit messages and branch naming by applying deterministic rules and templates with guardrails. This prevents ambiguous changes and ensures consistent commit hygiene across both personal config and shared project repositories.

When should I push directly to a repository versus opening a pull request?

Push directly for personal config repositories, but use pull requests for project or shared repositories. PR governance rules determine exactly when to branch, push, and open PRs, including automerge considerations for safe operations.

Does this branching strategy work for both personal config repos and shared project repos?

Yes, the branching strategy classifies repositories into personal config versus project or shared repos. It prescribes exact branch, commit, and push strategies tailored to each scenario to maintain orderly and auditable version control.

What are the limitations of enforcing strict PR workflows and push governance?

Strict PR workflows and push governance limit rapid direct commits to shared repositories. Guardrails prevent unsafe operations, meaning developers must follow prescribed branching and commit templates rather than making ad-hoc changes.

What's the best way to standardize PR workflows and prevent unsafe git operations?

The best way to standardize PR workflows is implementing deterministic rules with guardrails that prevent unsafe git operations. This enforces consistent branch naming, conventional commit messages, and controlled push strategies across all repositories.