Git workflow standards
Skill LIghtJUNction/lightjunction/skills/git-workflow-standards
This skill should be used when the user asks to "add Git standards", "create a branch", "commit changes", "write a commit message", "open a PR", "review a PR", "prepare a release", "tag a version", or mentions trunk-based development, Conventional Commits, branch naming, PR checklist, semantic versioning, or release tags.From its SKILL.md
npx -y skills add LIghtJUNction/lightjunction --skill git-workflow-standardsAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 3 stars3 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
- runs commandsInstructs the agent to run 1 command, including `git status --short`.
SKILL.md
1.8 KB, 379 tokens by cl100k_base, as published. Nobody here has run it
Git Workflow Standards
Apply this skill when planning, committing, reviewing, merging, or releasing changes with Git.
Workflow
- Inspect
git status --shortbefore making Git decisions. - Keep unrelated user changes intact. Do not revert changes that were not made for the current task.
- Load
references/git-workflow-standards.mdbefore creating branches, commits, pull requests, tags, or release branches. - Keep each branch, commit, and PR small enough to review and validate.
- Run relevant checks before committing or requesting review.
- Use Conventional Commits for commits and PR titles.
Defaults
- Use trunk-based development.
- Treat
mainas the only long-lived branch. - Create short-lived
feature/,bugfix/,hotfix/, orrelease/branches frommain. - Avoid force pushing
main. - Prefer feature flags for large features that cannot be completed quickly.
- Use squash merge for pull requests unless the project explicitly requires a different merge strategy.
Commit Message Shape
Use:
<type>(<scope>): <subject>
[body]
[footer]
Use types: feat, fix, docs, style, refactor, perf, test,
build, ci, chore, revert.
Release Shape
Use semantic version tags:
v<major>.<minor>.<patch>[-prerelease]
Examples: v1.2.3, v2.0.0-rc.1.
Reference Files
references/git-workflow-standards.md- Detailed branch, commit, pull request, versioning, tag, and prohibited-pattern rules.