The Problem of OpenCode Skills Not Invoking Sub-agents

I’ve been using OpenCode for my daily coding recently.
OpenCode supports both skills and sub-agents, and I enjoy building a system that advances software development by effectively utilizing these elements.
Furthermore, the ability to create an efficient workflow within projects by accurately defining these skills and sub-agents will become a required skill for future software developers.

Are sub-agents really automatically called at the right time without instructions?

To cut to the chase, this doesn’t seem to be working well.
At least in my usual environment (OpenCode), I didn’t feel they were called automatically.
From what I can see, the orchestrator seems to handle each task directly without any specific input from me.

Specifying Sub-agents to Be Executed Within Skills

So, how do we address this? I found that specifying sub-agents within skills leads to more accurate assignment of tasks to the appropriate sub-agents.

For example, the beginning of the new feature implementation skill looks like this:

---
name: feature-implementation
description: Defines the entire process for adding or modifying features. The orchestrator directly handles background organization and design, while implementation is delegated to task agents by splitting into tickets. Covers overall checks, code reviews, security checks, commits, and PR creation.
---

When receiving a request for a new feature or modification, follow the steps in this skill.

When this skill is executed, actively use the defined sub-agents.
In particular,
* Design: solution-architect
* Code review: code-reviewer
* Database review: database-reviewer
* Documentation update: documentation-manager
* Rails coding: rails-implementer
* Frontend coding: frontend-implementer
* Security review: security-auditor
* Testing: test-engineer
* Git/Github operations: repository-operator

are recommended.
Also, start other agents as needed.
Each sub-agent should use the model defined within its own sub-agent.


**If there are any unclear points regarding the request content, requirements, or design intent during each phase, ask the user for clarification before proceeding.** Proceeding with assumptions can cause rework, so always confirm unclear points.

(Excerpt)

```
Clarification of background and purpose
  ↓
Consideration of ideal vs. reality → Final decision
  ↓
Requirement gathering
  ↓
Current situation investigation (code, libraries, existing UI/UX)
  ↓
Design guidelines (request to design sub-agent) → Interface design (request to design sub-agent) → Internal design (request to design sub-agent) → DB design (request to design sub-agent)
  ↓
Ticket splitting and execution plan creation (request to design sub-agent)
  ↓
Branch creation (request to repository sub-agent)
  ↓
Delegation to task agents (control parallel/serial based on dependencies)
  ↓  Internal loops in each agent: (all requests to Rails implementer and visual view sub-agents)
  ↓  Implementation → Static analysis → Related tests → Self-review → Functionality check ↺
  ↓
Completion verification (all tickets)
  ↓
Overall check: Type check → Rubocop → Security scan → All tests
  → System test → Code review (request to code review sub-agent) → Sensitive information scan → Security review (request to security audit sub-agent)
  ↓  If there are issues, create a correction ticket and return to delegation (main loop)
Confirmation of requirement fulfillment
  ↓  If not fulfilled, create a ticket and return to delegation (main loop)
Commit → Push → PR creation → Report (request to repository sub-agent)
```
（Continued）

It would be nice if it could make decisions on its own, but for now, I’m proceeding with this approach.

In practice, this is how it works.

After setting this up, each reviewer now runs in parallel as a sub-agent.

Costs

I divide the models used by each agent according to the sub-agent’s area of responsibility.
Simply put,

• Design and reviews use GPT 5.6 Sol
• Documentation maintenance uses GPT 5.6 Terra
• Implementation uses DeepSeekV4 flash

This way, high-capacity models handle the entry (design) and exit (review) processes, while cheaper and faster models like DeepSeekV4 handle the intermediate tasks.
I believe this approach saves both time and money compared to using GPT alone with Codex.
I think this capability is a strength of tools like OpenCode that can handle various models.