git-commit

Stars11

Forks0

UpdatedJune 30, 2026 at 09:09

Analyze code changes and generate professional Git Commit Messages adhering to the industry-standard Conventional Commits specification.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Source

pirate-608

pirate-608/ZJUers_simulator

View GitHub Repository View Creator Repositories

Download

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

File Explorer

3 files

SKILL.md

readonly

name	git-commit
description	Analyze code changes and generate professional Git Commit Messages adhering to the industry-standard Conventional Commits specification.
argument-hint	[--tag <tagname>] [--push]

Git Commit Skill

🎯 Objective

This skill guides the AI to analyze staged code changes (git diff) and generate clear, semantic, and structurally sound Git Commit Messages following the Conventional Commits specification.

📜 Core Principles

Atomic: One commit must do exactly one thing.
Clear: Explain what was done and why, rather than just describing mechanical code changes.
Imperative Mood: The subject line must use the imperative mood (e.g., "Add feature", not "Added feature" or "Adds feature"), as if giving a command to the codebase.
Length Limits: Subject line ≤ 50 characters. Body lines ≤ 72 characters for optimal terminal readability.
No Trailing Punctuation: Do not end the subject line with a period (.).

⚙️ Execution Flow (Instructions for AI)

When requested to generate a commit message, you MUST follow this exact branching logic:

Step 1: Analyze Atomicity (CRITICAL)

Review the provided git diff or code changes.

IF the changes contain multiple unrelated modifications (e.g., fixing a bug in auth AND updating documentation in README), STOP.
- Action: Output only a brief, polite warning: "⚠️ The staged changes appear to contain multiple unrelated modifications. For best practices, please split them into separate atomic commits before I generate the message." Do not generate a commit message template.
ELSE (the changes are atomic or logically grouped), proceed to Step 2.

Step 2: Determine Metadata

Type: Select the most appropriate type from the [Type List] below.
Scope (Optional): Extract the specific module/component affected (e.g., auth, ui, api).

Step 3: Generate Output (STRICT TEMPLATE)

If Step 1 passed, you MUST output the commit message strictly adhering to the template below. Do not add conversational filler (like "Here is your commit message:") before or after the template.

📚 Type List

feat: A new feature
fix: A bug fix
docs: Documentation only changes
style: Formatting, white-space, missing semi-colons (no logic change)
refactor: Code change that neither fixes a bug nor adds a feature
perf: Code change that improves performance
test: Adding missing tests or correcting existing tests
build: Changes affecting the build system or external dependencies
ci: Changes to CI configuration files and scripts
chore: Other changes that don't modify src or test files
revert: Reverts a previous commit

Step 4: Handle Git Tag (Conditional - ONLY if user requested)

After outputting the commit message template, IF the user explicitly requested a tag (e.g., "create tag v1.0.0", "tag this commit", or via a --tag parameter), execute the following logic:

Create the tag locally: Run git tag <tagname>
Check for existing tag: If the tag already exists, output a warning:
- "⚠️ Tag '' already exists. Force recreate? (yes/no)"
- IF user confirms, run git tag -f <tagname>
Push the tag (Conditional):
- IF user also requested push (or --push is present), run git push origin <tagname>
- IF pushing to remote and tag already exists remotely, use git push origin <tagname> --force (with user confirmation)
If no tag requested: Skip this entire step silently.

Important: Tag creation is a separate operation from commit creation. The commit message template is always output first, then tag logic executes only on user request.

📝 Commit Message Template

<type>(<scope>): <subject>
# ↑ Max 50 chars. Imperative mood. No trailing period.

<body>
# ↑ Blank line
# Explain the motivation and context ("why", not "how").
# Wrap lines at 72 characters.

<footer>
# ↑ Blank line (only if applicable)
# Issue references: Closes #123, Fixes #456
# Breaking changes: BREAKING CHANGE: <explain incompatibility and migration>

🚫 Anti-Patterns to Avoid

❌ update code (Too vague)
❌ Fixed the bug (Not imperative, lacks context)
❌ feat: add new feature. (Trailing period)
❌ Generating a single commit message for unrelated changes (violates Step 1).
❌ Adding conversational text like "Sure, here is your commit message:" around the template.

📚 Additional Resources

Commit Examples: See references/commit-examples.md for real-world commit message samples.
Tag Handling Examples: See references/tag-handling-examples.md for the exact structure.

More from this repository

same repository

zjus-docs-sync

pirate-608/ZJUers_simulator

Update ZJUers Simulator documentation after product, API, onboarding, deployment, architecture, or agent-workflow changes. Use when modifying VitePress pages, README files, AGENTS.md, .claude/CLAUDE.md, user guides, developer guides, navigation, screenshots/previews, API docs, setup docs, or when removing stale references such as the old entrance exam flow.

2026-07-0111

zjus-player-onboarding

pirate-608/ZJUers_simulator

Work safely on the ZJUers Simulator player entry flow: invite-code auth, JWT versus persistent user token handling, character creation, initial stat budget validation, returning-user save selection, WebSocket save loading, and new-game reset behavior. Use when modifying LoginView, CharacterCreate, SaveSelect, App phase routing, auth.py, game.py, GameService, SaveService, or related tests.

2026-07-0111

zjus-pylance-noise

pirate-608/ZJUers_simulator

