Architectural Analysis of Claude Code Skill Routing and Execution

Tool Scheema and Invocation Definition

The specialized task routing mechanism is implemented as a dedicated function-calling tool. The underlying JSON schema defines a strict contract for dispatching domain-specific operations, requiring a target identifier and accepting an optional parameter string.

{
  "tool_name": "SkillDispatcher",
  "tool_description": "Routes user requests to predefined operational modules. Detects slash commands or implicit task requirements, then triggers the corresponding execution pipeline.",
  "parameters": {
    "type": "object",
    "required": ["target_module"],
    "additionalProperties": false,
    "properties": {
      "target_module": {
        "type": "string",
        "description": "Identifier for the operational module (e.g., 'code-review', 'doc-sync')"
      },
      "execution_params": {
        "type": "string",
        "description": "Optional runtime arguments passed to the target module"
      }
    }
  }
}

Routing Directives and Behavioral Constraints

The system prompt enforces a strict execution protocol to prevent hallucination and ensure deterministic tool usage. The directive follows a structured pattern: operational context, trigger conditions, invocation syntax, and hard constraints.

Core Execution Rules

  • Immediate Dispatch: When a matching module is identified, the tool must be invoked as the primary action. Textual acknowledgments without tool execution are strictly prohibited.
  • Pre-Execution Validation: The model must verify the current conversation state. If a <module-tag> element is already present in the active turn, the routing step must be skipped to prevent recursive invocation.
  • Scope Boundaries: The tool is exclusively reserved for user-defined modules. Built-in terminal commands (e.g., /help, /reset) must be processed through native handlers.

The instruction block heavily utilizes imperative syntax and explicit negative constraints to override the model's tendency toward conversational filler. By framing tool execution as a BLOCKING_REQUIREMENT, the prompt ensures the LLM prioritizes API calls over natural language generation.

Two-Phase Execution Pipeline

Slash command resolution is decomposed into two sequential payload injections rather than a single synchronous operation:

  1. Signal Injection: A metadata block containing the command identifier is appended to the conversation history.
{
  "role": "user",
  "content": [
    {
      "type": "text",
      "text": "<command-label>tr:code-review</command-label>\n<module-tag>/tr:code-review</module-tag>"
    }
  ]
}
  1. Module Payload Delivery: The actual instruction set is injected as a separate message block immediately following the signal.
{
  "role": "user",
  "content": [
    {
      "type": "text",
      "text": "MODULE_CONTENT_PLACEHOLDER"
    }
  ]
}

This separation allows the routing layer to intercept the command tag, validate state, and then feed the full operational guidelines to the model in a controlled sequence.

Directory Structure and Path Resolution

Operational modules can bundle auxiliary assets within a standardized directory hierarchy. The framework avoids hardcoded absolute paths by dynamically injecting the module root into the prompt context.

.claude
└── modules
    └── code-review
        ├── analysis
        │   └── validate.sh
        └── MODULE.md

The MODULE.md file defines execution parameters using YAML frontmatter:

---
identifier: code-review
summary: Automated static analysis for pull requests
execution_mode: synchronous
---
Execute: analysis/validate.sh --verbose

When triggered, the framework constructs a prompt that explicitly declares the working directory:

Module root: /workspace/.claude/modules/code-review

Execute: analysis/validate.sh --verbose

Relative path resolusion is entirely delegated to the LLM's file system reasoning capabilities. The system relies on the injected base directory string to ground path inference, introducing a dependency on the model's contextual accuracy.

Subagent Context Behavior and Isolation

The configuration flag context: fork implies duplication of the primary conversation state. Empirical packet analysis reveals a different architectural reality. Enabling this flag spawns an isolated execution environment with a clean context window.

{
  "model_version": "claude-3.5-sonnet-20241022",
  "message_history": [
    {
      "role": "user",
      "payload": "Module root: /workspace/.claude/modules/code-review\n\nExecute: analysis/validate.sh --verbose"
    },
    {
      "role": "assistant",
      "payload": [
        {
          "type": "reasoning_trace",
          "content": "Evaluating execution environment. Base directory confirmed. Preparing to launch validation script in isolated context."
        },
        {
          "type": "tool_invocation",
          "tool_id": "exec_9x2m4p",
          "tool_name": "Terminal",
          "parameters": {
            "cmd": "bash /workspace/.claude/modules/code-review/analysis/validate.sh --verbose",
            "timeout_ms": 5000
          }
        }
      ]
    }
  ]
}

The subagent does not inherit prior conversation turns or cached state from the primary session. Instead, it receives only the module definition and its immediate parameters. This design choice prioritizes execution safety and deterministic output over contextual continuity.

Architectural Characteristics

  • Minimalist Routing: The system operates as a prompt-based dispatcher rather than a complex orchestration engine. State management relies on simple XML-style tags to prevent execution loops.
  • Dynamic Path Grounding: File system interactions are resolved through injected directory strings. This reduces configuration overhead but shifts path validation responsibility to the model.
  • Strict Context Isolation: Subagent execution environments are spawned as independent instances. No conversation history, memory state, or temporary variables are propagated from the parent session.
  • Structural Limitations: The absence of shared memory between parent and child agents restricts complex multi-step workflows. Operational modules must be entirely self-contained or rely on external persistence mechanisms for state synchronization.

Tags: claude-code agent-routing prompt-engineering function-calling subagent-context

Posted on Sat, 16 May 2026 08:03:30 +0000 by richard-elland