mirror of
https://github.com/cline/cline.git
synced 2026-10-25 10:26:36 +08:00
db0be4c3fa
* docs: match the CLI automation pages to the CLI The scheduling, teams, subagents, connector and sample pages told readers to run commands and flags the CLI doesn't have, and the samples downloaded files that are gone. - Scheduling: `executions` is `history`; `--workspace` is required; provider and model are separate flags; the other create options, subcommands and cron names are listed. Routing results now names the chat with `--delivery-thread` or `/schedule create` in the chat. A schedule with only `--delivery-bot` never posts anything. - Teams: start with `/team` and resume with `cline --id`, not the hidden `--team-name`; there is no `--no-teams`; state is in teams.db. The SDK teams guide gets the same CLI fix. - Subagents: the page described the old read-only research tool. `spawn_agent` subagents can edit files and run commands without further approval, run in the CLI and Desktop only, and are turned off with the `spawn_agent` tool. - Connectors: gchat, WhatsApp and Linear flag names; Discord tools are on by default. - Samples: inline the scripts whose download links 404; filter `run_result` for the final answer; `cline auth` needs `--modelid`; current model ids and prices; the issue responder runs Cline with a read-only token and posts from a second job, like the PR reviewer. Part of #14853. Co-authored-by: Harshil Mistry <125483347+harshil-mistry@users.noreply.github.com> * docs: check commenter permission, fail scripts on failed runs The @cline issue responder admitted any OWNER, MEMBER or COLLABORATOR, and organization members or collaborators with read access pass that check. A secret-free authorize job now looks up the comment author's repository permission and lets the analyze job run only for write or admin. It checks the comment's author rather than the actor, so editing someone else's comment doesn't start Cline on their text. The analyze job also stops setting CLINE_DIR from runner.temp, which isn't available at job level. Plan mode removes the editing tools and refuses common file-changing commands, but python -c and node -e still write files. The scheduling and subagent pages now say so instead of promising that Plan runs can't edit files. When a run fails, the CLI exits 1 but run_result still carries the error text, so jq prints it and the pipeline succeeds. The orchestration scripts now use set -euo pipefail, wait on each background review by PID, remove output files from earlier runs and name their inputs instead of globbing. analyze-issue.sh sets pipefail. The PR review pattern names the pull requests the sample skips. * docs: wait on saved review PIDs, list the current team tools The parallel review samples waited on $(jobs -p). Bash 3.2, the macOS /bin/bash, leaves finished jobs out of that list, so a review that failed fast was never waited on and the next model read an empty review. Save $! after each background pipeline and wait on those PIDs. The SDK teams guide listed team_delegate_task, team_check_status and team_get_result, which no longer exist, and a JSON layout under ~/.cline/data/teams/. List the tools in TEAM_TOOL_NAMES and say that team state is in ~/.cline/data/db/teams.db, keyed by session and restored when the session resumes. --------- Co-authored-by: Dominic Cooney <55120+dominiccooney@users.noreply.github.com> Co-authored-by: Harshil Mistry <125483347+harshil-mistry@users.noreply.github.com>
59 lines
3.3 KiB
Plaintext
59 lines
3.3 KiB
Plaintext
---
|
|
title: "Subagents"
|
|
sidebarTitle: "Subagents"
|
|
description: "Run parallel research agents to explore your codebase without filling the main agent's context window."
|
|
---
|
|
|
|
<Warning>
|
|
Subagents are available in the Cline CLI and Cline Desktop. The VS Code and JetBrains extensions don't use them.
|
|
</Warning>
|
|
|
|
Subagents let Cline hand a focused task to another agent. Each subagent gets its own prompt and context window, does the work, and returns a report to the main agent. This keeps the main agent's context clean, and several subagents can run at the same time.
|
|
|
|
## How It Works
|
|
|
|
When Cline uses the `spawn_agent` tool, it starts a subagent. Each one:
|
|
|
|
- Gets its own instructions and task from the main agent
|
|
- Runs with a separate context window
|
|
- Has Cline's built-in tools for the current mode. In Act mode it can read and edit files and run commands. In Plan mode it has no tools for editing files, and Cline refuses shell commands that usually change files, such as `rm` and `git commit`. Other commands still run, and some of them, such as `python -c`, can write files. A subagent can start subagents of its own. It doesn't get MCP tools.
|
|
- Returns its final reply to the main agent
|
|
|
|
The main agent waits for its subagents, then continues. Their token use and cost are added to the session's total.
|
|
|
|
## Approvals
|
|
|
|
Approving the `spawn_agent` call approves everything the subagent then does: its own tool calls don't ask for approval. Approval settings don't apply inside a subagent, so read the subagent's task before you approve it.
|
|
|
|
## Turning Subagents Off
|
|
|
|
Subagents are on in Act and Plan modes. To turn them off, turn off the `spawn_agent` tool:
|
|
|
|
- **CLI:** run `cline`, type `/settings`, and turn off `spawn_agent` on the **Tools** tab.
|
|
- **Desktop:** open **Customize**, select **Tools**, and turn off `spawn_agent`.
|
|
|
|
The setting applies to new sessions in both products.
|
|
|
|
## Using Subagents
|
|
|
|
Cline decides when a task is worth splitting. You can also ask for subagents in your prompt.
|
|
|
|
Example prompts:
|
|
|
|
- "Use subagents to explore how authentication works and where the database models are defined"
|
|
- "Spin up subagents to investigate the API routes, the test setup, and the deployment config"
|
|
- "I'm new to this codebase. Use subagents to map out the main entry points, the routing layer, and the data access patterns"
|
|
|
|
Give each subagent one focused question. Asking for research only, and working in Plan mode, make subagents less likely to change files, but neither stops every change.
|
|
|
|
## When to Use Subagents
|
|
|
|
Subagents work best when you need broad context from multiple areas of a codebase at once:
|
|
|
|
- **Onboarding to an unfamiliar project**: Ask subagents to map out the architecture, key entry points, and data flow in parallel.
|
|
- **Investigating cross-cutting concerns**: Have separate subagents trace authentication, logging, and error handling simultaneously.
|
|
- **Pre-edit research**: Before making changes, use subagents to gather context from related files so the main agent can make informed edits without burning through its context window.
|
|
- **Large codebases**: When reading many files sequentially would consume too much of the main agent's context, subagents let you explore broadly without that tradeoff.
|
|
|
|
For small, focused tasks where you already know which files to look at, subagents add unnecessary overhead. Just ask Cline directly.
|