mirror of
https://github.com/AtomUI/AtomUI.git
synced 2026-10-17 05:31:01 +08:00
docs: add commit message convention and AI generation skill
This commit is contained in:
chinboy
@@ -0,0 +1,228 @@
|
||||
---
|
||||
name: atomui-commit-msg
|
||||
description: Generate a single-line commit message for AtomUI by reading the project's git staged area and recent commit style. Use when the user asks for a commit message, says "msg", "commit msg", "写提交信息", or wants one-line text that covers all staged changes. Output should match the repository's existing commit style and summarize all staged changes in one line.
|
||||
---
|
||||
|
||||
# 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.
|
||||
|
||||
## Trigger Conditions
|
||||
|
||||
Use this skill when the user:
|
||||
|
||||
- Asks for a commit message or "提交信息"
|
||||
- Says "msg" in a git commit context
|
||||
- Wants a one-line summary generated from current changes
|
||||
- Asks the agent to summarize staged changes into a commit title
|
||||
|
||||
## 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:**
|
||||
|
||||
```bash
|
||||
git status --short
|
||||
git diff --cached --stat
|
||||
git diff --cached
|
||||
git log --oneline -10
|
||||
```
|
||||
|
||||
- `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` — Check the repository's recent commit style, language, and type/scope conventions.
|
||||
|
||||
### 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:
|
||||
|
||||
```text
|
||||
<type>(<scope>): <subject>
|
||||
```
|
||||
|
||||
or (when scope cannot be determined):
|
||||
|
||||
```text
|
||||
<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`.
|
||||
|
||||
### Type selection
|
||||
|
||||
All types are **lowercase**:
|
||||
|
||||
- `feat` — New feature, control, property, or API
|
||||
- `fix` — Bug fix — incorrect behavior, crash, memory leak, rendering issue
|
||||
- `refactor` — Code restructuring with no behavior change — moving code between layers, renaming, splitting classes
|
||||
- `docs` — Documentation only — README, XML doc comments, architecture docs, copilot-instructions
|
||||
- `style` — Code formatting only (no logic change) — whitespace, indentation, code style
|
||||
- `perf` — Performance improvement — rendering optimization, reduced allocations, caching
|
||||
- `test` — Adding or updating tests
|
||||
- `build` — Build system or dependency changes — MSBuild props, `Directory.Packages.props`, scripts
|
||||
- `chore` — Maintenance that doesn't modify src/test — tooling config, `.editorconfig`, IDE settings
|
||||
- `ci` — CI/CD configuration changes
|
||||
- `gallery` — Gallery / ShowCase changes — demo pages, gallery navigation, gallery assets
|
||||
- `release` — Version bumps, changelog updates, release preparation
|
||||
- `revert` — Reverting a previous commit (must reference the reverted commit hash in the body)
|
||||
|
||||
When uncertain:
|
||||
|
||||
- User-visible behavior correction → prefer `fix`
|
||||
- Only text, examples, or descriptions updated → prefer `docs`
|
||||
- Only tooling, dependencies, or scripts adjusted → prefer `chore`
|
||||
- ShowCase / Gallery demo changes → prefer `gallery`
|
||||
- Code structure changed but behavior unchanged → prefer `refactor`
|
||||
|
||||
### Scope selection
|
||||
|
||||
- For changes to a single control, use the control name in PascalCase: `Button`, `Select`, `DatePicker`, `TreeView`, `Cascader`, `FloatButton`
|
||||
- For infrastructure modules, use the module name: `TokenSystem`, `Theme`, `Motion`, `WaveSpirit`, `Core`, `Icons`, `Fonts`, `Generator`, `Native`, `i18n`, `MediaQuery`
|
||||
- For cross-cutting maintenance, use a summary scope: `deps`, `scripts`, `Packaging`, `Bindings`, `MemoryLeak`
|
||||
- For multiple closely related controls, use comma-separated names: `Select,AutoComplete`
|
||||
- If no clear scope exists, it may be omitted
|
||||
|
||||
## Language Rules
|
||||
|
||||
- `type` and `scope` **MUST be English** (they are fixed keywords / identifiers)
|
||||
- `subject` and `body` **default to English; Chinese is also acceptable**
|
||||
- Use Chinese for the `subject` when the user is conversing in Chinese or explicitly requests it
|
||||
|
||||
## Layer Awareness
|
||||
|
||||
AtomUI uses a three-tier architecture: Foundation → Base Control (`AtomUI.Controls`) → Platform Control (`AtomUI.Desktop.Controls`).
|
||||
|
||||
When changes span layers:
|
||||
|
||||
- If each layer's changes can be understood independently, suggest splitting into multiple commits
|
||||
- If tightly coupled and inseparable, use a single commit with the control name as the scope
|
||||
|
||||
## Edge Cases
|
||||
|
||||
### Mixed change types
|
||||
|
||||
If staged changes include a mix of docs, styles, types, and small fixes:
|
||||
|
||||
- Identify the **primary purpose** first
|
||||
- If there is no single primary purpose, use a higher-level summary
|
||||
- The goal is to "honestly cover all changes", not to cram every detail into the title
|
||||
|
||||
### Scattered / unrelated changes
|
||||
|
||||
If the staging area contains clearly unrelated groups of changes:
|
||||
|
||||
- Still produce an honest one-line message
|
||||
- Do not pretend these changes share a single specific purpose
|
||||
- Use a broad summary, e.g., `chore(controls): clean up styles, types and docs`
|
||||
|
||||
### Breaking Changes
|
||||
|
||||
If the changes include a breaking API change:
|
||||
|
||||
- Append `!` after type/scope, e.g., `refactor(TokenSystem)!: rename ControlDesignToken to AbstractControlDesignToken`
|
||||
- If the user requests a body, include a `BREAKING CHANGE:` footer
|
||||
|
||||
## Prohibited
|
||||
|
||||
- Generating a message without reading `git diff --cached`
|
||||
- Guessing content based only on filenames
|
||||
- Describing only some files/changes while ignoring other staged content
|
||||
- Outputting multi-line explanations as the commit message
|
||||
- Breaking from established repository style just to fit a template
|
||||
- Writing headers longer than 72 characters unless truly unavoidable
|
||||
- Wrapping the final output in backticks, quotes, or code blocks
|
||||
|
||||
## Reference
|
||||
|
||||
For detailed type/scope definitions, style examples, and input→output samples, see `references/commit-message-convention.md`.
|
||||
@@ -0,0 +1,372 @@
|
||||
# AtomUI Git Commit Message Convention
|
||||
|
||||
## Style Reference
|
||||
|
||||
Common commit patterns in the AtomUI repository:
|
||||
|
||||
- `feat(QRCode): add error correction level selection`
|
||||
- `fix(MemoryLeak): fix event handler leak in input controls`
|
||||
- `refactor(Segmented): extract AbstractSegmented to AtomUI.Controls`
|
||||
- `docs(Core): add three-tier architecture documentation`
|
||||
- `chore(deps): bump Avalonia to 11.3.2`
|
||||
- `gallery: add QRCode showcase with comprehensive examples`
|
||||
- `build(ci): add macOS ARM64 to build matrix`
|
||||
- `fix(Select): 修复多选模式下点击后下拉框意外关闭`
|
||||
|
||||
Key observations:
|
||||
|
||||
- `type` and `scope` **MUST be English** (they are fixed keywords / identifiers)
|
||||
- `subject` and `body` **prefer English, but Chinese is also acceptable**
|
||||
- Two common forms: `type(scope): subject` and `type: subject` (when scope is unnecessary)
|
||||
- `gallery` is used as a direct type prefix for showcase / gallery app changes (analogous to `site` in ant-design)
|
||||
|
||||
---
|
||||
|
||||
## Format
|
||||
|
||||
```
|
||||
<type>(<scope>): <subject>
|
||||
|
||||
[optional body]
|
||||
|
||||
[optional footer(s)]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 1. Types
|
||||
|
||||
All types MUST be **lowercase**.
|
||||
|
||||
| Type | When to Use |
|
||||
|---|---|
|
||||
| `feat` | New control, property, API, or user-facing behavior |
|
||||
| `fix` | Bug fix — incorrect behavior, crash, memory leak, rendering issue |
|
||||
| `refactor` | Code restructuring with no behavior change — moving code between layers, renaming, splitting classes |
|
||||
| `docs` | Documentation only — README, XML doc comments, architecture docs, copilot-instructions |
|
||||
| `style` | Code formatting only (no logic change) — whitespace, indentation, code style |
|
||||
| `perf` | Performance improvement — optimizing rendering, reducing allocations, caching |
|
||||
| `test` | Adding or updating tests — test cases, test infrastructure, test fixtures |
|
||||
| `build` | Build system or dependency changes — MSBuild props, `Directory.Packages.props`, scripts |
|
||||
| `chore` | Maintenance that doesn't modify src/test — tooling config, `.editorconfig`, IDE settings |
|
||||
| `ci` | CI/CD configuration — GitHub Actions workflows, build pipeline |
|
||||
| `gallery` | Control gallery / showcase app changes — ShowCase demos, gallery navigation, gallery assets |
|
||||
| `release` | Version bumps, changelog updates, release preparation |
|
||||
| `revert` | Reverting a previous commit (must reference the reverted commit hash in body) |
|
||||
|
||||
> **Note**: `feat` and `fix` will appear in auto-generated changelogs.
|
||||
|
||||
---
|
||||
|
||||
## 2. Scope (Recommended)
|
||||
|
||||
The scope identifies *what area* of the codebase is affected. Placed in parentheses after the type. Use **PascalCase**.
|
||||
|
||||
### Scope Categories
|
||||
|
||||
| Category | Examples | When to Use |
|
||||
|---|---|---|
|
||||
| **Control name** | `Button`, `Select`, `Tag`, `DatePicker`, `TreeView`, `Cascader`, `FloatButton`, `ColorPicker`, `DataGrid` | Change is specific to one control |
|
||||
| **Infrastructure** | `TokenSystem`, `Theme`, `Motion`, `WaveSpirit`, `Core`, `Icons`, `Fonts`, `Generator`, `Native`, `i18n`, `MediaQuery` | Change to core framework infrastructure |
|
||||
| **Cross-cutting** | `deps`, `scripts`, `Packaging`, `Bindings`, `MemoryLeak` | Change spans multiple areas or is a maintenance concern |
|
||||
|
||||
### Scope Selection Rules
|
||||
|
||||
#### When to use `fix(Component)`
|
||||
|
||||
The change corrects a component's behavior:
|
||||
|
||||
- Interaction doesn't match the expected design spec
|
||||
- Boundary / edge-case rendering error
|
||||
- Type, logic, or layout error that affects usage
|
||||
|
||||
```
|
||||
fix(Table): correct pagination when data source is empty
|
||||
fix(Form): preserve validation status after reset
|
||||
fix(Select): prevent dropdown from closing on multi-select click
|
||||
```
|
||||
|
||||
#### When to use `feat(Component)`
|
||||
|
||||
The change adds new user-facing capability to a component:
|
||||
|
||||
```
|
||||
feat(Tag): add closable animation with motion system
|
||||
feat(QRCode): add error correction level selection
|
||||
feat(Button): add danger style variant for ghost button
|
||||
```
|
||||
|
||||
#### When to use `refactor(Component)` or `refactor(Infrastructure)`
|
||||
|
||||
The change restructures code without altering external behavior:
|
||||
|
||||
```
|
||||
refactor(Avatar): extract AbstractAvatar to AtomUI.Controls
|
||||
refactor(TokenSystem): migrate to three-layer token derivation
|
||||
refactor(Bindings): refactor reactive bindings across controls
|
||||
```
|
||||
|
||||
#### When to use `docs`
|
||||
|
||||
Only documentation text changed — README, XML doc comments, architecture docs, demo descriptions, copilot-instructions:
|
||||
|
||||
```
|
||||
docs: update FAQ link in issue template
|
||||
docs(Button): clarify loading demo description
|
||||
docs(Core): add three-tier architecture documentation
|
||||
```
|
||||
|
||||
#### When to use `gallery`
|
||||
|
||||
Changes to the control gallery / showcase app — demo pages, gallery navigation, gallery assets:
|
||||
|
||||
```
|
||||
gallery: add QRCode showcase with comprehensive examples
|
||||
gallery(Button): update danger button demo layout
|
||||
```
|
||||
|
||||
#### When to use `chore`
|
||||
|
||||
Dependency upgrades, lint rules, script maintenance, non-business engineering tasks:
|
||||
|
||||
```
|
||||
chore: update .editorconfig formatting rules
|
||||
chore(deps): bump Avalonia from 11.3.1 to 11.3.2
|
||||
chore(scripts): update release helper
|
||||
```
|
||||
|
||||
### Multiple Scopes
|
||||
|
||||
When a change spans multiple closely related controls, use a comma-separated list or a higher-level scope:
|
||||
|
||||
```
|
||||
fix(Select,AutoComplete): fix shared dropdown positioning logic
|
||||
fix(MemoryLeak): fix event handler leak in input controls
|
||||
```
|
||||
|
||||
### Omitting Scope
|
||||
|
||||
Scope MAY be omitted for broadly cross-cutting changes:
|
||||
|
||||
```
|
||||
chore: update .editorconfig formatting rules
|
||||
build: upgrade to .NET 10 RC1
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 3. Subject (Required)
|
||||
|
||||
The subject is a succinct description of the change.
|
||||
|
||||
### Rules
|
||||
|
||||
- **Imperative, present tense**: "add", "fix", "change" — not "added", "fixed", "changed". 中文时同理，使用动词开头："修复"、"添加"、"调整"。
|
||||
- **Do NOT capitalize** the first letter (English subject).
|
||||
- **Do NOT end** with a period (or `。`).
|
||||
- **Max 72 characters** for the entire header line (`type(scope): subject`).
|
||||
- Be **specific** — describe *what* changed, not just *where*.
|
||||
- **Language**: prefer English; Chinese is acceptable when it expresses the intent more clearly.
|
||||
|
||||
### Good vs. Bad
|
||||
|
||||
| ❌ Bad | ✅ Good |
|
||||
|---|---|
|
||||
| `fix(Button): fix bug` | `fix(Button): prevent double-click event during animation` |
|
||||
| `feat(Tag): Tag updates` | `feat(Tag): add closable animation with motion system` |
|
||||
| `refactor: refactor code` | `refactor(TokenSystem): migrate to three-layer token derivation` |
|
||||
| `Fixed the issue.` | `fix(Select): correct dropdown z-index in overlay layer` |
|
||||
| `fix(Select): 修了个问题` | `fix(Select): 修复多选模式下点击后下拉框意外关闭` |
|
||||
|
||||
---
|
||||
|
||||
## 4. Body (Optional)
|
||||
|
||||
Provides additional context when the subject line alone is insufficient.
|
||||
|
||||
- Separate from subject with **one blank line**.
|
||||
- Imperative, present tense.
|
||||
- Explain **what** and **why**, not *how* (the diff shows *how*).
|
||||
- Wrap at **100 characters**.
|
||||
- Use bullet points (`-`) for multiple items.
|
||||
|
||||
```
|
||||
refactor(Avatar): extract platform-agnostic logic to AbstractAvatar
|
||||
|
||||
- Move shared properties (Shape, Size, Src, Alt) to AbstractAvatar in AtomUI.Controls
|
||||
- Keep desktop-specific token registration in Avatar (AtomUI.Desktop.Controls)
|
||||
- AbstractAvatar defines behavior; Avatar inherits and registers TokenScope
|
||||
- Prepares for future Mobile control layer reuse
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 5. Footer (Optional)
|
||||
|
||||
### Breaking Changes
|
||||
|
||||
Append `!` after type/scope **and** add a `BREAKING CHANGE:` footer:
|
||||
|
||||
```
|
||||
refactor(TokenSystem)!: rename ControlDesignToken to AbstractControlDesignToken
|
||||
|
||||
BREAKING CHANGE: All custom token classes must now inherit from
|
||||
AbstractControlDesignToken instead of ControlDesignToken.
|
||||
```
|
||||
|
||||
### Issue References
|
||||
|
||||
```
|
||||
fix(Cascader): fix search result not highlighting matched text
|
||||
|
||||
Fixes #234
|
||||
```
|
||||
|
||||
Keywords: `Fixes #N`, `Closes #N`, `Resolves #N`, `Refs #N`, `Related to #N`.
|
||||
|
||||
---
|
||||
|
||||
## 6. Multi-Change Commits
|
||||
|
||||
When the staging area contains multiple small related changes, use a higher-level summary to cover them all:
|
||||
|
||||
| Situation | Commit Message |
|
||||
|---|---|
|
||||
| Multiple small control fixes | `chore(controls): clean up styles and types` |
|
||||
| Docs + code examples together | `docs: update Button demo and README` |
|
||||
| Bug fix that also adjusts styling | `fix(Table): correct pagination and styling` |
|
||||
| Multiple gallery demo adjustments | `gallery: refine theme preview interactions` |
|
||||
| Type fix + test + minor style in one control | `fix(Table): adjust pagination types, styles and test` |
|
||||
|
||||
**Principle**: pick the most semantically significant type, and let the subject describe the combined scope.
|
||||
|
||||
---
|
||||
|
||||
## 7. Layer-Aware Commits
|
||||
|
||||
AtomUI has a three-tier architecture. When a change spans layers, prefer **separate commits per layer** when independently meaningful:
|
||||
|
||||
```
|
||||
# Commit 1: Base layer (AtomUI.Controls)
|
||||
refactor(Avatar): extract AbstractAvatar to AtomUI.Controls
|
||||
|
||||
# Commit 2: Platform layer (AtomUI.Desktop.Controls)
|
||||
refactor(Avatar): update desktop Avatar to inherit AbstractAvatar
|
||||
```
|
||||
|
||||
If the changes are tightly coupled and make no sense independently, a single commit with a descriptive body is acceptable.
|
||||
|
||||
---
|
||||
|
||||
## 8. Special Commits
|
||||
|
||||
### Revert
|
||||
|
||||
```
|
||||
revert: revert "feat(Tag): add closable animation"
|
||||
|
||||
This reverts commit abc1234.
|
||||
Reason: animation causes layout flicker on macOS.
|
||||
```
|
||||
|
||||
### Release
|
||||
|
||||
```
|
||||
release: v5.2.0
|
||||
```
|
||||
|
||||
### Merge
|
||||
|
||||
Merge commits generated by Git/GitHub are acceptable as-is.
|
||||
|
||||
---
|
||||
|
||||
## 9. Summary Table
|
||||
|
||||
| Element | Rule |
|
||||
|---|---|
|
||||
| Type | Required. Lowercase English. One of: `feat`, `fix`, `refactor`, `docs`, `style`, `perf`, `test`, `build`, `chore`, `ci`, `gallery`, `release`, `revert` |
|
||||
| Scope | Recommended. PascalCase English. Parenthesized. |
|
||||
| Subject | Required. Imperative mood. Lowercase start (English) or verb start (Chinese). No period. ≤72 chars total header. Prefer English; Chinese OK. |
|
||||
| Body | Optional. Blank line after subject. Wrap at 100 chars. English or Chinese. |
|
||||
| Footer | Optional. `BREAKING CHANGE:` for breaking changes. `Fixes #N` for issues. |
|
||||
| Breaking | Append `!` after scope, and/or add `BREAKING CHANGE:` footer. |
|
||||
|
||||
---
|
||||
|
||||
## 10. AI Agent Output Requirements
|
||||
|
||||
When generating commit messages automatically (e.g., from `git diff --cached`):
|
||||
|
||||
- Output **one line only** (the header) unless the user explicitly requests a body
|
||||
- Do **NOT** wrap in backticks or quotes
|
||||
- Do **NOT** explain reasoning unless asked
|
||||
- Keep the header line **≤ 72 characters**
|
||||
- `type` and `scope` MUST be **English**
|
||||
- `subject` defaults to **English**; use Chinese if the user's conversation language is Chinese or if the user explicitly requests it
|
||||
|
||||
---
|
||||
|
||||
## 11. Input → Output Examples
|
||||
|
||||
**Input**: `git diff --cached` shows changes only in `src/AtomUI.Desktop.Controls/Button/ButtonToken.cs` — a new token property `DangerColor` was added.
|
||||
|
||||
**Output**: `feat(Button): add DangerColor token property`
|
||||
|
||||
---
|
||||
|
||||
**Input**: Staging area contains a type fix in `Tag.cs`, a style adjustment in `TagTheme.axaml`, and a test update in `TagTests.cs`.
|
||||
|
||||
**Output**: `fix(Tag): adjust tag type definition, theme style and test`
|
||||
|
||||
---
|
||||
|
||||
**Input**: Only `controlgallery/AtomUIGallery/ShowCases/QRCodeShowCase.axaml` and its code-behind changed.
|
||||
|
||||
**Output**: `gallery(QRCode): add error correction level demo`
|
||||
|
||||
---
|
||||
|
||||
**Input**: `scripts/PublishToLocalSources.ps1` was modified.
|
||||
|
||||
**Output**: `chore(scripts): update local publish script`
|
||||
|
||||
---
|
||||
|
||||
**Input**: Multiple files across `AtomUI.Controls/Avatar/` and `AtomUI.Desktop.Controls/Avatar/` were restructured, moving shared properties to the abstract base class.
|
||||
|
||||
**Output**: `refactor(Avatar): extract shared properties to AbstractAvatar`
|
||||
|
||||
---
|
||||
|
||||
**Input**: `Directory.Packages.props` bumped the Avalonia version from 11.3.1 to 11.3.2.
|
||||
|
||||
**Output**: `chore(deps): bump Avalonia from 11.3.1 to 11.3.2`
|
||||
|
||||
---
|
||||
|
||||
**Input**: `src/AtomUI.Core/Theme/DesignToken.Alias.cs` had a performance optimization reducing dictionary lookups.
|
||||
|
||||
**Output**: `perf(TokenSystem): reduce dictionary lookups in alias token calculation`
|
||||
|
||||
---
|
||||
|
||||
**Input**: `README.md` and `README.zh-CN.md` were updated with new badges and installation instructions.
|
||||
|
||||
**Output**: `docs: update README badges and installation guide`
|
||||
|
||||
---
|
||||
|
||||
**Input**: Large refactoring that renames `ControlDesignToken` to `AbstractControlDesignToken` across 40+ files, breaking the public API.
|
||||
|
||||
**Output**:
|
||||
|
||||
```
|
||||
refactor(TokenSystem)!: rename ControlDesignToken to AbstractControlDesignToken
|
||||
|
||||
BREAKING CHANGE: All custom token classes must now inherit from
|
||||
AbstractControlDesignToken instead of ControlDesignToken.
|
||||
```
|
||||
|
||||
|
||||
|
||||
Symlink
+1
@@ -0,0 +1 @@
|
||||
../.agents/skills
|
||||
Reference in New Issue
Block a user