القائمة
当用户提出想根据某个需求、工作流、角色职责或项目约定创建一个全新的 Agent skill 时使用；先深度理解用户目标、触发场景、输入输出、执行边界和质量标准，在需求不清时主动追问，最终生成结构清晰、触发准确、流程可执行、可维护的 `.ai/skills/<skill-name>/SKILL.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 | 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 的规则执行该任务；若执行任务前仍有关键需求不明确，先追问。