mcpField
R
ruby-commit-message

ruby-commit-message

github.com/lucianghindaDevelopment42545 installsUpdated today
Repository

About ruby-commit-message

A commit-message writing skill for Ruby and Rails developers. It applies Conventional Commits structure and guides concise, debugging-oriented explanations of why changes were made.

Key features

  1. 01Apply Conventional Commits types
  2. 02Write imperative subject lines
  3. 03Keep subjects within 70 characters
  4. 04Explain motivation and impact in the body
  5. 05Use supported footers and AI attribution

Use cases

  1. 01Describe a bug fix for future debugging
  2. 02Record a Rails feature change
  3. 03Document a breaking change or ticket reference

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/lucianghinda/superpowers-ruby --skill ruby-commit-message

After installing, type/ruby-commit-messagein Claude Code to confirm it loaded.

Details

From the project README

Ruby Commit Message

Overview

Write structured commit messages following Conventional Commits. The body should help a junior Ruby on Rails developer understand the change during a debugging session.

Format

<type>(<scope>): <subject>

<body>

<footer>

Quick Reference — Commit Types

TypePurpose
featNew feature
fixBug fix
refactorRefactoring (no behavior change)
perfPerformance improvement
docsDocumentation only
testTest additions or corrections
buildBuild system or dependencies
ciCI configuration
choreMaintenance tasks
styleCode formatting (no logic change)
revertRevert previous commit
metaRepository metadata
licenseLicense changes

Subject Line Rules

  • Imperative mood: "Add", "Fix", "Update", "Remove"
  • Present tense: "Add feature" not "Added feature"
  • Capitalized first letter, no period at end
  • Maximum 70 characters
  • Scope (optional): noun describing the section of codebase, e.g. (api), (auth)

Body Guidelines

Couple of sentences, wrapped at 72 chars, blank line after subject. Write for a junior Ruby developer: simple language they can understand during debugging. Add any useful information that would help a junior Ruby developer understand the impact of the change, why the change was done.

  • WHY — motivation, problem, or user impact. Use context if it exists for this.
  • WHAT changed — make this brief; the diff already shows the HOW
  • HOW — only when there are details about the how that are not reflected by the code or the naming in the code

Call out tradeoffs when supported by context. Do not invent details.

Footer & AI Attribution

Fixes TICKET-123       # or: Fixes #123, Refs TICKET-123
BREAKING CHANGE: ...   # for breaking changes; use ! in type too: feat(api)!:
Co-Authored-By: <AI Name> <email>   # when AI generated the change

Do NOT add "Generated by AI" or "Written with Claude" in the subject or body. Use only Co-Authored-By.

Examples

Security/Authorization Fix
fix(api): Scope report access to current user

Report.find allowed any authenticated user to view any report by ID.
Querying through current_user.reports makes Rails raise RecordNotFound
(404) if the report doesn't belong to the requester.
New Feature
feat(alerts): Add Slack thread replies for alert updates

When an alert is updated or resolved, post a reply to the original
Slack thread. This keeps related notifications grouped together.

Refs GH-1234
Breaking Change
feat(api)!: Remove deprecated v1 endpoints

Remove all v1 API endpoints deprecated in version 23.1.
Clients should migrate to v2 endpoints.

BREAKING CHANGE: v1 endpoints no longer available

Common Mistakes

MistakeFix
Body explains HOW without contextOnly include HOW when it helps debugging
Subject describes implementation ("Changed X to Y")Use imperative: "Fix X", "Add Y"
Body repeats what the diff showsExplain WHY it was changed
Subject over 70 charactersTrim scope or rephrase
"Generated by AI" in bodyUse Co-Authored-By footer only

Comments

Markdown supported