google-gemini / google-gemini/gemini-cli

Standardizing Reusable Intelligence: A Native "Sub-agent" and "Skills" Architecture

Open
#15,670 1 comment 0 reactions 0 assignees View on GitHub
🔒 maintainer only area/agent kind/enhancement priority/p2 status/bot-triaged workstream-rollup
Dominant language
TypeScript
Stars
107k
Forks
14.6k
Avg merge
2d 3h
Merged PRs (30d)
45

Description

### What would you like to be added?

Proposed Architecture: Domain-Specific Sub-Agents (The "Squad" Model)

I propose implementing a Sub-Agent / Expert System where the Main Agent acts as an Orchestrator/Product Manager, delegating tasks to specialized, transient experts.

Instead of one generic agent, the CLI should support Specialized Experts with distinct toolsets and system prompts:

The Frontend Expert: Pre-loaded with design system context, Tailwind/CSS docs, and browser-testing tools.

The Backend Expert: Pre-loaded with API schemas, database connectors, and security guidelines.

The DevOps Expert: Pre-loaded with Docker/K8s context and deployment keys.

How it works technically:

Delegation: The Main Agent recognizes a task (e.g., "Fix the API endpoint") and spawns the Backend_Expert.

Isolation: The Backend_Expert runs in a clean, isolated loop. It does not see the clutter of previous frontend CSS errors. It focuses purely on the Node.js/SQL logic.

Return: Once the task is done, it kills the loop and returns a sanitized result to the Main Agent.

### Why is this needed?

The "Generalist" Limitation in Complex Workflows Currently, the Gemini CLI operates as a single "Generalist" agent. While capable, this architecture struggles with Context Drift during full-stack development.

If I ask the CLI to build a feature, it must simultaneously hold context for React components (Frontend), Node.js logic (Backend), and SQL schemas (Database).

The Problem: As the context grows, the model "hallucinates" relationships between these distinct layers (e.g., trying to use a frontend CSS class in a backend logic check).

The Inefficiency: We are forcing a single prompt to be a "Jack of all trades," leading to degraded performance in every specific domain.

The Reality: In real-world engineering, we don't expect one developer to perfectly context-switch between CSS pixel-pushing and database indexing in seconds. We use specialized roles.

Furthermore, without this architecture, "Reusable Intelligence" is impossible. I cannot currently save and reuse a "Frontend Expert" configuration; I have to manually prompt the generic agent every time.

### Additional context

Why this is irresistible (The Business Case):

Code Quality: "Experts" make fewer mistakes because their context is pure and domain-specific.

Competitive Parity: Tools like Claude Code are effectively simulating this "Senior Engineer" behavior. To stay competitive, Gemini CLI must adopt this Reusable Intelligence (RI) pattern—where users can share and import "Experts" (e.g., downloading a gemini-expert-angular package) rather than just raw prompts.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.