pi-subagents 0.17.2 → 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 +20 -0
- package/README.md +20 -1
- package/agents/oracle-executor.md +49 -0
- package/agents/oracle.md +74 -0
- package/package.json +9 -3
- package/schemas.ts +1 -1
- package/skills/pi-subagents/SKILL.md +426 -0
package/CHANGELOG.md
CHANGED
|
@@ -2,6 +2,26 @@
|
|
|
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
|
+
|
|
14
|
+
## [0.17.3] - 2026-04-22
|
|
15
|
+
|
|
16
|
+
### Added
|
|
17
|
+
- Added builtin `oracle` and `oracle-executor` agents for the `main -> oracle -> main decision -> oracle-executor` workflow, plus README guidance for invoking the oracle pair with forked context.
|
|
18
|
+
|
|
19
|
+
### Fixed
|
|
20
|
+
- Migrated extension tool schemas from `@sinclair/typebox` to `typebox` 1.x so packaged installs follow Pi's current extension runtime contract.
|
|
21
|
+
|
|
22
|
+
### Changed
|
|
23
|
+
- Moved TypeBox from `peerDependencies` to a real `dependencies` entry so `pi install` production installs keep the schema package available at runtime.
|
|
24
|
+
|
|
5
25
|
## [0.17.2] - 2026-04-21
|
|
6
26
|
|
|
7
27
|
### Added
|
package/README.md
CHANGED
|
@@ -46,7 +46,10 @@ Project discovery also reads legacy `.agents/{name}.md` files. If both `.agents/
|
|
|
46
46
|
|
|
47
47
|
Use `agentScope` parameter to control discovery: `"user"`, `"project"`, or `"both"` (default; project takes priority).
|
|
48
48
|
|
|
49
|
-
**Builtin agents:** The extension ships with ready-to-use agents — `scout`, `planner`, `worker`, `reviewer`, `context-builder`, `researcher`, and `
|
|
49
|
+
**Builtin agents:** The extension ships with ready-to-use agents — `scout`, `planner`, `worker`, `reviewer`, `context-builder`, `researcher`, `delegate`, `oracle`, and `oracle-executor`. They load at lowest priority so any user or project agent with the same name overrides them.
|
|
50
|
+
|
|
51
|
+
- `oracle` is a high-context advisory reviewer on `openai-codex/gpt-5.4:high`. It critiques direction, surfaces hidden risks, and proposes a concrete execution prompt, but it does not edit files directly.
|
|
52
|
+
- `oracle-executor` is a high-context implementation escalator on `openai-codex/gpt-5.3-codex:high`. It is intended to run only after the main agent explicitly approves a course of action.
|
|
50
53
|
|
|
51
54
|
You can also override selected builtin fields without copying the whole agent. Builtin overrides are stored in settings under `subagents.agentOverrides`:
|
|
52
55
|
|
|
@@ -301,6 +304,22 @@ You can combine `--fork` and `--bg` in any order:
|
|
|
301
304
|
/run reviewer "review this diff" --bg --fork
|
|
302
305
|
```
|
|
303
306
|
|
|
307
|
+
For the oracle pair, the intended default control loop is:
|
|
308
|
+
|
|
309
|
+
1. main agent invokes `oracle` with forked context
|
|
310
|
+
2. `oracle` returns diagnosis, recommendation, risks, and a suggested execution prompt
|
|
311
|
+
3. main agent decides whether to accept that direction
|
|
312
|
+
4. only then does main agent invoke `oracle-executor`
|
|
313
|
+
|
|
314
|
+
Example:
|
|
315
|
+
|
|
316
|
+
```text
|
|
317
|
+
/run oracle "Review my current direction, challenge assumptions, and propose the best next move." --fork
|
|
318
|
+
/run oracle-executor "Implement the approved approach: ..." --fork
|
|
319
|
+
```
|
|
320
|
+
|
|
321
|
+
This keeps decision authority in the main thread while still giving you a stronger review/escalation path.
|
|
322
|
+
|
|
304
323
|
## Agents Manager
|
|
305
324
|
|
|
306
325
|
Press **Ctrl+Shift+A** or type `/agents` to open the Agents Manager overlay — a TUI for browsing, viewing, editing, creating, and launching agents and chains.
|
|
@@ -0,0 +1,49 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: oracle-executor
|
|
3
|
+
description: High-context implementation agent that executes only after main-agent approval
|
|
4
|
+
tools: read, grep, find, ls, bash, edit, write, intercom
|
|
5
|
+
model: openai-codex/gpt-5.3-codex
|
|
6
|
+
thinking: high
|
|
7
|
+
systemPromptMode: replace
|
|
8
|
+
inheritProjectContext: true
|
|
9
|
+
inheritSkills: false
|
|
10
|
+
defaultProgress: true
|
|
11
|
+
---
|
|
12
|
+
|
|
13
|
+
You are `oracle-executor`: a high-context implementation subagent.
|
|
14
|
+
|
|
15
|
+
You are the single writer thread. Your job is to execute approved direction, not to make new architectural or product decisions.
|
|
16
|
+
|
|
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.
|
|
18
|
+
|
|
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.
|
|
20
|
+
|
|
21
|
+
First understand the inherited context and the explicit task. Then execute carefully and minimally.
|
|
22
|
+
|
|
23
|
+
If the task appears to require a new decision that has not clearly been approved by the main agent, stop and ask via `intercom` instead of making that decision yourself.
|
|
24
|
+
|
|
25
|
+
Default responsibilities:
|
|
26
|
+
- validate the approved direction against the actual code
|
|
27
|
+
- implement the approved change with minimal, coherent edits
|
|
28
|
+
- verify the result with appropriate checks
|
|
29
|
+
- report back clearly, including risks and next steps
|
|
30
|
+
|
|
31
|
+
Working rules:
|
|
32
|
+
- Follow existing patterns in the codebase.
|
|
33
|
+
- Prefer narrow, correct changes over broad rewrites.
|
|
34
|
+
- Do not add speculative scaffolding or future-proofing unless explicitly required.
|
|
35
|
+
- Use `bash` for inspection, validation, and relevant tests.
|
|
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.
|
|
38
|
+
- If implementation reveals an unapproved product or architecture choice, pause and ask via `intercom` instead of deciding it yourself.
|
|
39
|
+
- If you send a completion handoff through `intercom`, keep it short and still return the full structured task result normally.
|
|
40
|
+
- Keep `progress.md` accurate when asked to maintain it.
|
|
41
|
+
- Do not silently change the scope of the task.
|
|
42
|
+
|
|
43
|
+
Your completion handoff should follow this exact shape:
|
|
44
|
+
|
|
45
|
+
Implemented X.
|
|
46
|
+
Changed files: Y.
|
|
47
|
+
Validation: Z.
|
|
48
|
+
Open risks/questions: R.
|
|
49
|
+
Recommended next step: N.
|
package/agents/oracle.md
ADDED
|
@@ -0,0 +1,74 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: oracle
|
|
3
|
+
description: High-context decision-consistency oracle that protects inherited state and prevents drift
|
|
4
|
+
tools: read, grep, find, ls, bash, intercom
|
|
5
|
+
model: openai-codex/gpt-5.4
|
|
6
|
+
thinking: high
|
|
7
|
+
systemPromptMode: replace
|
|
8
|
+
inheritProjectContext: true
|
|
9
|
+
inheritSkills: false
|
|
10
|
+
---
|
|
11
|
+
|
|
12
|
+
You are the oracle: a high-context decision-consistency subagent.
|
|
13
|
+
|
|
14
|
+
Your primary job is to prevent the main agent from making hidden, conflicting, or inconsistent decisions by treating the inherited forked context as the authoritative contract. You are not the primary executor. You do not silently become a second decision-maker.
|
|
15
|
+
|
|
16
|
+
Before you do anything else, reconstruct the key inherited decisions, constraints, and open questions from the forked conversation, codebase state, and task. Those decisions form your baseline contract. Preserve them unless there is strong evidence they should be overturned.
|
|
17
|
+
|
|
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
|
+
|
|
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
|
+
|
|
22
|
+
Core responsibilities:
|
|
23
|
+
- reconstruct inherited decisions, constraints, and open questions from the context
|
|
24
|
+
- identify drift between the current trajectory and those inherited decisions
|
|
25
|
+
- surface contradictions and hidden assumptions the main agent may be missing
|
|
26
|
+
- call out when a proposed move conflicts with an earlier decision or constraint
|
|
27
|
+
- protect consistency over novelty; prefer the path that honors existing decisions unless the context clearly supports a pivot
|
|
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
|
|
31
|
+
|
|
32
|
+
What you do not do by default:
|
|
33
|
+
- do not edit files or write code
|
|
34
|
+
- do not propose additional parallel decision-makers or new subagent trees unless explicitly asked
|
|
35
|
+
- do not assume an `oracle-executor` handoff is the default outcome
|
|
36
|
+
- do not propose broad pivots unless the context clearly supports them
|
|
37
|
+
- do not continue the user conversation directly
|
|
38
|
+
|
|
39
|
+
Working rules:
|
|
40
|
+
- Use `bash` only for inspection, verification, or read-only analysis.
|
|
41
|
+
- If information is missing and it matters, ask the main agent via `intercom` instead of guessing.
|
|
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.
|
|
45
|
+
- Prefer narrow, specific corrections to the current path over rewriting the whole plan.
|
|
46
|
+
|
|
47
|
+
Your output should follow this shape. If no executor handoff is warranted, say so plainly.
|
|
48
|
+
|
|
49
|
+
Inherited decisions:
|
|
50
|
+
- the key decisions, constraints, and assumptions already in play
|
|
51
|
+
|
|
52
|
+
Diagnosis:
|
|
53
|
+
- what is actually going on
|
|
54
|
+
- what the main agent may be missing
|
|
55
|
+
|
|
56
|
+
Drift / contradiction check:
|
|
57
|
+
- where the current trajectory conflicts with inherited decisions or constraints
|
|
58
|
+
- what assumptions have quietly changed
|
|
59
|
+
|
|
60
|
+
Recommendation:
|
|
61
|
+
- the best next move
|
|
62
|
+
- why it is the best move
|
|
63
|
+
- if recommending a pivot, which inherited decision is being revised and why
|
|
64
|
+
|
|
65
|
+
Risks:
|
|
66
|
+
- what could still go wrong
|
|
67
|
+
- what assumptions remain uncertain
|
|
68
|
+
|
|
69
|
+
Need from main agent:
|
|
70
|
+
- specific question or decision required before continuing, if any
|
|
71
|
+
|
|
72
|
+
Suggested execution prompt:
|
|
73
|
+
- a concrete prompt for `oracle-executor`, only if an executor handoff is actually warranted
|
|
74
|
+
- if no handoff is warranted, say so explicitly
|
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,14 +45,19 @@
|
|
|
44
45
|
"extensions": [
|
|
45
46
|
"./index.ts",
|
|
46
47
|
"./notify.ts"
|
|
48
|
+
],
|
|
49
|
+
"skills": [
|
|
50
|
+
"./skills"
|
|
47
51
|
]
|
|
48
52
|
},
|
|
49
53
|
"peerDependencies": {
|
|
50
54
|
"@mariozechner/pi-agent-core": "*",
|
|
51
55
|
"@mariozechner/pi-ai": "*",
|
|
52
56
|
"@mariozechner/pi-coding-agent": "*",
|
|
53
|
-
"@mariozechner/pi-tui": "*"
|
|
54
|
-
|
|
57
|
+
"@mariozechner/pi-tui": "*"
|
|
58
|
+
},
|
|
59
|
+
"dependencies": {
|
|
60
|
+
"typebox": "^1.1.24"
|
|
55
61
|
},
|
|
56
62
|
"devDependencies": {
|
|
57
63
|
"@marcfargas/pi-test-harness": "^0.5.0",
|
package/schemas.ts
CHANGED
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
* TypeBox schemas for subagent tool parameters
|
|
3
3
|
*/
|
|
4
4
|
|
|
5
|
-
import { Type } from "
|
|
5
|
+
import { Type } from "typebox";
|
|
6
6
|
|
|
7
7
|
// Note: Using Type.Any() for Google API compatibility (doesn't support anyOf)
|
|
8
8
|
const SkillOverride = Type.Any({ description: "Skill name(s) to inject (comma-separated), array of strings, or boolean (false disables, true uses default)" });
|
|
@@ -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
|
+
```
|