一些可能需要的skill支持参考资料
- skill-inventory-template.md：Skill 规划索引要求&示例，列出所有 Skill 的候选名称、类型、优先级和复杂度等信息。
Skill Inventory
基于你对代码库的分析，请将产品中的“人 vs 产品”交互操作抽象为 Agent 可使用的 Skill Inventory。
请注意
- 不要按照页面机械拆分 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>` - 是否需要后端重构： - 备注：- skill-naming-conventions.md：Skill 命名规范，可选读取 ```md 请遵循以下 Skill 命名规范： 1. 使用英文小写 kebab-case。 2. 名称表达任务，不表达页面。 3. 避免使用过泛名称，例如： - `user-management` - `data-helper` - `product-agent` 4. 优先使用动词 + 业务对象，例如： - `create-project` - `search-orders` - `summarize-customer-profile` - `export-invoice-report` - `approve-access-request` - `publish-content` 5. 查询型 Skill 可使用： - `search-*` - `get-*` - `list-*` - `summarize-*` - `analyze-*` 6. 操作型 Skill 可使用： - `create-*` - `update-*` - `delete-*` - `submit-*` - `send-*` - `publish-*` 7. 工作流型 Skill 可使用： - `onboard-*` - `process-*` - `resolve-*` - `review-*` - `approve-*` 8. 管理型 Skill 可使用： - `manage-*` - `configure-*` - `audit-*`- skill-spec.md：Skill 封装规范，必须阅读
在构建/封装 Skills 时，请严格遵守以下规则：
不要凭空创造产品能力。
- 所有 Skill 候选项都必须能追溯到当前代码中的页面、组件、接口、服务、模型、脚本或测试。
- 如果只是合理推测，必须标记为“推测”。
不要把 UI 操作直接等同于 Skill。
- Skill 应该对应用户任务，而不是按钮、页面或接口。
- 例如，“点击新建按钮”不是 Skill，“创建项目”才是 Skill。
不要把 API 直接等同于 Skill。
- 单个 API 可能只是一个 Skill 的步骤。
- 多个 API 也可能组成一个工作流型 Skill。
不要创建巨型 Skill。
- 一个 Skill 只能服务一个清晰的任务边界。
- 如果一个 Skill 需要覆盖多个业务对象，请拆分。
- 如果一个 Skill 同时包含多个风险级别，请拆分。
不要隐藏风险操作。
- 删除、发布、付款、授权、批量修改、发送消息、导出敏感数据等操作，必须设计用户确认点。
- 涉及权限、隐私、安全、审计的操作，必须标注边界。
不要一开始就改代码。
- 第一阶段只分析。
- 第二阶段输出 Skill Inventory。
- 第三阶段等待确认。
- 第四阶段才使用
skill-creator创建 Skills。
不要把大量代码复制进
SKILL.md。SKILL.md只写任务流程和使用说明。- API、Schema、业务规则写入
references/。 - 可重复执行逻辑写入
scripts/。 - 模板、样例、导入导出文件写入
assets/。
- skill-references-spec.md：references 整理规范 ```md 在创建 Skill 的 `references/` 文档时，遵循以下原则： - `SKILL.md` 保持精简。 - 复杂、详细、低频读取的信息放入 `references/`。 - 不要在 `SKILL.md` 和 `references/` 中重复大段内容。 - 引用文档要能帮助另一个 Agent 准确执行任务。 解析项目的代码实现，为每个需要引用文档的 Skill 创建或更新以下资料： 1. API 参考 - 接口路径或函数名 - 方法 - 入参 - 出参 - 错误码 - 权限要求 - 示例 2. 数据模型参考 - 表/模型名称 - 字段说明 - 关键状态字段 - 状态流转规则 - 关联关系 3. 业务规则参考 - 前置条件 - 校验规则 - 权限规则 - 风险操作 - 用户确认点 - 回滚或补偿策略 4. 工作流参考 - 多步骤流程 - 每一步依赖什么输入 - 每一步调用什么能力 - 每一步如何判断成功或失败