How Subagent Skills in Reasonix Inherit Models and Execute Their Tasks

Subagent skills in Reasonix inherit model settings through the Skill struct's Model and Effort fields parsed from Markdown front-matter, then execute in isolated child loops via the SubagentRunner interface which receives the complete skill configuration.

The DeepSeek-Reasonix repository implements a modular skill system where specialized tasks can be delegated to subagent skills. These subagent skills operate in isolated execution contexts while inheriting model configurations defined in their front-matter, allowing precise control over which LLM handles specific subtasks.

Declaring a Subagent Skill

A subagent skill is identified by the front-matter key runAs: subagent. The optional model: and effort: fields allow authors to specify exactly which LLM and effort level the isolated child loop should use.

---
name: deepsearch
description: run a deep-search with a specific LLM
runAs: subagent
model: deepseek-pro
effort: max
---

<skill body …>

According to the source code in internal/skill/skill.go, the Skill struct records these fields at lines 55-68. The Model and Effort fields are populated when the skill is parsed, ensuring the configuration travels with the skill throughout its lifecycle.

Loading and Parsing Skills

When Reasonix starts, the Store scans skill directories (project, custom, global, and builtin) and builds a Skill instance for every Markdown file containing valid front-matter. If runAs is set to subagent, the Skill retains its Model and Effort values unchanged.

The discovery logic in internal/skill/skill.go (lines 82-95) parses the front-matter and explicitly populates Skill.RunAs, Skill.Model, and Skill.Effort. This ensures that every subagent skill carries its own model configuration from the moment it is loaded into memory.

Executing the Skill via run_skill

The generic tool run_skill serves as the entry point for both inline and subagent skills. Implemented in internal/skill/tools.go, the Execute method inspects the Skill value and branches based on the RunAs field.

func (t *runSkillTool) Execute(ctx context.Context, args json.RawMessage) (string, error) {
    // … parsing omitted …
    if sk.RunAs == RunSubagent {
        if t.runner == nil {
            return "", fmt.Errorf("run_skill: skill %q is runAs=subagent but no subagent runner is configured in this session", name)
        }
        if rawArgs == "" {
            return "", fmt.Errorf("run_skill: skill %q is a subagent and requires 'arguments' — the subagent has no other context, so describe the concrete task", name)
        }
        return t.runner(ctx, sk, rawArgs, opts)   // ← sub-agent execution
    }
    // Inline path falls through to renderInline(...)
}

As shown in lines 76-108 of internal/skill/tools.go, when sk.RunAs equals RunSubagent, the method delegates to the configured SubagentRunner, passing the complete Skill object including its model settings.

Model Inheritance Through SubagentRunner

The SubagentRunner interface defines the contract for subagent execution:

type SubagentRunner func(ctx context.Context, sk Skill, task string, opts SubagentRunOptions) (string, error)

Defined in internal/skill/tools.go (lines 20-30), this runner receives the full Skill object, including any Model and Effort values parsed from front-matter. The host implementation (typically provided by the UI or command-line interface) handles the actual execution:

1. Creates a child loop using the skill body (sk.Body) as the system prompt.
2. Selects the model: If sk.Model is non-empty, that model name is used; otherwise, the runner falls back to a default host configuration.
3. Applies effort: The same precedence rule applies to sk.Effort.
4. Runs the task in isolation, returning only the final answer to the parent context.

The runner may also consult an optional ProfileResolver (referenced in lines 15-33) to compute dynamic profiles, but the explicit Model and Effort fields on the Skill struct take precedence when present.

Built-in Subagent Wrappers

Reasonix ships with built-in subagent skills including explore, research, review, and security_review. These are wrapped by tools constructed in BuiltinSubagentTools within internal/skill/tools.go (lines 62-73 and 86-103).

func BuiltinSubagentTools(store *Store, runner SubagentRunner, profileResolver ...ProfileResolver) []tool.Tool {
    // … iterate over builtin specs …
    out = append(out, &subagentSkillTool{
        toolName:    s.toolName,
        skillName:   s.skillName,
        description: s.description,
        taskDesc:    s.taskDesc,
        store:       store,
        runner:      runner,
        profile:     pr,
    })
}

These wrappers automatically inherit the model and effort declared in the underlying skill file. Because they pass the same Skill struct to the SubagentRunner, the inheritance rules remain consistent whether invoking a built-in wrapper or calling run_skill directly.

Summary

• Front-matter declaration: Subagent skills use runAs: subagent with optional model: and effort: fields defined in internal/skill/skill.go.
• Skill loading: The Store in internal/skill/skill.go (lines 82-95) parses these fields into the Skill struct, preserving model configuration.
• Execution branching: The run_skill tool in internal/skill/tools.go (lines 76-108) detects subagent mode and delegates to the SubagentRunner.
• Model inheritance: The SubagentRunner receives the complete Skill object and uses sk.Model and sk.Effort when creating the isolated child LLM loop.
• Built-in consistency: Wrapper tools like explore and research use the same inheritance mechanism by passing their Skill configuration to the shared runner.

Frequently Asked Questions

How do I specify a custom model for a subagent skill?

Add the model: key to the skill's front-matter. For example, model: deepseek-pro tells the SubagentRunner to use that specific model when creating the child execution loop. This value is stored in the Skill.Model field as defined in internal/skill/skill.go.

What happens if a subagent skill doesn't define a model?

If the model: field is empty in the skill's front-matter, the SubagentRunner implementation falls back to a default model configured by the host application. The runner checks sk.Model first, then uses the host default if the field is blank.

How do built-in skills like explore handle model inheritance?

Built-in skills such as explore declare their model preferences in their Markdown definition files. The BuiltinSubagentTools function wraps these skills but still passes the complete Skill struct (including Model and Effort) to the SubagentRunner, ensuring they inherit their preferred configuration while using the same execution path as custom skills.

Can subagent skills access the parent context?

No. Subagent skills execute in isolated child loops with no access to the parent's conversation history or tool state. As enforced in internal/skill/tools.go, the caller must provide all necessary context via the arguments parameter, which becomes the task description for the subagent. The subagent returns only its final answer to the parent.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}