القائمة
用户提出新需求、重构想法、业务分析、先写 brief 或需要理清影响模块时使用；产出 .specs/<需求名>/brief.md，并支持迭代到冻结。
التثبيت باستخدام 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 | 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 必须：
不合格的信号：