Menu
当用户要求优化、重写、评审、增强或规范化已有 Agent skill 时使用；以专业提示词工程师视角先理解目标和使用场景，识别不确定需求并主动提问，在关键需求未确认前不得直接修改 skill，确认后产出高质量、可触发、可执行、可维护的 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-optimizer |
| description | 当用户要求优化、重写、评审、增强或规范化已有 Agent skill 时使用；以专业提示词工程师视角先理解目标和使用场景，识别不确定需求并主动提问，在关键需求未确认前不得直接修改 skill，确认后产出高质量、可触发、可执行、可维护的 SKILL.md。 |
| when_to_use | 当用户提到优化已有 skill、改进 skill、重构 skill 提示词、检查 skill 质量、让 skill 更稳定、更专业、更会追问、更符合项目流程，或要求基于现有 skill 生成改进版时激活。若用户只是要求创建全新 skill 且没有已有 skill 作为输入，优先使用 skill-generator；若用户明确要求直接实现且需求完整，可在完成确认后进入编辑。 |
本 skill 用于优化仓库中已有的 Agent skill，使其更准确触发、更好理解用户意图、更能处理不确定需求，并产出高质量、可维护的 SKILL.md。
执行者应以专业提示词工程师和工程流程设计者的标准工作，重点提升：
在修改任何 skill 前，必须先读取目标 skill 的当前内容，并结合用户请求判断：
不得在未读取目标 skill 的情况下凭空重写。
如果存在以下任一情况，必须先向用户提问，不得直接执行修改：
提问规则：
只有同时满足以下条件，才允许修改文件：
AGENTS.md、项目流程的关系如果用户明确说"按你的判断直接改"，可以基于已有上下文做保守修改，但仍必须先说明核心假设。
执行本 skill 时至少读取：
AGENTS.mdSKILL.md如果目标 skill 涉及特定模块或流程，还应按需读取：
project_info.md.ai/prompts/project.md只读取支撑优化判断所需的最小上下文，不做无关代码审查。
检查 frontmatter：
name 是否简短、稳定、语义准确description 是否清楚说明"何时触发"when_to_use 是否覆盖典型触发语句和排除场景description 是触发入口，必须优先优化。不要把关键触发条件只写在正文里。
检查正文是否明确：
边界必须能阻止 Agent 在需求不确定时过早执行。
工作流应满足：
避免写成泛泛的提示词建议。skill 必须能指导 Agent 完成实际工作。
优化后的 skill 应具备明确提问策略：
检查输出要求是否包含：
从用户请求中提取：
如果目标不明确，停止并提问。
读取目标 skill 和必要的项目上下文，形成简短诊断：
在修改前输出简短方案，除非用户已明确要求直接改。
方案至少包含：
若仍有阻塞问题，只提问，不修改。
确认后再编辑目标 skill。
修改要求：
修改后必须自检：
description 是否能准确触发最终回复必须说明：
根据用户意图选择一种输出方式：
如果用户没有说清楚输出方式，必须先问。
优化后的 skill 不合格条件：
若发现以上问题，必须继续修订，不能交付为完成。