菜单
Format git commit messages and Pull Request titles using Conventional Commits with a deterministic gitmoji prefix. Use when generating or suggesting commit messages, PR titles, or when the user says "commit this", "create PR", "write a commit", "prepare PR", or similar.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Uses Forze queue, pub/sub, and stream contracts with QueueSpec, PubSubSpec, StreamSpec, SQSDepsModule, RabbitMQDepsModule, Redis adapters, and Mock adapters. Use when producing, consuming, or testing async messages/events.
Implements Forze document and search access the kit-first way: DocumentFacade and SearchFacade over build_document_registry / build_search_registry, kit DTOs (DocumentIdDTO, ListRequestDTO, DocumentUpdateDTO), the query DSL, pagination, cache-aware DocumentSpec / SearchSpec, and the Postgres / Mongo / Firestore / Meilisearch backends behind them. Use when building data access features.
Optimize code only after a real, measured performance problem - distinguish macro (design-level) from micro (fine-tuned) performance, reach for data-structure and algorithm wins before micro-tweaks, profile to find real hotspots, and don't trade readability or adaptability for unmeasured speed. Use when optimizing code, reviewing performance suggestions, choosing "faster" constructs, or when the user mentions performance, optimization, speed, or efficiency.
Name variables, functions, classes, and modules well by avoiding known anti-patterns - single letters, abbreviations, types baked into names, missing units, "Base"/"Abstract" class names, and "Utils"/"Helper" grab-bags. Use when naming or renaming code, reviewing names in a diff, or when the user mentions naming, identifiers, variable names, readability, or that a name feels off.
Keep code flat and readable by limiting indentation depth, using guard clauses with early returns, and extracting nested blocks into well-named functions. Use when writing or refactoring code with deep nesting, pyramid-shaped if/else, arrow code, or when the user mentions nesting, indentation, guard clauses, early returns, extracting functions, cyclomatic complexity, or making code more readable.
Make code explain itself instead of relying on comments - name sub-expressions, extract complex conditions into well-named functions, lean on the type system, and reserve comments for the "why" the code cannot express. Use when writing or reviewing comments, refactoring hard-to-read logic, deciding whether a comment is needed, or when the user mentions comments, self-documenting code, or code readability.
| name | gitmoji-conventional |
| description | Format git commit messages and Pull Request titles using Conventional Commits with a deterministic gitmoji prefix. Use when generating or suggesting commit messages, PR titles, or when the user says "commit this", "create PR", "write a commit", "prepare PR", or similar. |
Format git commits and Pull Request titles as:
<gitmoji> <type>[optional scope][!]: <description>
Examples:
✨ feat(api): add OAuth login support
🔥 refactor(cache): remove deprecated cache layer
🚑 fix(auth): patch token validation vulnerability
This skill MUST be applied when the assistant:
Apply it even if the user does not explicitly mention Conventional Commits or gitmoji.
Gitmoji mapping: See references/gitmoji-mapping.md for the full Gitmoji → Conventional Commit type table. Load it when choosing a gitmoji.
Choose the gitmoji that best represents the main change.
If multiple changes exist, priority order: fix > feat > perf > refactor > build > docs > test > chore
For PRs with mixed changes, pick one primary semantic category. Do NOT describe all changes in the title.
Use scope when it improves clarity. Common scopes: auth, api, core, cli, ui, deps, build, ci, db.
If scope is not obvious, omit it.
The description MUST:
Correct: ✨ feat(api): add OAuth login support
Incorrect: ✨ feat(api): Added OAuth login support. or - ✨ feat(api): add OAuth login support
If the commit introduces a breaking change, use <gitmoji> <type>[optional scope][!]: <description> with a footer BREAKING CHANGE: <details>.
Example:
💥 feat(api)!: redesign authentication API
BREAKING CHANGE: authentication endpoints changed to OAuth2
Use when context is helpful: 2+ meaningful changes, subject needs context, or bullet-style change notes.
Example:
✨ feat(auth): add OAuth login
- add Google provider
- add GitHub provider
- store refresh tokens securely
Supported footers: BREAKING CHANGE: ..., Closes #123, Refs #123
A PR title MUST:
If the PR introduces a breaking change, use <gitmoji> <type>[optional scope][!]: <description>. Do NOT include footers or migration notes in the title.