All skills
github avatar

/commit-message-storyteller

@252f342 official
by githubgithub/awesome-copilot40k stars
5,040

Analyzes git diffs or staged changes and generates narrative commit messages that explain WHY a change was made, not just what changed — following Conventional Commits format. Use when asked to "write a commit message", "generate a commit", "describe my changes", "what should I commit this as", "commit this", "summarize my diff", or "help me commit". Works with git diff output, staged files, or plain descriptions of changes.

Use this Skill: https://skilld.dev/gh/github/awesome-copilot/commit-message-storyteller

This session only. Nothing lands on disk.

referencesconventional-commits-guide.md

≈1k tokens on demand. Your agent reads this file only when SKILL.md points to it.

Conventional Commits — Quick Reference Guide

Full spec: https://www.conventionalcommits.org/en/v1.0.0/


Format

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

[optional body]

[optional footer(s)]

Type Examples

feat — New Feature

feat(payments): add Apple Pay support for checkout flow

Users in supported regions can now complete purchases using Apple Pay.
This reduces checkout friction and is expected to improve mobile conversion rates.

Closes #88

fix — Bug Fix

fix(api): correct off-by-one error in pagination offset

The results page was skipping the last item on every page because the
offset calculation used `>` instead of `>=`. Users were missing records
silently with no error.

Fixes #201

refactor — Code Restructure (no behavior change)

refactor(user-service): extract email validation into shared utility

Email validation logic was duplicated across 4 modules. Extracted into
`utils/validators.ts` so future changes only need to happen in one place.

perf — Performance Improvement

perf(dashboard): lazy-load chart components to reduce initial bundle size

The dashboard was importing all chart types upfront, adding ~180KB to the
initial load. Charts are now loaded on demand, cutting initial load time
by ~40% on slow connections.

docs — Documentation Only

docs(readme): add local development setup instructions

New contributors were struggling to get the dev environment running.
Added step-by-step instructions covering Node version, env vars, and
the database seed command.

test — Tests Added or Updated

test(auth): add coverage for concurrent login edge cases

The login flow had no tests for simultaneous requests from the same
session. Added tests that verify only one session token is issued
when multiple requests arrive in the same tick.

chore — Maintenance / Config

chore(deps): upgrade eslint from v8 to v9

v8 reached end-of-life. Migrated config to flat config format required
by v9. No rule changes — this is a tooling-only update.

ci — CI/CD Pipeline

ci: add caching for node_modules in GitHub Actions

Cold CI runs were taking 4+ minutes due to repeated installs.
Adding cache restore on lockfile hash reduces this to ~90 seconds.

revert — Reverting a Commit

revert: feat(notifications): add push notification opt-in

Reverts commit a3f92bc.

The push notification feature caused a crash on Android 12 devices.
Rolling back until the root cause is identified.

Scope Guidelines

The scope is optional but strongly recommended. It should be:

  • A short noun identifying the area of the codebase: auth, api, dashboard, payments
  • Consistent across the project (don't mix user and users)
  • Omitted if the change is truly global

Breaking Changes

Add BREAKING CHANGE: in the footer (or use ! after the type):

feat(api)!: remove v1 endpoints

All v1 REST endpoints have been removed following the 6-month deprecation
notice. Consumers must migrate to v2 before upgrading.

BREAKING CHANGE: /api/v1/* routes no longer exist. See migration guide at docs/v2-migration.md

Body Writing Tips

Ask yourself before writing the body:

  • What was broken / missing before this change?
  • Why was this approach chosen over alternatives?
  • What will be different for users or developers after this?

Avoid:

  • Restating what the diff already shows ("changed the variable name")
  • Vague language ("various improvements", "miscellaneous fixes")
  • Future tense ("this will fix...") — write in present/past tense

Commit Message Anti-Patterns

❌ Bad ✅ Better
fix bug fix(cart): prevent duplicate items on rapid add-to-cart clicks
updates feat(profile): allow users to update display name
WIP Don't commit WIP — stash it
misc changes Split into separate, meaningful commits
John's changes Describe what changed, not who changed it

Source: SKILL.md on GitHub

No alerts16d3 checks · Risk SAFE
  • Gen Agent Trust Hub16d

    The skill is designed to transform git diffs and code descriptions into formatted commit messages. It is generally safe but carries a low risk of indirect prompt injection because it processes untrusted user-provided content.

  • Socket16d

    No alerts

  • Snyk16d

    Risk: LOW · No issues

Signed by skilld at 252f342. This ties the file your Agent reads to that commit on GitHub. It does not review the instructions.

Last checked against GitHub yesterday.

Activeupdated 5 months ago
  • Git/VCS
  • commit-messages
  • conventional-commits
  • diff
  • workflow

README badge

README badge for github/awesome-copilot/commit-message-storyteller

Analyzes git diffs or staged changes and generates narrative commit messages following Conventional Commits format, emphasizing why a change was made rather than just what changed. Guides you through identifying commit type, crafting an imperative subject line, and writing a body that explains the problem solved and context.

Generated from the current SKILL.md.

Does this skill work with any git workflow, or just certain branching strategies?
It works with any git workflow. The skill analyzes diffs and generates Conventional Commits messages regardless of whether you're using Git Flow, trunk-based development, or any other strategy.
What if my changes don't fit neatly into one of the Conventional Commits types?
The skill provides a mapping table of ten types (feat, fix, refactor, perf, docs, style, test, chore, ci, revert) that cover the vast majority of real changes. If your change spans multiple types, the skill will ask you to clarify or suggest splitting it into separate commits.
Can I use this if I only have a description of changes, not an actual git diff?
Yes. The skill accepts a plain description of what changed and why, and will generate a commit message without requiring `git diff` output.
Does this enforce breaking change notation automatically?
The skill detects breaking changes from the diff context and will add a `BREAKING CHANGE:` footer automatically if one is identified.
What happens if I don't have an issue number to reference in the footer?
You can omit the footer entirely. Issue references are optional — the skill only includes them if relevant context is available.

Generated from the current SKILL.md. These answers refresh after source changes.