Skip to main content
ClaudeWave
EN, English
Skill288 repo starsupdated 7d ago

git-commit-smart

git-commit-smart automatically generates conventional commit messages by analyzing staged git changes and applying standardized formatting rules. Use this when committing code to produce messages that follow best practices, including appropriate type classification (feat, fix, docs, etc.), optional scope notation, and descriptive subject lines and body text written in imperative mood.

Install in Claude Code
Copy
git clone --depth 1 https://github.com/majiayu000/spellbook /tmp/git-commit-smart && cp -r /tmp/git-commit-smart/skills/git-commit-smart ~/.claude/skills/git-commit-smart
Then start a new Claude Code session; the skill loads automatically.

SKILL.md

# Smart Git Commit

> Inspired by [claude-code-plugins-plus](https://github.com/jeremylongshore/claude-code-plugins-plus)

## Purpose

Automatically generate meaningful commit messages by analyzing staged changes, following conventional commit format.

## Commit Message Format

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

<body>

<footer>
```

### Types

| Type | Description |
|------|-------------|
| `feat` | New feature |
| `fix` | Bug fix |
| `docs` | Documentation only |
| `style` | Formatting, no code change |
| `refactor` | Code change, no new feature or fix |
| `perf` | Performance improvement |
| `test` | Adding/updating tests |
| `chore` | Maintenance tasks |
| `ci` | CI/CD changes |
| `build` | Build system changes |

### Scope

Optional, indicates the section of codebase:
- `auth`, `api`, `ui`, `db`, `config`, etc.

### Subject

- Imperative mood ("add" not "added")
- No period at end
- Max 50 characters
- Lowercase

### Body

- Explain WHAT and WHY, not HOW
- Wrap at 72 characters
- Separate from subject with blank line

### Footer

- Breaking changes: `BREAKING CHANGE: description`
- Issue references: `Closes #123`, `Fixes #456`

## Workflow

### 1. Analyze Changes

```bash
# View staged changes
git diff --staged

# View changed files
git diff --staged --name-only

# View stats
git diff --staged --stat
```

### 2. Determine Type

Based on changes:
- New files with features → `feat`
- Modified files fixing issues → `fix`
- Only .md files → `docs`
- Only test files → `test`
- package.json, configs → `chore` or `build`

### 3. Identify Scope

Look at file paths:
- `src/auth/*` → scope: `auth`
- `src/api/*` → scope: `api`
- `tests/*` → scope: `test`
- Multiple areas → omit scope or use broader term

### 4. Write Subject

Summarize the change:
```
feat(auth): add OAuth2 login support
fix(api): handle null response in user endpoint
docs: update README with installation steps
refactor(db): extract query builder to separate module
```

### 5. Write Body (if needed)

For complex changes:
```
feat(auth): add OAuth2 login support

Implement OAuth2 authentication flow with support for
Google and GitHub providers. This allows users to sign
in without creating a separate account.

- Add OAuth2 client configuration
- Implement callback handlers
- Store OAuth tokens securely
- Add provider selection UI
```

## Examples

### Simple Feature
```
feat(ui): add dark mode toggle
```

### Bug Fix with Issue Reference
```
fix(api): prevent duplicate user creation

Check for existing email before inserting new user record.
Race condition could cause duplicate entries when requests
arrived simultaneously.

Fixes #234
```

### Breaking Change
```
feat(api)!: change response format to JSON:API

BREAKING CHANGE: All API responses now follow JSON:API
specification. Clients must update their parsers.

Migration guide: docs/migration-v2.md
```

### Multiple Files, Single Purpose
```
refactor: extract validation logic to shared module

Move duplicate validation code from controllers to
a shared validation module. Reduces code duplication
and ensures consistent validation across endpoints.
```

## Anti-Patterns to Avoid

```
❌ "fix stuff"
❌ "update code"
❌ "WIP"
❌ "changes"
❌ "fixed bug"
❌ "misc updates"
❌ Commits with 50+ files and vague message
```

## Best Practices

1. **Atomic commits** - One logical change per commit
2. **Meaningful messages** - Future you will thank present you
3. **Reference issues** - Link to tickets/issues when relevant
4. **Review before commit** - `git diff --staged` always
5. **Don't commit secrets** - Check for API keys, passwords

## Quick Reference

```bash
# Stage specific files
git add <file>

# Stage all changes
git add -A

# Interactive staging
git add -p

# Commit with message
git commit -m "type(scope): subject"

# Commit with body
git commit -m "type(scope): subject" -m "body paragraph"

# Amend last commit
git commit --amend
```
agentsmd-optimizeSkill

Audit AND optimize a CLAUDE.md / AGENTS.md instruction file — score it against the five high-leverage patterns, flag anti-patterns, then apply approved fixes in place. Use when the user says 优化 CLAUDE.md / 优化 AGENTS.md / optimize my agent doc / 帮我改 claudemd, or after an audit when they want the fixes applied (not just reported).

agentsmd-scaffoldSkill

Generate or update repository-specific AGENTS.md instruction files from real repo evidence. Use when asked to create, design, scaffold, split, or improve root or scoped AGENTS.md files for Codex/Claude/agent workflows, especially when a repo needs directory-specific rules, validation commands, generated-file boundaries, or a short agent onboarding router.

api-designSkill

REST/GraphQL/gRPC API design best practices. Use when designing APIs, defining contracts, handling versioning. Covers OpenAPI 3.2, GraphQL Federation, gRPC streaming.

app-ui-designSkill

Mobile app UI design expert for iOS and Android. Use when designing app interfaces, creating design systems, ensuring accessibility, or following platform guidelines. Covers Material Design 3, Human Interface Guidelines, color theory, typography, and 2025 trends.

app-user-story-qaSkill

End-to-end app feature inventory and user-story testing workflow with a canonical tracker. Use when the user asks to audit every feature, derive expected behavior from code, test user journeys, or explicitly fix and retest documented UX or logistical defects.

architecture-foundationSkill

Design architecture foundations before implementation. Use when asked to design or refactor architecture, choose Rust/Go crate, package, module, runtime, workflow, or service boundaries, compare mature project architecture, prevent stacked one-off PRs, audit migration debt in existing repos, or produce a spec before coding.

architecture-researchSkill

Evidence-driven architecture research for understanding real systems and making technical decisions. Use when doing architecture landscape studies, source-backed system archaeology, build-vs-buy or adopt/adapt/build decisions, open-source and commercial comparisons, revisiting an earlier architecture choice, or handling requests such as 架构调研, 架构选型, 竞品架构, 技术尽调, 同类方案, 开源替代, how is X built, and what should we learn from X. Do not use for small mechanical changes, market-only discovery, or detailed design after the technology direction is already fixed.

ask-opencliSkill

Ask Grok or Gemini via opencli (browser-session based, no API cost). Use when the user says "问 grok", "问 gemini", "ask grok", "ask gemini", "用 grok 查", "grok 怎么看", "让 gemini 分析", or wants a second opinion from Grok/Gemini without paying API tokens. Routes to opencli which drives the already-logged-in Chrome session.