git-workflow

Applies conventional commits, branching strategy, and pull request rules to git workflows.

Updated Apr 4, 2026
One-click install
npx skills add https://github.com/juanjo-zurich/juarvis-v4 --skill git-workflow-juanjo-zurich
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: git-workflow
Source: https://github.com/juanjo-zurich/juarvis-v4/tree/main/plugins/core/skills/git-workflow
Command: npx skills add https://github.com/juanjo-zurich/juarvis-v4 --skill git-workflow-juanjo-zurich

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams often produce inconsistent commit histories, mixed-concern commits, and unclear pull requests, making code review and project history hard to follow. This Skill enforces a structured git workflow so every change is traceable and reviewable. ## Core Features & Use Cases - Conventional Commits: Standardizes commit messages with typed prefixes (feat, fix, docs, refactor, perf, test, chore) and scoped descriptions. - Commit Discipline: Encourages small, frequent, single-concept commits with meaningful messages explaining what changed and why. - Branching & PR Strategy: Defines branch naming (main, feature/, fix/, refactor/) and pull request rules including CI checks before merge. - Use Case: When finishing a bug fix, the agent writes a commit like "fix: race condition in pluginCache" with a body explaining the technical detail, instead of a vague "fix stuff" message. ## Quick Start Ask the agent to commit the current changes following the git-workflow conventions with a proper conventional commit message.

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 conventional commit message?▼

Use the format type(scope): description, where type is one of feat, fix, docs, refactor, perf, test, or chore. Keep the first line under 72 characters and add an optional body with technical details and reasoning.

What commit types exist in conventional commits?▼

The skill defines seven types: feat for new functionality, fix for bug corrections, docs for documentation, refactor for behavior-preserving changes, perf for performance, test for tests, and chore for build or CI changes.

When should I create a pull request instead of committing directly?▼

Create a pull request for substantial changes, defined as more than 50 lines or architectural modifications. The CI must pass before merging, and the PR description should explain what changed and why.

What branching strategy does this workflow use?▼

It uses a protected main branch that stays stable via CI, plus feature/ branches for new functionality, fix/ branches for urgent bug corrections, and refactor/ branches for large refactorings.

Why should commits be small and frequent?▼

Each commit should represent one logical unit of change, never mixing fixes with features. Committing after each completed phase keeps history reviewable and makes it easier to isolate and revert problematic changes.