@markusylisiurunen/tau 0.3.49 → 0.3.50
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +22 -908
- package/dist/core/commands/registry.js +4 -4
- package/dist/core/commands/registry.js.map +1 -1
- package/dist/core/personas.js +19 -10
- package/dist/core/personas.js.map +1 -1
- package/dist/core/runtime/runtime_bootstrap.js +14 -9
- package/dist/core/runtime/runtime_bootstrap.js.map +1 -1
- package/dist/core/static/tau_docs/client-tools.md +228 -0
- package/dist/core/static/tau_docs/config-reference.md +422 -0
- package/dist/core/static/tau_docs/configuration.md +210 -0
- package/dist/core/static/tau_docs/credentials.md +200 -0
- package/dist/core/static/tau_docs/getting-started.md +140 -0
- package/dist/core/static/tau_docs/history.md +163 -0
- package/dist/core/static/tau_docs/index.md +40 -0
- package/dist/core/static/tau_docs/manifest.json +28 -0
- package/dist/core/static/tau_docs/models.md +198 -0
- package/dist/core/static/tau_docs/node-sdk.md +399 -0
- package/dist/core/static/tau_docs/nook.md +264 -0
- package/dist/core/static/tau_docs/ownership-and-scope.md +104 -0
- package/dist/core/static/tau_docs/personas.md +199 -0
- package/dist/core/static/tau_docs/prompts-and-project-context.md +181 -0
- package/dist/core/static/tau_docs/remote-sessions.md +274 -0
- package/dist/core/static/tau_docs/security.md +188 -0
- package/dist/core/static/tau_docs/session-protocol-methods.md +577 -0
- package/dist/core/static/tau_docs/session-protocol.md +265 -0
- package/dist/core/static/tau_docs/sessions.md +223 -0
- package/dist/core/static/tau_docs/skills.md +176 -0
- package/dist/core/static/tau_docs/subagents.md +203 -0
- package/dist/core/static/tau_docs/telegram.md +342 -0
- package/dist/core/static/tau_docs/tools.md +203 -0
- package/dist/core/static/tau_docs/troubleshooting.md +292 -0
- package/dist/core/static/tau_docs/tui.md +224 -0
- package/dist/core/telegram/session_manager.js +4 -3
- package/dist/core/telegram/session_manager.js.map +1 -1
- package/dist/core/tools/catalog.js +3 -1
- package/dist/core/tools/catalog.js.map +1 -1
- package/dist/core/tools/presentation.js +12 -1
- package/dist/core/tools/presentation.js.map +1 -1
- package/dist/core/tools/tau_docs.js +115 -0
- package/dist/core/tools/tau_docs.js.map +1 -0
- package/dist/core/tools/tool_names.js +8 -0
- package/dist/core/tools/tool_names.js.map +1 -1
- package/dist/core/utils/repository.js +19 -0
- package/dist/core/utils/repository.js.map +1 -1
- package/dist/core/version.js +1 -1
- package/dist/host/client_tool_broker.js +3 -18
- package/dist/host/client_tool_broker.js.map +1 -1
- package/dist/protocol/session_protocol.d.ts +1 -0
- package/dist/protocol/session_protocol.js +2 -1
- package/dist/protocol/session_protocol.js.map +1 -1
- package/dist/tui/session_chat_app.js +1 -0
- package/dist/tui/session_chat_app.js.map +1 -1
- package/dist/tui/session_chat_controller.js +13 -13
- package/dist/tui/session_chat_controller.js.map +1 -1
- package/dist/tui/session_creation_attributes.js +3 -3
- package/dist/tui/session_creation_attributes.js.map +1 -1
- package/package.json +2 -2
|
@@ -0,0 +1,176 @@
|
|
|
1
|
+
# Skills
|
|
2
|
+
|
|
3
|
+
Skills are local packages of instructions and supporting material that teach an agent how to handle a particular kind of work. Tau discovers them from the execution environment, shows the selected skills to the active persona, and lets the agent open a skill only when the task calls for it.
|
|
4
|
+
|
|
5
|
+
A skill is not a prompt template, a persona, or project context. A [prompt template](prompts-and-project-context.md) is text placed in the input editor. A [persona](personas.md) chooses the model, system prompt, skills, and tools for a session. `AGENTS.md` gives standing instructions for a directory tree. A skill is a reusable, selectively activated workflow with its own directory.
|
|
6
|
+
|
|
7
|
+
## Where Tau discovers skills
|
|
8
|
+
|
|
9
|
+
Tau looks for skill directories at global and project levels:
|
|
10
|
+
|
|
11
|
+
| Scope | Locations |
|
|
12
|
+
| --- | --- |
|
|
13
|
+
| Global | `~/.config/tau/skills/<name>/SKILL.md` and `~/.agents/skills/<name>/SKILL.md` |
|
|
14
|
+
| Project | `<level>/.tau/skills/<name>/SKILL.md` and `<level>/.agents/skills/<name>/SKILL.md` |
|
|
15
|
+
|
|
16
|
+
The global level is in scope only when the session working directory is inside the execution environment's home directory. For project discovery, Tau walks from the working directory toward home, or toward the filesystem root when the working directory is outside home. A directory participates as a project level when it contains `.tau/` or `.agents/skills/`.
|
|
17
|
+
|
|
18
|
+
Skills are keyed by name. Precedence runs from broadest to most specific:
|
|
19
|
+
|
|
20
|
+
1. Global skills are the base layer.
|
|
21
|
+
2. Parent project levels override global and more distant parent levels.
|
|
22
|
+
3. The nearest project level wins.
|
|
23
|
+
4. At the same level, `.agents/skills/` overrides `.tau/skills/`.
|
|
24
|
+
|
|
25
|
+
For example, with a session in `~/code/atlas/apps/api`, these definitions of `release-check` resolve to the last one listed:
|
|
26
|
+
|
|
27
|
+
```text
|
|
28
|
+
~/.config/tau/skills/release-check/SKILL.md
|
|
29
|
+
~/code/atlas/.tau/skills/release-check/SKILL.md
|
|
30
|
+
~/code/atlas/apps/.agents/skills/release-check/SKILL.md
|
|
31
|
+
```
|
|
32
|
+
|
|
33
|
+
`~/.agents/skills/` also overrides `~/.config/tau/skills/` for a same-named global skill.
|
|
34
|
+
|
|
35
|
+
All discovery happens in the execution environment. A remote host does not inspect the attached client's filesystem for skills.
|
|
36
|
+
|
|
37
|
+
## The skill directory contract
|
|
38
|
+
|
|
39
|
+
Each skill is a directory containing an exact uppercase `SKILL.md` filename:
|
|
40
|
+
|
|
41
|
+
```text
|
|
42
|
+
.tau/skills/release-check/
|
|
43
|
+
├── SKILL.md
|
|
44
|
+
├── references/
|
|
45
|
+
│ └── environments.md
|
|
46
|
+
├── scripts/
|
|
47
|
+
│ └── verify.sh
|
|
48
|
+
└── assets/
|
|
49
|
+
└── checklist.txt
|
|
50
|
+
```
|
|
51
|
+
|
|
52
|
+
Only `SKILL.md` is required. `references/`, `scripts/`, and `assets/` are conventional optional directories, not separately registered content. The instructions in `SKILL.md` decide when and how to use them. Paths mentioned by a skill are relative to the skill directory unless the skill says otherwise.
|
|
53
|
+
|
|
54
|
+
`SKILL.md` starts with YAML frontmatter followed by Markdown instructions:
|
|
55
|
+
|
|
56
|
+
```markdown
|
|
57
|
+
---
|
|
58
|
+
name: release-check
|
|
59
|
+
description: Verify a release candidate and summarize blockers. Trigger: explicit.
|
|
60
|
+
license: MIT
|
|
61
|
+
compatibility: Requires Git and npm.
|
|
62
|
+
metadata:
|
|
63
|
+
owner: platform
|
|
64
|
+
maturity: stable
|
|
65
|
+
allowed-tools: bash, view_image
|
|
66
|
+
---
|
|
67
|
+
|
|
68
|
+
Check the release branch, run the repository verification commands, and report only blocking failures.
|
|
69
|
+
```
|
|
70
|
+
|
|
71
|
+
The frontmatter contract is:
|
|
72
|
+
|
|
73
|
+
| Field | Requirement |
|
|
74
|
+
| --- | --- |
|
|
75
|
+
| `name` | Required. Between 1 and 64 characters, using lowercase letters, digits, and single dashes between segments. It must exactly match the containing directory name. |
|
|
76
|
+
| `description` | Required. A non-empty string of at most 1,024 characters. Tau includes it in the discovered skill index, so it should say what the skill does and when it applies. |
|
|
77
|
+
| `license` | Optional non-empty string. |
|
|
78
|
+
| `compatibility` | Optional non-empty string of at most 500 characters. |
|
|
79
|
+
| `metadata` | Optional map whose keys and values are strings. |
|
|
80
|
+
| `allowed-tools` | Optional non-empty string. It is accepted for skills-format compatibility but currently ignored by Tau. |
|
|
81
|
+
|
|
82
|
+
Unknown frontmatter fields are discarded. `allowed-tools` does not enable, disable, or restrict any tool. Tool availability comes from the active persona and, for a subagent, its subagent definition. See [tools](tools.md) and [subagents](subagents.md).
|
|
83
|
+
|
|
84
|
+
Keep the description useful without copying the full workflow into it. Tau initially exposes the name, description, and `SKILL.md` path. The agent opens the file after activation, then reads only the referenced resources needed for the task.
|
|
85
|
+
|
|
86
|
+
## Selecting skills in a persona
|
|
87
|
+
|
|
88
|
+
A persona's `skills` field controls which discovered skills appear in its skill index:
|
|
89
|
+
|
|
90
|
+
```yaml
|
|
91
|
+
skills: "*"
|
|
92
|
+
```
|
|
93
|
+
|
|
94
|
+
`"*"` selects every discovered skill. This is the default for built-in personas and for a custom persona that does not inherit another persona and omits `skills`.
|
|
95
|
+
|
|
96
|
+
A list selects an explicit subset:
|
|
97
|
+
|
|
98
|
+
```yaml
|
|
99
|
+
skills:
|
|
100
|
+
- release-check
|
|
101
|
+
- incident-summary
|
|
102
|
+
```
|
|
103
|
+
|
|
104
|
+
An empty list disables skills for that persona:
|
|
105
|
+
|
|
106
|
+
```yaml
|
|
107
|
+
skills: []
|
|
108
|
+
```
|
|
109
|
+
|
|
110
|
+
When a persona extends another persona and omits `skills`, it inherits the base persona's selection. Selection names are matched case-insensitively to discovered skill names, although valid skill names themselves are lowercase. An unknown selected name produces a warning when Tau builds or reloads the session context; Tau keeps the known skills.
|
|
111
|
+
|
|
112
|
+
Selecting a skill does not run it on every turn. It makes the skill discoverable to the agent and subject to activation policy.
|
|
113
|
+
|
|
114
|
+
## Activation and trigger sensitivity
|
|
115
|
+
|
|
116
|
+
A skill declares trigger sensitivity in its `description`. The supported policy levels are:
|
|
117
|
+
|
|
118
|
+
- **eager**: activate proactively whenever the capability would help.
|
|
119
|
+
- **balanced**: activate when the request clearly matches the skill. This is the default when no trigger is stated.
|
|
120
|
+
- **explicit**: activate only when the skill is explicitly named by an active instruction.
|
|
121
|
+
|
|
122
|
+
Use a clear phrase such as `Trigger: eager.`, `Trigger: balanced.`, or `Trigger: explicit.` in the description. Trigger sensitivity is an agent-facing convention carried by the description, not a separate frontmatter field.
|
|
123
|
+
|
|
124
|
+
An exact skill reference has this form:
|
|
125
|
+
|
|
126
|
+
```text
|
|
127
|
+
@@skill:release-check
|
|
128
|
+
```
|
|
129
|
+
|
|
130
|
+
A reference in the current user request, active `AGENTS.md` instructions, or an already-active skill explicitly activates that skill. Generic wording or a coincidental keyword does not activate an explicit skill.
|
|
131
|
+
|
|
132
|
+
Skill references compose. If `release-check` instructs the agent to use `@@skill:dependency-audit`, Tau's activation policy allows the second skill to activate transitively. Each skill activates at most once per request, so repeated references and cycles do not reopen it.
|
|
133
|
+
|
|
134
|
+
After activation, the agent reads `SKILL.md` from the path in the discovered index. It should load only relevant files from `references/` or `assets/`, and prefer provided scripts when they implement the required workflow. Skills are treated as read-only unless the user explicitly asks to edit them.
|
|
135
|
+
|
|
136
|
+
## Installing starter skills
|
|
137
|
+
|
|
138
|
+
Tau ships starter prompts and skills that can be copied into a project:
|
|
139
|
+
|
|
140
|
+
```bash
|
|
141
|
+
tau install
|
|
142
|
+
```
|
|
143
|
+
|
|
144
|
+
By default this installs all starter prompts and skills under the current directory's `.tau/`. To install one skill:
|
|
145
|
+
|
|
146
|
+
```bash
|
|
147
|
+
tau install --skill code-review
|
|
148
|
+
```
|
|
149
|
+
|
|
150
|
+
To install under `~/.config/tau/` instead:
|
|
151
|
+
|
|
152
|
+
```bash
|
|
153
|
+
tau install --global --skill commit
|
|
154
|
+
```
|
|
155
|
+
|
|
156
|
+
Existing skill directories are skipped. `--force` replaces the entire same-named target directory, including files that are not present in the starter copy, so use it only when replacement is intended. `--prompt` and `--skill` are mutually exclusive. See [prompts and project context](prompts-and-project-context.md) for the prompt side of `tau install`.
|
|
157
|
+
|
|
158
|
+
## Applying changes and checking discovery
|
|
159
|
+
|
|
160
|
+
A running TUI session keeps its current content catalog and prompt context until it reloads. Run:
|
|
161
|
+
|
|
162
|
+
```text
|
|
163
|
+
/reload
|
|
164
|
+
```
|
|
165
|
+
|
|
166
|
+
Reloading re-discovers skills, re-applies the active persona's selection, and rebuilds the effective skill index. Tau refuses to reload while a session turn is running. If the active persona disappeared, reload selects the first available persona; if no personas remain, reload fails.
|
|
167
|
+
|
|
168
|
+
For a new local TUI session, `tau --debug` prints the discovered skills and the effective system prompt without starting the TUI. Combine it with `--persona` to inspect a particular selection:
|
|
169
|
+
|
|
170
|
+
```bash
|
|
171
|
+
tau --debug --persona release-coder
|
|
172
|
+
```
|
|
173
|
+
|
|
174
|
+
Invalid skills are skipped and reported as configuration warnings. Common causes are malformed YAML, non-object frontmatter, a missing required field, an invalid name, a directory/name mismatch, an unreadable file, or an unreadable skills directory. A subdirectory without `SKILL.md` is simply not a skill.
|
|
175
|
+
|
|
176
|
+
When troubleshooting precedence, check the session's execution-environment working directory first. Discovery is based on that path, not necessarily the filesystem where the TUI is running. Broader configuration diagnostics are covered in [troubleshooting](troubleshooting.md).
|
|
@@ -0,0 +1,203 @@
|
|
|
1
|
+
# Subagents
|
|
2
|
+
|
|
3
|
+
Subagents are host-supervised background agent threads created by the main agent. They are useful when work can proceed independently, needs a separate context, or benefits from a deliberately narrower tool set. A subagent is not a second session and does not have its own persona file. Its definition belongs to the active persona.
|
|
4
|
+
|
|
5
|
+
The persona decides which subagent names exist. The host enforces launch models, tools, working directory, concurrency, follow-up state, interruption, and cleanup.
|
|
6
|
+
|
|
7
|
+
## The built-in `default` subagent
|
|
8
|
+
|
|
9
|
+
Tau provides one built-in subagent named `default`. It is a general-purpose background worker and has explicit trigger sensitivity. Built-in personas enable it, and a standalone custom persona also enables it when `subagents` is omitted.
|
|
10
|
+
|
|
11
|
+
The `default` subagent inherits the active main persona's model-facing behavior through Tau's maintained wrapper. Its wrapper and built-in prompt are implementation-owned and are not configuration surfaces. It cannot be overridden in persona frontmatter.
|
|
12
|
+
|
|
13
|
+
Disable it explicitly when a persona should expose only named custom workers or no subagents:
|
|
14
|
+
|
|
15
|
+
```yaml
|
|
16
|
+
subagents:
|
|
17
|
+
default: false
|
|
18
|
+
```
|
|
19
|
+
|
|
20
|
+
If `subagents` is omitted by a persona that extends a built-in, Tau inherits the base persona's entire subagent map. If a persona supplies a `subagents` map, Tau builds a new map from it and adds `default` unless the map says `default: false`.
|
|
21
|
+
|
|
22
|
+
## Defining custom subagents
|
|
23
|
+
|
|
24
|
+
Custom definitions live under `subagents` in a [persona](personas.md):
|
|
25
|
+
|
|
26
|
+
```yaml
|
|
27
|
+
subagents:
|
|
28
|
+
default: false
|
|
29
|
+
dependency-auditor:
|
|
30
|
+
description: Audit dependency changes and report concrete risks. Trigger: explicit.
|
|
31
|
+
systemPrompt: >-
|
|
32
|
+
Inspect the requested dependency change. Verify lockfile and release implications,
|
|
33
|
+
then return prioritized findings with paths.
|
|
34
|
+
tools:
|
|
35
|
+
- bash
|
|
36
|
+
- history
|
|
37
|
+
launchModels:
|
|
38
|
+
- anthropic/claude-haiku-4-5:low
|
|
39
|
+
- openai/gpt-5.6-sol:high
|
|
40
|
+
```
|
|
41
|
+
|
|
42
|
+
A custom subagent name must:
|
|
43
|
+
|
|
44
|
+
- contain 1 to 64 characters;
|
|
45
|
+
- use lowercase letters and digits;
|
|
46
|
+
- use single dashes between segments; and
|
|
47
|
+
- begin and end with a letter or digit.
|
|
48
|
+
|
|
49
|
+
`dependency-auditor` and `review2` are valid. `DependencyAuditor`, `dependency_auditor`, and `-review` are not.
|
|
50
|
+
|
|
51
|
+
Each custom definition accepts:
|
|
52
|
+
|
|
53
|
+
| Field | Contract |
|
|
54
|
+
| --- | --- |
|
|
55
|
+
| `systemPrompt` | Required non-empty string containing the subagent's base instructions. |
|
|
56
|
+
| `description` | Optional non-empty catalog description. Include trigger sensitivity here when needed. |
|
|
57
|
+
| `tools` | Optional list of eligible subagent tools. Omission inherits eligible tools from the main persona. |
|
|
58
|
+
| `launchModels` | Optional allowlist of exact model overrides accepted by `spawn_agent`. |
|
|
59
|
+
|
|
60
|
+
Unknown fields are discarded. In particular, `provider`, `model`, `reasoning`, and `serviceTier` inside a subagent definition do not configure its runtime. Use `launchModels` for approved launch-time model changes.
|
|
61
|
+
|
|
62
|
+
A custom entry cannot be `false`; only `default: false` has disable semantics. Every custom entry requires `systemPrompt`.
|
|
63
|
+
|
|
64
|
+
## Trigger sensitivity
|
|
65
|
+
|
|
66
|
+
Trigger sensitivity is expressed in the `description`, not in a separate field:
|
|
67
|
+
|
|
68
|
+
- **eager**: use proactively whenever the capability would help;
|
|
69
|
+
- **balanced**: use when the request clearly matches, which is the default when no trigger is stated;
|
|
70
|
+
- **explicit**: use only when an active instruction names the subagent.
|
|
71
|
+
|
|
72
|
+
Use a clear phrase such as `Trigger: explicit.`. An exact user reference looks like:
|
|
73
|
+
|
|
74
|
+
```text
|
|
75
|
+
@@agent:dependency-auditor
|
|
76
|
+
```
|
|
77
|
+
|
|
78
|
+
An exact reference in the user request, an active `AGENTS.md` instruction, or the instructions of an already-active skill explicitly activates that subagent. A subagent reference tells the main agent which capability to use; it does not itself create a thread. The main agent still calls `spawn_agent`.
|
|
79
|
+
|
|
80
|
+
Trigger sensitivity is agent-facing policy. The host enforces whether the named subagent exists, but it does not infer whether a prompt semantically satisfied `eager`, `balanced`, or `explicit`.
|
|
81
|
+
|
|
82
|
+
## Tool inheritance and restriction
|
|
83
|
+
|
|
84
|
+
The persona-configurable subagent tool subset contains only:
|
|
85
|
+
|
|
86
|
+
- `bash`
|
|
87
|
+
- `write`
|
|
88
|
+
- `edit`
|
|
89
|
+
- `view_image`
|
|
90
|
+
- `web`
|
|
91
|
+
- `history`
|
|
92
|
+
|
|
93
|
+
Tau then adds intrinsic `tau_docs` to every subagent registry, independently of this subset. Neither a persona nor a subagent `tools` list can disable it. Apart from `tau_docs`, subagents do not receive Nook, goal controls, subagent supervision tools, client tools, or TUI-local tools.
|
|
94
|
+
|
|
95
|
+
When `tools` is omitted, Tau filters the main persona's tool list to the eligible names above. For example, a main persona with `bash`, `edit`, `history`, and `spawn_agent` gives an omitted subagent list of `bash`, `edit`, and `history`.
|
|
96
|
+
|
|
97
|
+
An explicit `tools` list replaces inheritance. It may select any of the six eligible subagent tools, even if that name is absent from the main persona's own list. Use `tools: []` for a worker with no persona-configurable tools; it still receives `tau_docs`. Names are normalized to lowercase, duplicate entries are removed, and an unknown name rejects the containing persona.
|
|
98
|
+
|
|
99
|
+
The main persona must itself expose the subagent supervision tools for the model to operate subagents. Defining a subagent while omitting `spawn_agent` from an explicit persona `tools` list leaves the definition present but not launchable by the main agent. See [tools](tools.md) for the broader availability contract.
|
|
100
|
+
|
|
101
|
+
## Models and settings
|
|
102
|
+
|
|
103
|
+
By default, a new subagent inherits the active persona's model and complete settings, including reasoning and service tier. This inheritance is captured when the thread is created. Later persona or reasoning changes do not reconfigure that existing thread.
|
|
104
|
+
|
|
105
|
+
A launch override must use exact form:
|
|
106
|
+
|
|
107
|
+
```text
|
|
108
|
+
<provider>/<model>:<effort>
|
|
109
|
+
```
|
|
110
|
+
|
|
111
|
+
The provider is normalized to lowercase. The model ID remains exact and case-sensitive. Effort is one of `none`, `minimal`, `low`, `medium`, `high`, `xhigh`, or `max`.
|
|
112
|
+
|
|
113
|
+
`launchModels` is an allowlist, not a default selection. The main agent should normally omit the `model` argument to `spawn_agent`; when omitted, the subagent inherits the active persona model and reasoning. When supplied, the normalized value must exactly match an entry in the selected subagent's allowlist. The override changes provider, model, and reasoning. Other inherited settings remain.
|
|
114
|
+
|
|
115
|
+
Model IDs may be unbundled when their provider is known, following the synthesis rules in [models](models.md). Invalid provider, model, effort, or format rejects the persona during content loading. Duplicate normalized entries are removed.
|
|
116
|
+
|
|
117
|
+
### Allowing overrides for `default`
|
|
118
|
+
|
|
119
|
+
The built-in `default` definition cannot be edited in persona frontmatter. Configure its launch allowlist through `subagents.defaultLaunchModels` in `config.json`:
|
|
120
|
+
|
|
121
|
+
```json
|
|
122
|
+
{
|
|
123
|
+
"subagents": {
|
|
124
|
+
"defaultLaunchModels": [
|
|
125
|
+
"anthropic/claude-haiku-4-5:low",
|
|
126
|
+
"openai/gpt-5.6-sol:high"
|
|
127
|
+
]
|
|
128
|
+
}
|
|
129
|
+
}
|
|
130
|
+
```
|
|
131
|
+
|
|
132
|
+
This list is layered configuration. The nearest defined `defaultLaunchModels` array replaces the broader array rather than appending to it. Tau applies the effective list to every persona that currently enables `default`; it does not add `default` to a persona that disabled it.
|
|
133
|
+
|
|
134
|
+
## Working-directory context
|
|
135
|
+
|
|
136
|
+
`spawn_agent` normally runs the child in the main session's `cwd`. Its optional `workingDirectory` may be absolute or relative to that `cwd`; Tau resolves it to an absolute execution-environment path.
|
|
137
|
+
|
|
138
|
+
When the resolved path differs from the parent `cwd`, Tau rebuilds prompt context from that target directory. It discovers the target platform and repository metadata, reads applicable `AGENTS.md` and configured context files, discovers target skills, and filters those skills through the parent persona's skill selection.
|
|
139
|
+
|
|
140
|
+
The target directory does **not** select a different persona, subagent definition, model catalog, runtime configuration, credential source, or tool policy for the child. Those remain under parent-session authority. Target configuration is consulted only where needed to rebuild target prompt context, such as target `agentContextFiles` and skill discovery.
|
|
141
|
+
|
|
142
|
+
This distinction matters in monorepos and hosted environments. `workingDirectory` is an execution-environment path. The host and attached client must not reinterpret it against their own filesystems.
|
|
143
|
+
|
|
144
|
+
A launch is blocked if Tau cannot build target context, the directory is invalid for the backend, or working-directory resolution is unavailable. Passing `.` or another path that resolves to the existing parent `cwd` reuses the already composed parent context.
|
|
145
|
+
|
|
146
|
+
## Lifecycle and supervision tools
|
|
147
|
+
|
|
148
|
+
Subagent threads are addressed by host-generated IDs. Names identify configurations; IDs identify live thread records.
|
|
149
|
+
|
|
150
|
+
### Spawn
|
|
151
|
+
|
|
152
|
+
`spawn_agent` validates the configured name, optional launch model, title, prompt, and working directory. The prompt is the child's only initial user input, so it should be self-contained. A successful call returns immediately with the new ID while the child continues in the background.
|
|
153
|
+
|
|
154
|
+
At most eight subagent runs may be active concurrently within one main session. Completed or interrupted idle threads do not consume active capacity.
|
|
155
|
+
|
|
156
|
+
### Observe and wait
|
|
157
|
+
|
|
158
|
+
`list_agents` returns every retained thread with its ID, name, title, runtime model and reasoning, working directory, run state, context usage, cost, and response availability. Use it to rediscover an ID or inspect progress.
|
|
159
|
+
|
|
160
|
+
`wait_for_agents` accepts one or more IDs. It returns as soon as at least one requested thread finishes, and includes current state for all requested IDs. A completed response remains readable through later waits until a follow-up run replaces that retained response.
|
|
161
|
+
|
|
162
|
+
The host also publishes bounded live subagent activity to observing clients. That activity is presentation state, not a replacement for the final response returned by supervision tools.
|
|
163
|
+
|
|
164
|
+
### Follow up
|
|
165
|
+
|
|
166
|
+
`send_input_to_agent` starts another run on an existing idle thread. The thread retains its conversation state, model, settings, tools, and working directory. It must finish or be interrupted before another input is accepted.
|
|
167
|
+
|
|
168
|
+
Starting a follow-up replaces the previously retained response in the thread's latest-run state. Read any needed result before sending the next input. Follow-ups do not reread a changed persona definition or adopt a newly reloaded launch model.
|
|
169
|
+
|
|
170
|
+
### Interrupt
|
|
171
|
+
|
|
172
|
+
`interrupt_agent` requests interruption of the current run and waits for its latest state. The thread remains available for follow-up input. Calling it on an already idle thread simply returns that state.
|
|
173
|
+
|
|
174
|
+
The TUI can also interrupt the selected running subagent with `Ctrl+G`. Interrupting the main session and interrupting a child are separate actions.
|
|
175
|
+
|
|
176
|
+
## Detach, rewind, and recovery
|
|
177
|
+
|
|
178
|
+
Subagents are owned by the live host session, not by an observing TUI. Detaching a client or losing an attach transport does not by itself stop children while the hosted session remains alive. Another observer can reconnect to that live session and see current projected state.
|
|
179
|
+
|
|
180
|
+
Subagent runtimes are not recoverable across host-session disposal or process recovery. Tau may persist projected agent status while the session is live, but recovery removes those records and agent-owned presentation because the underlying conversation runtimes no longer exist. A recovered session cannot send follow-up input to an old subagent ID.
|
|
181
|
+
|
|
182
|
+
Rewind also removes subagent threads whose spawning assistant message is no longer in active history. Host shutdown or session disposal interrupts and disposes all child runtimes.
|
|
183
|
+
|
|
184
|
+
Plan durable work accordingly. Important conclusions should be returned to the main agent and committed to ordinary session history or project files before the live host disappears. [Sessions](sessions.md) explains persistence and recovery more broadly.
|
|
185
|
+
|
|
186
|
+
## Reloading and validation
|
|
187
|
+
|
|
188
|
+
Persona and global launch-policy changes take effect after `/reload` in an idle TUI session or in a newly created session. Reload updates which subagent definitions new `spawn_agent` calls see. It does not kill, rename, or reconfigure already spawned threads, and follow-ups continue on their captured runtime.
|
|
189
|
+
|
|
190
|
+
An invalid subagent definition rejects its containing persona. Common content warnings include:
|
|
191
|
+
|
|
192
|
+
- a name outside the lowercase-dash contract or longer than 64 characters;
|
|
193
|
+
- `subagents` that is not an object;
|
|
194
|
+
- `default` set to anything other than `false`;
|
|
195
|
+
- a custom entry set to `false` or missing `systemPrompt`;
|
|
196
|
+
- blank descriptions, prompts, or list entries;
|
|
197
|
+
- unknown subagent tools;
|
|
198
|
+
- `launchModels` or `defaultLaunchModels` that is not a string array; and
|
|
199
|
+
- an unknown provider or model, invalid effort, or malformed `<provider>/<model>:<effort>` value.
|
|
200
|
+
|
|
201
|
+
At execution time, launches can still be blocked by an unenabled name, a model outside the allowlist, exhausted concurrency, invalid arguments, missing prompt composition, or target-context failure. Follow-up, wait, and interrupt calls reject unknown IDs; follow-up also rejects a thread that is still running.
|
|
202
|
+
|
|
203
|
+
Use `tau --debug --persona <id>` before starting a local TUI to inspect effective subagent names, inherited model and settings, and tool lists. It does not reveal managed prompt bodies for built-in subagents. In a running session, `/reload` reports exact file warnings and `list_agents` verifies live runtime choices.
|