git-workflow

Enforces commit conventions, branch naming, PR discipline, and rebase strategies for git repositories.

1|Updated Mar 13, 2026
One-click install
npx skills add https://github.com/dominionism/Noesis --skill git-workflow-dominionism
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: git-workflow
Source: https://github.com/dominionism/Noesis/tree/main/assets/skills/git-workflow
Command: npx skills add https://github.com/dominionism/Noesis --skill git-workflow-dominionism

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Inconsistent commit messages, oversized pull requests, and tangled git histories make code review slow and debugging painful. This Skill provides concrete conventions for commits, branches, PRs, rebasing, conflict resolution, and bisect-based bug hunting so teams maintain a clean, reviewable, debuggable history. ## Core Features & Use Cases - Commit Conventions: Enforces the type(scope): description format with a catalog of commit types (feat, fix, refactor, test, docs, chore, perf, style) and rules for atomic, independently revertable commits. - Branch & PR Discipline: Standardizes branch naming as type/ticket-id/description and keeps pull requests under 400 lines, single-concern, with what/why/how-to-test descriptions. - History Management: Provides a decision framework for rebase vs. merge, a step-by-step conflict resolution method, and git bisect workflows (including automated bisect with test commands) to locate breaking commits. - Use Case: When a bug appears in production, use the bisect workflow to identify the exact breaking commit in log2(N) steps, then craft a properly scoped fix commit referencing the original ticket. ## Quick Start Review my recent commits and pull request against the git workflow conventions and tell me what to fix before merging.

Frequently Asked Questions about git-workflow

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

FAQPage Schema
How do I write a good git commit message?▼

Use the format type(scope): description with an imperative subject under 72 characters and no trailing period. The body should explain why the change was made, not what changed, and reference related tickets with Refs: or Fixes: footers.

When should I rebase vs merge in git?▼

Rebase your own feature branches onto main to keep a clean linear history, and use merge for long-lived or shared branches to preserve integration points. Never rebase branches others have pulled, and never force-push to main.

How do I find which commit introduced a bug?▼

Use git bisect: mark the current commit bad and a known-good commit good, then test each midpoint until git identifies the breaking commit in log2(N) steps. You can automate it with git bisect run followed by a test command.

How big should a pull request be for code review?▼

Keep pull requests under 400 lines of diff so a reviewer can meaningfully evaluate them in 15-30 minutes. Split larger changes into multiple PRs using feature flags or incremental delivery, excluding generated code and lock files.

What is an atomic commit in git?▼

An atomic commit contains exactly one logical change that can be understood, reviewed, and reverted independently. The test is whether reverting the commit leaves the codebase in a valid, working state without breaking unrelated functionality.

How do I resolve git merge conflicts safely?▼

Read both sides of each conflict and understand why each change was made before editing to the correct final state. Never blindly accept ours or theirs, and always run the full test suite after resolution since conflicts often introduce subtle bugs.