agent-skill-orchestrator

agent-skill-orchestrator

用途

智能任务规划与资源编排引擎，可分析用户需求，并利用最佳可用资源制定战略执行计划。此技能支持自动发现、带置信度评分的智能匹配，以及生成包含多个选项和回退策略的全面计划。

编排器作为规划助手运行——它会推荐方案，但始终会在执行前请求用户明确批准。它是发现基础之上的智能层，将“我有什么”转化为“我应该如何使用”。

使用时机

在以下情况下调用此技能：

• 用户有一项需要多个步骤或资源的复杂任务
• 用户想知道解决问题的最佳方案
• 用户需要协调多个插件、Agent、技能或 MCP
• 用户希望优化任务的资源利用
• 用户不确定应使用哪些工具或方案
• 用户在实施前需要一份战略计划
• 用户想探索多种解决方案

平台支持

在所有 AI CLI 平台上的运行方式完全相同：

• Claude Code（claude）
• GitHub Copilot CLI（gh copilot）
• Gemini CLI（gemini）
• OpenCode（opencode）
• OpenAI Codex（codex）

进度跟踪

在每个编排阶段开始前显示进度：

[██░░░░░░░░░░░░░░░░░░] 15% — Step 0: Discovering Available Resources
[████░░░░░░░░░░░░░░░░] 25% — Step 1: Analyzing User Request
[████████░░░░░░░░░░░░] 45% — Step 2: Intelligent Matching & Scoring
[████████████░░░░░░░░] 65% — Step 3: Generating Execution Plan
[██████████████████░░] 85% — Step 4: Presenting Plan for Approval
[████████████████████] 100% — Step 5: Plan Approved / Execution Ready

工作流

步骤 -1：提示词质量检查（分析前）

目标： 在规划前确保用户请求清晰且结构良好。

此步骤的重要性：

• 提示词含糊 → 资源匹配效果差 → 计划质量低
• 提示词经过优化 → 需求明确 → 计划置信度高
• 减少规划迭代和“优化计划”周期

提示词质量检查： 规划前，评估用户请求是否足够具体，能否实现准确的资源匹配。如果请求少于 20 个词、缺少明确的动作动词或目标，或者只使用含糊的指代词（“这个”“它”“那个”）而没有上下文，则先调用 prompt-engineer 进行优化。经过充分优化的请求可将置信度评分提高 20–30%，并减少规划迭代。如果请求已经清晰，则直接继续。

对规划的影响：

• ✅ 置信度评分提高 20–30%
• ✅ 资源匹配更加准确
• ✅ 更好地定义成功标准
• ✅ 减少计划执行过程中的歧义

---

步骤 0：发现可用资源

目标： 获取所有已安装资源的最新清单。

关键依赖： 此技能必须先调用 agent-skill-discovery。

操作：

调用发现技能以获取完整资源目录：

# Call agent-skill-discovery skill
resources = invokeSkill("agent-skill-discovery")

预期输出：

{
  "platform": "Claude Code",
  "plugins": [
    {
      "name": "feature-dev",
      "agents": [
        {
          "name": "code-explorer",
          "description": "Analyzes existing codebase",
          "tools": ["Glob", "Grep", "Read", "Bash"]
        }
      ]
    }
  ],
  "skills": [
    {
      "name": "skill-creator",
      "description": "Creates new skills",
      "triggers": ["create a skill", "new skill"],
      "category": "development"
    }
  ],
  "mcpServers": [
    {
      "name": "claude_ai_Notion",
      "type": "stdio",
      "tools": ["notion-search", "notion-create-pages"]
    }
  ]
}

此步骤至关重要的原因：

• 确保资源可用性信息准确且为最新
• 适用于所有平台（由发现技能处理平台检测）
• 为智能匹配提供完整上下文
• 避免推荐不可用的资源

步骤 1：分析用户请求

目标： 从用户的任务描述中提取需求。

操作：

解析请求以提取：

• 任务类型——开发、内容、集成、分析、文档或规划。根据动词推断：build/create/implement → 开发；transcribe/summarize/convert → 内容；connect/sync/automate → 集成；review/debug/diagnose → 分析；document/write → 文档；design/plan/architect → 规划。
• 所需能力——代码生成、网络访问、文件处理、外部集成（检测服务名称：Notion、Jira、GitHub、Slack、Confluence、browser）。
• 关键词——提取名词和技术名称，以便与资源描述和触发词进行匹配。
• 复杂度——简单（单个工具、一个步骤）、中等（2–3 个步骤，需进行一些协调）、复杂（多阶段、步骤间存在依赖关系）。

