git

Generates conventional commit messages, PR descriptions, and validates branch naming for Git workflows.

Updated Jul 9, 2026
One-click install
npx skills add https://github.com/ByronWilliamsCPA/plugin --skill git-byronwilliamscpa
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: git
Source: https://github.com/ByronWilliamsCPA/plugin/tree/main/plugins/wff-code/skills/git
Command: npx skills add https://github.com/ByronWilliamsCPA/plugin --skill git-byronwilliamscpa

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? It prevents common Git mistakes—committing unintended staged files, misjudging merge status in squash-merge repos, and producing non-compliant commit messages—by enforcing conventional commit standards, branch naming rules, and safety checks at the moment of decision. ## Core Features & Use Cases - Conventional Commit Preparation: Analyzes staged changes, generates compliant commit messages with type, scope, and breaking-change footers, and verifies the staged set matches intent before committing. - PR Description Generation: Gathers branch context, runs a self-review checklist for secrets and debug artifacts, and produces a structured PR description with summary, impact, acceptance criteria, and testing sections. - Branch Strategy Validation: Enforces {type}/{descriptive-slug} branch naming mapped to semantic release version impact, and blocks work directly on protected branches. - Use Case: Before committing in a shared clone with parallel sessions, the skill verifies git diff --cached --name-only matches the intended file set, preventing another session's work from being swept into your commit. ## Quick Start Ask the assistant to prepare a conventional commit for the currently staged changes and confirm the staged file set before committing.

Frequently Asked Questions about git

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

FAQPage Schema
How do I write a conventional commit message?▼

Use the format type(scope): subject, where type is feat, fix, docs, refactor, test, perf, chore, ci, or style. Keep the subject imperative and under 50 characters, add a body explaining what and why, and use a BREAKING CHANGE footer with an exclamation mark for breaking changes.

How do I check if a branch was merged in a squash-merge repository?▼

Check PR state with gh pr list --head <branch> --state all, then confirm with a two-tree diff: git diff origin/main origin/<branch> over the touched files. Ancestry tests and three-dot diffs report squash-merged work as unmerged, so avoid them.

Why did my git commit include files I did not stage?▼

git add adds to the index rather than defining commit scope, so any previously staged files get committed too. Run git diff --cached --name-only before committing and unstage extras, or use git commit -- <paths> with the pathspec placed after all options.

What branch naming format works with semantic release?▼

Use {type}/{descriptive-slug} in lowercase with hyphens, such as feat/user-authentication or fix/null-pointer-api. The prefix maps to version impact: feat triggers a minor bump, fix and perf trigger patch bumps, and docs, test, or chore trigger no release.

Can I use git stash to compare against a clean baseline?▼

Avoid it, because git stash shares one stack across all branches and popping may apply another branch's work. Use git show ref:path or create a throwaway worktree with git worktree add against origin/main instead.