| name | sjmcl-commit-msg |
| description | Generate a single-line commit message for SJMCL by reading the staged changes and recent commit style. Use this skill when the user asks for a commit message, says commit msg, or wants one-line text that covers all staged changes. |
SJMCL Commit Message 生成规范
触发场景
当用户提及以下情况时使用本 skill：
- 要写 commit message、git 提交信息
- 需要根据当前工作区改动、暂存区生成一句提交说明
基本规则
一、默认只看暂存区
默认只根据 staged changes 生成 message，因为真正会被提交的是暂存区内容。
只有用户明确要求包含未暂存内容时，才额外查看 git diff。
二、必须先看最近提交风格
生成 message 前，除了看暂存区，还要看最近提交历史，避免写出不符合仓库习惯的格式。
三、默认只输出最终一行
除非用户明确要求解释，否则最终回复只给一行 commit message，不附带分析。
格式规范
优先使用以下格式之一：
<type>(<scope>): <summary>
或
<type>: <summary>
标题规则：
- 使用祈使语气，写现在要做什么，如
add / fix / update
- 首字母不要大写，结尾不要句号
- 不要出现
WIP、misc、update files 这类空泛表述
type 选择
feat: 新增、扩展一个面向用户的功能或特性。fix: 修复缺陷、错误或安全漏洞。build: 影响构建系统或外部依赖的变动。chore: 不修改源码或测试代码的杂项维护工作，例如更新辅助工具、配置文件、.gitignore 等。ci: 持续集成和部署相关的配置文件或脚本的变更，如修改 GitHub Actions 等。docs: 仅修改文档，包括 README、API 文档、注释、使用指南等，不涉及代码逻辑。perf: 以提高性能为目标的代码更改，如优化算法、降低内存占用、减少 I/O 操作。refactor: 对代码进行重构，既不修复缺陷也不新增功能，旨在改善结构、可读性或可维护性。revert: 撤销之前的一个或多个提交，通常用于回滚引入问题的变更。style: 不影响代码含义的格式调整，如空格、缩进、分号、换行、代码排序等代码风格修正。test: 添加、修正或重构测试代码，包括单元测试、集成测试、端到端测试等。
scope 选择
- 涉及功能域的更改，通常需要前后端联合，
scope 建议写功能域，比如 account、instance、intelligence 等。
- 仅更改前端、后端、CI 工作流、国际化文本、脚本时，
scope 只写结构域，比如 frontend、backend、ci、l10n/locale、script 等。
docs 类型的改动，scope 可以写 readme、changelog 等具体的文档范围。chore 类型的改动，scope 可以写 Tauri、nextjs、nsis 等具体依赖名称或术语。- 若没有明确
scope 或者难以概括，允许省略。
示例：
fix(frontend): prevent wrong config key updates in resource pack pagefeat(launch): support use custom authlib injector in advanced game settingsdocs(readme): update install methodschore: auto update Minecraft version list, add 26.2-rc-2
执行步骤
1. 读取 git 状态、暂存区和最近提交
建议首先执行命令：
git status --short
git diff --cached --stat
git diff --cached
git log --oneline -10
不要只凭文件名猜测内容。
2. 判断是否能生成
如果暂存区为空：
- 不要编造 message。
- 明确说明当前没有 staged changes，无法基于提交区生成准确的一行 commit message。
3. 归纳这次提交的主要语义
根据 git diff --cached 结果：
- 判断本次提交的主要目的，是
feat、fix、docs、refactor、chore 等哪一类。
- 判断 主要影响范围，是否适合加
scope。
- 如果包含多个小改动，优先找主目的，用一个更高层级的概括覆盖全部，不要把每个点都塞进标题。
4. 对齐仓库风格和写法要求
根据 git log --oneline -10 结果可见 SJMCL 仓库近期写法。
优先模仿近期写法和后文的写法要求，如：
fix(frontend): ...fix(instance): ...feat(ci): ...docs(readme): ...refactor(backend): ...chore: ...
注意：
- 不要强行把所有提交都写成严格的 Conventional Commits。
- 如果仓库已有更自然的写法，优先贴近仓库已有习惯。
- 不要默认添加
[skip ci]，除非用户明确要求，或这次改动明显符合仓库里已有的自动化提交模式。
5. 生成一行 message
输出应满足：
- 一行英文、简洁，与仓库风格和写法要求一致
- 覆盖全部 staged changes
- 可直接用于提交