第 2 步：智能匹配与评分

目标： 根据用户需求为发现的每项资源评分。

根据解析出的需求为每项发现的资源评分，评分维度如下：

维度	权重	评分方式
触发短语匹配	30%	资源的触发短语是否与用户关键词有重合？
语义相似度	25%	资源描述是否符合用户的目标和领域？
工具可用性	20%	资源的工具是否涵盖所需能力（网页、文件 I/O、代码、集成）？
类别相关性	15%	资源类别是否与检测到的任务类型相符？
MCP 集成加分	10%	这是否为 MCP 工具，且任务是否需要外部服务集成？

总分 = 0–100。过滤掉低于 40 分的资源。按层级分组：高置信度（≥80）、中置信度（60–79）、低置信度（40–59）。

第 3 步：生成执行计划

目标： 制定包含备选方案的战略执行计划。

构建主要策略：将高置信度资源按逻辑执行顺序排列：

1. 首先使用分析/发现资源（如果任务需要了解现有状态）
2. 中间使用实施资源（创建、构建、转换）
3. 最后使用验证/审查资源（检查、审计、确认）

构建备选策略：使用尚未纳入主要计划的中置信度资源——备选方案采用简化的两步流程即可。

提取前提条件： 对于计划中的每项 MCP 资源，添加“必须配置 MCP 服务 X。”对于每个插件 Agent，添加“必须安装插件 X。”

根据任务类型定义成功标准：

• 开发 → 代码编译无错误、测试通过、遵循项目规范
• 内容 → 输出格式符合要求，内容准确且完整
• 集成 → 外部服务成功响应，数据正确同步

第 4 步：提交计划以供批准

目标： 使用简洁的 Markdown 格式向用户展示完整计划。

输出结构：

## 📊 Discovery Analysis

**Platform:** {detected_platform}
**Task Type:** {requirements.taskType}
**Complexity:** {requirements.complexity}
**External Integrations:** {requirements.externalIntegrations.join(', ') || 'None'}

---

## 🔍 Resources Found ({total_count})

### High Confidence (80-100%)
- **{resource_name}** [{score}%] - {description}
  - **Why selected:** {reasoning}

### Medium Confidence (60-79%)
- **{resource_name}** [{score}%] - {description}

---

## ✅ Recommended Execution Plan

### Option 1: Primary Strategy (Recommended)

**Step {n}:** Use **{resource_name}** to {action}
- **Input:** {input_description}
- **Output:** {expected_output}
- **Tool:** {platform_tool_name}
- **Rationale:** {why_this_resource}

*(Repeat for each step)*

**Expected Outcome:** {final_result_description}
**Estimated Time:** {time_estimate}
**Risk Level:** {low|medium|high}

---

### Option 2: Alternative Strategy

**Step {n}:** Use **{alt_resource_name}** to {action}
- **Input:** {input_description}
- **Output:** {expected_output}
- **Rationale:** {why_this_alternative}

*(Simpler or different approach)*

---

## ⚠️ Prerequisites

Before executing this plan, ensure:

- [ ] {prerequisite_1}
- [ ] {prerequisite_2}
- [ ] {prerequisite_3}

---

## 🎯 Success Criteria

This plan will be successful when:

- [ ] {criterion_1}
- [ ] {criterion_2}
- [ ] {criterion_3}

---

## 💡 Notes

- **Parallel Execution:** Steps {x} and {y} can run in parallel
- **Fallback:** If Step {n} fails, try {alternative}
- **Dependencies:** Step {n+1} requires output from Step {n}

---

**⏸️ Awaiting your approval to proceed...**

第 5 步：请求批准

目标： 在执行前获得用户明确确认。

使用 AskUserQuestion：

AskUserQuestion({
  question: "Which execution plan would you like to proceed with?",
  header: "Plan Approval",
  options: [
    {
      label: "Execute Option 1 (Recommended)",
      description: "Primary strategy with highest confidence resources"
    },
    {
      label: "Execute Option 2 (Alternative)",
      description: "Alternative approach with different resource mix"
    },
    {
      label: "Refine plan",
      description: "Modify requirements or resource selection"
    },
    {
      label: "Cancel",
      description: "Do not execute, return to planning"
    }
  ]
});

