메뉴
分析当前仓库的 git 变更（staged/unstaged/untracked），判断是否需要拆分为多条提交，并按 Conventional Commits 生成清晰的提交信息与提交计划；每次执行 git commit 前必须等待用户明确确认
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
指导在终端用 @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、凭证