Commit

Skill ComeOnOliver/skillshub/skills/aiskillstore/marketplace/davidopdebeeck/commit

🧠 The right skill, one API call. AI agent skills registry with token-efficient skill resolution. 5,000+ skills from 500+ top repos.

Install

npx -y skills add ComeOnOliver/skillshub --skill commit

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

What its author says it does

Copied from the file, not written here

Generate commit messages following project conventions for staged changes. Use when the user asks to commit changes or run /commit.

SKILL.md

3.1 KB, as published. Nobody here has run it

Commit Message Generator

Generate commit messages following project conventions for staged changes.

Instructions

When this skill is invoked:

Run git diff --staged to review the staged changes
Run git status to understand the overall state
Run git log --oneline -10 to see recent commit style for context
Analyze what was changed and why
Generate a commit message following the format below
Present the commit message to the user for approval - keep it concise, just show the message and ask for approval
If approved, execute the commit

Presentation Style: Be direct and minimal. Present only the commit message and ask "Proceed with this commit message?" - no analysis, explanations, or bullet points unless the changes are complex or ambiguous.

Commit Message Format

<type>: <short description>

[optional body with more detail]

Types

feat - New feature
fix - Bug fix
refactor - Code restructuring without behavior change
test - Adding or updating tests
docs - Documentation changes
style - Formatting, whitespace (no code change)
chore - Build, config, dependency updates

Rules

First line: Must be under 72 characters
Tense: Present tense, imperative mood ("add" not "added" or "adds")
Description: Complete the sentence "This commit will..."
Body: Optional, use for explaining "why" not "what"
NO AI attribution: Never include "Generated with Claude Code" or "Co-Authored-By" lines

Examples

feat: add auto-reveal toggle for estimation rounds

fix: prevent duplicate user connections to lobby

refactor: extract insight resolution logic to separate resolvers

test: add usecase tests for SetEstimateCommand handler

docs: update architecture documentation with processing groups

chore: upgrade Spring Boot to 3.4.12

Analysis Guidelines

When analyzing changes, consider:

Module affected: Which module (api, lobby, session, ui)?
Layer affected: Domain, usecase, adapter, or API contract?
Intent: What problem does this solve or capability does it add?
Scope: Is this a single logical change or mixed concerns?

Common Patterns to Recognize

Backend Changes:

New Commands/Events/Queries in api/ → feat: add X command/event/query
Handler implementations → feat: implement X handler or fix: correct X handler logic
Domain logic updates → feat: add X behavior to aggregate or refactor: simplify X logic
Read model updates → feat: update X view projection
Tests → test: add tests for X

Frontend Changes:

New components → feat: add X component
State management → feat: implement X state handling
UI improvements → feat: enhance X interface
Styling → style: update X component styles

Mixed Changes:

If frontend + backend for same feature → feat: add X feature (describe full feature)
If unrelated changes → Suggest splitting into multiple commits