处理响应：

• 执行选项 1/2： 按所选计划继续（第 6 步）
• 优化： 提出后续问题，重新生成计划
• 取消： 正常退出，不执行

第 6 步：执行计划（可选）

目标： 按步骤执行已批准的计划。

执行策略：

async function executePlan(approvedPlan) {
  const results = [];

  for (const step of approvedPlan) {
    console.log(`\n🔄 Executing Step ${step.number}...`);
    console.log(`   Resource: ${step.resource.name}`);
    console.log(`   Action: ${step.action}`);

    try {
      // Invoke the resource (agent, skill, or MCP tool)
      const result = await invokeResource(step.resource, step.input);

      results.push({
        step: step.number,
        status: 'success',
        output: result
      });

      console.log(`✅ Step ${step.number} completed`);

    } catch (error) {
      console.error(`❌ Step ${step.number} failed: ${error.message}`);

      // Check for fallback
      if (step.fallback) {
        console.log(`🔄 Trying fallback: ${step.fallback.resource.name}`);
        const fallbackResult = await invokeResource(step.fallback.resource, step.input);
        results.push({
          step: step.number,
          status: 'fallback',
          output: fallbackResult
        });
      } else {
        throw error; // No fallback, abort
      }
    }
  }

  return results;
}

async function invokeResource(resource, input) {
  if (resource.type === 'skill') {
    return await invokeSkill(resource.name, input);
  } else if (resource.type === 'agent') {
    return await invokeAgent(resource.name, input);
  } else if (resource.type === 'mcp') {
    return await invokeMCPTool(resource.name, input);
  }
}

进度报告：

在执行过程中显示进度：

## 🚀 Execution Progress

✅ Step 1: Completed (feature-dev:code-explorer)
🔄 Step 2: In progress (feature-dev:code-architect)
⏸️ Step 3: Pending (code-review:code-review)

**Current Output:**
{step_output_preview}

关键规则

绝不：

• ❌ 跳过首先调用 agent-skill-discovery（第 0 步为必需步骤）
• ❌ 未经用户明确批准就执行计划
• ❌ 在未说明的情况下推荐评分低于 40% 的资源
• ❌ 对平台特定逻辑进行硬编码（使用发现结果中的平台检测）
• ❌ 未检查发现结果就假定资源可用
• ❌ 在发现结果为空时不作提示（告知用户）
• ❌ 混用不同平台的资源（保持一致）
• ❌ 在生成计划时忽略用户的限制或偏好

始终：

• ✅ 在规划前评估提示词质量（第 -1 步）——v1.1.0 新增
• ✅ 如果质量评分低于 50%，调用 prompt-engineer 以获得最佳结果
• ✅ 每次调用时都从全新发现开始（第 0 步）
• ✅ 为所有建议展示置信度评分及其理由
• ✅ 在可行时提供多个选项（选项 1、选项 2）
• ✅ 在执行前清楚列出前提条件
• ✅ 定义可衡量的成功标准
• ✅ 在执行前请求明确批准（第 5 步）
• ✅ 使用发现结果中的平台适用工具名称
• ✅ 妥善处理缺失的资源（建议替代方案或中止）
• ✅ 在执行期间报告进度（如果执行到第 6 步）
• ✅ 说明选择每项资源的理由

编排原则：

• 优先发现： 未获取最新资源清单前，绝不制定计划
• 置信度透明： 始终展示评分和推理过程
• 提供多个选项： 尽可能提供替代方案
• 需要批准： 未经同意，不得自主执行
• 优雅降级： 如果主要计划失败，则尝试替代方案
• 平台无关： 在所有 5 个平台上以相同方式运行

使用示例

示例 1：功能开发

用户请求：

"Plan how to build a REST API with authentication"

编排器输出：

## 📊 Discovery Analysis

**Platform:** Claude Code
**Task Type:** development
**Complexity:** moderate
**External Integrations:** None

---

## 🔍 Resources Found (8)

### High Confidence (80-100%)
- **feature-dev:code-architect** [92%] - Designs feature architectures
  - **Why selected:** Best match for API design patterns
