Atomui Commit Msg

AtomUI Commit Message Generation Skill

Goals

1. Accurately summarize the commit — Generate a one-line commit message based on the current git staging area, covering all staged changes.

2. Stay consistent with repository style — Match the repository's existing commit conventions rather than mechanically applying a template.

Core Principle

A commit message is not a per-file listing of the diff — it is a compressed expression of the commit's intent. Read the staging area first, then summarize, then output one line.

IMPORTANT: Trigger Conditions

This skill MUST be invoked when the user's message matches ANY of the following patterns. Do NOT skip this skill and handle the request manually.

When triggered, this skill handles the entire commit workflow: reading staged changes, generating the message, creating the commit, and verifying the result. The caller should NOT add extra trailers (e.g., Co-Authored-By) or wrap the message in additional formatting.

Fundamental Rules

1. Default to staged changes only

Generate the message based on staged changes only, because that is what will actually be committed.

Only include unstaged changes if the user explicitly requests it (e.g., "include unstaged" or "cover all changes").

2. Always check recent commit style first

Before generating a message, review recent commits to avoid producing a format inconsistent with the repository's conventions.

3. Default to a single line of output

Unless the user explicitly asks for an explanation or a body, the final response should be one line of commit message only — no analysis, bullet points, code blocks, or quotes.

Execution Steps

Step 1: Read git status, staging area, and recent commits

Gather the following information before generating. Do not guess or rely on filenames alone.

Recommended commands:

git status --short
git diff --cached --stat
git diff --cached
git log --oneline -10 --no-merges

• git status --short — Confirm which files are staged and whether unstaged changes exist.
• git diff --cached --stat — Quickly assess the scope of changes.
• git diff --cached — Read the actual content being committed. This is the primary basis for the message.
• git log --oneline -10 --no-merges — Check the repository's recent commit style, language, and type/scope conventions. When reviewing commit style, ignore any Co-Authored-By: trailers — they are not part of the project's commit convention and must not be reproduced.

Step 2: Check if generation is possible

If the staging area is empty:

• Do NOT fabricate a message.
• Clearly inform the user that there are no staged changes and an accurate commit message cannot be generated.

Step 3: Identify the primary semantic intent

Based on the git diff --cached output:

1. Determine the primary purpose — new feature, bug fix, documentation, refactoring, performance optimization, test, Gallery ShowCase, script/dependency update, etc.
2. Identify the primary affected scope — specific control name, infrastructure module (TokenSystem / Theme / Motion, etc.), Gallery, scripts, docs, etc.
3. If the diff contains multiple files or mixed small changes, use a higher-level summary that covers everything. Do not concatenate per-file descriptions into one long sentence.

Step 4: Align with AtomUI repository style

Prefer to mimic the repository's recent conventions. Common patterns in AtomUI:

• feat(Component): ...
• fix(Component): ...
• refactor(Component): ...
• docs: ... / docs(Core): ...
• chore(deps): ...
• gallery: ... / gallery(Component): ...
• build(ci): ...
• perf(TokenSystem): ...

Notes:

• type and scope MUST be in English.
• subject defaults to English; Chinese is acceptable if the user is conversing in Chinese or explicitly requests it.
• If the repository already uses a more natural phrasing, prefer matching the existing style.
• gallery is used as a type prefix in AtomUI (analogous to site in ant-design) for ShowCase / Gallery app changes.

Step 5: Generate one line

The output must be:

• One line
• Covering all staged changes
• Concise
• Consistent with repository style
• Ready to use as-is for the commit

Writing Rules

Header format

Use one of the following:

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

or (when scope cannot be determined):

<type>: <subject>

Examples:

• feat(Button): add danger style variant for ghost button
• fix(Select): prevent dropdown from closing on multi-select click
• refactor(Avatar): extract AbstractAvatar to AtomUI.Controls
• docs(Core): add three-tier architecture documentation
• gallery: add QRCode showcase with comprehensive examples
• chore(deps): bump Avalonia from 11.3.1 to 11.3.2
• fix(Select): 修复多选模式下点击后下拉框意外关闭

Header rules

• Use imperative mood — add / fix / update, not added / fixed / updated. For Chinese subjects, start with a verb: "修复" / "添加" / "调整".
• Do NOT capitalize the first letter of an English subject.
• Do NOT end with a period (. or 。).
• Keep the header line to 72 characters or fewer.
• Avoid vague terms like WIP, misc, update files.