@llblab/pi-actors 0.14.3 → 0.16.0
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/AGENTS.md +5 -1
- package/BACKLOG.md +54 -32
- package/CHANGELOG.md +39 -0
- package/README.md +53 -61
- package/banner.jpg +0 -0
- package/docs/actor-messages.md +1 -1
- package/docs/async-runs.md +4 -4
- package/docs/command-templates.md +11 -11
- package/docs/recipe-library.md +7 -3
- package/docs/task-first-recipes.md +44 -43
- package/docs/template-recipes.md +45 -23
- package/docs/tool-registry.md +50 -42
- package/index.ts +34 -0
- package/lib/actor-messages.ts +20 -7
- package/lib/async-runs.ts +35 -12
- package/lib/command-templates.ts +6 -1
- package/lib/config.ts +3 -2
- package/lib/execution.ts +9 -5
- package/lib/observability.ts +20 -10
- package/lib/paths.ts +6 -1
- package/lib/prompts.ts +14 -21
- package/lib/recipe-discovery.ts +226 -0
- package/lib/recipe-migration.ts +123 -0
- package/lib/recipe-references.ts +45 -13
- package/lib/recipe-usage.ts +44 -0
- package/lib/registry.ts +48 -15
- package/lib/runtime.ts +59 -15
- package/lib/tools.ts +237 -65
- package/package.json +21 -11
- package/recipes/coordinator-locker.json +46 -0
- package/recipes/music-player.json +16 -2
- package/recipes/pipeline-architect-coordinator.json +11 -3
- package/recipes/pipeline-artifact-bundle.json +12 -3
- package/recipes/pipeline-artifact-report.json +9 -3
- package/recipes/pipeline-artifact-write.json +9 -3
- package/recipes/pipeline-async-run-ops.json +18 -9
- package/recipes/pipeline-checkpoint-continuation.json +14 -3
- package/recipes/pipeline-development-tasking.json +12 -3
- package/recipes/pipeline-docs-maintenance.json +12 -3
- package/recipes/pipeline-media-library.json +12 -3
- package/recipes/pipeline-quorum-review.json +12 -9
- package/recipes/pipeline-release-readiness.json +27 -9
- package/recipes/pipeline-release-summary.json +89 -0
- package/recipes/pipeline-repo-health.json +12 -3
- package/recipes/pipeline-research-synthesis.json +11 -3
- package/recipes/pipeline-review-readiness.json +12 -6
- package/recipes/subagent-artifact.json +9 -3
- package/recipes/subagent-checkpoint.json +10 -3
- package/recipes/subagent-conflict-report.json +11 -3
- package/recipes/subagent-contradiction-map.json +11 -3
- package/recipes/subagent-critic.json +11 -3
- package/recipes/subagent-evidence-map.json +11 -3
- package/recipes/subagent-followup.json +10 -3
- package/recipes/subagent-judge.json +11 -3
- package/recipes/subagent-merge.json +11 -3
- package/recipes/subagent-message.json +8 -3
- package/recipes/subagent-normalize.json +11 -3
- package/recipes/subagent-plan.json +11 -3
- package/recipes/subagent-prompt.json +10 -3
- package/recipes/subagent-quorum.json +10 -7
- package/recipes/subagent-review-coordinator.json +14 -6
- package/recipes/subagent-review.json +11 -3
- package/recipes/subagent-task-card.json +11 -3
- package/recipes/subagent-tools.json +10 -3
- package/recipes/subagent-verify.json +11 -3
- package/recipes/subagents-prompts.json +10 -3
- package/recipes/utility-coordinator-lock-snapshot.json +14 -0
- package/recipes/utility-run-ops-snapshot.json +3 -3
- package/recipes/utility-skill-summary.json +14 -0
- package/scripts/coordinator-locker.mjs +272 -0
- package/scripts/music-player.mjs +2 -1
- package/scripts/recipe-utils.mjs +239 -81
- package/scripts/validate-recipe.mjs +28 -10
- package/skills/actors/SKILL.md +301 -0
- package/skills/swarm/SKILL.md +451 -0
- package/skills/swarm/references/development-swarm.md +596 -0
|
@@ -0,0 +1,596 @@
|
|
|
1
|
+
# Small-Team Development Swarm
|
|
2
|
+
|
|
3
|
+
Also known as `MAWP`: Multi-Agent Worktree Protocol.
|
|
4
|
+
|
|
5
|
+
Use this protocol when 2–4 implementation agents work on one project at the same time.
|
|
6
|
+
It is intentionally lighter than a full orchestrator runtime.
|
|
7
|
+
|
|
8
|
+
Core idea: do not block everything in advance. Isolate work surfaces, declare intent before edits, exchange context only after collisions, and merge through one integrator.
|
|
9
|
+
|
|
10
|
+
## Core Shape
|
|
11
|
+
|
|
12
|
+
```text
|
|
13
|
+
1 project
|
|
14
|
+
→ 1 shared backlog
|
|
15
|
+
→ 2–4 isolated worktrees or branches
|
|
16
|
+
→ each agent owns a small task card
|
|
17
|
+
→ conflicts trigger structured context exchange
|
|
18
|
+
→ one integrator merges
|
|
19
|
+
```
|
|
20
|
+
|
|
21
|
+
Agents should not mutate the same `main` checkout concurrently. Prefer isolated branches or worktrees:
|
|
22
|
+
|
|
23
|
+
```bash
|
|
24
|
+
git worktree add ../agent-a -b agent/a-task
|
|
25
|
+
git worktree add ../agent-b -b agent/b-task
|
|
26
|
+
git worktree add ../agent-c -b agent/c-task
|
|
27
|
+
```
|
|
28
|
+
|
|
29
|
+
## When To Use
|
|
30
|
+
|
|
31
|
+
Use this mode when:
|
|
32
|
+
|
|
33
|
+
- Work can be split into small file/domain scopes.
|
|
34
|
+
- Agents need to write code, docs, tests, or fixtures concurrently.
|
|
35
|
+
- A human or integrator-agent can merge patches.
|
|
36
|
+
- The project is not high-risk enough to justify a heavy orchestration platform.
|
|
37
|
+
|
|
38
|
+
Do not use this mode when:
|
|
39
|
+
|
|
40
|
+
- Tasks require the same public API files.
|
|
41
|
+
- The architecture direction is unsettled.
|
|
42
|
+
- The expected conflicts are semantic, not just file-level.
|
|
43
|
+
- No integrator is available.
|
|
44
|
+
|
|
45
|
+
## Agent Role Split
|
|
46
|
+
|
|
47
|
+
Prefer splitting agents by **mutation class**, not by unrelated features.
|
|
48
|
+
|
|
49
|
+
Stable split:
|
|
50
|
+
|
|
51
|
+
```text
|
|
52
|
+
Agent A: mutate behavior
|
|
53
|
+
Agent B: verify behavior
|
|
54
|
+
Agent C: describe behavior
|
|
55
|
+
Agent D: integrate behavior
|
|
56
|
+
```
|
|
57
|
+
|
|
58
|
+
Practical mappings:
|
|
59
|
+
|
|
60
|
+
- `2 agents`: implementation; tests/docs/review.
|
|
61
|
+
- `3 agents`: implementation; tests; docs plus review.
|
|
62
|
+
- `4 agents`: implementation; tests; docs/examples; integrator/refactor/audit.
|
|
63
|
+
|
|
64
|
+
Recommended roles:
|
|
65
|
+
|
|
66
|
+
- `Implementation Agent`: writes logic; avoids docs unless needed for the task.
|
|
67
|
+
- `Test Agent`: writes tests and may expose bugs; avoids changing production logic.
|
|
68
|
+
- `Docs Agent`: updates docs/spec/examples/comments; avoids code.
|
|
69
|
+
- `Review/Integrator Agent`: reviews patches, resolves conflicts, runs checks, and merges.
|
|
70
|
+
|
|
71
|
+
Dangerous split:
|
|
72
|
+
|
|
73
|
+
```text
|
|
74
|
+
Agent A: implement feature X
|
|
75
|
+
Agent B: implement feature Y
|
|
76
|
+
Agent C: refactor architecture
|
|
77
|
+
Agent D: clean up types
|
|
78
|
+
```
|
|
79
|
+
|
|
80
|
+
This creates overlapping semantic ownership. Prefer behavior/test/docs/integration separation so agents do not compete for the same memetic niche.
|
|
81
|
+
|
|
82
|
+
## Task Card
|
|
83
|
+
|
|
84
|
+
Every implementation agent gets a task card. The card is the unit of delegation.
|
|
85
|
+
|
|
86
|
+
```markdown
|
|
87
|
+
# Task
|
|
88
|
+
|
|
89
|
+
Goal:
|
|
90
|
+
|
|
91
|
+
- What needs to be done.
|
|
92
|
+
|
|
93
|
+
Allowed files:
|
|
94
|
+
|
|
95
|
+
- Src/lib/foo.ts
|
|
96
|
+
- Src/routes/game/+page.svelte
|
|
97
|
+
|
|
98
|
+
Avoid files:
|
|
99
|
+
|
|
100
|
+
- Src/lib/shared/types.ts
|
|
101
|
+
- Src/lib/stores/\*
|
|
102
|
+
|
|
103
|
+
Expected output:
|
|
104
|
+
|
|
105
|
+
- Patch
|
|
106
|
+
- Short summary
|
|
107
|
+
- Tests/checks run
|
|
108
|
+
- Touched files list
|
|
109
|
+
```
|
|
110
|
+
|
|
111
|
+
A task card should specify mutation zones, not just intent. The smaller the allowed file set, the less coordination machinery is needed.
|
|
112
|
+
|
|
113
|
+
Scope expansion is the main conflict generator. Agents must not opportunistically refactor unrelated code or silently edit outside the declared task. If an out-of-scope change is needed, write it as a new backlog item or ask the integrator to replan.
|
|
114
|
+
|
|
115
|
+
## Backlog Partitioning
|
|
116
|
+
|
|
117
|
+
Use explicit task IDs when a coordinator will split backlog work across agents. File position is too fragile once agents start editing, while stable IDs can appear in scope files, branch names, handoffs, and review reports.
|
|
118
|
+
|
|
119
|
+
Recommended task card shape:
|
|
120
|
+
|
|
121
|
+
```markdown
|
|
122
|
+
## T-001: Add trust warnings
|
|
123
|
+
|
|
124
|
+
Labels:
|
|
125
|
+
|
|
126
|
+
- Docs
|
|
127
|
+
- Runtime
|
|
128
|
+
|
|
129
|
+
Allowed files:
|
|
130
|
+
|
|
131
|
+
- Docs/command-templates.md
|
|
132
|
+
- Lib/schema.ts
|
|
133
|
+
|
|
134
|
+
Avoid files:
|
|
135
|
+
|
|
136
|
+
- Package.json
|
|
137
|
+
|
|
138
|
+
Exit:
|
|
139
|
+
|
|
140
|
+
- Docs explain the trusted executable boundary.
|
|
141
|
+
- Tests cover warning detection.
|
|
142
|
+
```
|
|
143
|
+
|
|
144
|
+
Partition by independent mutation zones first, then by effort. Do not split one shared public contract across agents unless a single integrator owns that contract. If task independence is uncertain, assign the risky task to the integrator or run a planning/review swarm before implementation.
|
|
145
|
+
|
|
146
|
+
## Collaborative Branch Subagents
|
|
147
|
+
|
|
148
|
+
Use this pattern when a coordinator needs 2-4 implementation agents to work from one backlog without sharing a mutable checkout.
|
|
149
|
+
|
|
150
|
+
```text
|
|
151
|
+
coordinator reads backlog
|
|
152
|
+
→ coordinator writes one scope file per agent
|
|
153
|
+
→ local async-run adapter starts isolated clone or worktree branches
|
|
154
|
+
→ each subagent works only inside its branch workspace
|
|
155
|
+
→ runner verifies commit and pushes branch
|
|
156
|
+
→ coordinator reviews ready branches
|
|
157
|
+
→ integrator merges through the normal project flow
|
|
158
|
+
```
|
|
159
|
+
|
|
160
|
+
This is primarily a branch artifact protocol, not real-time agent chat. Subagents do not coordinate with each other during execution. They communicate by branch commits, handoff files, conflict reports, and integrator review. When the local runtime supports resumable sessions, a subagent may also use a coordinator checkpoint to ask the orchestrator for a bounded decision without losing its own context.
|
|
161
|
+
|
|
162
|
+
Coordinator responsibilities:
|
|
163
|
+
|
|
164
|
+
1. Read the canonical backlog and project instructions.
|
|
165
|
+
2. Select independent task groups with stable task IDs.
|
|
166
|
+
3. Write one scope file per agent with goal, allowed files, avoided files, exit criteria, checks, and branch name.
|
|
167
|
+
4. Start the local async-run adapter.
|
|
168
|
+
5. Inspect run status and logs until terminal.
|
|
169
|
+
6. Review successful branch diffs before merge.
|
|
170
|
+
7. Record failed or out-of-scope work back into the backlog.
|
|
171
|
+
|
|
172
|
+
Scope file rules:
|
|
173
|
+
|
|
174
|
+
- Prefer local files over large inline prompts.
|
|
175
|
+
- Include task IDs and exact workspace path.
|
|
176
|
+
- Include allowed and avoided file lists.
|
|
177
|
+
- Require the agent to restate task IDs, allowed files, and exit criteria before editing.
|
|
178
|
+
- State that commit and push may be handled by the runner when the local adapter owns git finalization.
|
|
179
|
+
|
|
180
|
+
Subagent instruction core:
|
|
181
|
+
|
|
182
|
+
```text
|
|
183
|
+
Work only in this repository workspace: <work_dir>.
|
|
184
|
+
Read your assigned scope from: <scope_file>.
|
|
185
|
+
Before editing, restate task IDs, allowed files, avoided files, and exit criteria.
|
|
186
|
+
Do not edit outside declared scope.
|
|
187
|
+
If an out-of-scope change is required, write it as a backlog note or handoff risk.
|
|
188
|
+
If blocked by a coordinator-only decision and the runtime supports checkpoints, emit a bounded Coordinator Checkpoint instead of discarding your context.
|
|
189
|
+
Run the checks named in the scope when practical.
|
|
190
|
+
Write a concise handoff report before finishing.
|
|
191
|
+
```
|
|
192
|
+
|
|
193
|
+
## Coordinator Checkpoints
|
|
194
|
+
|
|
195
|
+
A coordinator checkpoint is a deliberate pause, not free-form chat. It is useful when the subagent has built local context that should not be thrown away, but continuing requires a coordinator decision: scope change, ambiguous product choice, conflict policy, credential/account boundary, or release/publish permission.
|
|
196
|
+
|
|
197
|
+
Target behavior for capable adapters:
|
|
198
|
+
|
|
199
|
+
```text
|
|
200
|
+
subagent reaches a decision gate
|
|
201
|
+
→ subagent emits Coordinator Checkpoint
|
|
202
|
+
→ runner pauses the subagent session without dropping context
|
|
203
|
+
→ coordinator answers the bounded question
|
|
204
|
+
→ runner resumes the same subagent context with the answer
|
|
205
|
+
→ subagent records the decision in its handoff
|
|
206
|
+
```
|
|
207
|
+
|
|
208
|
+
Checkpoint payload:
|
|
209
|
+
|
|
210
|
+
```markdown
|
|
211
|
+
# Coordinator Checkpoint
|
|
212
|
+
|
|
213
|
+
Agent:
|
|
214
|
+
Task IDs:
|
|
215
|
+
Workspace:
|
|
216
|
+
Question:
|
|
217
|
+
Why coordinator input is needed:
|
|
218
|
+
Options considered:
|
|
219
|
+
Recommended option:
|
|
220
|
+
Risk if guessed:
|
|
221
|
+
State to preserve:
|
|
222
|
+
```
|
|
223
|
+
|
|
224
|
+
Coordinator reply should answer only the checkpoint question. It should not inject broad new context unless the subagent explicitly asked for it. If the runtime cannot resume the same subagent context, write the checkpoint as an artifact, stop the branch as degraded, and let the coordinator replan or launch a new subagent with the checkpoint included.
|
|
225
|
+
|
|
226
|
+
Coordinator prompt template:
|
|
227
|
+
|
|
228
|
+
```text
|
|
229
|
+
Read the project backlog and instructions.
|
|
230
|
+
Partition actionable work into <N> independent task groups.
|
|
231
|
+
Prefer groups with non-overlapping allowed files.
|
|
232
|
+
Write one scope file per agent under <run_dir>/scopes/.
|
|
233
|
+
Each scope file must include task IDs, goal, allowed files, avoided files, exit criteria, checks, branch name, and handoff path.
|
|
234
|
+
Do not start execution until every scope has a clear branch artifact contract.
|
|
235
|
+
```
|
|
236
|
+
|
|
237
|
+
Scope file template:
|
|
238
|
+
|
|
239
|
+
```markdown
|
|
240
|
+
# Scope: agent-01
|
|
241
|
+
|
|
242
|
+
Run:
|
|
243
|
+
Branch:
|
|
244
|
+
Workspace:
|
|
245
|
+
Handoff path:
|
|
246
|
+
|
|
247
|
+
Task IDs:
|
|
248
|
+
|
|
249
|
+
- T-001
|
|
250
|
+
- T-002
|
|
251
|
+
|
|
252
|
+
Goal:
|
|
253
|
+
|
|
254
|
+
- ...
|
|
255
|
+
|
|
256
|
+
Allowed files:
|
|
257
|
+
|
|
258
|
+
- ...
|
|
259
|
+
|
|
260
|
+
Avoid files:
|
|
261
|
+
|
|
262
|
+
- ...
|
|
263
|
+
|
|
264
|
+
Exit criteria:
|
|
265
|
+
|
|
266
|
+
- ...
|
|
267
|
+
|
|
268
|
+
Checks:
|
|
269
|
+
|
|
270
|
+
- ...
|
|
271
|
+
|
|
272
|
+
Out-of-scope handling:
|
|
273
|
+
|
|
274
|
+
- Do not edit outside allowed files.
|
|
275
|
+
- Record required out-of-scope changes in the handoff risk section.
|
|
276
|
+
```
|
|
277
|
+
|
|
278
|
+
Branch artifact contract:
|
|
279
|
+
|
|
280
|
+
- Success means the expected branch exists, contains at least one commit for the assigned task group, and has been pushed.
|
|
281
|
+
- The branch name should include the run id and task range or agent id.
|
|
282
|
+
- The handoff report should name task IDs, touched files, checks, risks, and follow-up.
|
|
283
|
+
- A branch with no commit is not a successful artifact, even if the subagent exits with code 0.
|
|
284
|
+
|
|
285
|
+
Partial failure is normal. Treat a run with some ready branches and some failed branches as degraded, not as total failure. The coordinator should report ready branches, failed branches, failure reasons, and the safest next action for each failed scope.
|
|
286
|
+
|
|
287
|
+
## Soft-Lock Manifest
|
|
288
|
+
|
|
289
|
+
For 2–4 agents, start with a simple repository-local manifest rather than a lock server.
|
|
290
|
+
|
|
291
|
+
Suggested path:
|
|
292
|
+
|
|
293
|
+
```text
|
|
294
|
+
.agents/locks.md
|
|
295
|
+
```
|
|
296
|
+
|
|
297
|
+
Example:
|
|
298
|
+
|
|
299
|
+
```markdown
|
|
300
|
+
# Agent Locks
|
|
301
|
+
|
|
302
|
+
## agent-a
|
|
303
|
+
|
|
304
|
+
Task: fix scheduler tests
|
|
305
|
+
Owns:
|
|
306
|
+
|
|
307
|
+
- Pallets/aaa/src/tests/scheduler/\*
|
|
308
|
+
- Pallets/aaa/src/mock.rs
|
|
309
|
+
|
|
310
|
+
## agent-b
|
|
311
|
+
|
|
312
|
+
Task: update fee model docs
|
|
313
|
+
Owns:
|
|
314
|
+
|
|
315
|
+
- Docs/aaa/fees.md
|
|
316
|
+
- Docs/aaa/spec.md
|
|
317
|
+
|
|
318
|
+
## agent-c
|
|
319
|
+
|
|
320
|
+
Task: refactor frontend card component
|
|
321
|
+
Owns:
|
|
322
|
+
|
|
323
|
+
- Src/lib/components/Card.svelte
|
|
324
|
+
```
|
|
325
|
+
|
|
326
|
+
Protocol:
|
|
327
|
+
|
|
328
|
+
1. Read `.agents/locks.md` before starting.
|
|
329
|
+
2. Add or update your section before editing.
|
|
330
|
+
3. Treat `Owns:` as a soft write claim.
|
|
331
|
+
4. Avoid another agent's owned files unless the integrator replans.
|
|
332
|
+
5. On completion, remove the section or mark it done.
|
|
333
|
+
|
|
334
|
+
This manifest is weaker than an automated lock adapter but easier for humans and agents to inspect. Use a runtime-backed lock protocol when automation, TTL, or conflict enforcement is needed.
|
|
335
|
+
|
|
336
|
+
## Exclusive Files
|
|
337
|
+
|
|
338
|
+
Some files create semantic conflicts even when Git merges cleanly. Require exclusive ownership for public contracts and central runtime boundaries.
|
|
339
|
+
|
|
340
|
+
Examples:
|
|
341
|
+
|
|
342
|
+
```text
|
|
343
|
+
src/lib/types/*
|
|
344
|
+
pallets/*/src/lib.rs
|
|
345
|
+
runtime/src/*
|
|
346
|
+
docs/spec/*
|
|
347
|
+
package.json
|
|
348
|
+
Cargo.toml
|
|
349
|
+
```
|
|
350
|
+
|
|
351
|
+
Project-local protocol should define its own exclusive files. If a task needs one, assign it to a single agent or the integrator.
|
|
352
|
+
|
|
353
|
+
## Conflict Types
|
|
354
|
+
|
|
355
|
+
### Merge Conflict
|
|
356
|
+
|
|
357
|
+
Git cannot combine two edits to the same file.
|
|
358
|
+
|
|
359
|
+
Response:
|
|
360
|
+
|
|
361
|
+
1. Both agents produce conflict reports.
|
|
362
|
+
2. Resolver/integrator reads both reports.
|
|
363
|
+
3. Resolver merges patch.
|
|
364
|
+
4. Original agents review affected files only.
|
|
365
|
+
|
|
366
|
+
### Semantic Conflict
|
|
367
|
+
|
|
368
|
+
Files may merge, but meaning diverges. Example: one agent changes an API while another writes code against the old API.
|
|
369
|
+
|
|
370
|
+
Response:
|
|
371
|
+
|
|
372
|
+
1. Stop affected workers.
|
|
373
|
+
2. Integrator decides whether the backlog task is invalidated.
|
|
374
|
+
3. Split or replan before more implementation.
|
|
375
|
+
|
|
376
|
+
### Architecture Conflict
|
|
377
|
+
|
|
378
|
+
The task decomposition itself is wrong.
|
|
379
|
+
|
|
380
|
+
Response:
|
|
381
|
+
|
|
382
|
+
1. Stop workers on affected scopes.
|
|
383
|
+
2. Re-open planning.
|
|
384
|
+
3. Produce new task cards with corrected ownership.
|
|
385
|
+
|
|
386
|
+
## Conflict Handshake Protocol
|
|
387
|
+
|
|
388
|
+
Agents should not freely negotiate in long context-sharing threads. Exchange semantic deltas in a bounded format.
|
|
389
|
+
|
|
390
|
+
```markdown
|
|
391
|
+
# Conflict Report
|
|
392
|
+
|
|
393
|
+
Agent:
|
|
394
|
+
Task:
|
|
395
|
+
Conflicting files:
|
|
396
|
+
|
|
397
|
+
- ...
|
|
398
|
+
|
|
399
|
+
What I changed:
|
|
400
|
+
|
|
401
|
+
- ...
|
|
402
|
+
|
|
403
|
+
Why I changed it:
|
|
404
|
+
|
|
405
|
+
- ...
|
|
406
|
+
|
|
407
|
+
What I need preserved:
|
|
408
|
+
|
|
409
|
+
- ...
|
|
410
|
+
|
|
411
|
+
Can safely discard:
|
|
412
|
+
|
|
413
|
+
- ...
|
|
414
|
+
|
|
415
|
+
Suggested resolution:
|
|
416
|
+
|
|
417
|
+
- ...
|
|
418
|
+
```
|
|
419
|
+
|
|
420
|
+
Resolution flow:
|
|
421
|
+
|
|
422
|
+
```text
|
|
423
|
+
Agent A hits conflict with Agent B
|
|
424
|
+
→ Agent A writes Conflict Report
|
|
425
|
+
→ Agent B writes Conflict Report
|
|
426
|
+
→ Integrator/resolver reads both
|
|
427
|
+
→ Resolver creates merged patch
|
|
428
|
+
→ Original agents review only affected files
|
|
429
|
+
```
|
|
430
|
+
|
|
431
|
+
The goal is to exchange intent and invariants, not to let agents recursively debate.
|
|
432
|
+
|
|
433
|
+
## Scope Expansion Rule
|
|
434
|
+
|
|
435
|
+
Multi-agent work is stricter than solo work.
|
|
436
|
+
|
|
437
|
+
Required instruction for implementation agents:
|
|
438
|
+
|
|
439
|
+
```text
|
|
440
|
+
Do not opportunistically refactor unrelated code.
|
|
441
|
+
Do not modify files outside declared scope.
|
|
442
|
+
If you discover a needed out-of-scope change, record it as a backlog item or conflict note.
|
|
443
|
+
```
|
|
444
|
+
|
|
445
|
+
This is the difference between useful parallelism and diff chaos.
|
|
446
|
+
|
|
447
|
+
## Handoff Report
|
|
448
|
+
|
|
449
|
+
Each agent writes a concise handoff after finishing.
|
|
450
|
+
|
|
451
|
+
Suggested path:
|
|
452
|
+
|
|
453
|
+
```text
|
|
454
|
+
.agents/handoff/agent-a.md
|
|
455
|
+
```
|
|
456
|
+
|
|
457
|
+
Template:
|
|
458
|
+
|
|
459
|
+
```markdown
|
|
460
|
+
# Handoff: agent-a
|
|
461
|
+
|
|
462
|
+
Task:
|
|
463
|
+
Branch/worktree:
|
|
464
|
+
|
|
465
|
+
Summary:
|
|
466
|
+
|
|
467
|
+
- ...
|
|
468
|
+
|
|
469
|
+
Touched files:
|
|
470
|
+
|
|
471
|
+
- ...
|
|
472
|
+
|
|
473
|
+
Tests/checks:
|
|
474
|
+
|
|
475
|
+
- ...
|
|
476
|
+
|
|
477
|
+
Behavior changes:
|
|
478
|
+
|
|
479
|
+
- ...
|
|
480
|
+
|
|
481
|
+
Risks / follow-up:
|
|
482
|
+
|
|
483
|
+
- ...
|
|
484
|
+
|
|
485
|
+
Integrator notes:
|
|
486
|
+
|
|
487
|
+
- What must be preserved during merge.
|
|
488
|
+
```
|
|
489
|
+
|
|
490
|
+
Example:
|
|
491
|
+
|
|
492
|
+
```markdown
|
|
493
|
+
# Agent A Handoff
|
|
494
|
+
|
|
495
|
+
Task:
|
|
496
|
+
A1: Add tests for scheduler window expiry
|
|
497
|
+
|
|
498
|
+
Touched files:
|
|
499
|
+
|
|
500
|
+
- Pallets/aaa/src/tests/scheduler/window.rs
|
|
501
|
+
|
|
502
|
+
Summary:
|
|
503
|
+
|
|
504
|
+
- Added tests for inclusive window end.
|
|
505
|
+
- Added test for close only when current_block > end.
|
|
506
|
+
|
|
507
|
+
Checks:
|
|
508
|
+
|
|
509
|
+
- Cargo test -p pallet-aaa scheduler_window
|
|
510
|
+
|
|
511
|
+
Open questions:
|
|
512
|
+
|
|
513
|
+
- None.
|
|
514
|
+
|
|
515
|
+
Conflict notes:
|
|
516
|
+
|
|
517
|
+
- Does not touch runtime logic.
|
|
518
|
+
```
|
|
519
|
+
|
|
520
|
+
## Runner Adapter Contract
|
|
521
|
+
|
|
522
|
+
A local branch runner may be useful, but it is adapter policy rather than portable Swarm core. Keep concrete model names, tool allowlists, async-run syntax, and runtime-specific CLI invocation outside this skill.
|
|
523
|
+
|
|
524
|
+
Minimum runner behavior:
|
|
525
|
+
|
|
526
|
+
1. Clone or create an isolated worktree from the requested repo and base branch.
|
|
527
|
+
2. Create the expected feature branch.
|
|
528
|
+
3. Run one subagent with the prepared scope file and bounded tool access.
|
|
529
|
+
4. Verify the current branch is still the expected branch.
|
|
530
|
+
5. Verify there are intentional changes before commit.
|
|
531
|
+
6. Commit with a task-aware summary when the adapter owns git finalization.
|
|
532
|
+
7. Push the expected branch.
|
|
533
|
+
8. Emit a structured result with branch, commit, pushed status, handoff path, checks, and failure reason.
|
|
534
|
+
|
|
535
|
+
Recommended subagent tools are the smallest set that can complete the task, usually read, edit/write, and shell validation. Avoid broad external account tools inside implementation subagents. External actions such as opening pull requests, merging, publishing, or commenting belong to the coordinator or integrator after review.
|
|
536
|
+
|
|
537
|
+
Runner exit policy:
|
|
538
|
+
|
|
539
|
+
- Exit 0 only after commit verification and successful push when the runner owns git finalization.
|
|
540
|
+
- Exit non-zero when clone, checkout, subagent execution, commit verification, or push fails.
|
|
541
|
+
- A failed branch should not cancel sibling branches in the same async fanout.
|
|
542
|
+
- Timeouts should preserve logs and any handoff artifacts for coordinator inspection.
|
|
543
|
+
|
|
544
|
+
## Integrator Protocol
|
|
545
|
+
|
|
546
|
+
The integrator is the only actor that merges to the shared target branch.
|
|
547
|
+
|
|
548
|
+
Integrator steps:
|
|
549
|
+
|
|
550
|
+
1. Read backlog, locks, and handoffs.
|
|
551
|
+
2. Merge one branch at a time.
|
|
552
|
+
3. Resolve conflicts using conflict reports, not guesses.
|
|
553
|
+
4. Run the project's validation gates.
|
|
554
|
+
5. Ask original agents to review affected files when conflict resolution changed their work.
|
|
555
|
+
6. Produce final summary: merged tasks, tests, touched files, residual risks.
|
|
556
|
+
|
|
557
|
+
## Effective Protocol
|
|
558
|
+
|
|
559
|
+
```markdown
|
|
560
|
+
# Multi-Agent Protocol
|
|
561
|
+
|
|
562
|
+
1. Each agent MUST work in a separate branch or worktree.
|
|
563
|
+
2. Before editing, each agent MUST declare task, intended files, forbidden files, and expected output.
|
|
564
|
+
3. Agents SHOULD avoid files already claimed in `.agents/locks.md`.
|
|
565
|
+
4. Public API, storage, runtime, schema, and spec files require exclusive ownership.
|
|
566
|
+
5. Each agent MUST produce a handoff note after completion: touched files, semantic changes, checks run, unresolved risks.
|
|
567
|
+
6. If a conflict occurs, both agents MUST produce Conflict Reports.
|
|
568
|
+
7. Conflict resolution MUST preserve semantic intent, not merely compile.
|
|
569
|
+
8. Integrator merges patches into the shared target after checks pass.
|
|
570
|
+
9. No agent may silently expand task scope.
|
|
571
|
+
```
|
|
572
|
+
|
|
573
|
+
Context exchange rule:
|
|
574
|
+
|
|
575
|
+
```text
|
|
576
|
+
Before conflict: minimal shared context.
|
|
577
|
+
At conflict: compressed intent/diff/risk exchange.
|
|
578
|
+
After conflict: update backlog/locks.
|
|
579
|
+
```
|
|
580
|
+
|
|
581
|
+
Constant agent chat destroys independence. Conflict reports preserve the useful context without contaminating every worker.
|
|
582
|
+
|
|
583
|
+
## Minimal Directory
|
|
584
|
+
|
|
585
|
+
```text
|
|
586
|
+
.agents/
|
|
587
|
+
backlog.md
|
|
588
|
+
locks.md
|
|
589
|
+
protocol.md
|
|
590
|
+
handoff/
|
|
591
|
+
agent-a.md
|
|
592
|
+
agent-b.md
|
|
593
|
+
agent-c.md
|
|
594
|
+
```
|
|
595
|
+
|
|
596
|
+
This directory is optional. Use it when the repository lacks an existing coordination plane. If the project already has backlog, lock, and handoff conventions, reuse them instead.
|