Git and Pull Request Workflows with Skills

Every development team has a standard for Git. You want conventional commits with clean scopes, pull requests that link to issue trackers with reproducible test steps, and pre-merge reviews that catch leftover debug lines before CI runs.

In practice, these standards constantly slip. Developers under deadline pressure write "fix bugs" as a commit message, leave PR descriptions blank, and forget to run linters before pushing. Encoding these expectations into Claude skills eliminates this friction by making high-quality Git hygiene the path of least resistance.

Why Git workflows are the highest-ROI skills

Git workflows are the ideal candidate for skill automation for three reasons:

• Inputs are bounded and unambiguous: Claude inspects `git diff --staged` or `git log main...HEAD`, which are structured, deterministic text diffs.
• Outputs follow rigid conventions: Conventional commits and PR templates have clear structural rules that models excel at formatting.
• Immediate feedback: A well-crafted commit message or PR summary saves mental energy several times per day for every engineer on the team.

Building a conventional commit helper

Here is a complete, production-tested `commit-helper` skill. It inspects only what you have staged, selects the correct conventional commit type, and formats a concise summary under 72 characters.

---
name: commit-helper
description: Use when writing a conventional git commit message for staged changes in the repository.
---

# Commit helper

When invoked:
1. Run `git diff --staged --name-status` to inspect changed files.
2. Run `git diff --staged` to review the exact diff.
3. Select the appropriate conventional commit type: feat, fix, docs, refactor, test, or chore.
4. Determine the primary scope from the affected directory (e.g. auth, billing, routes).
5. Format the message as `<type>(<scope>): <imperative summary>` under 72 characters.
6. If the diff resolves an issue, add `Closes #<id>` in a separate body paragraph.
7. Present the proposed message and ask for user confirmation before committing.

Automating comprehensive pull request descriptions

Writing a thorough pull request description is often neglected because it requires gathering context across multiple commits. A `pr-summary` skill automates this by comparing your feature branch against the default branch.

---
name: pr-summary
description: Use when drafting a pull request description for the current branch against main.
---

# Pull Request Summary

1. Run `git diff main...HEAD --stat` and review the full branch diff.
2. Run `git log main...HEAD --oneline` to inspect commit history.
3. Output a markdown document matching our team template:
   - ## Summary (three clear bullet points explaining why the change was made)
   - ## Technical Changes (bulleted breakdown grouped by architectural layer)
   - ## Verification (exact commands executed and test results confirmed)

Running a pre-merge code review checklist

Before pushing code to a remote branch, you can have Claude conduct a self-review against common anti-patterns. A `pre-merge-review` skill examines your branch diff for leftover console statements, missing tests, and unhandled error cases.

Gating side-effecting Git actions

Git commands that modify remote history (such as `git push` or `git tag`) should never run autonomously. For skills that execute push operations, always include `disable-model-invocation: true` in your frontmatter so the skill runs only when you explicitly type its slash command.