Menu
分析当前仓库的 git 变更（staged/unstaged/untracked），判断是否需要拆分为多条提交，并按 Conventional Commits 生成清晰的提交信息与提交计划；每次执行 git commit 前必须等待用户明确确认
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
指导在终端用 @baklib/baklib-cli（baklib 命令）通过 Baklib Open API 管理站点、知识库、DAM、成员与用户，以及主题拉取/预览上传与本地 theme dev；含鉴权配置、--json 脚本输出与执行规范。在用户已安装或可安装 baklib CLI、要用命令行/脚本/CI 读写 Baklib 线上数据时使用；Liquid 模版语法见 baklib-theme-dev（需另行安装）。
Baklib 专用：根据 CHANGELOG/更新说明撰写面向用户的对外发布日志（Markdown 正文 + 封面图提示词）， 用于 release.baklib.cn 等站点页；含标题规范、help.baklib.cn/术语表内链、DaisyUI baklib 品牌与 Liquid Glass 封面。 在用户要写 Baklib 发布日志、release note、版本更新文章、或从 CHANGELOG 生成对外稿时使用；出图与 MCP 写入须先确认。
Baklib 站点主题（模板）开发：Liquid 目录与命名、`config/settings_schema.json` 与模板 `{% schema %}`、多语言 `locales`、对象与指令/过滤器、静态页 URL、seeds 与迁移；站点表单 `form_tag`/`form_field_tag` 全量说明见 references/forms.md。并含「新建主题脚手架」「参考站复刻工作流」、本地 `baklib theme dev` 预览，以及 CLI 初始化 manifest（template.json，见 references/theme-init-template-manifest.md）。新建或迭代主题起步模版、写 template.json、theme init/apply 时必读该文档；完成主题开发后应把过程沉淀进 manifest 的 developmentNotes/workflow。页面预览参数用 `baklib theme preview set`（theme-preview-page-config.md），勿让用户手填面板。在用户编写 .liquid、配置 schema、新建模板、复刻参考站或排查模板与变量时使用；详规见 references/。
本地 MinerU 将 PDF/Office/图片转为 Markdown（含 images/ 图文、表格与公式识别）。复杂版式、扫描件、长书须先确认页范围与后端。用户要转 PDF、提取表格、OCR、或问「这篇 PDF 讲了什么」时使用。
通过 Playwright CDP 连接用户本机 Chrome，提供页面感知 JSON（链接、输入框、按钮等）与类人操作（点击、填写、滚动、截图）。 业务逻辑由消费该技能的 AI 决策，脚本不做站点硬编码。用于网页调研、表单填写、可控交互抓取； 涉及发布评论、点赞、关注、私信、表单提交等写入外部系统的操作前须先向用户确认执行计划。
Self-contained guide for writing Baklib BKE Markdown (L1/L2, DAM dam-id, file colon-syntax, link cards, fragments, embeds, tables). Use when authoring or importing BKE Markdown, inserting DAM assets, or resolving DAM ids via MCP; not for editor implementation or maintaining product docs repos.
| name | git-commit |
| description | 分析当前仓库的 git 变更（staged/unstaged/untracked），判断是否需要拆分为多条提交，并按 Conventional Commits 生成清晰的提交信息与提交计划；每次执行 git commit 前必须等待用户明确确认 |
帮助用户把当前工作区变更整理成高质量提交：先看清变更 → 必要时拆分 → 给出规范提交信息 → 每次 commit 前都要用户确认。
git commit 前，必须等待用户明确确认（可 edit/skip/cancel）。依次执行并收集输出：
git status
git status --short
git diff
git diff --cached
git log --oneline -10
输出给用户：
对每个文件判定：
.env、个人路径等）——发现则提醒并建议不要提交输出给用户：
优先使用这些判断：
给出拆分建议格式：
建议拆分为 N 条 commit：
1) <type>(<scope>): <subject>
- files: ...
- why: ...
2) ...
格式：
<type>(<scope>): <subject>
<body 可选：说明为什么这么改/影响范围/迁移提示>
生成规则：
readme、skills、auth），不确定可省略对每条计划提交，必须先展示：
然后询问用户：yes / no / edit / skip
仅在用户回答 yes 后才执行：
git add <files...>
git commit -m "<message>"
提交后再展示：
git status 结果准备提交以下变更：
提交信息：
<type>(<scope>): <subject>
变更文件：
- ...
变更说明：
- ...
是否确认提交？(yes/no/edit/skip)
.env、密钥/Token 文件、cookie、凭证