메뉴
发版自动化技能：CalVer 版本号 + 从 git log 生成 changelog + GitHub Releases。 覆盖完整发版流程：版本号生成→changelog 生成→git tag→GitHub Release（或本地 changelog 文件）。 在发版前自动触发 security-audit 安全审查（如果配置了 CI/CD 则检查 CI 状态）。 触发词：发版、发布、release、生成 changelog、打 tag、版本发布。 触发场景：功能开发完成准备发布、用户主动要求发版、里程碑完成。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | release |
| version | 1.0.0 |
| last_updated | "2026-04-08T00:00:00.000Z" |
| repository | https://github.com/312362115/claude |
| description | 发版自动化技能：CalVer 版本号 + 从 git log 生成 changelog + GitHub Releases。 覆盖完整发版流程：版本号生成→changelog 生成→git tag→GitHub Release（或本地 changelog 文件）。 在发版前自动触发 security-audit 安全审查（如果配置了 CI/CD 则检查 CI 状态）。 触发词：发版、发布、release、生成 changelog、打 tag、版本发布。 触发场景：功能开发完成准备发布、用户主动要求发版、里程碑完成。 |
发版不只是打 tag，是一个质量门禁流程：安全审查→生成版本→创建 Release。
发版前必须确认以下条件：
准备发版
│
├─ 1. 代码状态检查
│ ├─ 工作区干净？（无未提交改动）
│ ├─ 在正确的分支上？（main / release branch）
│ └─ 已合并所有需要的 PR？
│
├─ 2. CI 状态检查（如果有）
│ └─ GitHub Actions 全绿？
│
├─ 3. 安全审查
│ └─ 提示用户：是否需要跑 security-audit？（上线服务强烈建议）
│
└─ 4. 测试验证
└─ 核心功能是否经过验证？
检查命令：
# 工作区状态
git status
# CI 状态（GitHub）
gh run list --limit 5
# 未合并的 PR
gh pr list
任何检查不通过，提示用户处理后再继续，不强行发版。
YYYY.MM.PATCH
| 部分 | 含义 | 示例 |
|---|---|---|
| YYYY | 年份 | 2026 |
| MM | 月份（不补零） | 4 |
| PATCH | 当月第几次发布（从 1 开始） | 1, 2, 3... |
版本号生成逻辑：
# 获取当前年月
YEAR=$(date +%Y)
MONTH=$(date +%-m)
# 查找当月已有的最大版本号
LATEST=$(git tag --list "${YEAR}.${MONTH}.*" --sort=-version:refname | head -1)
if [ -z "$LATEST" ]; then
# 当月第一次发布
VERSION="${YEAR}.${MONTH}.1"
else
# 递增 PATCH
PATCH=$(echo "$LATEST" | awk -F. '{print $3 + 1}')
VERSION="${YEAR}.${MONTH}.${PATCH}"
fi
echo "版本号: $VERSION"
示例：
2026.4.12026.4.22026.5.1# 获取上一个 tag 到 HEAD 的所有提交
PREV_TAG=$(git describe --tags --abbrev=0 2>/dev/null || echo "")
if [ -z "$PREV_TAG" ]; then
# 没有历史 tag，取所有提交
COMMITS=$(git log --oneline --pretty=format:"%s")
else
COMMITS=$(git log ${PREV_TAG}..HEAD --oneline --pretty=format:"%s")
fi
根据 commit message 的 type(scope): desc 格式自动分组：
# Changelog — v2026.4.1
## 新功能（Features）
- **auth**: 支持 OAuth2 第三方登录
- **export**: 用户数据导出功能
## 修复（Fixes）
- **login**: 修复密码错误时返回 500 的问题
- **cache**: 修复缓存 key 冲突
## 重构（Refactoring）
- **api**: 统一错误响应格式
## 其他
- **docs**: 更新 API 文档
- **test**: 补充登录模块测试用例
分组规则：
| commit type | changelog 分组 |
|---|---|
| feat | 新功能（Features） |
| fix | 修复（Fixes） |
| refactor | 重构（Refactoring） |
| perf | 性能优化（Performance） |
| docs, test, chore, ci | 其他（如果没有 feat/fix/refactor 可省略） |
docs/changelog/YYYY-MM-DD-v<版本号>.md# 创建 tag
git tag -a "v${VERSION}" -m "Release v${VERSION}"
git push origin "v${VERSION}"
# 创建 GitHub Release
gh release create "v${VERSION}" \
--title "v${VERSION}" \
--notes "$(cat <<'EOF'
<changelog 内容>
EOF
)"
如果项目不在 GitHub 或不需要 GitHub Release：
# 创建 tag
git tag -a "v${VERSION}" -m "Release v${VERSION}"
# 写入 changelog 文件
# 存入 docs/changelog/YYYY-MM-DD-v<版本号>.md
用户：发个版
│
├─ Step 1: 发版前检查（代码状态 + CI + 安全）
├─ Step 2: 生成版本号（CalVer）
├─ Step 3: 生成 Changelog（从 git log）
├─ Step 4: 创建 Release（GitHub 或本地文件）
└─ Step 5: 发版后处理
task-finish（功能收尾）
↓
security-audit（发版前安全审查）
↓ 审查通过
release（本 skill — 发版）
通用写作技能：以"内容→组件→组合"的方式产出技术文档、产品文档、汇报材料。 覆盖 spec / plan / PRD / 用户手册 / 项目汇报 / 方案路演 / 调研报告 等所有结构化文档场景。 核心理念：组件驱动，不预设模板。先看内容形态，再挑能装这种形态的组件， 组合自然成文——不强制章节结构、不预设"必备模块"。 组件库（HTML / Markdown / 图示）见 references/components.md， 常见组合范式（spec / plan / PRD 等）见 references/templates/——但模板是参考不是规定。 触发词：写文档、写方案、写计划、写 PRD、写汇报、项目总结、写指南、帮我写、文档、方案设计。 即使用户没有明确说"写"，只要意图是"产出一份结构化的文档/报告/材料"，都应触发此技能。 本 skill 只负责"写"，不负责"调研"（调研由 deep-research 承担）和"调度"（流程由 task-start 承担）。
深度调研技能：对任意命题进行系统性调研并输出专业研究报告。 覆盖技术选型、行业分析、学术研究、竞品分析、概念探索等所有调研场景。 核心方法论：快速扫描→假设驱动研究、内外数据结合（先摸清内部现状再对标外部水位）、 反面证据强制搜索、数据来源三级分类、结论置信度分级、多层次报告输出。 采用 Orchestrator-Subagent 架构（Lead+Sub-agent 并行深挖、压缩回传、Scaling Rules 预算控制）， 对齐 Anthropic 官方 Research 工程实践。 包含信息交叉验证、专业图表生成（Diagram Bridge 统一图表体系）、 数据来源分级标注、分析框架自动选择、报告组件驱动（不预设模板，按内容形态调用组件）、质量自检（6 步工作流）。 触发词：调研、研究、分析报告、对比分析、行业报告、技术选型、竞品分析、 市场调研、深度研究、出一份报告、帮我调研一下、了解一下xxx、 评估、诊断、健康度、差距分析。 即使用户没有明确说"调研"，只要意图是"系统性地了解某个命题并形成结论"，都应触发此技能。
MD 文件浏览器预览：GitHub 风格渲染 + 左侧自动目录。 在完成方案设计（specs）或开发计划（plans）的 MD 文件后触发。 询问用户是否要在浏览器中打开预览，确认后执行。 触发词：方案写完、计划写完、review MD、预览文档。 工作流位置：task-start 方案产出后 / 任意 MD 文档完成后
专业图表生成技能：根据需求自动选择合适的图表类型，生成符合设计规范的 PNG 图表。 覆盖 29 种图表：结构图（流程图、泳道图、时序图、架构图、状态图、ER图、类图、思维导图、甘特图、Kanban、Git Graph 等） 和统计图（柱状图、折线图、饼图、雷达图、热力图、散点图、桑基图、漏斗图、瀑布图、矩形树图、柱线混合图等）。 统一工具：HTML/SVG + 内联 JS 布局计算。ER/类图使用 ELKjs 布局引擎。 所有图表遵循统一的设计规范（配色/字体/组件/间距），风格现代简洁。 支持三种输出：PNG（默认）、HTML（富文档嵌入）、DSL（Mermaid 文本，嵌入 MD 文档）。 触发词：画图、画一个、生成图表、流程图、架构图、时序图、柱状图、对比图、关系图。 即使用户没有说"画图"，只要需求中涉及可视化展示（流程、架构、数据对比、关系），都应触发此技能。 被 deep-research 等其他技能调用时，同样遵循本规范生成图表。
项目知识库引擎：持续维护 docs/ 目录作为活的知识库。 灵感来源：Karpathy LLM Wiki — LLM 不只是写文档，而是持续维护知识库。 五个核心操作：Ingest（摄入新信息）、Query（检索知识）、Lint（健康检查）、Index（索引维护）、Synthesize（聚合全局视图）。 触发词：文档检查、清理文档、文档索引、docs 整理、知识库、文档过期了吗、架构文档、用户手册。 触发场景：task-manager 标 done 时自动触发 Ingest、定期 Lint 健检、用户查询项目历史、 task-finish 提醒后触发 Synthesize 更新 architecture/ 或 user-guide/。 即使用户没有说"文档管理"，只要涉及 docs/ 目录的整理/检查/更新，都应触发此技能。
提交前质量门禁：CR 自检（快速/深度）。在 commit 之前触发。 只负责代码质量自检，不负责复盘——复盘在需求标 done 时由 task-manager 触发。 触发词：提交代码、自检、准备提交。 工作流位置：task-start → task-execute → task-finish（自检）→ task-manager（需求关闭时复盘）