agent-skill-orchestrator

name	agent-skill-orchestrator
description	This skill should be used when the user needs to solve a complex task and wants a detailed execution plan using the best available resources. Analyzes user requirements, discovers available plugins/agents/skills/MCPs, performs intelligent matching with confidence scoring, and creates strategic execution plans with alternatives. Works across all AI CLI platforms.
license	MIT

agent-skill-orchestrator

Purpose

Intelligent task planning and resource orchestration engine that analyzes user requirements and creates strategic execution plans using the best available resources. This skill matches against the skill catalog already in the system prompt, scores options, and generates comprehensive plans with alternatives.

The orchestrator operates as a planning assistant—it recommends approaches but always requests explicit user approval before execution.

When to Use

Invoke this skill when:

• User has a complex task requiring multiple steps or resources
• User wants to know the best approach to solve a problem
• User needs coordination between multiple plugins, agents, skills, or MCPs
• User wants optimized resource utilization for a task
• User is unsure which tools or approach to use
• User needs a strategic plan before implementation
• User wants to explore multiple solution approaches

Platform Support

OLLMchat Agent Pi — skill catalog in the system prompt + Agent Pi tools.

Progress Tracking

Display progress before each orchestration phase:

[██░░░░░░░░░░░░░░░░░░] 15% — Step 0: Using Catalog Already in Context
[████░░░░░░░░░░░░░░░░] 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

Workflow

Step -1: Prompt Quality Check (Pre-Analysis)

Objective: Ensure user request is clear and well-structured before planning.

Why This Step Matters:

• Vague prompts → poor resource matching → low-quality plans
• Optimized prompts → precise requirements → high-confidence plans
• Reduces planning iterations and "Refine plan" cycles

Prompt Quality Check: Before planning, assess whether the user request is specific enough to yield accurate resource matching. If the request is fewer than 20 words, lacks a clear action verb or goal, or uses only ambiguous references ("this", "it", "that") without context, invoke prompt-engineer to refine it first. A well-refined request improves confidence scores by 20–30% and reduces planning iterations. Proceed directly if the request is already clear.

Impact on Planning:

• ✅ Confidence scores increase 20-30%
• ✅ More accurate resource matching
• ✅ Better success criteria definition
• ✅ Reduced ambiguity in plan execution

---

Step 0: Use the Skill Catalog Already in Context

Objective: Inventory skills available for matching.

Agent Pi injects an <available_skills> catalog in the system prompt ({skills_md}).

Actions:

1. Treat the skills listed in that catalog as the inventory (name + description + location).
2. Optionally read a skill’s SKILL.md from its catalog location when you need more detail for scoring.
3. Match plans to Agent Pi tools (read / write / edit / bash / browser, and others registered for the agent).

Why This Step is Critical:

• Uses the host catalog already in context
• Keeps recommendations limited to offered skills

Step 1: Analyze User Request

Objective: Extract requirements from user's task description.

Actions:

Parse the request to extract:

• Task type — development, content, integration, analysis, documentation, or planning. Infer from verbs: build/create/implement → development; transcribe/summarize/convert → content; connect/sync/automate → integration; review/debug/diagnose → analysis; document/write → documentation; design/plan/architect → planning.
• Required capabilities — code generation, web access, file processing, external integrations (detect service names: Notion, Jira, GitHub, Slack, Confluence, browser).
• Keywords — extract nouns and technology names for matching against resource descriptions and triggers.
• Complexity — simple (single tool, one step), moderate (2–3 steps, some coordination), complex (multi-phase, dependencies between steps).

Step 2: Intelligent Matching & Scoring

Objective: Score each discovered resource against user requirements.

Score each discovered resource against the parsed requirements using five dimensions:

Dimension	Weight	How to score
Trigger phrase match	30%	Does any trigger phrase from the resource overlap with the user's keywords?
Semantic similarity	25%	Does the resource description align with the user's goal and domain?
Tool availability	20%	Do the resource's tools cover the required capabilities (web, file I/O, code, integrations)?
Category relevance	15%	Does the resource category match the detected task type?
MCP integration bonus	10%	Is this an MCP tool and does the task require external service integrations?

Total score = 0–100. Filter out resources below 40. Group into tiers: high confidence (≥80), medium (60–79), low (40–59).

Step 3: Generate Execution Plan

Objective: Create strategic execution plans with alternatives.

Build the primary strategy by ordering high-confidence resources into a logical execution sequence:

1. Analysis/discovery resources first (if task requires understanding existing state)
2. Implementation resources in the middle (create, build, transform)
3. Validation/review resources last (check, audit, confirm)

Build an alternative strategy using medium-confidence resources not already in the primary plan — a simplified 2-step approach is sufficient for the alternative.

