菜单
实现完成后，从当前改动创建规范分支、提交并发起 PR。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
当用户要求基于某个需求、功能、改造、技术方案或项目实践生成博客文章时使用；必须结合用户给出的完整需求、当前项目真实实现逻辑、业务场景和代码/文档上下文做深入分析，输出通俗易懂且专业的 Markdown 博客到 `.specs/blog/《博客名称》.md`。
当修改 AGENTS.md/CLAUDE.md、docs/api、docs/internals、docs/ops，或代码变更影响这些文档记录的 API、MySQL schema、MQ 契约、Redis 缓存、OSS、错误码、模块架构、配置时，检查并同步更新对应文档，保证项目文档自动维护。
MySQL 建表与字段规范（面向 Java 管理端业务：用户、LLM 配置、数据集、知识文件、解析任务）。统一命名、索引、字段类型、时间戳、引擎字符集与注释要求，便于研发与 DBA 评审落地。
SpringDoc OpenAPI 3 中文注解生成工作流。为 Spring Boot Controller 和 DTO 生成符合企业级规范的中文 Swagger 注解（@Tag、@Operation、@Parameter、@Schema）。
brief.md 和 acceptance.feature 已冻结后，生成 .specs/<需求名>/technical_design.md；必须基于真实 Java 代码、组件文档和契约。
为 toLink-Service 的 HTTP 接口构建并执行全面的 curl 黑盒测试。分析待测接口与边界条件，必要时直连数据库或经接口造数，对本地已启动服务发起 curl 请求，断言响应，最终在对话中返回测试结果汇总。
| name | branch-pr-workflow |
| description | 实现完成后，从当前改动创建规范分支、提交并发起 PR。 |
| when_to_use | 创建分支、提交、发 PR、把当前修改提 PR。 |
执行前必须确认：
git branch --show-current 检查当前分支。dev），停止并告知用户，不自动切换分支。git status --short 确认工作区状态，识别无关改动。| 前缀 | 适用场景 |
|---|---|
feature/ | 新增业务能力、接口、流程 |
fix/ | Bug 修复 |
refactor/ | 重构、结构调整，无新增业务能力 |
docs/ | 纯文档修改 |
chore/ | 构建、配置、脚本调整 |
主题使用英文 kebab-case：feature/recall-gateway、fix/mq-duplicate-consume。
避免泛泛名称，如 feature/update、fix/bug。
dev 是日常集成分支；master 是稳定发布分支。feature/、refactor/、chore/、fix/、docs/ 分支默认从 dev 拉出并 PR 回 dev。master 不接受日常 feature/、refactor/、chore/ 直接合入。dev 拉出 release/<version>，通过 release PR 合入 master。dev / release/<version> 到 master 的发布合并必须使用普通 merge commit，禁止 squash merge。master 后，在 master 的发布 merge commit 上打版本 tag。hotfix/<topic> 从 master 拉出，PR 合入 master 后必须 merge 或 cherry-pick 回 dev。git diff --stat
git status --short --branch
识别哪些改动属于本次需求，哪些是无关修改。若有无关改动，告知用户，只暂存相关文件。
mvn -pl <module> test # 或 mvn test（全量）
python3 scripts/check_docs_sync.py --working
若测试或校验失败，停止并报告，不继续提交。
git switch -c <branch-name>
当前未提交改动会随工作区留在新分支上。
只暂存本次相关文件，不用 git add -A。
提交信息使用约定式提交（Conventional Commits）：
feat(模块): 简短描述（不超过 70 字符）
- 改动点 1
- 改动点 2
前缀与分支前缀对应：feat / fix / refactor / docs / chore。
提 PR 前将 .specs/<需求名>/feature_info.md 状态更新为 PR 待合并，并将本次提交纳入暂存，一并提交或单独提交均可。这样 feature 状态变更才能随分支推上去。
git push -u origin <branch-name>
PR base 默认 dev。仅 release PR 使用 master 作为 base；hotfix PR 先合入 master，发布后必须回合 dev。
关联 Issue：检查 .specs/<需求名>/feature_info.md 和当前对话上下文中是否有 GitHub issue 号。有则在 PR 正文开头加 Closes #<issue号>，没有则跳过，不追问用户。
优先用 gh pr create：
gh pr create --title "..." --body "$(cat <<'EOF'
Closes #<issue号>
## Summary
...
EOF
)"
PR 创建成功后，若有关联 issue，在该 issue 下发一条评论，说明解决思路：
gh issue comment <issue号> --body "$(cat <<'EOF'
已在 PR #<PR号> 中实现。
**解决思路：**
<2-3 句话说明核心方案，例如：在哪里改了什么、用了什么机制解决问题>
EOF
)"
评论只写思路，不贴代码，不重复 PR 描述的全部内容。
必须包含：
Closes #<issue号> ← 若有关联 issue；无则省略
## Summary
- 解决了什么问题
- 核心实现方式
## Changes
- 主要代码改动
- 配置、文档、测试改动
## Tests
- 实际运行的测试命令
- 测试结果
## Risks
- 兼容性、数据、MQ、OSS、回滚风险
- 若无明显风险写 No known high-risk items
涉及 DB、MQ、Redis、OSS 或 Java/Python 跨端协作时，必须在 Risks 中说明运行时前提和影响。
必须包含：