概念对齐所有产品都由给人看的前端和负责逻辑处理的后端组成前后端通过接口请求完成通信以标记语言表述的前端都可以被渲染到对话里Markdown、HTML大多数应用都可以基于 Agent 交互范式重新组织一次后端能力从原有前端中解耦沉淀为可被 Agent 调用的能力层状态型能力以 API、数据库、对象存储等形式提供持久化服务动作型能力以脚本、Webhook 等形式提供触发式执行服务前端不再是图形界面而是重构为面向对话的表达层将信息展示转换为对话友好的结构化内容将用户操作转换为 Agent 可调用的工具、指令或工作流将复杂流程转换为可分步确认、可追踪、可回滚的交互过程MakeSkills分步执行版(建议前期选用)skill-creator.zip分析项目、输出拆解报告直出拆解报告基于当前代码库对已经实现的产品进行 Agent 化改造分析。目标将产品中所有原本面向人类用户的“人 vs 产品”交互操作拆解为一个个可以被其他 Agent 理解、调用、组合和执行的 Skills。你可以阅读skill-creator技能的说明文档了解 Skills 的概念和价值请基于当前代码库完成以下工作理解产品阅读项目结构、前端页面、路由、组件、后端接口、服务层、数据库模型、任务脚本、配置文件和测试文件。还原这个产品实际提供给用户的核心功能。识别用户在前端界面中可以完成的主要操作。识别这些操作背后依赖的后端接口、数据模型、业务规则和状态变化。抽象能力不要只按照页面或接口拆分能力而要按照“用户想完成的任务”拆分。将每个用户任务抽象为一个 Agent 可使用的 Skill 候选项。每个 Skill 候选项应描述Skill 名称使用场景触发该 Skill 的用户意图示例该 Skill 需要读取或修改哪些数据该 Skill 需要调用哪些接口、函数、服务、脚本或数据库操作执行流程前置条件权限和安全边界成功结果失败场景和错误处理方式是否需要用户确认是否适合进一步拆成多个 Skill解耦前后端能力将原本隐藏在前端页面、按钮、表单、弹窗、路由跳转中的操作抽象为清晰的能力调用。将后端 API、服务函数、数据库操作、任务脚本整理为 Agent 可调用的能力层。如果发现某些能力只存在于前端逻辑中请指出并建议如何下沉到后端、服务层或脚本中。如果发现某些后端接口过于面向页面请建议如何重构为面向任务的能力接口。如果发现某些流程需要多个接口组合调用请将其抽象为工作流型 Skill。设计 Skills请优先输出 Skill 规划也就是技能清单不要一开始就创建文件。对每个 Skill 进行分类查询型 Skill只读取信息不改变状态操作型 Skill会创建、更新、删除或触发业务动作工作流型 Skill需要组合多个步骤、多个接口或多轮确认管理型 Skill面向管理员、运营或内部人员集成型 Skill对接外部系统、第三方 API、Webhook 或文件导入导出标注每个 Skill 的优先级P0产品核心高频能力必须封装P1重要但非最高频能力P2辅助能力或边缘能力标注每个 Skill 的封装复杂度S可以直接基于现有接口或函数封装M需要组合多个接口、补充文档或做少量适配L需要重构后端能力、补充权限控制或新增脚本输出要求第一阶段只输出分析结果和 Skill 规划不修改代码、不封装 Skill。输出内容必须包括产品功能地图用户操作路径清单前端页面/组件到用户任务的映射用户任务到后端接口/服务/数据模型的映射Skill 规划推荐的封装顺序需要我确认的问题在当前项目路径下/skills-planning目录并将分析结果和 Skill 规划输出到该目录下的文件中如果信息不足不要凭空假设。请明确标注“不确定”并说明需要检查哪些文件或需要我补充什么信息。优先基于代码事实推断不要只基于文件名猜测。支持资料在/skills-planning目录skill-inventory-template.mdSkill 规划索引要求示例列出所有 Skill 的候选名称、类型、优先级和复杂度等信息。skill-naming-conventions.mdSkill 命名规范可选读取skill-spec.mdSkill 封装规范必须阅读- 先拆功能再梳理 Skills md 阅读当前项目代码完成产品理解分析。 **重点不是解释技术栈而是还原这个产品对用户提供了哪些功能以及用户通过哪些前端交互完成这些功能。** 请输出以下内容 ## 1. 项目结构概览 说明当前代码库的主要目录和职责例如 - 前端页面/路由目录 - 前端组件目录 - API 请求封装目录 - 后端路由/API 目录 - 服务层/业务逻辑目录 - 数据模型/数据库 Schema 目录 - 脚本/任务/定时任务目录 - 配置、权限、鉴权相关目录 - 测试目录 ## 2. 产品功能地图 请根据代码还原产品的核心功能模块。每个模块包括 - 模块名称 - 面向的用户角色 - 用户可以完成的任务 - 对应的页面、路由或组件 - 对应的后端接口或服务 - 涉及的数据模型 - 是否会改变业务状态 ## 3. 用户操作路径清单 请列出用户在产品中可以执行的主要操作。不要只列按钮名称要表达为用户任务。 格式 | 用户任务 | 用户入口 | 前端文件 | 后端接口/服务 | 数据模型 | 状态变化 | 备注 | |---|---|---|---|---|---|---| | 示例创建项目 | 项目列表页的新建按钮 | xxx | POST /api/projects | Project | 创建项目记录 | 需要校验权限 | ## 4. 前后端通信地图 请整理前端调用后端的接口清单包括 | 接口/函数 | 调用位置 | 业务用途 | 入参 | 出参 | 是否改变状态 | 可否封装为 Agent Skill | |---|---|---|---|---|---|---| 你可以阅读skill-creator技能的说明文档了解 Agent Skill 的概念和价值 ## 5. 初步 Agent 化判断 请判断哪些能力适合封装为 Agent Skill。分类为 - 查询型能力 - 操作型能力 - 工作流型能力 - 管理型能力 - 集成型能力 暂时不要创建 Skill只输出分析将每一个分析结果以 Markdown 文档形式输出在/skills-planning/analysis/目录下。md基于你对代码库的分析请将产品中的“人 vs 产品”交互操作抽象为 Agent 可使用的 Skill Inventory输出在/skills-planning/skill-inventory.md请注意不要按照页面机械拆分 Skill。不要按照单个 API 机械拆分 Skill。请按照“用户想完成的任务”拆分 Skill。一个 Skill 应该代表一个 Agent 可以独立帮助用户完成的明确任务。如果某个任务需要多个步骤请设计为工作流型 Skill。如果某个任务风险较高例如删除、付款、发布、发送通知、修改权限、批量操作请标记为需要用户确认。如果某个能力只适合内部管理员使用请标记角色边界。如果现有代码不支持 Agent 直接调用请指出需要补充的后端能力或脚本。Skill Inventory 建议字段| Skill 候选名称 | 类型 | 优先级 | 复杂度 | 用户意图示例 | 对应产品能力 | 依赖接口/函数/数据 | 是否改变状态 | 是否需要确认 | 备注 |字段说明类型查询型操作型工作流型管理型集成型优先级P0核心高频能力必须封装P1重要能力建议封装P2辅助能力可后续封装复杂度S现有接口或函数基本可直接复用M需要组合多个接口、补充引用文档或少量适配L需要重构后端能力、补充权限控制、新增脚本或新增抽象层先给出简单的索引表格之后每个 Skill 作为二级标题、字段作为三级标题给出详细描述。示例模板# Skill Inventory ## 总览 | Skill | 类型 | 优先级 | 复杂度 | 是否改变状态 | 是否需要确认 | 依赖能力 | 备注 | |---|---|---|---|---|---|---|---| ## 详情 ### Skillskill-name - 中文名称 - 类型 - 优先级 - 复杂度 - 目标 - 适用角色 - 用户意图示例 - - - - 前端入口 - - 后端依赖 - - 数据依赖 - - 执行流程 1. 2. 3. - 输入 - - 输出 - - 权限边界 - 风险点 - 用户确认点 - 错误处理 - 建议资源 - SKILL.md - references/api.md - references/schema.md - references/business-rules.md - scripts/script-name - assets/asset-name - 是否需要后端重构 - 备注- 执行 Skills 封装 md 请基于已经确认的 Skill Inventory开始批量创建 Skills。 执行规则 1. 按优先级处理 - 先处理 P0 - 再处理 P1 - 最后处理 P2 2. 同一优先级内按复杂度处理 - 先处理 S - 再处理 M - 最后处理 L 3. 每次创建 1 个 Skills。 - 可以激活 SubAgents 或子 Agent 协助拆解但务必给出详细的说明规范 - 如果遇到不确定的业务逻辑暂停该 Skill转而处理下一个确定的 Skill 4. 每个 Skill 都必须使用 skill-creator 技能创建将 skill 创建在/skills-created目录下。 5. 不允许创建一个覆盖整个产品的大型 Skill。 - 每个 Skill 必须对应一个清晰的用户任务。 - 每个 Skill 必须能被一句用户意图触发。 - 每个 Skill 必须有明确输入、处理流程和输出。 6. 每个 Skill 完成后在/skills-created/skills-index.md路径下追加已创建技能的说明包含以下内容Skill名称类型优先级复杂度文件路径主要用途触发意图依赖产品能力是否改变状态是否需要用户确认测试建议待补充事项Skills 测评请对/skills-created目录下已经创建的 Skills 做一次质量验收。验收标准如下1. 结构检查检查每个 Skill 是否满足存在独立技能目录存在SKILL.mdSKILL.md包含有效 YAML 前置元数据包含name包含description资源目录使用合理references/存放详细文档scripts/存放可执行脚本assets/存放模板或资产2. 描述质量检查检查每个 Skill 的description是否使用第三人称明确说明何时应该使用该技能足够具体避免过泛不与其他 Skill 触发条件严重重叠3. 工作流检查检查每个 Skill 是否说明任务目标适用场景所需输入前置条件执行步骤结果输出错误处理权限边界用户确认点相关引用文件或脚本的使用方式4. 代码依据检查检查每个 Skill 是否能追溯到当前产品代码中的真实能力包括前端入口API 调用后端接口服务函数数据模型权限逻辑测试或示例如果 Skill 中存在没有代码依据的假设请标记出来。5. Agent 可用性检查启用子 Agent 分别使用这些 Skills 帮助用户操作该产品检查是否知道何时使用 Skill是否知道需要向用户收集哪些信息是否知道如何调用产品能力是否知道如何解释结果是否知道哪些操作必须先确认是否知道失败时如何处理6. 输出验收报告请输出Skill结构是否合格描述是否清晰工作流是否完整代码依据是否充分是否存在风险建议最后给出通过验收的 Skills需要修改的 Skills建议合并的 Skills建议拆分的 Skills需要补充代码能力的地方#### 一包梭哈 为 Claude Code 或者 Cursor 配置/makeSkills命令 md --- name: makeSkills description: 解析项目代码将产品拆解为 Agent 可用的 Skills。 --- 你是一个面向既有产品代码进行 Agent 化改造的 Coding Agent。你的任务是读取当前项目代码理解产品的前端交互、后端能力、数据模型和业务流程然后将原本由用户在界面中完成的“人 vs 产品”操作路径抽象并封装为一组可被其他 Agent 使用的 Skills。 ## 背景定义 该产品原本由面向人的前端和承载业务逻辑的后端组成。用户通过页面、表单、按钮、菜单、跳转、弹窗等方式完成操作前端通过接口请求、状态管理、路由和组件逻辑与后端交互后端通过 API、服务、数据库、任务、脚本或第三方集成完成业务处理。 现在需要将这些能力重新组织为面向 Agent 的交互形态 - 将后端能力从前端操作路径中解耦出来整理为 Agent 可理解、可调用、可组合的能力 - 将前端中的用户操作流程抽象为任务流程、输入要求、执行步骤、结果反馈和异常处理 - 将可复用任务封装为 Skills - 为每个 Skill 提供必要的 SKILL.md、references、scripts 或 assets ## Skill 定义 Skill 是一种帮助 Agent 更规范完成指定任务的插件。每个 Skill 是一个自包含目录至少包含 text skill-name/ ├── SKILL.md └── references/ └── scripts/ └── assets/其中SKILL.md是必需文件SKILL.md必须包含 YAML 前置元数据YAML 前置元数据必须包含name和descriptionname使用小写 kebab-casedescription使用第三人称明确说明该 Skill 何时应该被使用SKILL.md正文使用命令式/不定式风格不使用第二人称references/用于存放 API、数据模型、业务规则、流程细节等较长文档scripts/用于存放可重复、确定性、适合自动化执行的脚本assets/仅用于模板、示例文件、图标、表单样例等输出资源工作目标请在当前项目根目录下生成一个agent-skills/目录完成以下产物agent-skills/ ├── product-capability-map.md ├── interaction-inventory.md ├── skill-design.md ├── skills/ │ └── skill-name/ │ ├── SKILL.md │ ├── references/ │ ├── scripts/ │ └── assets/ └── README.md第一步理解项目结构读取项目代码识别前端技术栈后端技术栈路由结构页面结构组件结构状态管理方式API 请求封装方式后端接口定义数据模型鉴权机制权限模型异步任务、定时任务、队列或脚本第三方服务集成环境变量和配置方式将结果写入agent-skills/product-capability-map.md第二步盘点所有“人 vs 产品”的交互从前端代码中识别所有用户可见、可操作、可触发的交互包括但不限于页面访问菜单导航搜索筛选表单填写新建编辑删除批量操作上传下载导入导出审批状态流转支付登录注册权限管理设置修改报表查看数据分析消息通知第三方集成授权对每个交互记录交互名称所属页面或模块用户意图入口位置前端组件或文件路径涉及的路由涉及的 API涉及的数据模型必需输入可选输入前置条件执行步骤成功结果失败情况权限要求是否适合封装为 Skill适合归属到哪个 Skill将结果写入agent-skills/interaction-inventory.md第三步后端能力解耦从后端代码、API 定义、服务层、数据库模型和任务脚本中识别产品能力。不要只按接口拆能力而要按业务语义拆能力。对于每个能力记录能力名称业务含义对应用户意图API 或函数入口请求参数响应结构依赖的数据表或模型权限要求鉴权方式幂等性要求副作用可观测结果常见错误可否被 Agent 安全调用是否需要人工确认将这些信息补充到agent-skills/product-capability-map.md第四步设计 Skill 拆分方案基于交互清单和后端能力设计一组 Skills。Skill 拆分原则以用户意图和可复用任务为中心而不是以按钮或接口为中心一个 Skill 应该对应一个相对完整的任务域或高频任务流程多个低层 API 可以归属于同一个 Skill多个页面上的相似操作可以合并为同一个 Skill不要为单个简单按钮创建 Skill不要把无关任务塞进一个过大的 Skill对需要复杂判断、状态流转或多步骤操作的流程优先封装为 Skill对需要稳定重复执行的 API 调用优先提供 scripts对复杂业务规则、字段含义、数据模型和 API 细节优先放入 references对模板、示例文件、导入导出样例放入 assets对每个候选 Skill 输出Skill 名称Skill 触发场景覆盖的用户意图覆盖的前端交互涉及的后端能力必需输入可选输入工作流程需要的 references需要的 scripts需要的 assets安全风险是否需要执行前确认是否需要执行后校验不应该由该 Skill 处理的边界情况将设计写入agent-skills/skill-design.md第五步生成 Skills根据skill-design.md创建实际 Skill 目录。每个 Skill 至少包含skills/skill-name/ ├── SKILL.md └── references/如果该 Skill 需要稳定调用 API、执行重复流程或处理复杂数据则创建skills/skill-name/scripts/如果该 Skill 需要模板或示例文件则创建skills/skill-name/assets/SKILL.md 写作要求每个SKILL.md必须满足--- name: skill-name description: 第三人称描述。说明当用户希望完成什么任务时应该使用此技能。 --- # Skill Title ## Purpose 用简短文字说明该 Skill 的目的。 ## When to Use 说明何时使用该 Skill。 ## Inputs 列出完成任务需要的信息。 ## Workflow 用步骤描述 Agent 应如何完成该任务。 ## Tool and API Usage 说明应调用哪些 API、脚本、函数或服务。 ## Validation 说明如何判断任务完成成功。 ## Error Handling 说明常见失败情况和处理方式。 ## Safety and Confirmation 说明哪些操作需要用户确认哪些操作存在副作用。 ## References 列出该 Skill 需要按需读取的 references 文件。SKILL.md正文要求保持精简优先存放核心流程不要把大段 API 文档全部塞进 SKILL.md将详细 API、数据结构、业务规则放入 references使用命令式/不定式风格避免“你应该”“你可以”等第二人称明确说明何时使用该 Skill何时不要使用该 Skill对有副作用的操作标记确认要求对涉及删除、支付、外部通知、批量修改、权限变更的操作必须要求执行前确认references 写作要求为每个 Skill 生成必要的引用文档例如references/api.md references/data-model.md references/workflows.md references/permissions.md references/errors.md内容应来自实际代码不要编造不存在的接口、字段或流程。scripts 写作要求如果生成脚本必须满足不硬编码密钥、Token、密码、生产地址通过环境变量读取配置提供.env.example或在 README 中说明环境变量对危险操作默认 dry-run对删除、批量更新、支付、通知发送等操作增加显式确认参数对 API 错误输出清晰错误信息返回结构化结果尽可能复用项目已有 SDK、client、类型定义或请求封装如果无法可靠调用后端则只生成说明不要伪造可执行脚本第六步生成总 README在agent-skills/README.md中说明这个目录的用途产品能力概览已生成的 Skills 列表每个 Skill 覆盖的任务如何安装或复制这些 Skills如何配置环境变量哪些 Skill 有副作用哪些操作需要人工确认后续如何维护第七步自检完成后执行一次自检并在agent-skills/README.md末尾追加自检结果是否所有 Skill 都包含合法的 SKILL.md是否所有 Skill 都包含name和descriptionSkill 名称是否为 kebab-casedescription 是否使用第三人称是否存在硬编码密钥是否存在编造接口是否引用了不存在的文件是否对危险操作设置确认要求是否将过长文档放入 references 而不是 SKILL.md是否每个 Skill 都有明确边界重要约束只基于实际代码生成结论不要编造产品能力如果某个能力无法从代码中确认在文档中标记为Needs verification如果某个 API 存在但无法确认业务含义在文档中标记为Unclear business meaning如果某个前端交互存在但没有找到对应后端能力在文档中标记为Frontend-only or unresolved backend如果某个后端能力存在但没有前端入口在文档中标记为Backend-only capability不要修改原产品代码除非为了生成独立 Skill 脚本且不会影响原项目运行不要删除或重构原项目文件所有新增内容都放在agent-skills/目录下保持文档可被其他 Agent 阅读和执行
把产品功能/应用封装为 Agent 可用的 Skill 技能
发布时间：2026/6/12 11:02:14
概念对齐所有产品都由给人看的前端和负责逻辑处理的后端组成前后端通过接口请求完成通信以标记语言表述的前端都可以被渲染到对话里Markdown、HTML大多数应用都可以基于 Agent 交互范式重新组织一次后端能力从原有前端中解耦沉淀为可被 Agent 调用的能力层状态型能力以 API、数据库、对象存储等形式提供持久化服务动作型能力以脚本、Webhook 等形式提供触发式执行服务前端不再是图形界面而是重构为面向对话的表达层将信息展示转换为对话友好的结构化内容将用户操作转换为 Agent 可调用的工具、指令或工作流将复杂流程转换为可分步确认、可追踪、可回滚的交互过程MakeSkills分步执行版(建议前期选用)skill-creator.zip分析项目、输出拆解报告直出拆解报告基于当前代码库对已经实现的产品进行 Agent 化改造分析。目标将产品中所有原本面向人类用户的“人 vs 产品”交互操作拆解为一个个可以被其他 Agent 理解、调用、组合和执行的 Skills。你可以阅读skill-creator技能的说明文档了解 Skills 的概念和价值请基于当前代码库完成以下工作理解产品阅读项目结构、前端页面、路由、组件、后端接口、服务层、数据库模型、任务脚本、配置文件和测试文件。还原这个产品实际提供给用户的核心功能。识别用户在前端界面中可以完成的主要操作。识别这些操作背后依赖的后端接口、数据模型、业务规则和状态变化。抽象能力不要只按照页面或接口拆分能力而要按照“用户想完成的任务”拆分。将每个用户任务抽象为一个 Agent 可使用的 Skill 候选项。每个 Skill 候选项应描述Skill 名称使用场景触发该 Skill 的用户意图示例该 Skill 需要读取或修改哪些数据该 Skill 需要调用哪些接口、函数、服务、脚本或数据库操作执行流程前置条件权限和安全边界成功结果失败场景和错误处理方式是否需要用户确认是否适合进一步拆成多个 Skill解耦前后端能力将原本隐藏在前端页面、按钮、表单、弹窗、路由跳转中的操作抽象为清晰的能力调用。将后端 API、服务函数、数据库操作、任务脚本整理为 Agent 可调用的能力层。如果发现某些能力只存在于前端逻辑中请指出并建议如何下沉到后端、服务层或脚本中。如果发现某些后端接口过于面向页面请建议如何重构为面向任务的能力接口。如果发现某些流程需要多个接口组合调用请将其抽象为工作流型 Skill。设计 Skills请优先输出 Skill 规划也就是技能清单不要一开始就创建文件。对每个 Skill 进行分类查询型 Skill只读取信息不改变状态操作型 Skill会创建、更新、删除或触发业务动作工作流型 Skill需要组合多个步骤、多个接口或多轮确认管理型 Skill面向管理员、运营或内部人员集成型 Skill对接外部系统、第三方 API、Webhook 或文件导入导出标注每个 Skill 的优先级P0产品核心高频能力必须封装P1重要但非最高频能力P2辅助能力或边缘能力标注每个 Skill 的封装复杂度S可以直接基于现有接口或函数封装M需要组合多个接口、补充文档或做少量适配L需要重构后端能力、补充权限控制或新增脚本输出要求第一阶段只输出分析结果和 Skill 规划不修改代码、不封装 Skill。输出内容必须包括产品功能地图用户操作路径清单前端页面/组件到用户任务的映射用户任务到后端接口/服务/数据模型的映射Skill 规划推荐的封装顺序需要我确认的问题在当前项目路径下/skills-planning目录并将分析结果和 Skill 规划输出到该目录下的文件中如果信息不足不要凭空假设。请明确标注“不确定”并说明需要检查哪些文件或需要我补充什么信息。优先基于代码事实推断不要只基于文件名猜测。支持资料在/skills-planning目录skill-inventory-template.mdSkill 规划索引要求示例列出所有 Skill 的候选名称、类型、优先级和复杂度等信息。skill-naming-conventions.mdSkill 命名规范可选读取skill-spec.mdSkill 封装规范必须阅读- 先拆功能再梳理 Skills md 阅读当前项目代码完成产品理解分析。 **重点不是解释技术栈而是还原这个产品对用户提供了哪些功能以及用户通过哪些前端交互完成这些功能。** 请输出以下内容 ## 1. 项目结构概览 说明当前代码库的主要目录和职责例如 - 前端页面/路由目录 - 前端组件目录 - API 请求封装目录 - 后端路由/API 目录 - 服务层/业务逻辑目录 - 数据模型/数据库 Schema 目录 - 脚本/任务/定时任务目录 - 配置、权限、鉴权相关目录 - 测试目录 ## 2. 产品功能地图 请根据代码还原产品的核心功能模块。每个模块包括 - 模块名称 - 面向的用户角色 - 用户可以完成的任务 - 对应的页面、路由或组件 - 对应的后端接口或服务 - 涉及的数据模型 - 是否会改变业务状态 ## 3. 用户操作路径清单 请列出用户在产品中可以执行的主要操作。不要只列按钮名称要表达为用户任务。 格式 | 用户任务 | 用户入口 | 前端文件 | 后端接口/服务 | 数据模型 | 状态变化 | 备注 | |---|---|---|---|---|---|---| | 示例创建项目 | 项目列表页的新建按钮 | xxx | POST /api/projects | Project | 创建项目记录 | 需要校验权限 | ## 4. 前后端通信地图 请整理前端调用后端的接口清单包括 | 接口/函数 | 调用位置 | 业务用途 | 入参 | 出参 | 是否改变状态 | 可否封装为 Agent Skill | |---|---|---|---|---|---|---| 你可以阅读skill-creator技能的说明文档了解 Agent Skill 的概念和价值 ## 5. 初步 Agent 化判断 请判断哪些能力适合封装为 Agent Skill。分类为 - 查询型能力 - 操作型能力 - 工作流型能力 - 管理型能力 - 集成型能力 暂时不要创建 Skill只输出分析将每一个分析结果以 Markdown 文档形式输出在/skills-planning/analysis/目录下。md基于你对代码库的分析请将产品中的“人 vs 产品”交互操作抽象为 Agent 可使用的 Skill Inventory输出在/skills-planning/skill-inventory.md请注意不要按照页面机械拆分 Skill。不要按照单个 API 机械拆分 Skill。请按照“用户想完成的任务”拆分 Skill。一个 Skill 应该代表一个 Agent 可以独立帮助用户完成的明确任务。如果某个任务需要多个步骤请设计为工作流型 Skill。如果某个任务风险较高例如删除、付款、发布、发送通知、修改权限、批量操作请标记为需要用户确认。如果某个能力只适合内部管理员使用请标记角色边界。如果现有代码不支持 Agent 直接调用请指出需要补充的后端能力或脚本。Skill Inventory 建议字段| Skill 候选名称 | 类型 | 优先级 | 复杂度 | 用户意图示例 | 对应产品能力 | 依赖接口/函数/数据 | 是否改变状态 | 是否需要确认 | 备注 |字段说明类型查询型操作型工作流型管理型集成型优先级P0核心高频能力必须封装P1重要能力建议封装P2辅助能力可后续封装复杂度S现有接口或函数基本可直接复用M需要组合多个接口、补充引用文档或少量适配L需要重构后端能力、补充权限控制、新增脚本或新增抽象层先给出简单的索引表格之后每个 Skill 作为二级标题、字段作为三级标题给出详细描述。示例模板# Skill Inventory ## 总览 | Skill | 类型 | 优先级 | 复杂度 | 是否改变状态 | 是否需要确认 | 依赖能力 | 备注 | |---|---|---|---|---|---|---|---| ## 详情 ### Skillskill-name - 中文名称 - 类型 - 优先级 - 复杂度 - 目标 - 适用角色 - 用户意图示例 - - - - 前端入口 - - 后端依赖 - - 数据依赖 - - 执行流程 1. 2. 3. - 输入 - - 输出 - - 权限边界 - 风险点 - 用户确认点 - 错误处理 - 建议资源 - SKILL.md - references/api.md - references/schema.md - references/business-rules.md - scripts/script-name - assets/asset-name - 是否需要后端重构 - 备注- 执行 Skills 封装 md 请基于已经确认的 Skill Inventory开始批量创建 Skills。 执行规则 1. 按优先级处理 - 先处理 P0 - 再处理 P1 - 最后处理 P2 2. 同一优先级内按复杂度处理 - 先处理 S - 再处理 M - 最后处理 L 3. 每次创建 1 个 Skills。 - 可以激活 SubAgents 或子 Agent 协助拆解但务必给出详细的说明规范 - 如果遇到不确定的业务逻辑暂停该 Skill转而处理下一个确定的 Skill 4. 每个 Skill 都必须使用 skill-creator 技能创建将 skill 创建在/skills-created目录下。 5. 不允许创建一个覆盖整个产品的大型 Skill。 - 每个 Skill 必须对应一个清晰的用户任务。 - 每个 Skill 必须能被一句用户意图触发。 - 每个 Skill 必须有明确输入、处理流程和输出。 6. 每个 Skill 完成后在/skills-created/skills-index.md路径下追加已创建技能的说明包含以下内容Skill名称类型优先级复杂度文件路径主要用途触发意图依赖产品能力是否改变状态是否需要用户确认测试建议待补充事项Skills 测评请对/skills-created目录下已经创建的 Skills 做一次质量验收。验收标准如下1. 结构检查检查每个 Skill 是否满足存在独立技能目录存在SKILL.mdSKILL.md包含有效 YAML 前置元数据包含name包含description资源目录使用合理references/存放详细文档scripts/存放可执行脚本assets/存放模板或资产2. 描述质量检查检查每个 Skill 的description是否使用第三人称明确说明何时应该使用该技能足够具体避免过泛不与其他 Skill 触发条件严重重叠3. 工作流检查检查每个 Skill 是否说明任务目标适用场景所需输入前置条件执行步骤结果输出错误处理权限边界用户确认点相关引用文件或脚本的使用方式4. 代码依据检查检查每个 Skill 是否能追溯到当前产品代码中的真实能力包括前端入口API 调用后端接口服务函数数据模型权限逻辑测试或示例如果 Skill 中存在没有代码依据的假设请标记出来。5. Agent 可用性检查启用子 Agent 分别使用这些 Skills 帮助用户操作该产品检查是否知道何时使用 Skill是否知道需要向用户收集哪些信息是否知道如何调用产品能力是否知道如何解释结果是否知道哪些操作必须先确认是否知道失败时如何处理6. 输出验收报告请输出Skill结构是否合格描述是否清晰工作流是否完整代码依据是否充分是否存在风险建议最后给出通过验收的 Skills需要修改的 Skills建议合并的 Skills建议拆分的 Skills需要补充代码能力的地方#### 一包梭哈 为 Claude Code 或者 Cursor 配置/makeSkills命令 md --- name: makeSkills description: 解析项目代码将产品拆解为 Agent 可用的 Skills。 --- 你是一个面向既有产品代码进行 Agent 化改造的 Coding Agent。你的任务是读取当前项目代码理解产品的前端交互、后端能力、数据模型和业务流程然后将原本由用户在界面中完成的“人 vs 产品”操作路径抽象并封装为一组可被其他 Agent 使用的 Skills。 ## 背景定义 该产品原本由面向人的前端和承载业务逻辑的后端组成。用户通过页面、表单、按钮、菜单、跳转、弹窗等方式完成操作前端通过接口请求、状态管理、路由和组件逻辑与后端交互后端通过 API、服务、数据库、任务、脚本或第三方集成完成业务处理。 现在需要将这些能力重新组织为面向 Agent 的交互形态 - 将后端能力从前端操作路径中解耦出来整理为 Agent 可理解、可调用、可组合的能力 - 将前端中的用户操作流程抽象为任务流程、输入要求、执行步骤、结果反馈和异常处理 - 将可复用任务封装为 Skills - 为每个 Skill 提供必要的 SKILL.md、references、scripts 或 assets ## Skill 定义 Skill 是一种帮助 Agent 更规范完成指定任务的插件。每个 Skill 是一个自包含目录至少包含 text skill-name/ ├── SKILL.md └── references/ └── scripts/ └── assets/其中SKILL.md是必需文件SKILL.md必须包含 YAML 前置元数据YAML 前置元数据必须包含name和descriptionname使用小写 kebab-casedescription使用第三人称明确说明该 Skill 何时应该被使用SKILL.md正文使用命令式/不定式风格不使用第二人称references/用于存放 API、数据模型、业务规则、流程细节等较长文档scripts/用于存放可重复、确定性、适合自动化执行的脚本assets/仅用于模板、示例文件、图标、表单样例等输出资源工作目标请在当前项目根目录下生成一个agent-skills/目录完成以下产物agent-skills/ ├── product-capability-map.md ├── interaction-inventory.md ├── skill-design.md ├── skills/ │ └── skill-name/ │ ├── SKILL.md │ ├── references/ │ ├── scripts/ │ └── assets/ └── README.md第一步理解项目结构读取项目代码识别前端技术栈后端技术栈路由结构页面结构组件结构状态管理方式API 请求封装方式后端接口定义数据模型鉴权机制权限模型异步任务、定时任务、队列或脚本第三方服务集成环境变量和配置方式将结果写入agent-skills/product-capability-map.md第二步盘点所有“人 vs 产品”的交互从前端代码中识别所有用户可见、可操作、可触发的交互包括但不限于页面访问菜单导航搜索筛选表单填写新建编辑删除批量操作上传下载导入导出审批状态流转支付登录注册权限管理设置修改报表查看数据分析消息通知第三方集成授权对每个交互记录交互名称所属页面或模块用户意图入口位置前端组件或文件路径涉及的路由涉及的 API涉及的数据模型必需输入可选输入前置条件执行步骤成功结果失败情况权限要求是否适合封装为 Skill适合归属到哪个 Skill将结果写入agent-skills/interaction-inventory.md第三步后端能力解耦从后端代码、API 定义、服务层、数据库模型和任务脚本中识别产品能力。不要只按接口拆能力而要按业务语义拆能力。对于每个能力记录能力名称业务含义对应用户意图API 或函数入口请求参数响应结构依赖的数据表或模型权限要求鉴权方式幂等性要求副作用可观测结果常见错误可否被 Agent 安全调用是否需要人工确认将这些信息补充到agent-skills/product-capability-map.md第四步设计 Skill 拆分方案基于交互清单和后端能力设计一组 Skills。Skill 拆分原则以用户意图和可复用任务为中心而不是以按钮或接口为中心一个 Skill 应该对应一个相对完整的任务域或高频任务流程多个低层 API 可以归属于同一个 Skill多个页面上的相似操作可以合并为同一个 Skill不要为单个简单按钮创建 Skill不要把无关任务塞进一个过大的 Skill对需要复杂判断、状态流转或多步骤操作的流程优先封装为 Skill对需要稳定重复执行的 API 调用优先提供 scripts对复杂业务规则、字段含义、数据模型和 API 细节优先放入 references对模板、示例文件、导入导出样例放入 assets对每个候选 Skill 输出Skill 名称Skill 触发场景覆盖的用户意图覆盖的前端交互涉及的后端能力必需输入可选输入工作流程需要的 references需要的 scripts需要的 assets安全风险是否需要执行前确认是否需要执行后校验不应该由该 Skill 处理的边界情况将设计写入agent-skills/skill-design.md第五步生成 Skills根据skill-design.md创建实际 Skill 目录。每个 Skill 至少包含skills/skill-name/ ├── SKILL.md └── references/如果该 Skill 需要稳定调用 API、执行重复流程或处理复杂数据则创建skills/skill-name/scripts/如果该 Skill 需要模板或示例文件则创建skills/skill-name/assets/SKILL.md 写作要求每个SKILL.md必须满足--- name: skill-name description: 第三人称描述。说明当用户希望完成什么任务时应该使用此技能。 --- # Skill Title ## Purpose 用简短文字说明该 Skill 的目的。 ## When to Use 说明何时使用该 Skill。 ## Inputs 列出完成任务需要的信息。 ## Workflow 用步骤描述 Agent 应如何完成该任务。 ## Tool and API Usage 说明应调用哪些 API、脚本、函数或服务。 ## Validation 说明如何判断任务完成成功。 ## Error Handling 说明常见失败情况和处理方式。 ## Safety and Confirmation 说明哪些操作需要用户确认哪些操作存在副作用。 ## References 列出该 Skill 需要按需读取的 references 文件。SKILL.md正文要求保持精简优先存放核心流程不要把大段 API 文档全部塞进 SKILL.md将详细 API、数据结构、业务规则放入 references使用命令式/不定式风格避免“你应该”“你可以”等第二人称明确说明何时使用该 Skill何时不要使用该 Skill对有副作用的操作标记确认要求对涉及删除、支付、外部通知、批量修改、权限变更的操作必须要求执行前确认references 写作要求为每个 Skill 生成必要的引用文档例如references/api.md references/data-model.md references/workflows.md references/permissions.md references/errors.md内容应来自实际代码不要编造不存在的接口、字段或流程。scripts 写作要求如果生成脚本必须满足不硬编码密钥、Token、密码、生产地址通过环境变量读取配置提供.env.example或在 README 中说明环境变量对危险操作默认 dry-run对删除、批量更新、支付、通知发送等操作增加显式确认参数对 API 错误输出清晰错误信息返回结构化结果尽可能复用项目已有 SDK、client、类型定义或请求封装如果无法可靠调用后端则只生成说明不要伪造可执行脚本第六步生成总 README在agent-skills/README.md中说明这个目录的用途产品能力概览已生成的 Skills 列表每个 Skill 覆盖的任务如何安装或复制这些 Skills如何配置环境变量哪些 Skill 有副作用哪些操作需要人工确认后续如何维护第七步自检完成后执行一次自检并在agent-skills/README.md末尾追加自检结果是否所有 Skill 都包含合法的 SKILL.md是否所有 Skill 都包含name和descriptionSkill 名称是否为 kebab-casedescription 是否使用第三人称是否存在硬编码密钥是否存在编造接口是否引用了不存在的文件是否对危险操作设置确认要求是否将过长文档放入 references 而不是 SKILL.md是否每个 Skill 都有明确边界重要约束只基于实际代码生成结论不要编造产品能力如果某个能力无法从代码中确认在文档中标记为Needs verification如果某个 API 存在但无法确认业务含义在文档中标记为Unclear business meaning如果某个前端交互存在但没有找到对应后端能力在文档中标记为Frontend-only or unresolved backend如果某个后端能力存在但没有前端入口在文档中标记为Backend-only capability不要修改原产品代码除非为了生成独立 Skill 脚本且不会影响原项目运行不要删除或重构原项目文件所有新增内容都放在agent-skills/目录下保持文档可被其他 Agent 阅读和执行
