Menü
创建符合规范的 git 提交消息，并在提交前 review 将提交的变更。优先遵循项目现有提交规范，支持 Conventional Commits 格式。使用场景：用户要求创建提交、编写提交消息、提交前检查变更
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
在 GitHub/GitLab/Gitea 上创建格式规范的 Issue。优先使用仓库 Issue 模板，支持 Bug 报告、功能请求等类型，自动生成结构化描述。使用场景：用户要求提交 issue、报告 bug、提出功能需求
使用 ddgr 在终端搜索 DuckDuckGo，返回结构化结果。支持站点限定、时间过滤、区域搜索。使用场景：用户要求搜索信息、查找文档、搜索特定网站内容
自动化 GitHub/GitLab/Gitea 发布流程。使用场景：发布新版本、创建版本标签、更新 CHANGELOG。自动分析 Git 提交、更新 CHANGELOG.md、确定语义化版本号、创建 Git 标签、推送到远程并创建 Release
将指定目录下的 skills 通过符号链接安装到目标目录。支持单 skill 目录和多 skill 父目录，自动校验 SKILL.md 存在性。使用场景：安装技能、链接 skills 到指定目录
自动化处理 GitHub/GitLab/Gitea Issue 的完整工作流：获取 issue → 分支管理（含 worktree）→ 代码实现 → 提交 → 创建 PR/MR。使用场景：用户要求处理 issue、解决 bug、实现功能、贴了 issue 链接
Tauri 框架最佳实践指南。使用场景：Tauri 应用开发、代码审查、架构设计
| name | git-commit |
| description | 创建符合规范的 git 提交消息，并在提交前 review 将提交的变更。优先遵循项目现有提交规范，支持 Conventional Commits 格式。使用场景：用户要求创建提交、编写提交消息、提交前检查变更 |
创建清晰、规范的 git 提交消息。优先遵循项目现有风格，其次参考 Conventional Commits 标准。
如果对话中已通过本技能确定过项目规范，直接复用，跳过本步骤。
首次执行时并行收集以下信息：
git log -5 --pretty=format:"%s"
git branch --show-current
同时检查项目根目录是否存在 commitlint 配置（.commitlintrc.*、commitlint.config.*、package.json 中的 "commitlint" 字段）。
按优先级取第一个匹配：
extends（预设）、parserPreset（解析模式）、rules（type-enum、scope-enum、header-max-length 等）feat/feature）、语言（中文/英文）、issue 引用位置（subject 中/footer 中）优先使用项目已有类型。无明确类型时参考：
| 类型 | 说明 |
|---|---|
feat / feature | 新功能 |
fix / bugfix | Bug 修复 |
docs | 文档变更 |
style | 代码格式（不影响功能） |
refactor | 重构（功能不变） |
perf | 性能优化 |
test | 测试相关 |
chore | 构建/工具链 |
从当前分支名中提取 issue 编号：
feature/#1254 → #1254fix/123-login-blank → #123feat/new-feature-456 → #456issue/789 → #789feature/PROJ-123-desc → #PROJ-123解析到 issue 编号时，按上述确定的引用风格放置（subject 中或 footer 中）。
一次并行执行以下命令，不要分步调用：
暂存区有内容时：
git status --short
git diff --cached --stat
git diff --cached
git diff --cached --check
git log @{u}..HEAD --oneline 2>/dev/null
暂存区为空时：
git status --short
git diff --stat
git diff
git diff --check
git log @{u}..HEAD --oneline 2>/dev/null
基于收集的数据一次性完成以下判断：
属于同一模块（一起提交）：
不搭界（分开提交）：
所有变更属于同一模块：直接提交。
大部分属于同一模块，少量不搭界：
主要模块：用户模块
不相关变更（建议暂不提交）：
- src/api/orders.ts (订单模块)
跳过不相关内容，仅提交用户模块相关变更？(y/n)
多个模块变更相当：
用户模块：70行 | 订单模块：90行
建议先提交变更较多的模块，是否仅提交订单模块？(y/n/all)
基于 git log @{u}..HEAD 结果判断。仅在有领先远程的本地提交时合并。合并条件：同一类型 + 相同模块文件、同一 bug 的修复、文档连续更新。其他情况不合并。
用户明确要求跳过 review 时（如"不 review"、"直接提交"），跳过本步骤。
直接复用步骤 2 已收集的 diff 数据，不要重新执行 git diff 命令。
先判断当前运行环境使用的 agent 及其能力，按以下优先级执行：
优先 review 暂存区；如果没有暂存内容，则 review 工作区变更；如果步骤 2 决定拆分提交，只 review 将纳入本次提交的文件。
使用 subagent review 时，只传递客观材料：本次提交范围、git diff --stat、完整 diff、相关用户需求和本步骤检查项。不要传递主线程的判断结论、期望结果或提交消息草稿。subagent 输出应优先列出阻塞问题，其次列出非阻塞风险；无问题时明确说明未发现阻塞问题。
无阻塞问题：继续生成提交消息，并可在回复中简要说明 review 通过。
发现阻塞问题：先停止提交，向用户列出问题、文件位置和建议修复方式；不要生成会掩盖问题的提交消息。
发现非阻塞风险：继续生成提交消息，但在回复中提示风险和建议验证项。
基于项目规范和变更内容生成消息：
<type>(<scope>): <subject>
<body>
<footer>
必需：type + subject（10-72 字符）
可选：scope、body、footer
add 而非 addedBREAKING CHANGE: API endpoints now require authentication
Closes #123
Refs #456
scope-enum 中获取可用值两种标记方式（均为 Conventional Commits 标准）：
方式 1：类型后加 !
feat!: remove deprecated endpoints
feat(api)!: remove deprecated endpoints
方式 2：Footer 中声明
feat(api): remove deprecated endpoints
BREAKING CHANGE: v1 endpoints are no longer available.
Migration guide: docs/migration.md
Co-Authored-By 等元信息feat: add dark mode support
fix: 修复登录超时问题
docs: 更新安装指南
feat(auth): 实现 OAuth2 登录
fix(ui): 修复移动端按钮对齐问题
feat(auth): #1254 实现 OAuth2 登录
fix(ui): #123 修复移动端按钮对齐问题
feat(api)!: 重构分页接口为 cursor-based
旧的 page/limit 参数不再支持，迁移方式见 docs/migration.md
Closes #42