把产品功能/应用封装为 Agent 可用的 Skill 技能
概念对齐
- 所有产品都由给人看的前端和负责逻辑处理的后端组成
- 前后端通过接口请求完成通信
- 以标记语言表述的前端，都可以被渲染到对话里（Markdown、HTML）
- 大多数应用，都可以基于 Agent 交互范式重新组织一次
- 后端能力从原有前端中解耦，沉淀为可被 Agent 调用的能力层
- 状态型能力：以 API、数据库、对象存储等形式提供持久化服务
- 动作型能力：以脚本、Webhook 等形式提供触发式执行服务
- 前端不再是图形界面，而是重构为面向对话的表达层
- 将信息展示转换为对话友好的结构化内容
- 将用户操作转换为 Agent 可调用的工具、指令或工作流
- 将复杂流程转换为可分步确认、可追踪、可回滚的交互过程
- 后端能力从原有前端中解耦，沉淀为可被 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.md：Skill 规划索引要求&示例，列出所有 Skill 的候选名称、类型、优先级和复杂度等信息。skill-naming-conventions.md：Skill 命名规范，可选读取skill-spec.md：Skill 封装规范，必须阅读
- 先拆功能再梳理 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 | 类型 | 优先级 | 复杂度 | 是否改变状态 | 是否需要确认 | 依赖能力 | 备注 | |---|---|---|---|---|---|---|---| ## 详情 ### Skill：<skill-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.md SKILL.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和description name使用小写 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和description - Skill 名称是否为 kebab-case
- description 是否使用第三人称
- 是否存在硬编码密钥
- 是否存在编造接口
- 是否引用了不存在的文件
- 是否对危险操作设置确认要求
- 是否将过长文档放入 references 而不是 SKILL.md
- 是否每个 Skill 都有明确边界
重要约束
- 只基于实际代码生成结论，不要编造产品能力
- 如果某个能力无法从代码中确认，在文档中标记为
Needs verification - 如果某个 API 存在但无法确认业务含义，在文档中标记为
Unclear business meaning - 如果某个前端交互存在但没有找到对应后端能力，在文档中标记为
Frontend-only or unresolved backend - 如果某个后端能力存在但没有前端入口，在文档中标记为
Backend-only capability - 不要修改原产品代码，除非为了生成独立 Skill 脚本且不会影响原项目运行
- 不要删除或重构原项目文件
- 所有新增内容都放在
agent-skills/目录下 - 保持文档可被其他 Agent 阅读和执行