Commit skills davidopdebeeck commit

Skill bg-szy/TOP-SKILLS/skills/marketplace/commit__skills-davidopdebeeck-commit

全球最大的 Claude Code 技能聚合库 · 收录 3900+ 来自 12+ 来源的技能，提供在线搜索与趋势分析看板 / The world's largest Claude Code skill aggregation hub — 3900+ skills from 12+ sources with online search and trend dashboard

Install

npx -y skills add bg-szy/TOP-SKILLS --skill commit__skills-davidopdebeeck-commit

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

2 things to look at

no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

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, 699 tokens by cl100k_base, 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