Marketplace commit

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

install

source · Clone the upstream repo

git clone https://github.com/aiskillstore/marketplace

Claude Code · Install into ~/.claude/skills/

T=$(mktemp -d) && git clone --depth=1 https://github.com/aiskillstore/marketplace "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/davidopdebeeck/commit" ~/.claude/skills/aiskillstore-marketplace-commit-292088 && rm -rf "$T"

manifest: skills/davidopdebeeck/commit/SKILL.md

source content

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

fix: correct X handler logic

Domain logic updates →

feat: add X behavior to aggregate

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