Guides Git branching, merging, and PR workflows using GitHub Flow conventions.
npx skills add https://github.com/fusengine/kimi-code --skill git-flow-fusengine
Please help me install this Agent Skill. Skill: git-flow Source: https://github.com/fusengine/kimi-code/tree/main/plugins/commit-pro/skills/git-flow Command: npx skills add https://github.com/fusengine/kimi-code --skill git-flow-fusengine
<type>/<scope> kebab-case branch naming convention with protected-branch blocking for main, master, develop, and production. - CI-Gated Merging: Provides a three-case decision tree for merging PRs based on whether required status checks exist, including a polling workaround for the GitHub CLI check-registration race condition. - Release-Safe Tagging: Explains why merge commits (never squash) and post-merge tag timing are required so release tags and GitHub Releases resolve correctly. - Use Case: When finishing a feature, ask the AI to create a properly named branch, open a PR with the standard template, wait for CI checks to register and pass, merge with a real merge commit, and tag the release on main afterward. ## Quick Start Ask the AI to create a feature branch, open a pull request, wait for CI checks to pass, and merge it following the git-flow conventions.High-intent search queries and answers about installing and using this skill.
Use the format <type>/<scope-or-summary> in kebab-case, such as feat/oauth-google or fix/csv-parser. Keep names under 50 characters, avoid personal prefixes and bare issue numbers, and use types like feat, fix, chore, docs, refactor, perf, test, ci, build, or style.
GitHub Flow (feature branch, PR, merge, delete) is the recommended default for teams and open source. Trunk-based works for solo prototypes with strong CI, while Git Flow is considered outdated for most projects with heavy release cycles.
This is a known GitHub CLI race condition where checks take a few seconds to register on a new PR, causing gh pr checks --watch to error with no checks reported. Poll gh pr checks until checks register, then watch and merge only if they pass.
Use a real merge commit via gh pr merge --merge --delete-branch. Squash merging is avoided here because the release tag points at the bump commit, and squashing would orphan that commit so the tag never lands on main.
No, protected branches like main, master, develop, and production should never receive direct commits. The workflow blocks this and proposes an auto-named feature branch instead, with exceptions only for solo prototypes without a remote.
Push the version tag only after the merge completes on main, never before, since CI could still fail or branch protection could block the merge. Then create a GitHub Release with gh release create so tools resolving latest release can find it.
MohibShaikhStage changes, create a contextual commit message, and push the current branch.
SpillwaveSolutionsAutomate CCH release workflows from version management to GitHub publishing.
ketronkowskiValidate Git commit messages against conventional commit formatting rules.
wahidyankfEnforce small, frequent commits to the main branch for Trunk Based Development workflows.