Menú
brief.md 和 acceptance.feature 已冻结后，生成 .specs/<需求名>/technical_design.md；必须基于真实 Java 代码、组件文档和契约。
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional 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）。
为 toLink-Service 的 HTTP 接口构建并执行全面的 curl 黑盒测试。分析待测接口与边界条件，必要时直连数据库或经接口造数，对本地已启动服务发起 curl 请求，断言响应，最终在对话中返回测试结果汇总。
实现完成后，从当前改动创建规范分支、提交并发起 PR。
| name | technical-design |
| description | brief.md 和 acceptance.feature 已冻结后，生成 .specs/<需求名>/technical_design.md；必须基于真实 Java 代码、组件文档和契约。 |
| when_to_use | 用户要求生成技术方案、technical_design.md、技术实现文档，且 brief + acceptance 已冻结。 |
把 brief.md 与 acceptance.feature 转成可落地的 technical_design.md。回答：改哪些文件、怎么改、为什么这样改、如何验证。
.specs/<需求名>/brief.md 已冻结.specs/<需求名>/acceptance.feature 已冻结任一不满足，停止并说明，不允许基于聊天记忆直接生成。
AGENTS.mdproject_info.md.specs/<需求名>/brief.md.specs/<需求名>/acceptance.feature.specs/<需求名>/feature_info.md（若存在）.ai/skills/technical-design/technical_design.template.md组件文档强制规则：
| 涉及内容 | 必须先读 |
|---|---|
| Redis 缓存 | docs/internals/cache_module.md |
| OSS / 文件存储 | docs/internals/object_storage_module.md |
| MQ 消息 | docs/api/mq_contracts.md + mq-middleware skill |
| 数据库表 | docs/api/mysql_schema.md + scripts/db/init.sql + link-api/src/main/resources/schema.sql |
.specs/<需求名>/technical_design.md
[新增] / [修改] / [删除] / [不改]，并说明原因）acceptance.feature 中每个 Scenario 对应哪个实现点和测试点确认 brief.md + acceptance.feature 存在且冻结，否则停止。
在落方案前必须确认：
[修改] 文件是否真实存在[新增] 文件的父目录是否符合现有项目结构[修改] 方法是否真实存在未扫代码就写方案，TD 默认不合格。
确定 API 设计、数据模型、缓存策略、消息结构、幂等/事务/一致性处理方式。
逐条 Scenario 自查：它由哪个方法实现？由哪个测试验证？若有 Scenario 无承接，必须在"风险与待确认项"中说明。
以下问题不清楚时，必须先向用户提问，不允许直接出 TD：
只问会改变设计的关键问题，低风险假设写入"假设与依赖"不阻塞文档。
用户审核后把修订写回对应章节，不追加在末尾。用户确认后更新 feature_info.md 为 technical_design 已冻结，告知下一步进入 implementation-execution。
[修改] 文件和方法必须真实存在，不能凭命名猜测。contract-guard 检查。requirement.md 不再作为输入。