企业官网建设流程全解析

• 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 时，请严格遵守以下规则：

1. 不要凭空创造产品能力。

   • 所有 Skill 候选项都必须能追溯到当前代码中的页面、组件、接口、服务、模型、脚本或测试。
   • 如果只是合理推测，必须标记为“推测”。

2. 不要把 UI 操作直接等同于 Skill。

   • Skill 应该对应用户任务，而不是按钮、页面或接口。
   • 例如，“点击新建按钮”不是 Skill，“创建项目”才是 Skill。

3. 不要把 API 直接等同于 Skill。

   • 单个 API 可能只是一个 Skill 的步骤。
   • 多个 API 也可能组成一个工作流型 Skill。

4. 不要创建巨型 Skill。

   • 一个 Skill 只能服务一个清晰的任务边界。
   • 如果一个 Skill 需要覆盖多个业务对象，请拆分。
   • 如果一个 Skill 同时包含多个风险级别，请拆分。

5. 不要隐藏风险操作。

   • 删除、发布、付款、授权、批量修改、发送消息、导出敏感数据等操作，必须设计用户确认点。
   • 涉及权限、隐私、安全、审计的操作，必须标注边界。

6. 不要一开始就改代码。

   • 第一阶段只分析。
   • 第二阶段输出 Skill Inventory。
   • 第三阶段等待确认。
   • 第四阶段才使用skill-creator创建 Skills。

7. 不要把大量代码复制进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. 工作流参考 - 多步骤流程 - 每一步依赖什么输入 - 每一步调用什么能力 - 每一步如何判断成功或失败