pi-subagents 0.17.3 → 0.17.4
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/CHANGELOG.md +9 -0
- package/agents/oracle-executor.md +3 -0
- package/agents/oracle.md +5 -1
- package/package.json +5 -1
- package/skills/pi-subagents/SKILL.md +426 -0
package/CHANGELOG.md
CHANGED
|
@@ -2,6 +2,15 @@
|
|
|
2
2
|
|
|
3
3
|
## [Unreleased]
|
|
4
4
|
|
|
5
|
+
## [0.17.4] - 2026-04-22
|
|
6
|
+
|
|
7
|
+
### Added
|
|
8
|
+
- Bundled a `pi-subagents` skill that teaches agents how to use builtin subagents, slash-command vs tool workflows, management-mode agent creation/editing, fork/intercom coordination, clarify mode, worktrees, async status inspection, and chain templating.
|
|
9
|
+
|
|
10
|
+
### Changed
|
|
11
|
+
- Tightened the builtin `oracle` prompt so intercom-enabled forked reviews now prefer concise conversational handoffs during the review and send a short final recommendation via `pi-intercom` before returning the full structured result.
|
|
12
|
+
- Tightened `oracle-executor` so it explicitly frames itself as the single writer thread and escalates gaps in the approved direction instead of silently patching around them.
|
|
13
|
+
|
|
5
14
|
## [0.17.3] - 2026-04-22
|
|
6
15
|
|
|
7
16
|
### Added
|
|
@@ -12,6 +12,8 @@ defaultProgress: true
|
|
|
12
12
|
|
|
13
13
|
You are `oracle-executor`: a high-context implementation subagent.
|
|
14
14
|
|
|
15
|
+
You are the single writer thread. Your job is to execute approved direction, not to make new architectural or product decisions.
|
|
16
|
+
|
|
15
17
|
You are invoked after the main agent has already decided on a direction, often based on advice from `oracle`. You are allowed to act, but you are not the owner of product or architecture decisions. The main agent remains the final decision authority.
|
|
16
18
|
|
|
17
19
|
If runtime bridge instructions are present, use them as the source of truth for which orchestrator session to contact and how to coordinate. Use `intercom({ action: "ask", ... })` when a new decision is needed to continue safely. Use `intercom({ action: "send", ... })` for concise progress or completion handoffs when that extra coordination is helpful.
|
|
@@ -32,6 +34,7 @@ Working rules:
|
|
|
32
34
|
- Do not add speculative scaffolding or future-proofing unless explicitly required.
|
|
33
35
|
- Use `bash` for inspection, validation, and relevant tests.
|
|
34
36
|
- Escalate uncertainty to the main agent with `intercom` when needed.
|
|
37
|
+
- If the implementation reveals a gap in the approved direction, pause and escalate via `intercom` rather than silently patching around it with an implicit decision.
|
|
35
38
|
- If implementation reveals an unapproved product or architecture choice, pause and ask via `intercom` instead of deciding it yourself.
|
|
36
39
|
- If you send a completion handoff through `intercom`, keep it short and still return the full structured task result normally.
|
|
37
40
|
- Keep `progress.md` accurate when asked to maintain it.
|
package/agents/oracle.md
CHANGED
|
@@ -17,7 +17,7 @@ Before you do anything else, reconstruct the key inherited decisions, constraint
|
|
|
17
17
|
|
|
18
18
|
If you need clarification from the main agent, use `intercom`. If runtime bridge instructions are present, use them as the source of truth for which orchestrator session to contact and how to phrase coordination.
|
|
19
19
|
|
|
20
|
-
Use `intercom({ action: "ask", ... })` when you need a real decision or clarification. Use `intercom({ action: "send", ... })`
|
|
20
|
+
Use `intercom({ action: "ask", ... })` when you need a real decision or clarification. Use `intercom({ action: "send", ... })` for concise conversational handoffs during the review and for a short final recommendation before you return your full result. Keep intercom traffic tight and purposeful. Do not narrate your whole review through intercom, but do treat `intercom` as the preferred path for back-and-forth with the orchestrator when bridge instructions are available.
|
|
21
21
|
|
|
22
22
|
Core responsibilities:
|
|
23
23
|
- reconstruct inherited decisions, constraints, and open questions from the context
|
|
@@ -26,6 +26,8 @@ Core responsibilities:
|
|
|
26
26
|
- call out when a proposed move conflicts with an earlier decision or constraint
|
|
27
27
|
- protect consistency over novelty; prefer the path that honors existing decisions unless the context clearly supports a pivot
|
|
28
28
|
- when you do recommend a pivot, explain exactly which prior assumption or decision should be revised and why
|
|
29
|
+
- exploit your clean forked context to spot things the main agent may have missed due to context rot, accumulated reasoning, or errors in the original instruction
|
|
30
|
+
- look beyond the explicit question and suggest guidance based on the overall agent trajectory, even when not directly asked
|
|
29
31
|
|
|
30
32
|
What you do not do by default:
|
|
31
33
|
- do not edit files or write code
|
|
@@ -38,6 +40,8 @@ Working rules:
|
|
|
38
40
|
- Use `bash` only for inspection, verification, or read-only analysis.
|
|
39
41
|
- If information is missing and it matters, ask the main agent via `intercom` instead of guessing.
|
|
40
42
|
- If the answer depends on a decision the main agent has not made yet, stop and ask via `intercom` before continuing.
|
|
43
|
+
- When bridge instructions are present, send concise intercom messages when a recommendation, concern, or question would benefit from immediate discussion instead of waiting silently until the final return.
|
|
44
|
+
- Before returning your full structured result, send a short intercom handoff summarizing the recommended next move when bridge instructions are present.
|
|
41
45
|
- Prefer narrow, specific corrections to the current path over rewriting the whole plan.
|
|
42
46
|
|
|
43
47
|
Your output should follow this shape. If no executor handoff is warranted, say so plainly.
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "pi-subagents",
|
|
3
|
-
"version": "0.17.
|
|
3
|
+
"version": "0.17.4",
|
|
4
4
|
"description": "Pi extension for delegating tasks to subagents with chains, parallel execution, and TUI clarification",
|
|
5
5
|
"author": "Nico Bailon",
|
|
6
6
|
"license": "MIT",
|
|
@@ -30,6 +30,7 @@
|
|
|
30
30
|
"!*.test.ts",
|
|
31
31
|
"*.mjs",
|
|
32
32
|
"agents/",
|
|
33
|
+
"skills/**/*",
|
|
33
34
|
"README.md",
|
|
34
35
|
"CHANGELOG.md"
|
|
35
36
|
],
|
|
@@ -44,6 +45,9 @@
|
|
|
44
45
|
"extensions": [
|
|
45
46
|
"./index.ts",
|
|
46
47
|
"./notify.ts"
|
|
48
|
+
],
|
|
49
|
+
"skills": [
|
|
50
|
+
"./skills"
|
|
47
51
|
]
|
|
48
52
|
},
|
|
49
53
|
"peerDependencies": {
|
|
@@ -0,0 +1,426 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: pi-subagents
|
|
3
|
+
description: |
|
|
4
|
+
Delegate work to builtin or custom subagents with single-agent, chain,
|
|
5
|
+
parallel, async, forked-context, and intercom-coordinated workflows. Use
|
|
6
|
+
for advisory review, implementation handoffs, and multi-step tasks where a
|
|
7
|
+
single agent should stay in control while other agents contribute context,
|
|
8
|
+
planning, or execution.
|
|
9
|
+
---
|
|
10
|
+
|
|
11
|
+
# Pi Subagents
|
|
12
|
+
|
|
13
|
+
Use this skill when you need to launch a specialized subagent, compose multiple
|
|
14
|
+
agents into a workflow, or create/edit agents and chains on demand.
|
|
15
|
+
|
|
16
|
+
## When to Use
|
|
17
|
+
|
|
18
|
+
- **Advisory review**: fork to `oracle` or `reviewer` for a branched review thread
|
|
19
|
+
- **Implementation handoff**: have `oracle` advise, then `oracle-executor` or `worker` implement
|
|
20
|
+
- **Recon and planning**: use `scout` or `context-builder`, then `planner`
|
|
21
|
+
- **Parallel exploration**: run multiple non-conflicting tasks concurrently
|
|
22
|
+
- **Long-running work**: launch async/background runs and inspect them later
|
|
23
|
+
- **Agent authoring**: create, update, or override agents and chains for a project
|
|
24
|
+
|
|
25
|
+
## Tool vs Slash Commands
|
|
26
|
+
|
|
27
|
+
Agents can use the `subagent(...)` and `subagent_status(...)` tools directly.
|
|
28
|
+
Humans often use the slash-command layer instead:
|
|
29
|
+
|
|
30
|
+
- `/run` — launch a single agent
|
|
31
|
+
- `/chain` — launch a chain of steps
|
|
32
|
+
- `/parallel` — launch top-level parallel tasks
|
|
33
|
+
- `/agents` — open the agents manager TUI
|
|
34
|
+
- `/subagents-status` — inspect active/recent async runs
|
|
35
|
+
|
|
36
|
+
Prefer the tool when you are writing agent logic. Prefer the slash commands when
|
|
37
|
+
you are guiding a human through an interactive flow.
|
|
38
|
+
|
|
39
|
+
## Builtin Agents
|
|
40
|
+
|
|
41
|
+
Builtin agents load at the lowest priority. Project agents override user agents,
|
|
42
|
+
and user/project agents override builtins with the same name.
|
|
43
|
+
|
|
44
|
+
| Agent | Purpose | Model | Typical output / role |
|
|
45
|
+
|-------|---------|-------|------------------------|
|
|
46
|
+
| `scout` | Fast codebase recon | `openai-codex/gpt-5.4-mini` | Writes `context.md` handoff material |
|
|
47
|
+
| `planner` | Creates implementation plans | `openai-codex/gpt-5.4` | Writes `plan.md` |
|
|
48
|
+
| `worker` | General implementation | `openai-codex/gpt-5.4` | Edits code directly |
|
|
49
|
+
| `reviewer` | Review-and-fix specialist | `openai-codex/gpt-5.3-codex:high` | Can edit/fix reviewed code |
|
|
50
|
+
| `context-builder` | Requirements/codebase handoff builder | `openai-codex/gpt-5.4` | Writes structured context files |
|
|
51
|
+
| `researcher` | Web research brief generator | `openai-codex/gpt-5.4` | Writes `research.md` |
|
|
52
|
+
| `delegate` | Lightweight generic delegate | inherits parent model | No fixed output; generic delegated work |
|
|
53
|
+
| `oracle` | Decision-consistency advisory review | `openai-codex/gpt-5.4:high` | Advisory review, intercom coordination |
|
|
54
|
+
| `oracle-executor` | Implementation after approval | `openai-codex/gpt-5.3-codex:high` | Single-writer implementation after approval |
|
|
55
|
+
|
|
56
|
+
Override builtin defaults via settings before copying full agent files when a
|
|
57
|
+
small tweak is enough.
|
|
58
|
+
|
|
59
|
+
Settings locations:
|
|
60
|
+
- User scope: `~/.pi/agent/settings.json`
|
|
61
|
+
- Project scope: `.pi/settings.json`
|
|
62
|
+
|
|
63
|
+
Useful override fields: `model`, `fallbackModels`, `thinking`,
|
|
64
|
+
`systemPromptMode`, `inheritProjectContext`, `inheritSkills`, `disabled`,
|
|
65
|
+
`skills`, `tools`, and `systemPrompt`.
|
|
66
|
+
|
|
67
|
+
## Discovery and Scope Rules
|
|
68
|
+
|
|
69
|
+
Agent files can live in:
|
|
70
|
+
- `~/.pi/agent/agents/*.md` — user scope
|
|
71
|
+
- `.pi/agents/*.md` — canonical project scope
|
|
72
|
+
- legacy `.agents/*.md` — still read for compatibility, but `.pi/agents/` wins on conflicts
|
|
73
|
+
|
|
74
|
+
Chains live in:
|
|
75
|
+
- `~/.pi/agent/agents/*.chain.md`
|
|
76
|
+
- `.pi/agents/*.chain.md`
|
|
77
|
+
- legacy `.agents/*.chain.md`
|
|
78
|
+
|
|
79
|
+
Precedence is:
|
|
80
|
+
1. project scope
|
|
81
|
+
2. user scope
|
|
82
|
+
3. builtin agents
|
|
83
|
+
|
|
84
|
+
## Running Subagents
|
|
85
|
+
|
|
86
|
+
### Single agent
|
|
87
|
+
|
|
88
|
+
```typescript
|
|
89
|
+
subagent({
|
|
90
|
+
agent: "oracle",
|
|
91
|
+
task: "Review my current direction and challenge assumptions."
|
|
92
|
+
})
|
|
93
|
+
```
|
|
94
|
+
|
|
95
|
+
### Forked context
|
|
96
|
+
|
|
97
|
+
```typescript
|
|
98
|
+
subagent({
|
|
99
|
+
agent: "oracle",
|
|
100
|
+
task: "Review my current direction and challenge assumptions.",
|
|
101
|
+
context: "fork"
|
|
102
|
+
})
|
|
103
|
+
```
|
|
104
|
+
|
|
105
|
+
`context: "fork"` creates a branched child session from the current persisted
|
|
106
|
+
parent session. It does **not** create a fresh minimal review context or filter
|
|
107
|
+
history down to only the relevant parts. Use it when you want a separate review
|
|
108
|
+
or execution thread that can still reference the parent session history.
|
|
109
|
+
|
|
110
|
+
### Parallel execution
|
|
111
|
+
|
|
112
|
+
```typescript
|
|
113
|
+
subagent({
|
|
114
|
+
tasks: [
|
|
115
|
+
{ agent: "scout", task: "Explore the auth module" },
|
|
116
|
+
{ agent: "reviewer", task: "Review the API client" }
|
|
117
|
+
]
|
|
118
|
+
})
|
|
119
|
+
```
|
|
120
|
+
|
|
121
|
+
### Chain execution
|
|
122
|
+
|
|
123
|
+
```typescript
|
|
124
|
+
subagent({
|
|
125
|
+
chain: [
|
|
126
|
+
{ agent: "scout", task: "Map the auth flow and summarize key files" },
|
|
127
|
+
{ agent: "planner", task: "Create an implementation plan from {previous}" },
|
|
128
|
+
{ agent: "worker", task: "Implement the approved plan based on {previous}" }
|
|
129
|
+
]
|
|
130
|
+
})
|
|
131
|
+
```
|
|
132
|
+
|
|
133
|
+
Chain steps can use templated variables such as `{task}`, `{previous}`, and
|
|
134
|
+
`{chain_dir}`. This is the main way to pass structured summaries between steps
|
|
135
|
+
without forcing each step to rediscover everything.
|
|
136
|
+
|
|
137
|
+
### Async/background
|
|
138
|
+
|
|
139
|
+
```typescript
|
|
140
|
+
subagent({
|
|
141
|
+
agent: "worker",
|
|
142
|
+
task: "Run the full test suite",
|
|
143
|
+
async: true
|
|
144
|
+
})
|
|
145
|
+
```
|
|
146
|
+
|
|
147
|
+
Inspect async runs with the `subagent_status(...)` tool or the
|
|
148
|
+
`/subagents-status` slash command.
|
|
149
|
+
|
|
150
|
+
## Clarify TUI
|
|
151
|
+
|
|
152
|
+
Single and parallel runs support a clarification TUI when you want to preview or
|
|
153
|
+
edit parameters before launch:
|
|
154
|
+
|
|
155
|
+
```typescript
|
|
156
|
+
subagent({
|
|
157
|
+
agent: "worker",
|
|
158
|
+
task: "Implement feature X",
|
|
159
|
+
clarify: true
|
|
160
|
+
})
|
|
161
|
+
```
|
|
162
|
+
|
|
163
|
+
Chains default to clarify mode unless you explicitly set `clarify: false`.
|
|
164
|
+
For programmatic background launches, use `clarify: false, async: true`.
|
|
165
|
+
|
|
166
|
+
## Worktree Isolation
|
|
167
|
+
|
|
168
|
+
When multiple agents might write concurrently, use worktrees instead of letting
|
|
169
|
+
them share one filesystem view.
|
|
170
|
+
|
|
171
|
+
```typescript
|
|
172
|
+
subagent({
|
|
173
|
+
tasks: [
|
|
174
|
+
{ agent: "worker", task: "Implement feature A" },
|
|
175
|
+
{ agent: "worker", task: "Implement feature B" }
|
|
176
|
+
],
|
|
177
|
+
worktree: true
|
|
178
|
+
})
|
|
179
|
+
```
|
|
180
|
+
|
|
181
|
+
`worktree: true` gives each parallel task its own git worktree branched from
|
|
182
|
+
HEAD. This requires a clean git state and is mainly for intentionally parallel
|
|
183
|
+
write workflows. If you want one writer thread and several advisory agents,
|
|
184
|
+
prefer a single-writer pattern instead.
|
|
185
|
+
|
|
186
|
+
## The Oracle Workflow
|
|
187
|
+
|
|
188
|
+
The intended oracle loop is:
|
|
189
|
+
1. the main agent forks to `oracle`
|
|
190
|
+
2. `oracle` reviews direction, drift, assumptions, and risks
|
|
191
|
+
3. `oracle` can coordinate back to the orchestrator via `intercom`
|
|
192
|
+
4. the main agent decides what direction to approve
|
|
193
|
+
5. only then should `oracle-executor` implement
|
|
194
|
+
|
|
195
|
+
```typescript
|
|
196
|
+
// Advisory review in a branched thread
|
|
197
|
+
subagent({
|
|
198
|
+
agent: "oracle",
|
|
199
|
+
task: "Review my current direction, challenge assumptions, and propose the best next move.",
|
|
200
|
+
context: "fork"
|
|
201
|
+
})
|
|
202
|
+
|
|
203
|
+
// Implementation only after explicit approval
|
|
204
|
+
subagent({
|
|
205
|
+
agent: "oracle-executor",
|
|
206
|
+
task: "Implement the approved approach: ...",
|
|
207
|
+
context: "fork"
|
|
208
|
+
})
|
|
209
|
+
```
|
|
210
|
+
|
|
211
|
+
`oracle` is not a fresh-context reviewer in the Cognition article sense. It is
|
|
212
|
+
a forked advisory thread that inherits the parent session history and uses that
|
|
213
|
+
history as a baseline contract.
|
|
214
|
+
|
|
215
|
+
## Subagent + Intercom Coordination
|
|
216
|
+
|
|
217
|
+
When `pi-intercom` is installed and enabled, delegated runs can coordinate with
|
|
218
|
+
the orchestrator through the intercom bridge.
|
|
219
|
+
|
|
220
|
+
### Subagent asks the orchestrator
|
|
221
|
+
|
|
222
|
+
```typescript
|
|
223
|
+
intercom({
|
|
224
|
+
action: "ask",
|
|
225
|
+
to: "orchestrator",
|
|
226
|
+
message: "Should I optimize for readability or performance here?"
|
|
227
|
+
})
|
|
228
|
+
```
|
|
229
|
+
|
|
230
|
+
### Orchestrator replies
|
|
231
|
+
|
|
232
|
+
```typescript
|
|
233
|
+
intercom({ action: "reply", message: "Optimize for readability." })
|
|
234
|
+
```
|
|
235
|
+
|
|
236
|
+
Or inspect unresolved asks first:
|
|
237
|
+
|
|
238
|
+
```typescript
|
|
239
|
+
intercom({ action: "pending" })
|
|
240
|
+
```
|
|
241
|
+
|
|
242
|
+
Use `intercom` when:
|
|
243
|
+
- a subagent is blocked on a decision
|
|
244
|
+
- an advisory agent wants to send a concise handoff mid-flight
|
|
245
|
+
- a detached or async child needs to coordinate without waiting for normal tool return flow
|
|
246
|
+
|
|
247
|
+
## Management Mode
|
|
248
|
+
|
|
249
|
+
The `subagent(...)` tool also supports management actions.
|
|
250
|
+
|
|
251
|
+
### List available agents and chains
|
|
252
|
+
|
|
253
|
+
```typescript
|
|
254
|
+
subagent({ action: "list" })
|
|
255
|
+
```
|
|
256
|
+
|
|
257
|
+
### Create an agent
|
|
258
|
+
|
|
259
|
+
```typescript
|
|
260
|
+
subagent({
|
|
261
|
+
action: "create",
|
|
262
|
+
config: {
|
|
263
|
+
name: "my-agent",
|
|
264
|
+
description: "Project-specific implementation helper",
|
|
265
|
+
systemPrompt: "Your system prompt here.",
|
|
266
|
+
systemPromptMode: "replace",
|
|
267
|
+
model: "openai-codex/gpt-5.4",
|
|
268
|
+
tools: "read,grep,find,ls,bash"
|
|
269
|
+
}
|
|
270
|
+
})
|
|
271
|
+
```
|
|
272
|
+
|
|
273
|
+
### Update an agent
|
|
274
|
+
|
|
275
|
+
```typescript
|
|
276
|
+
subagent({
|
|
277
|
+
action: "update",
|
|
278
|
+
agent: "my-agent",
|
|
279
|
+
config: {
|
|
280
|
+
thinking: "high"
|
|
281
|
+
}
|
|
282
|
+
})
|
|
283
|
+
```
|
|
284
|
+
|
|
285
|
+
### Delete an agent
|
|
286
|
+
|
|
287
|
+
```typescript
|
|
288
|
+
subagent({ action: "delete", agent: "my-agent" })
|
|
289
|
+
```
|
|
290
|
+
|
|
291
|
+
Use management actions when the system needs to create or edit subagents on
|
|
292
|
+
demand without dropping into raw file editing.
|
|
293
|
+
|
|
294
|
+
## Creating and Editing Agents by File
|
|
295
|
+
|
|
296
|
+
A minimal agent file looks like this:
|
|
297
|
+
|
|
298
|
+
```markdown
|
|
299
|
+
---
|
|
300
|
+
name: my-agent
|
|
301
|
+
description: What this agent does
|
|
302
|
+
model: openai-codex/gpt-5.4
|
|
303
|
+
thinking: high
|
|
304
|
+
tools: read, grep, find, ls, bash
|
|
305
|
+
systemPromptMode: replace
|
|
306
|
+
inheritProjectContext: true
|
|
307
|
+
inheritSkills: false
|
|
308
|
+
---
|
|
309
|
+
|
|
310
|
+
Your system prompt here.
|
|
311
|
+
```
|
|
312
|
+
|
|
313
|
+
That is only a starting point. Common optional fields include:
|
|
314
|
+
- `defaultProgress`
|
|
315
|
+
- `defaultReads`
|
|
316
|
+
- `output`
|
|
317
|
+
- `fallbackModels`
|
|
318
|
+
- `maxSubagentDepth`
|
|
319
|
+
|
|
320
|
+
For many customizations, builtin overrides in settings are lower-friction than
|
|
321
|
+
copying a full builtin file.
|
|
322
|
+
|
|
323
|
+
## Prompt Template Integration
|
|
324
|
+
|
|
325
|
+
If `pi-prompt-template-model` is installed, prompt templates can delegate into
|
|
326
|
+
`pi-subagents`. This is useful when a slash command should always run through a
|
|
327
|
+
particular agent or with forked context.
|
|
328
|
+
|
|
329
|
+
## Important Constraints
|
|
330
|
+
|
|
331
|
+
- **Forking requires a persisted parent session.** If the current session does not
|
|
332
|
+
have a persisted session file, forked runs fail.
|
|
333
|
+
- **Forked runs inherit parent history.** They are branched threads, not fresh
|
|
334
|
+
filtered contexts.
|
|
335
|
+
- **Default subagent nesting depth is 2.** Deeper recursive delegation is blocked
|
|
336
|
+
unless configured otherwise.
|
|
337
|
+
- **Intercom asks are blocking.** A session can only maintain one pending outbound
|
|
338
|
+
ask wait state at a time.
|
|
339
|
+
- **Keep conversational authority clear.** Advisory subagents should not silently
|
|
340
|
+
become second decision-makers.
|
|
341
|
+
|
|
342
|
+
## Best Practices
|
|
343
|
+
|
|
344
|
+
### Keep writes single-threaded by default
|
|
345
|
+
|
|
346
|
+
A strong pattern is one main decision-maker plus advisory/research/review
|
|
347
|
+
subagents around it. Use `oracle` for advice and `oracle-executor` or `worker`
|
|
348
|
+
for the actual write path.
|
|
349
|
+
|
|
350
|
+
### Use fork for branched advisory or execution threads
|
|
351
|
+
|
|
352
|
+
Forked runs are useful when the child should reason in a separate thread while
|
|
353
|
+
still inheriting the parent’s accumulated context.
|
|
354
|
+
|
|
355
|
+
### Prefer narrow tasks
|
|
356
|
+
|
|
357
|
+
Give subagents specific tasks rather than vague mandates.
|
|
358
|
+
`Review auth.ts for null-check gaps` works better than `Review everything`.
|
|
359
|
+
|
|
360
|
+
### Escalate decisions upward
|
|
361
|
+
|
|
362
|
+
If a subagent encounters an unapproved product, architecture, or scope choice,
|
|
363
|
+
it should coordinate back via `intercom` instead of deciding alone.
|
|
364
|
+
|
|
365
|
+
### Name sessions meaningfully
|
|
366
|
+
|
|
367
|
+
Use `/name` so intercom targeting stays stable.
|
|
368
|
+
|
|
369
|
+
## Common Workflows
|
|
370
|
+
|
|
371
|
+
### Recon → Plan → Implement
|
|
372
|
+
|
|
373
|
+
```typescript
|
|
374
|
+
subagent({
|
|
375
|
+
chain: [
|
|
376
|
+
{ agent: "scout", task: "Map the auth flow and summarize relevant files" },
|
|
377
|
+
{ agent: "planner", task: "Plan the migration from {previous}" },
|
|
378
|
+
{ agent: "worker", task: "Implement the approved plan from {previous}" }
|
|
379
|
+
]
|
|
380
|
+
})
|
|
381
|
+
```
|
|
382
|
+
|
|
383
|
+
### Review loop
|
|
384
|
+
|
|
385
|
+
```typescript
|
|
386
|
+
subagent({ agent: "worker", task: "Add retry logic to the API client." })
|
|
387
|
+
subagent({
|
|
388
|
+
agent: "reviewer",
|
|
389
|
+
task: "Review the retry logic implementation. Look for edge cases and race conditions.",
|
|
390
|
+
context: "fork"
|
|
391
|
+
})
|
|
392
|
+
```
|
|
393
|
+
|
|
394
|
+
### Parallel non-conflicting analysis
|
|
395
|
+
|
|
396
|
+
```typescript
|
|
397
|
+
subagent({
|
|
398
|
+
tasks: [
|
|
399
|
+
{ agent: "scout", task: "Audit frontend auth flow" },
|
|
400
|
+
{ agent: "researcher", task: "Research current retry/backoff best practices" }
|
|
401
|
+
]
|
|
402
|
+
})
|
|
403
|
+
```
|
|
404
|
+
|
|
405
|
+
## Error Handling
|
|
406
|
+
|
|
407
|
+
**"Unknown agent"**
|
|
408
|
+
```typescript
|
|
409
|
+
subagent({ action: "list" })
|
|
410
|
+
// Check available agents and chains, then confirm scope/precedence.
|
|
411
|
+
```
|
|
412
|
+
|
|
413
|
+
**"Max subagent depth exceeded"**
|
|
414
|
+
```typescript
|
|
415
|
+
// Flatten the workflow or raise maxSubagentDepth in config.
|
|
416
|
+
```
|
|
417
|
+
|
|
418
|
+
**"Session manager did not return a session file"**
|
|
419
|
+
```typescript
|
|
420
|
+
// Persist the current session before using context: "fork".
|
|
421
|
+
```
|
|
422
|
+
|
|
423
|
+
**Intercom "Already waiting for a reply"**
|
|
424
|
+
```typescript
|
|
425
|
+
// Resolve the current outbound ask before starting another one.
|
|
426
|
+
```
|