菜单
Format commit messages following conventional commits standard. Use when: writing commit messages, git commit, reviewing commit history. Keywords: commit, git, message, conventional, feat, fix, refactor.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Propose a new change with all artifacts generated in one step. Use when the user wants to quickly describe what they want to build and get a complete proposal with design, specs, and tasks ready for implementation.
審視 ECC（everything-claude-code）分發名單，包含兩個模式： (A) 既有清單瘦身：分析 distribution.yaml.enabled 與本地 skills/ 的重疊性與品質，輸出 enabled_remove 建議； (B) 新項目導入評估：根據 ecc-catalog.yaml 與上次更新範圍，介紹 ECC 上游新增 skill、分析適用情境、建議是否加入 enabled。 Use when: (1) 評估 ECC 分發名單是否該瘦身、(2) ECC 上游新增 skill 後決定要不要導入、 (3) 想為終端使用者產 ecc-profile.yaml starter、(4) 季度 / 半年一次定期審視。 Triggers: "分析 ECC skill", "ECC 重疊", "ECC 清單瘦身", "ECC 新項目", "ECC 上游新增", "要不要導入", "ecc analyze", "ecc new items review", "ecc profile starter", "ECC 品質審視".
用追問把模糊需求壓成專案語言，並在必要時更新 CONTEXT.md 或 ADR。 Use when: 需求還不清楚、術語不一致、要進 OpenSpec 前需要需求對齊、 或使用者想先 stress-test plan 而不是直接實作。
找出架構摩擦與 deep module 候選，但不直接修改實作程式碼。 Use when: 使用者要架構回看、找重構候選、改善可測性、 或把實作中暴露的架構摩擦整理成 OpenSpec 候選。
建立 MP 工作入口層的專案規則。Use when: 首次導入 mattpocock/skills 改寫版、 需要設定 docs/agents/、需要讓 Claude Code 與 Codex 共同讀取 issue tracker、 triage states、domain docs 規則，或 mp-* 技能缺少專案入口脈絡。
將 plan、PRD、OpenSpec change 或對話摘要切成可驗證的垂直切片。 Use when: 需要把大型需求拆成 OpenSpec tasks、GitHub issue draft、 或本地 Markdown 工作項目；不適用於直接 TDD 實作。
| name | commit-standards |
| scope | universal |
| description | Format commit messages following conventional commits standard. Use when: writing commit messages, git commit, reviewing commit history. Keywords: commit, git, message, conventional, feat, fix, refactor. |
Language: English | 繁體中文
Version: 1.0.0 Last Updated: 2025-12-24 Applicability: Claude Code Skills
Core Standard: This skill implements Commit Message Guide. For comprehensive methodology documentation, refer to the core standard.
This skill ensures consistent, meaningful commit messages following conventional commits.
<type>(<scope>): <subject>
<body>
<footer>
| English | When to Use |
|---|---|
feat | New feature |
fix | Bug fix |
refactor | Code refactoring (no functional change) |
docs | Documentation only |
style | Formatting (no code logic change) |
test | Adding or updating tests |
perf | Performance improvement |
build | Build system or dependencies |
ci | CI/CD pipeline changes |
chore | Maintenance tasks |
revert | Revert previous commit |
security | Security vulnerability fix |
For complete standards, see:
For AI assistants, use the YAML format files for reduced token usage:
ai/standards/commit-message.ai.yamlai/options/commit-message/english.ai.yamlai/options/commit-message/traditional-chinese.ai.yamlai/options/commit-message/bilingual.ai.yamlfeat(auth): Add OAuth2 Google login support
fix(api): Resolve memory leak in user session cache
refactor(database): Extract query builder to separate class
docs(readme): Update installation instructions for Node 20
fixed bug # Too vague, no scope
feat(auth): added google login # Past tense
Update stuff. # Period, vague
WIP # Not descriptive
Use the body to explain WHY the change was made:
fix(api): Resolve race condition in concurrent user updates
Why this occurred:
- Two simultaneous PUT requests could overwrite each other
- No optimistic locking implemented
What this fix does:
- Add version field to User model
- Return 409 Conflict if version mismatch
Fixes #789
Always document breaking changes in footer:
feat(api): Change user endpoint response format
BREAKING CHANGE: User API response format changed
Migration guide:
1. Update API clients to remove .data wrapper
2. Use created_at instead of createdAt
Closes #123 # Automatically closes issue
Fixes #456 # Automatically closes issue
Refs #789 # Links without closing
# === LANGUAGE DECISION MATRIX ===
decision_tree:
- q: "Open source project?"
y: "→ English (international contributors)"
n: next
- q: "International/distributed team?"
y: "→ English (common language)"
n: next
- q: "Single-language team?"
y: "→ Team's primary language OR English"
n: "→ Bilingual (subject:EN, body:local)"
recommendation_matrix:
open_source: {lang: English, reason: "international contributors"}
international_team: {lang: English, reason: "common language"}
local_team_EN: {lang: English, reason: "tool compatibility, career mobility"}
local_team_ZH: {lang: "繁體中文", reason: "clarity, team preference"}
mixed: {lang: Bilingual, reason: "best of both worlds"}
# === TOOL COMPATIBILITY ===
tool_support:
full_unicode:
- GitHub/GitLab/Bitbucket
- VS Code/JetBrains
- SourceTree/GitKraken
potential_issues:
- "Some CI/CD log viewers"
- "Legacy terminal encodings"
- "Email notifications (rare)"
# === FORMAT BY LANGUAGE ===
english:
types: [feat, fix, refactor, docs, style, test, perf, build, ci, chore, revert, security]
example: "feat(auth): add OAuth2 Google login support"
traditional_chinese:
types: [功能, 修復, 重構, 文件, 樣式, 測試, 效能, 建置, CI, 雜項, 回退, 安全]
example: "功能(認證): 新增 OAuth2 Google 登入支援"
bilingual:
format: "type(scope): English subject\n\n中文詳細說明"
example: |
feat(auth): add OAuth2 Google login
新增 Google OAuth2 登入功能
- 實作授權流程
- 處理 token 交換
This skill supports project-specific language configuration.
CONTRIBUTING.md for "Commit Message Language" sectionIf no configuration found and context is unclear:
CONTRIBUTING.md:## Commit Message Language
This project uses **[chosen option]** commit types.
<!-- Options: English | Traditional Chinese | Bilingual -->
In project's CONTRIBUTING.md:
## Commit Message Language
This project uses **English** commit types.
### Allowed Types
feat, fix, refactor, docs, style, test, perf, build, ci, chore, revert, security
| Version | Date | Changes |
|---|---|---|
| 1.0.0 | 2025-12-24 | Added: Standard sections (Purpose, Related Standards, Version History, License) |
This skill is released under CC BY 4.0.
Source: universal-dev-standards