Menu
当用户提出想根据某个需求、工作流、角色职责或项目约定创建一个全新的 Agent skill 时使用；先深度理解用户目标、触发场景、输入输出、执行边界和质量标准，在需求不清时主动追问，最终生成结构清晰、触发准确、流程可执行、可维护的 `.ai/skills/<skill-name>/SKILL.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 | skill-generator |
| description | 当用户提出想根据某个需求、工作流、角色职责或项目约定创建一个全新的 Agent skill 时使用；先深度理解用户目标、触发场景、输入输出、执行边界和质量标准，在需求不清时主动追问，最终生成结构清晰、触发准确、流程可执行、可维护的 `.ai/skills/<skill-name>/SKILL.md`。 |
| when_to_use | 当用户说'帮我生成一个 skill'、'创建一个 skill'、'把这个流程沉淀成 skill'、'根据我的需求写一个 skill'、'做一个用于 X 的 skill'，或希望把某类重复工作、项目流程、规范约束、文档生成流程、代码执行流程固化为可复用 Agent 能力时激活。若用户是优化已有 skill，转 skill-optimizer；若用户只是要执行某项业务任务而不是沉淀 skill，则按对应业务 skill 或普通实现流程执行。 |
本 skill 用于把用户的原始想法、工作流、项目规范或重复任务，沉淀为一个新的 Agent skill。
生成的 skill 必须让另一个 Agent 在未来遇到同类任务时能够：
.ai/skills/、AGENTS.md、文档阶段流转保持一致它不负责：
skill-optimizer）创建文件前必须先从用户请求中提取：
不得只根据 skill 名称或一句模糊描述直接写文件。
以下任一情况出现时，必须先问用户，不得直接落文件：
.ai/skills/提问规则：
新 skill 不应只写"深入分析""保证质量""灵活处理"等泛化表达。每个关键要求都要转化为：
创建新 skill 前至少读取：
AGENTS.md.ai/skills/ 下与目标能力相近的 skillSKILL.md按需读取：
.ai/prompts/project.mdproject_info.md只读取支撑 skill 设计的最小上下文，不做无关代码审查。
默认输出位置：
.ai/skills/<skill-name>/SKILL.md
命名规则：
<skill-name> 使用小写英文、数字和短横线assistant-helper默认只创建 SKILL.md。
只有在确有必要时才创建附加资源：
templates/ 或单个模板文件：当输出文档有固定格式references/：当详细参考内容过长，需要按需读取scripts/：当有可复用、确定性的脚本逻辑不得创建无关的 README.md、QUICK_START.md、CHANGELOG.md。
新 skill 至少包含以下内容。
---
name: <skill-name>
description: <一句话说明何时触发、做什么、输出什么>
when_to_use: "<典型触发语句、适用场景、排除场景>"
---
要求：
description 是触发入口，必须写清"何时使用"。when_to_use 覆盖典型用户说法和不适用场景。# <Skill Title>
## 1. 定位
说明 skill 负责什么、不负责什么、最终帮助 Agent 产出什么。
## 2. 触发边界
### 2.1 适合使用
- ...
### 2.2 不适合使用
- ...
## 3. 输入前提
- ...
## 4. 必读文件 / 上下文
- ...
## 5. 输出位置
```text
...
```
## 6. 输出内容要求
- ...
## 7. 工作步骤
### 步骤 1：...
### 步骤 2：...
## 8. 质量门禁
- ...
## 9. 与其他 skill 的衔接
- ...
可根据任务删减或增补章节，但必须保留"定位、触发边界、工作步骤、输出要求、质量门禁"。
把用户的自然语言需求整理为：
如果目标能力本质上是在优化已有 skill，停止并转 skill-optimizer。
在 .ai/skills/ 中查找相近能力：
若新增 skill 会明显重复已有 skill，先向用户说明并确认。
在写文件前形成简短契约：
如果用户已明确要求直接生成，契约可以内化为编辑前判断；如果存在阻塞性不确定，必须先问。
写作要求：
创建后逐项检查：
description 是否能准确触发when_to_use 是否包含排除场景最终回复说明：
生成的新 skill 出现以下任一情况即不合格，必须继续修订：
skill-optimizer。brief-generator。acceptance-generator。technical-design。implementation-execution。如果用户同时要求"创建 skill 并用它处理一次任务"，应先创建 skill，再按新 skill 的规则执行该任务；若执行任务前仍有关键需求不明确，先追问。