git-workflow

Manage Git branching, push sequencing, and merge approval gates.

Updated Apr 20, 2026
One-click install
npx skills add https://github.com/thistleknot/skills --skill git-workflow-thistleknot
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: git-workflow
Source: https://github.com/thistleknot/skills/tree/main/git-workflow
Command: npx skills add https://github.com/thistleknot/skills --skill git-workflow-thistleknot

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill prevents accidental or premature changes from reaching the canonical main branch by enforcing a consistent Git branching, push, and verification workflow that requires explicit user approval.

Core Features & Use Cases

  • Test-branch first workflow: Creates and uses test/* branches for new features, fixes, and skill work to isolate changes.
  • Gated promotion to dev and main: Pushes to dev only after user confirmation that the work is working, then pushes to main only after dev integration is validated and the user explicitly approves.
  • Pre-push quality and safety checklist: Verifies clean diffs against the last known working commit, checks for junk/unintended file changes, and recommends lightweight validation before any push.
  • Paired/variant testing guidance: Encourages testing a base feature and a variant to prove extensibility rather than only a single happy-path case.
  • Merge conflict and rollback playbooks: Provides command-level guidance for conflict resolution, undoing mistaken pushes, and reverting changes before they propagate.

Quick Start

Use git-workflow to manage a change by creating a test/<task-name> branch, committing your work, asking for confirmation to push to dev, then asking for approval before merging into and pushing to main.

Frequently Asked Questions about git-workflow

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

FAQPage Schema
How do I enforce a Git branch strategy that prevents accidental pushes to the main branch?

A gated merge workflow requires explicit user approval before pushing changes to dev or main, verifying clean diffs against the last known working commit to prevent premature or accidental changes from reaching the canonical branch.

What is the best way to verify a Git diff before pushing code to a dev branch?

Before pushing to dev, you should verify a clean diff against the last known working commit, check for junk or unintended file changes, and recommend lightweight validation to ensure code stability.

How do I roll back a mistaken Git push to a dev or main branch?

You can undo mistaken pushes by following command-level rollback playbooks that guide reverting changes and resolving merge conflicts before they propagate through your dev and main repository branches.

Does this Git workflow require testing feature variants or just a single happy-path case?

This workflow encourages paired and variant testing, recommending you test a base feature and a variant to prove extensibility rather than validating only a single happy-path case before promotion.

When do I need an explicit user confirmation gate in my repository workflow?

You need explicit user confirmation gates when promoting code from a test branch to dev, and again before merging dev integration into main, ensuring all diff-based verification passes before changes propagate.