152 lines
5.2 KiB
Markdown
152 lines
5.2 KiB
Markdown
---
|
||
name: epee-orchestrator
|
||
phases: ["all"]
|
||
description: >-
|
||
EPEE Skill Orchestrator：元层调度系统。检测任务是否可由已有 Skill 处理并分流，
|
||
或发现 Skill 缺口并引导创建新 Skill。当 Agent 遇到手动配置密集、重复模式明确、
|
||
手工指引过长的任务时触发。也用于 Skill Registry 的维护和同步。
|
||
---
|
||
|
||
# EPEE Skill Orchestrator
|
||
|
||
元层调度系统，负责 Skill 分流、缺口发现和 Registry 维护。
|
||
|
||
## 操作 A：Skill 分流（匹配已有 Skill）
|
||
|
||
### 流程
|
||
|
||
```
|
||
1. 读取 registry.md 获取所有已注册 Skill 的摘要
|
||
2. 将当前任务特征与每个 Skill 的"触发场景"关键词匹配
|
||
3. 如果匹配到：
|
||
a. 告知用户"此任务可以通过 [Skill名] 高效完成"
|
||
b. 简述该 Skill 的能力及与当前任务的契合点
|
||
c. 用户确认后，读取并激活对应 Skill 的 SKILL.md
|
||
```
|
||
|
||
### 匹配规则
|
||
|
||
- 优先匹配触发场景关键词与当前任务描述的交集
|
||
- 如有多个 Skill 匹配，按相关度排序推荐，由用户选择
|
||
- `deferred-decisions` 等标记为"基础设施"类型的 Skill 不参与任务分流匹配，
|
||
仅作为 Orchestrator 的下游工具使用
|
||
|
||
## 操作 B：Skill 缺口发现 + 创建引导
|
||
|
||
### 触发条件
|
||
|
||
操作 A 未找到匹配的 Skill，且当前任务满足"Skill 创建价值判断标准"中至少 2 条。
|
||
|
||
### 流程
|
||
|
||
```
|
||
1. 向用户提出建议：
|
||
"这类任务可以通过创建一个 [建议 Skill 名] 来自动化"
|
||
2. 给出 1-3 句方案概要：
|
||
- 这个 Skill 会做什么
|
||
- 核心工作机制
|
||
- 预估能节省的重复劳动
|
||
3. 询问用户选择：
|
||
a) "继续讨论并创建" → 进入创建流程
|
||
b) "以后再说" → 进入延期记录流程
|
||
c) "不需要" → 结束，正常执行当前任务
|
||
```
|
||
|
||
### a) 创建流程
|
||
|
||
```
|
||
1. 按 Skill 创建标准流程完成 Discovery → Design → Implementation → Verification
|
||
2. 将以下上下文纳入考量：
|
||
- 触发创建的原始任务描述
|
||
- Orchestrator 的方案概要
|
||
- 建议的 Skill 名称
|
||
3. 创建完成后，要求用户对新 Skill 进行实际测试
|
||
4. 测试通过后，执行操作 C 同步 Registry
|
||
5. 【强制】执行操作 D——运行 Layer 1 静态检查，确保所有耦合点已同步
|
||
→ 全部通过则创建流程完成
|
||
→ 有 FAIL 则回到对应步骤修复后重新运行
|
||
```
|
||
|
||
### b) 延期记录流程
|
||
|
||
```
|
||
1. 读取 deferred-decisions Skill（路径: .opencode/skills/deferred-decisions/SKILL.md）
|
||
2. 按其"操作 A：记录延期方案"流程，将 Skill 创建建议记录为 deferred item
|
||
3. tags 中包含 "skill-creation" 和相关领域标签
|
||
4. context 中记录方案概要，便于未来回忆
|
||
```
|
||
|
||
## 操作 C：Registry 同步
|
||
|
||
### 触发条件
|
||
|
||
- 新 Skill 被创建后
|
||
- 已有 Skill 的 SKILL.md 被实质性修改后（如能力范围变化、触发场景变化）
|
||
|
||
### 流程
|
||
|
||
```
|
||
1. 读取目标 Skill 的 SKILL.md
|
||
2. 从 frontmatter 提取 name 和 description
|
||
3. 从正文提取核心能力和触发场景关键词
|
||
4. 读取 registry.md
|
||
5. 新增或更新对应条目，遵循 registry.md 中定义的条目格式
|
||
6. 写回 registry.md
|
||
```
|
||
|
||
### 条目格式
|
||
|
||
参见 [registry.md](registry.md) 中的条目结构。
|
||
|
||
## 操作 D：耦合点完整性验证
|
||
|
||
### 触发条件
|
||
|
||
- 操作 A（Skill 创建）完成后
|
||
- 操作 C（Registry 同步）后
|
||
- 任何 Skill 的 SKILL.md 被实质性修改后
|
||
- 用户说"验证 Skill 耦合"、"检查 Skill 是否同步"
|
||
|
||
### 流程
|
||
|
||
```
|
||
1. 运行 Layer 1 静态检查：
|
||
python .opencode/skills/skill-tester/static-checks/run.py
|
||
|
||
2. 全部 PASS（退出码 0）：
|
||
→ 告知用户"所有耦合点已同步，7/7 通过"
|
||
|
||
3. 有 FAIL（退出码非 0）：
|
||
→ 逐条展示失败项
|
||
→ 根据提示定位缺失的同步点（manifest / init / registry / SKILL.md frontmatter）
|
||
→ 修复后重新运行，直到全部通过
|
||
```
|
||
|
||
## Skill 创建价值判断标准
|
||
|
||
当操作 A 无匹配时，Agent 使用以下标准评估是否建议创建新 Skill。
|
||
满足 **2 条及以上** 即认为值得建议：
|
||
|
||
1. **频次**：该类任务预计会出现 3 次以上
|
||
2. **模式明确**：任务有明确的输入/输出模式（输入 X → 产出 Y）
|
||
3. **步骤繁多**：手动操作步骤 >= 5 步，或涉及 >= 3 个文件的协调修改
|
||
4. **易错**：存在容易出错的重复性操作（如 GUID 填写、格式对齐等）
|
||
5. **可自动化**：可以通过生成 DSL / YAML / 配置文件来替代手动操作
|
||
|
||
不满足标准时，Agent 正常执行任务，不提出创建建议。
|
||
|
||
## 与其他系统的协作
|
||
|
||
| 系统 | 关系 | 说明 |
|
||
|------|------|------|
|
||
| `deferred-decisions` Skill | 下游工具 | 操作 B 延期记录的执行者 |
|
||
| AGENTS.md | 规则来源 | Skill 自迭代和 Registry 同步的强制要求由 AGENTS.md 定义 |
|
||
|
||
## 自迭代日志
|
||
|
||
本节记录使用本 Skill 过程中发现的必要检查项。
|
||
|
||
### 已知必要检查
|
||
|
||
1. **收尾动作级联遗漏** — 当 Agent 遗漏了一个收尾动作（如 changelog 写入）后，后续的收尾动作（自迭代、Registry 同步）也会被一并遗漏，因为它们都在同一个"收尾阶段"。AGENTS.md 中的 Checklist 化设计可以打断这种级联——每项独立检查，不依赖前一项的执行记忆。
|