メニュー
创建符合规范的 git 提交消息，并在提交前 review 将提交的变更。优先遵循项目现有提交规范，支持 Conventional Commits 格式。使用场景：用户要求创建提交、编写提交消息、提交前检查变更
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
在 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