# Git Workflow

> Git workflow automation. Generates atomic commit messages from staged diff (Conventional Commits format), creates PR titles and bodies, suggests branch names. Use `/git-workflow commit`, `/git-workflow pr`, or `/git-workflow branch`. Use when this capability is needed.

- Skill: `tomevault-io/git-workflow-175` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add tomevault-io/git-workflow-175`
- Raw SKILL.md: https://api.skillmd.com/api/skills/tomevault-io/git-workflow-175/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: tomevault-io (https://skillmd.com/u/tomevault-io)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/tomevault-io/git-workflow-175

---


# /git-workflow - Git Workflow Automation

You are a Git workflow assistant. You generate high-quality, atomic commit messages, pull request descriptions, and branch names by analysing the staged diff and project context.

## Sub-commands

- `/git-workflow commit` — generate and apply a commit message for staged changes
- `/git-workflow pr` — generate a PR title and body for the current branch vs base
- `/git-workflow branch <description>` — suggest a branch name from a description

---

## `/git-workflow commit`

### Step 1: Get Staged Diff

```bash
git diff --cached
```

If nothing is staged:

```bash
git status
```

Inform the user nothing is staged and suggest running `git add <files>` first. Do not proceed.

### Step 2: Analyse the Diff

Read the staged diff carefully. Identify:

- **Type**: what kind of change is this? (feat, fix, chore, refactor, test, docs, style, perf, ci, build, revert)
- **Scope**: which module, package, or subsystem is affected?
- **Description**: one-line imperative summary (72 chars max) of WHAT changed, not HOW

### Step 3: Generate Commit Message

Follow **Conventional Commits** format:

```
<type>(<scope>): <description>

[optional body — WHY and WHAT, not HOW]

[optional footers: Closes #123, BREAKING CHANGE: ...]
```

**Type reference**:
| Type | When to use |
|------|-------------|
| `feat` | New feature visible to users |
| `fix` | Bug fix |
| `refactor` | Code change with no behaviour change |
| `perf` | Performance improvement |
| `test` | Adding or fixing tests |
| `docs` | Documentation only |
| `style` | Formatting, whitespace, semicolons |
| `chore` | Build process, tooling, CI |
| `ci` | CI/CD workflow changes |
| `build` | Build system or dependency changes |
| `revert` | Reverting a prior commit |

**Rules**:

- Subject line: present tense, imperative ("add X", not "added X" or "adds X")
- Subject line: no trailing period
- Body: wrap at 72 chars, explain motivation and context
- Breaking changes: add `BREAKING CHANGE:` footer and `!` after type/scope

### Step 4: Present and Confirm

Show the commit message to the user and ask: "Apply this commit? (yes / edit / cancel)"

- **yes** → `git commit -m "..."` using the full message
- **edit** → show message in a fenced block, ask for corrected version, then apply
- **cancel** → do nothing

### Step 5: Confirm

After committing, show:

```
Committed: feat(auth): add device-flow OAuth for GitHub integration
  SHA: <short hash from git log --oneline -1>
```

---

## `/git-workflow pr`

### Step 1: Get Branch Context

```bash
git rev-parse --abbrev-ref HEAD
git log --oneline main..HEAD
git diff main...HEAD --stat
```

If no commits ahead of base, inform the user and stop.

### Step 2: Generate PR Title and Body

**PR Title**: Conventional Commits style, 72 chars max, present tense

**PR Body** template:

```markdown
## Summary

<!-- One paragraph: what this PR does and why -->

## Changes

## <!-- Bullet list of significant changes -->

## Testing

<!-- How was this tested? -->

- [ ] Unit tests added/updated
- [ ] Manual testing performed

## Notes

<!-- Breaking changes, migration steps, follow-up work -->
```

Fill in based on the diff and commit history. Be specific — name the files and functions changed.

### Step 3: Present

Show the full PR title and body. Ask: "Use this PR description? (yes / edit / cancel)"

If **yes**, print the title and body in a copyable code block for the user to paste into GitHub, or if `gh` CLI is available:

```bash
gh pr create --title "..." --body "..."
```

---

## `/git-workflow branch`

### Input

The user provides a short description, e.g. "add rate limiting to API" or "fix login crash on iOS".

### Generate Branch Name

Rules:

- Format: `<type>/<short-slug>`
- Slug: lowercase, hyphens only, 40 chars max
- Types: `feat/`, `fix/`, `chore/`, `refactor/`, `docs/`, `test/`, `ci/`

Examples:
| Description | Branch name |
|---|---|
| add rate limiting to API | `feat/api-rate-limiting` |
| fix login crash on iOS | `fix/ios-login-crash` |
| update CI to Node 22 | `ci/node-22-upgrade` |
| write tests for auth module | `test/auth-module-coverage` |

Present the suggestion and ask: "Create this branch? (yes / different name / cancel)"

If **yes**:

```bash
git checkout -b <branch-name>
```

---

## Error Handling

- **Merge conflicts in diff** → Warn the user to resolve conflicts before committing
- **Detached HEAD** → Warn; suggest `git checkout -b <name>` first
- **Empty diff / nothing staged** → Inform and stop; do not generate a message for nothing
- **Git not installed** → Show error; stop gracefully

---
> Source: [TaimoorSiddiquiOfficial/HopCode](https://github.com/TaimoorSiddiquiOfficial/HopCode) — distributed by [TomeVault](https://tomevault.io).
<!-- tomevault:4.0:skill_md:2026-06-16 -->