Extract prerequisites: For each MCP resource in the plan, add "MCP server X must be configured." For each plugin agent, add "Plugin X must be installed."

Define success criteria based on task type:

• development → code compiles without errors, tests pass, follows project conventions
• content → output format matches requirements, content is accurate and complete
• integration → external services respond successfully, data syncs correctly

Step 4: Present Plan for Approval

Objective: Show comprehensive plan to user in clean markdown format.

Output Structure:

## 📊 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}
 [ ] {criterion3}

---



  Steps {x} and {y} can run in parallel
  If Step {n} fails, try {alternative}
  Step {n+1} requires output from Step {n}

---

Step 5: Request Approval

Objective: Get explicit user confirmation before execution.

Ask the user in chat. Offer clear choices, for example:

• Execute Option 1 (Recommended)
• Execute Option 2 (Alternative)
• Refine plan
• Cancel

Handle Response:

• Execute Option 1/2: Proceed with selected plan (Step 6)
• Refine: Ask follow-up questions, regenerate plan
• Cancel: Exit gracefully, no execution

Step 6: Execute Plan (Optional)

Objective: Execute approved plan step-by-step.

Execution Strategy:

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: `);
         fallbackResult =  (step.., step.);
        results.({
          : step.,
          : ,
          : fallbackResult
        });
      }  {
         error; 
      }
    }
  }

   results;
}

  () {
   (resource. === ) {
      (resource., input);
  }   (resource. === ) {
      (resource., input);
  }   (resource. === ) {
      (resource., input);
  }
}

Progress Reporting:

Display progress during execution:

## 🚀 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}

Critical Rules

ALWAYS:

• ✅ Assess prompt quality before planning (Step -1)
• ✅ Call prompt-engineer if the request is too vague for matching
• ✅ Start from the system-prompt skill catalog (Step 0) on every invocation
• ✅ Show confidence scores with reasoning for all recommendations
• ✅ Provide multiple options (Option 1, Option 2) when feasible
• ✅ List prerequisites clearly before execution
• ✅ Define measurable success criteria
• ✅ Request explicit approval in chat before execution (Step 5)
• ✅ Use Agent Pi tool names (read / write / edit / bash / browser, …)
• ✅ Handle missing resources gracefully (suggest alternatives or abort)
• ✅ Report progress during execution (if Step 6 is reached)
• ✅ Explain reasoning for each resource selection
• ✅ Stay within the offered catalog; tell the user if it is empty

ORCHESTRATION PRINCIPLES:

• Catalog first: Plan from the skills already listed in context
• Confidence Transparency: Always show scores and reasoning
• Multiple Options: Provide alternatives when possible
• Approval Required: No autonomous execution without consent
• Graceful Degradation: If primary plan fails, try alternatives
• Platform Agnostic: Work identically on all 5 platforms

Example Usage

Example 1: Feature Development

User Request:

"Plan how to build a REST API with authentication"

Orchestrator Output:

## 📊 Discovery Analysis

**Platform:** Agent Pi
**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
  Read, Write, Glob
  Specialized in API design patterns (92% match)

 Use  to scaffold authentication boilerplate
  Architecture design from Step 2
  Auth middleware code structure
  Write
  Generates standard auth patterns (65% match)

 Use  to validate security
  Generated auth code from Step 3
  Security audit report
  Read, Grep
  Critical for auth security review (85% match)

 Secure REST API with JWT authentication, following project conventions
 ~45 minutes
 Low (high confidence resources, well-defined approach)

---



 Use  to scaffold complete API + auth structure
  User requirements
  Boilerplate API with basic auth
  Faster but less customized approach

 Use  to validate implementation
  Generated code
  Quality and security review
  Ensure boilerplate meets standards



---



 [ ] 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)

---



 [ ] 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

---



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

---

Example 2: Content Processing + Integration

User Request:

"Analyze this meeting recording and create Jira tickets"

Discovery Analysis:

## 📊 Discovery Analysis

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

---

(Plan output follows the same structure as Example 1 — resource scoring, primary + alternative strategies, prerequisites, success criteria, and approval prompt.)

Example 3: Web Research + Documentation

User Request:

"Research competitor pricing and create a Notion page"

Discovery Analysis:

## 📊 Discovery Analysis

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

---

(Plan output follows the same structure as Example 1 — resource scoring, primary + alternative strategies, prerequisites, success criteria, and approval prompt.)

Example 4: Vague Prompt → Optimized Plan (NEW v1.1.0)

User Request (Vague):

"help me with API stuff"

Discovery Analysis:

## 📊 Discovery Analysis

**Platform:** Agent Pi
**Task Type:** development
**Complexity:** moderate
**External Integrations:** None

---

(Plan output follows the same structure as Example 1 — resource scoring, primary + alternative strategies, prerequisites, success criteria, and approval prompt.)