git

Enforce conventional commits format for Git commit messages and pull request descriptions.

35|4|Updated Dec 18, 2024
One-click install
npx skills add https://github.com/wellcrafted-dev/wellcrafted --skill git-wellcrafted-dev
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: git
Source: https://github.com/wellcrafted-dev/wellcrafted/tree/main/.claude/skills/git
Command: npx skills add https://github.com/wellcrafted-dev/wellcrafted --skill git-wellcrafted-dev

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

This Skill provides comprehensive guidelines for writing effective Git commits and pull request descriptions, ensuring clarity, consistency, and maintainability in your codebase.

Core Features & Use Cases

  • Conventional Commits: Enforces a standardized format for commit messages (<type>[scope]: <description>).
  • Commit Best Practices: Guides on writing clear subjects, detailed bodies explaining the "why," and atomic commits.
  • Pull Request Guidelines: Details on structuring PR descriptions with a clear "what" and "why," including mandatory code examples for API changes and refactors.
  • Visual Communication: Encourages the use of ASCII art for diagrams (journeys, layers, flows) to explain complex changes.
  • Issue Referencing: Provides guidance on linking PRs to GitHub issues using Closes #, Partially addresses #, or Lays groundwork for #.
  • Username Verification: Emphasizes verifying GitHub usernames programmatically before mentioning them.
  • Merge Strategy: Recommends using merge commits (gh pr merge --merge) over squash or rebase.

Quick Start

Use the git skill to write a commit message for a new feature that adds user authentication.

Frequently Asked Questions about git

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write a conventional commit message for a breaking change?

Conventional commit messages for breaking changes use the format `<type>[scope]: <description>` and must include a `BREAKING CHANGE:` footer in the commit body. The subject line should be clear and concise, while the body explains the reasoning behind the change.

What is the best way to structure a pull request description for a complex refactor?

Pull request descriptions should clearly explain the "what" and "why" of the change. For refactors, include mandatory code examples, use ASCII art diagrams to visualize flows or layers, and properly link related issues using keywords like `Closes #`.

Should I use squash, rebase, or merge commits when merging a pull request?

Merge commits are recommended over squash or rebase to preserve the full development history. You can execute this strategy using the command `gh pr merge --merge` to maintain a clear, traceable record of changes across your codebase.

When do I need to use ASCII diagrams in a pull request?

ASCII diagrams should be used in pull requests to visually communicate complex changes such as system layers, user journeys, or data flows. This helps reviewers understand structural modifications that are difficult to grasp through code examples alone.

How do I reference a GitHub issue correctly in a pull request description?

GitHub issues are referenced in pull requests using specific keywords like `Closes #`, `Partially addresses #`, or `Lays groundwork for #` followed by the issue number. This programmatically links the PR to the issue and manages issue closure upon merging.

Can I mention a GitHub username in a pull request without verifying it first?

GitHub usernames must be verified programmatically before being mentioned in a pull request description. This ensures the mention tags the correct active user and avoids notifying non-existent or incorrect accounts.