git-commit

النجوم١١

التفرعات٠

آخر تحديث٣٠ يونيو ٢٠٢٦ في ٠٩:٠٩

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

التثبيت

التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.

المصدر

pirate-608

pirate-608/ZJUers_simulator

فتح مستودع GitHub عرض مستودعات المنشئ

تنزيل

المهن ذات الصلةSOC

استنادا إلى تصنيف SOC المهني

مطوّرو البرمجياتمهن الحاسوب والرياضيات·SOC 15-1252

مستكشف الملفات

3 ملفات

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.

المزيد من هذا المستودع

نفس المستودع

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.