- **feature-dev:code-explorer** [88%] - Analyzes existing codebase
  - **Why selected:** Understands existing auth patterns
- **feature-dev:code-reviewer** [85%] - Reviews code for security
  - **Why selected:** Critical for auth security validation

### Medium Confidence (60-79%)
- **skill-creator** [65%] - Scaffolds code structures
  - Can generate boilerplate auth code

---

## ✅ Recommended Execution Plan

### Option 1: Primary Strategy (Recommended)

**Step 1:** Use **feature-dev:code-explorer** to analyze existing authentication patterns
- **Input:** Codebase context
- **Output:** Analysis of current auth implementation
- **Tool:** Read, Grep, Glob
- **Rationale:** Understand existing patterns before designing (88% match)

**Step 2:** Use **feature-dev:code-architect** to design REST API structure with auth
- **Input:** Analysis results from Step 1
- **Output:** API architecture and auth flow design
- **Tool:** Read, Write, Glob
- **Rationale:** Specialized in API design patterns (92% match)

**Step 3:** Use **skill-creator** to scaffold authentication boilerplate
- **Input:** Architecture design from Step 2
- **Output:** Auth middleware code structure
- **Tool:** Write
- **Rationale:** Generates standard auth patterns (65% match)

**Step 4:** Use **feature-dev:code-reviewer** to validate security
- **Input:** Generated auth code from Step 3
- **Output:** Security audit report
- **Tool:** Read, Grep
- **Rationale:** Critical for auth security review (85% match)

**Expected Outcome:** Secure REST API with JWT authentication, following project conventions
**Estimated Time:** ~45 minutes
**Risk Level:** Low (high confidence resources, well-defined approach)

---

### Option 2: Alternative Strategy

**Step 1:** Use **skill-creator** to scaffold complete API + auth structure
- **Input:** User requirements
- **Output:** Boilerplate API with basic auth
- **Rationale:** Faster but less customized approach

**Step 2:** Use **feature-dev:code-reviewer** to validate implementation
- **Input:** Generated code
- **Output:** Quality and security review
- **Rationale:** Ensure boilerplate meets standards

*(Simpler 2-step approach for rapid prototyping)*

---

## ⚠️ Prerequisites

- [ ] Plugin "feature-dev" must be installed
- [ ] Plugin "code-review" must be installed (for Option 1 Step 4)
- [ ] Skill "skill-creator" must be installed
- [ ] Codebase must be accessible (for pattern analysis)

---

## 🎯 Success Criteria

- [ ] REST API endpoints defined and functional
- [ ] JWT authentication implemented correctly
- [ ] Security review passes with no critical issues
- [ ] Code follows project conventions
- [ ] Tests pass for auth flows

---

## 💡 Notes

- **Parallel Execution:** Steps 3 and 4 can overlap (scaffold while reviewing)
- **Fallback:** If feature-dev:code-architect unavailable, use manual design
- **Dependencies:** Step 2 requires output from Step 1 (pattern analysis)

---

**⏸️ Awaiting your approval to proceed...**

示例 2：内容处理 + 集成

用户请求：

"Analyze this meeting recording and create Jira tickets"

发现分析：

## 📊 Discovery Analysis

**Platform:** GitHub Copilot CLI
**Task Type:** content + integration
**Complexity:** moderate
**External Integrations:** Jira

---

（计划输出遵循与示例 1 相同的结构——资源评分、主要策略 + 替代策略、前置条件、成功标准和批准提示。）

示例 3：网络研究 + 文档编写

用户请求：

"Research competitor pricing and create a Notion page"

发现分析：

## 📊 Discovery Analysis

**Platform:** Gemini CLI
**Task Type:** integration + documentation
**Complexity:** moderate
**External Integrations:** Notion, Web

---

（计划输出遵循与示例 1 相同的结构——资源评分、主要策略 + 替代策略、前置条件、成功标准和批准提示。）

示例 4：模糊提示词 → 优化计划（NEW v1.1.0）

用户请求（模糊）：

"help me with API stuff"

发现分析：

## 📊 Discovery Analysis

**Platform:** Claude Code
**Task Type:** development
**Complexity:** moderate
**External Integrations:** None

---

（计划输出遵循与示例 1 相同的结构——资源评分、主要策略 + 替代策略、前置条件、成功标准和批准提示。）