Menu
用户提出新需求、重构想法、业务分析、先写 brief 或需要理清影响模块时使用；产出 .specs/<需求名>/brief.md，并支持迭代到冻结。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
当用户要求基于某个需求、功能、改造、技术方案或项目实践生成博客文章时使用；必须结合用户给出的完整需求、当前项目真实实现逻辑、业务场景和代码/文档上下文做深入分析，输出通俗易懂且专业的 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 | brief-generator |
| description | 用户提出新需求、重构想法、业务分析、先写 brief 或需要理清影响模块时使用；产出 .specs/<需求名>/brief.md，并支持迭代到冻结。 |
| when_to_use | 新需求、先分析、写 brief、需求理解、业务流程梳理、影响模块分析。若 brief 已冻结且用户要生成 acceptance，转 acceptance-generator。 |
把原始需求整理成面向开发者的 brief.md。brief 只回答"为什么做、做什么、不做什么、业务怎么跑、涉及哪些模块、风险是什么"，不到代码实现层。
.specs/<需求名>/brief.md
.specs/<需求名>/feature_info.md
若目录已存在 brief.md，先读旧版判断是修订还是覆盖，不允许无说明地重写关键结论。
AGENTS.mdproject_info.md# <需求名> Brief
## 1. 需求摘要
- 做什么
- 为什么做
- 本次不做
## 2. 业务流程
### 2.1 主流程图（Mermaid）
### 2.2 流程详解（主链路 + 关键异常分支）
## 3. 核心模块与实现思路
按模块说明：位置、职责、复用能力、新增能力、上下游关系、关键决策。
## 4. 风险与不确定性
| 风险 / 问题 | 触发条件 | 影响 | 当前判断 / 应对方向 |
## 5. 待确认问题
仅迭代期保留；冻结时整章删除，或由用户确认保留非阻塞项。
提炼核心目标、范围、非目标，标出明显缺失的信息。保留用户原话中的关键约束，不要丢失细节。
按需求关键词最小化探索：读相关模块入口、已有同业务域产物、公共契约文档。不做完整代码审查，读到能支撑模块草图为止。
按模板 5 章生成。第 3 章核心模块要写透（位置、职责、复用、新增、关键决策），第 4 章风险落到具体场景，第 5 章把所有不确定的问题列出。
进入用户审阅循环：
brief.md（不凭记忆）feature_info.md：状态改为 brief 已冻结。acceptance-generator。合格的 brief.md 必须：
不合格的信号：