9thlevelsoftware/legion/cli-dispatch

Step 1: Enumerate adapter files
  - List all files in the adapters/ directory matching *.md (exclude ADAPTER.md)
  - For each adapter file, attempt to parse its YAML frontmatter
 
Step 2: Parse Dispatch Configuration block
  - In each adapter file, locate the section: ## Dispatch Configuration
  - Within that section, find a fenced yaml block (```yaml ... ```)
  - Parse the block. If no Dispatch Configuration section exists, skip this adapter.
  - Required fields in the dispatch config:
      available: true | false
      capabilities: [list of capability strings]
      detection_command: string (e.g., "gemini --version")
      invoke_command: string (e.g., "gemini")
      invoke_flags: string (e.g., "--model pro")
      prompt_delivery: file_path | stdin_pipe | content_flag
      prompt_flag: string (e.g., "-f" or "--prompt") — required when prompt_delivery is file_path or content_flag
      result_path: string with {task-id} placeholder (e.g., ".planning/dispatch/{task-id}-RESULT.md")
      timeout_ms: integer (e.g., 120000)
 
Step 3: Filter to available adapters
  - Discard any adapter where available: false
  - The remaining list is the dispatch candidate set
 
Step 4: Check installation for each candidate
  - Run the adapter's detection_command using Bash tool
  - If exit code is 0: CLI is installed and available
  - If exit code is non-zero or command not found: CLI is not installed — remove from candidate set
  - Log result: "CLI {cli_display_name}: available" or "CLI {cli_display_name}: not installed (skipped)"
 
Step 5: Cache detection results
  - Store detection results in a session variable: dispatch_available_clis
  - Do NOT re-run detection_command on subsequent dispatches in the same session
  - The cache is session-scoped — it resets when the CLI session ends
  - If the cache already exists when this skill is invoked, skip Steps 3-4 and use cached results

Input:
  task: {
    task_type: string (one or more from capability vocabulary)
    languages: [list]        — optional, from plan or agent frontmatter
    frameworks: [list]       — optional
    division: string         — optional (Engineering, Design, Testing, etc.)
    description: string      — free text task description
  }
  candidate_clis: list of available CLIs from Section 1
 
Output: best-fit CLI dispatch config, or null (internal fallback)
 
Matching algorithm (priority order):
 
Priority 1: Exact capability match
  - For each candidate CLI, check if its capabilities list contains the task's task_type exactly
  - If exactly one CLI matches: select it
  - If multiple CLIs match: rank by number of matching capabilities (most matches wins)
  - If still tied: prefer the first match in adapter file order
 
Priority 2: Category match
  - Use the division → capability affinity table below to map task division to related capabilities
  - If no exact match was found, check if any CLI's capabilities include an affinity capability for the task's division
  - If a match is found: select it (with a note that this is a category match, not exact)
 
  Division → Capability Affinity:
  | Division          | Affinity Capabilities                              |
  |-------------------|----------------------------------------------------|
  | Engineering       | code_implementation, refactoring, bug_fixing       |
  | Design            | ui_design, ux_research                             |
  | Testing           | testing, code_review, performance_analysis         |
  | Marketing         | documentation, web_search                          |
  | Product           | documentation, ux_research                         |
  | Project Management| documentation, large_analysis                      |
  | Support           | large_analysis, security_audit, documentation      |
  | Spatial Computing | code_implementation, ui_design                     |
  | Specialized       | large_analysis, code_review                        |
 
Priority 3: Internal fallback
  - If no candidate CLI matched via Priority 1 or Priority 2, or if the candidate set is empty:
    Return null — the calling skill falls back to internal agent execution
  - Log: "No external CLI matched task type '{task_type}' in division '{division}'. Using internal agent."

For each dispatched task, assemble a prompt from these parts:
 
Part 1: Agent personality
  - Identify the assigned agent from the plan or task
  - **Resolve AGENTS_DIR first** via workflow-common-core Agent Path Resolution Protocol.
    Do NOT use a bare `agents/{agent-id}.md` path — installations outside the project
    root (global npm install at `~/.claude/agents/`) will fail with that path.
  - Read the ENTIRE agent .md file: `{AGENTS_DIR}/{agent-id}.md`
  - Capture as PERSONALITY_CONTENT
  - If no agent-id is assigned (autonomous task): PERSONALITY_CONTENT = ""
 
Part 2: Task description
  - Use the task description from the plan file (objective + tasks sections)
  - Or, for board meeting dispatches: use the board topic and discussion question
  - Capture as TASK_DESCRIPTION
 
Part 3: Result contract
  - Build instructions telling the CLI to write its output to {result_path}
  - Resolve {task-id} in the adapter's result_path before injecting
  - Specify the required output format (see Result Contract Format below)
  - Capture as RESULT_INSTRUCTION
 
Part 4: Control mode scope
  - Based on the current control_mode setting, inject file scope constraints
  - See Section 6 for mode-specific scope text
  - Capture as CONTROL_SCOPE
 
Part 5: Handoff context (optional)
  - If this task depends on prior wave outputs, extract and inject handoff context
  - Follow the same protocol as wave-executor Section 5.6
  - Capture as HANDOFF_CONTEXT (empty string if no prior wave)
 
Part 6: Model tier resolution
  - Read `model_tier` from the agent's frontmatter (in the .md file opened in Part 1).
    Valid values: `planning`, `execution`, `check`. Default if absent: `execution`.
  - Map to adapter model:
    - `planning`  → adapter.model_planning
    - `execution` → adapter.model_execution
    - `check`     → adapter.model_check
  - Capture as RESOLVED_MODEL.
  - When constructing the dispatch command in Section 4, substitute `{model}` (not
    hardcoded `{model_execution}`) with RESOLVED_MODEL. Adapter spawn rows MUST use
    the generic `{model}` placeholder to honor per-agent tier selection.
  - If this task depends on prior wave outputs, extract and inject handoff context
  - Follow the same protocol as wave-executor Section 5.6
  - Capture as HANDOFF_CONTEXT (empty string if no prior wave)
 
Assemble the final prompt using this exact template:
 
---
{PERSONALITY_CONTENT}
 
---
 
# Dispatch Task
 
You are executing a task as part of Legion, dispatched to an external CLI.
 
{HANDOFF_CONTEXT}
 
{CONTROL_SCOPE}
 
## Task
 
{TASK_DESCRIPTION}
 
{RESULT_INSTRUCTION}
---
 
Result Contract Format (injected as RESULT_INSTRUCTION):
 
---
## Result Instructions
 
When you complete this task, write your result to: {resolved_result_path}
 
Your result file MUST contain these sections:
- **Status**: Complete | Complete with Warnings | Failed
- **Summary**: What you did (2-4 sentences)
- **Outputs**: List of files created or modified (or "None")
- **Findings**: Key findings, decisions, or recommendations
- **Issues**: Any problems encountered (or "None")
- **Errors**: Error details if failed (or "None")
 
Do not write anything to stdout — write the full result to the file above.
---

Step 1: Write the prompt to disk (audit trail)
  - Resolve the task ID for this dispatch. If not provided, generate one:
    Format: {phase}-{plan}-{timestamp}  e.g., "04-02-1710000000"
  - Write the prompt to: .planning/dispatch/{task-id}-PROMPT.md
  - Create the .planning/dispatch/ directory if it does not exist
  - This file is the permanent audit record. Do not skip this step.
 
Step 2: Resolve the result path
  - Take the adapter's result_path value
  - Replace {task-id} with the actual task ID
  - Example: ".planning/dispatch/{task-id}-RESULT.md" → ".planning/dispatch/04-02-1710000000-RESULT.md"