How do I install the Branching Strategy And Conventions skill?

Run npx skillmds@latest add tomevault-io/branching-strategy-and-conventions in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Branching Strategy And Conventions safe to use?

This skill has not completed SkillMD's automated safety review yet. Independent scanners report: SkillSpector: PASS, Skill Scanner: PASS. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Branching Strategy And Conventions?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Branching Strategy And Conventions free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Branching Strategy And Conventions?

tomevault-io (@tomevault-io) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Branching Strategy And Conventions by tomevault-io

Name: Branching Strategy And Conventions
Author: tomevault-io

Branching Strategy And Conventions

Use when creating any repository, defining Git workflows, or enforcing commit conventions. Establishes branching policy, commit message standards (Conventional Commits), and merge rules aligned to SemVer.

tomevault-io Updated Sep 17, 2026

File contents

Branching Strategy and Conventions

Overview

P0 Foundational - Applies by default. Establishes branching model, commit conventions, and merge strategy.

REQUIRED: superpowers:verification-before-completion

When to Use

Any repository (default)
New repository creation
Existing repo without documented branching policy
User requests Git branching or commit conventions
Release management or versioning strategy needed

Core Workflow

Announce skill (default for all repos)
Define branching strategy (Trunk-Based, GitHub Flow, or Git Flow)
Set default branch as main
Define branch naming: feature/*, fix/*, docs/*, hotfix/*, release/*
Configure Conventional Commits (Commit Conventions)
Set up commitlint + pre-commit hooks
Define merge strategy: disable merge commits, prefer --ff-only or squash
Document squash merge SemVer preservation (Squash Merge Guide)
Configure branch protection rules
Document in CONTRIBUTING.md
Brownfield: baseline existing history, enforce on new commits

Quick Reference

Element	Standard	Enforcement
Default Branch	`main`	Repository
Branch Naming	`feature/`, `fix/`, `docs/*`	CI validation
Commit Format	Conventional Commits	commitlint
Commit Types	feat, fix, docs, chore, refactor, test, ci	Pre-commit + CI
Merge Strategy	Squash (multi-commit) or FF-only (single)	Branch rules
Breaking Change	`feat!:` or `BREAKING CHANGE` footer	SemVer MAJOR

See Branching Models for strategy comparison.

Red Flags - STOP

"Can define strategy later"
"Just use main for now"
"Team knows commits"
"History is messy anyway"
"Commit format not important"
"Can parse freeform messages"
"Too restrictive for developers"

All mean: Apply skill or document explicit opt-out in exclusions.md.

Rationalizations

Excuse	Reality
"Can define strategy later"	Later never comes. Strategy takes 15 minutes, prevents project-long confusion.
"Just use main branch for now"	No strategy = accidental commits to main, no review process, deployment chaos.
"Team knows how to write commits"	Inconsistent messages break automation, make history unreadable, prevent SemVer.
"History is already messy"	Enforce on new commits. Baseline existing history, don't rewrite it.
"Commit format not critical"	Conventional Commits enable changelogs, SemVer, release notes. Critical for automation.

Evidence Checklist

Branching strategy defined (Trunk-Based, GitHub Flow, or Git Flow)
Default branch is main
Branch naming conventions documented
Conventional Commits configured (commitlint)
Pre-commit hooks configured
Merge strategy defined (squash or FF-only)
CONTRIBUTING.md updated

Converted and distributed by TomeVault — claim your Tome and manage your conversions.

---name: branching-strategy-and-conventionsdescription: Use when creating any repository, defining Git workflows, or enforcing commit conventions. Establishes branching policy, commit message standards (Conventional Commits), and merge rules aligned to SemVer.---# Branching Strategy and Conventions## Overview**P0 Foundational** - Applies by default. Establishes branching model, commit conventions, and merge strategy.**REQUIRED:** superpowers:verification-before-completion## When to Use- Any repository (default)- New repository creation- Existing repo without documented branching policy- User requests Git branching or commit conventions- Release management or versioning strategy needed## Core Workflow1. Announce skill (default for all repos)2. Define branching strategy (Trunk-Based, GitHub Flow, or Git Flow)3. Set default branch as `main`4. Define branch naming: `feature/*`, `fix/*`, `docs/*`, `hotfix/*`, `release/*`5. Configure Conventional Commits ([Commit Conventions](references/commit-conventions.md))6. Set up commitlint + pre-commit hooks7. Define merge strategy: disable merge commits, prefer `--ff-only` or squash8. Document squash merge SemVer preservation ([Squash Merge Guide](references/squash-merge-guide.md))9. Configure branch protection rules10. Document in CONTRIBUTING.md11. Brownfield: baseline existing history, enforce on new commits## Quick Reference| Element | Standard | Enforcement || --------------- | ------------------------------------------ | --------------- || Default Branch | `main` | Repository || Branch Naming | `feature/*`, `fix/*`, `docs/*` | CI validation || Commit Format | Conventional Commits | commitlint || Commit Types | feat, fix, docs, chore, refactor, test, ci | Pre-commit + CI || Merge Strategy | Squash (multi-commit) or FF-only (single) | Branch rules || Breaking Change | `feat!:` or `BREAKING CHANGE` footer | SemVer MAJOR |See [Branching Models](references/branching-models.md) for strategy comparison.## Red Flags - STOP- "Can define strategy later"- "Just use main for now"- "Team knows commits"- "History is messy anyway"- "Commit format not important"- "Can parse freeform messages"- "Too restrictive for developers"**All mean: Apply skill or document explicit opt-out in exclusions.md.**## Rationalizations| Excuse | Reality || --------------------------------- | --------------------------------------------------------------------------------------- || "Can define strategy later" | Later never comes. Strategy takes 15 minutes, prevents project-long confusion. || "Just use main branch for now" | No strategy = accidental commits to main, no review process, deployment chaos. || "Team knows how to write commits" | Inconsistent messages break automation, make history unreadable, prevent SemVer. || "History is already messy" | Enforce on new commits. Baseline existing history, don't rewrite it. || "Commit format not critical" | Conventional Commits enable changelogs, SemVer, release notes. Critical for automation. |## Evidence Checklist- [ ] Branching strategy defined (Trunk-Based, GitHub Flow, or Git Flow)- [ ] Default branch is `main`- [ ] Branch naming conventions documented- [ ] Conventional Commits configured (commitlint)- [ ] Pre-commit hooks configured- [ ] Merge strategy defined (squash or FF-only)- [ ] CONTRIBUTING.md updated---> Converted and distributed by [TomeVault](https://tomevault.io/claim/mcj-coder) — claim your Tome and manage your conversions.

Frequently asked questions