Triage and reduce Pylance/Pyright diagnostics in ZJUers Simulator. Use when Codex sees or is asked about Python/Pylance/Pyright warnings in the FastAPI backend, SQLAlchemy async models/sessions, Redis asyncio calls, OpenAI response parsing, Pydantic schemas, import resolution, venv interpreter drift, generated/cache diagnostics, or editor-only type noise that should be cleaned without hiding real defects.

2026-07-0111

code-review

pirate-608/ZJUers_simulator

Path-aware full-stack review workflow for ZJUers Simulator. Use when reviewing changes, running checks, triaging regressions, validating frontend/backend edits, or deciding which focused tests/type checks to run.

2026-06-3011

zjus-game-item

pirate-608/ZJUers_simulator

Add, adjust, remove, or review ZJUers Simulator items in world/items.json. Use when the user asks Claude to create a new purchasable item, tune item prices/effects, add item categories or tags, or check item balance against the stat registry.

2026-06-3011

zjus-game-stat

pirate-608/ZJUers_simulator

Add, adjust, or remove ZJUers Simulator gameplay stats through the stat registry pipeline. Use when the user asks Claude to create a new attribute, change an attribute range/default, expose a stat to item/event effects, or update character creation allocatable stats.

2026-06-3011

name	git-commit
description	Analyze code changes and generate professional Git Commit Messages adhering to the industry-standard Conventional Commits specification.
argument-hint	[--tag <tagname>] [--push]

Git Commit Skill

🎯 Objective

This skill guides the AI to analyze staged code changes (git diff) and generate clear, semantic, and structurally sound Git Commit Messages following the Conventional Commits specification.

📜 Core Principles

Atomic: One commit must do exactly one thing.
Clear: Explain what was done and why, rather than just describing mechanical code changes.
Imperative Mood: The subject line must use the imperative mood (e.g., "Add feature", not "Added feature" or "Adds feature"), as if giving a command to the codebase.
Length Limits: Subject line ≤ 50 characters. Body lines ≤ 72 characters for optimal terminal readability.
No Trailing Punctuation: Do not end the subject line with a period (.).

⚙️ Execution Flow (Instructions for AI)

When requested to generate a commit message, you MUST follow this exact branching logic:

Step 1: Analyze Atomicity (CRITICAL)

Review the provided git diff or code changes.

IF the changes contain multiple unrelated modifications (e.g., fixing a bug in auth AND updating documentation in README), STOP.
- Action: Output only a brief, polite warning: "⚠️ The staged changes appear to contain multiple unrelated modifications. For best practices, please split them into separate atomic commits before I generate the message." Do not generate a commit message template.
ELSE (the changes are atomic or logically grouped), proceed to Step 2.

Step 2: Determine Metadata

Type: Select the most appropriate type from the [Type List] below.
Scope (Optional): Extract the specific module/component affected (e.g., auth, ui, api).

Step 3: Generate Output (STRICT TEMPLATE)

If Step 1 passed, you MUST output the commit message strictly adhering to the template below. Do not add conversational filler (like "Here is your commit message:") before or after the template.

📚 Type List

feat: A new feature
fix: A bug fix
docs: Documentation only changes
style: Formatting, white-space, missing semi-colons (no logic change)
refactor: Code change that neither fixes a bug nor adds a feature
perf: Code change that improves performance
test: Adding missing tests or correcting existing tests
build: Changes affecting the build system or external dependencies
ci: Changes to CI configuration files and scripts
chore: Other changes that don't modify src or test files
revert: Reverts a previous commit

Step 4: Handle Git Tag (Conditional - ONLY if user requested)

After outputting the commit message template, IF the user explicitly requested a tag (e.g., "create tag v1.0.0", "tag this commit", or via a --tag parameter), execute the following logic:

Create the tag locally: Run git tag <tagname>
Check for existing tag: If the tag already exists, output a warning:
- "⚠️ Tag '' already exists. Force recreate? (yes/no)"
- IF user confirms, run git tag -f <tagname>
Push the tag (Conditional):
- IF user also requested push (or --push is present), run git push origin <tagname>
- IF pushing to remote and tag already exists remotely, use git push origin <tagname> --force (with user confirmation)
If no tag requested: Skip this entire step silently.

Important: Tag creation is a separate operation from commit creation. The commit message template is always output first, then tag logic executes only on user request.

📝 Commit Message Template

<type>(<scope>): <subject>
# ↑ Max 50 chars. Imperative mood. No trailing period.

<body>
# ↑ Blank line
# Explain the motivation and context ("why", not "how").
# Wrap lines at 72 characters.

<footer>
# ↑ Blank line (only if applicable)
# Issue references: Closes #123, Fixes #456
# Breaking changes: BREAKING CHANGE: <explain incompatibility and migration>

🚫 Anti-Patterns to Avoid

❌ update code (Too vague)
❌ Fixed the bug (Not imperative, lacks context)
❌ feat: add new feature. (Trailing period)
❌ Generating a single commit message for unrelated changes (violates Step 1).
❌ Adding conversational text like "Sure, here is your commit message:" around the template.

📚 Additional Resources

Commit Examples: See references/commit-examples.md for real-world commit message samples.
Tag Handling Examples: See references/tag-handling-examples.md for the exact structure.