opencode-dispatcher 0.2.0 → 0.2.1
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 +427 -104
- package/package.json +1 -1
- package/workflow/agents/executor.md +2 -2
package/README.md
CHANGED
|
@@ -1,79 +1,357 @@
|
|
|
1
1
|
# OpenCode Dispatcher
|
|
2
2
|
|
|
3
|
-
|
|
4
|
-
|
|
5
|
-
|
|
6
|
-
|
|
7
|
-
|
|
8
|
-
|
|
9
|
-
|
|
10
|
-
|
|
11
|
-
-
|
|
12
|
-
-
|
|
13
|
-
-
|
|
14
|
-
-
|
|
15
|
-
|
|
16
|
-
|
|
17
|
-
|
|
18
|
-
|
|
19
|
-
|
|
20
|
-
|
|
21
|
-
|
|
22
|
-
|
|
23
|
-
-
|
|
24
|
-
|
|
25
|
-
|
|
26
|
-
|
|
27
|
-
|
|
28
|
-
|
|
29
|
-
|
|
30
|
-
|
|
31
|
-
|
|
32
|
-
|
|
33
|
-
|
|
34
|
-
|
|
35
|
-
|
|
36
|
-
|
|
37
|
-
|
|
38
|
-
|
|
39
|
-
|
|
40
|
-
|
|
41
|
-
|
|
42
|
-
|
|
43
|
-
|
|
44
|
-
|
|
45
|
-
|
|
3
|
+
OpenCode Dispatcher is a workflow pack for OpenCode that adds specialist development agents coordinated through file-based task artifacts.
|
|
4
|
+
|
|
5
|
+
It is designed for substantial coding work where you want the agent workflow to be easier to inspect, resume, and validate.
|
|
6
|
+
|
|
7
|
+
Instead of relying on long chat history, Dispatcher keeps durable task state in your project:
|
|
8
|
+
|
|
9
|
+
```text
|
|
10
|
+
.ai/context.md
|
|
11
|
+
.ai/tasks/<NNN>-<task-id>/task-spec.md
|
|
12
|
+
.ai/tasks/<NNN>-<task-id>/implementation-report.md
|
|
13
|
+
.ai/tasks/<NNN>-<task-id>/validation-report.md
|
|
14
|
+
.ai/tasks/<NNN>-<task-id>/documentation-report.md
|
|
15
|
+
```
|
|
16
|
+
|
|
17
|
+
For tiny one-off edits or quick questions, plain OpenCode is often enough.
|
|
18
|
+
|
|
19
|
+
## What Dispatcher Changes
|
|
20
|
+
|
|
21
|
+
Plain OpenCode is usually a general-purpose agent workflow.
|
|
22
|
+
|
|
23
|
+
OpenCode Dispatcher adds a user-facing orchestrator and a set of specialist agents. The orchestrator talks with you, clarifies the request, decides how complex the work is, and routes to the smallest safe workflow.
|
|
24
|
+
|
|
25
|
+
Not every agent runs every time.
|
|
26
|
+
|
|
27
|
+
```mermaid
|
|
28
|
+
flowchart TD
|
|
29
|
+
User[User] --> Orchestrator[Orchestrator]
|
|
30
|
+
|
|
31
|
+
Orchestrator -->|Question or review| Direct[Direct answer]
|
|
32
|
+
Orchestrator -->|Tiny exact edit| Executor[Executor]
|
|
33
|
+
Orchestrator -->|Substantial task| Planner[Task Planner]
|
|
34
|
+
Orchestrator -->|External facts needed| Research[Research]
|
|
35
|
+
Orchestrator -->|Commit or push requested| Shipper[Shipper]
|
|
36
|
+
|
|
37
|
+
Research --> Orchestrator
|
|
38
|
+
Executor --> Orchestrator
|
|
39
|
+
|
|
40
|
+
Planner --> Spec[Task Spec]
|
|
41
|
+
Spec --> TestWriter{Test-first useful?}
|
|
42
|
+
TestWriter -->|Yes| Tests[Test Writer]
|
|
43
|
+
TestWriter -->|No| Implementer[Implementer]
|
|
44
|
+
Tests --> Implementer
|
|
45
|
+
Implementer --> Validator[Validator]
|
|
46
|
+
Validator --> Orchestrator
|
|
47
|
+
|
|
48
|
+
Shipper --> Orchestrator
|
|
49
|
+
```
|
|
50
|
+
|
|
51
|
+
The chat is used for coordination. The `.ai/` files become the source of truth for scoped work.
|
|
52
|
+
|
|
53
|
+
## Why Use It?
|
|
54
|
+
|
|
55
|
+
Dispatcher is useful when you want agent work to be:
|
|
56
|
+
|
|
57
|
+
* easier to inspect
|
|
58
|
+
* easier to resume later
|
|
59
|
+
* easier to validate against an approved scope
|
|
60
|
+
* less dependent on chat history
|
|
61
|
+
* separated by role boundaries
|
|
62
|
+
* safer for multi-step development work
|
|
63
|
+
* more suitable for git-tracked project artifacts
|
|
64
|
+
|
|
65
|
+
It helps answer questions like:
|
|
66
|
+
|
|
67
|
+
* What exactly was the agent asked to build?
|
|
68
|
+
* What files were relevant?
|
|
69
|
+
* What was explicitly out of scope?
|
|
70
|
+
* What tests or checks were expected?
|
|
71
|
+
* What did the implementer change?
|
|
72
|
+
* Did the validator check the result against the approved task?
|
|
73
|
+
|
|
74
|
+
## Compared to Plain OpenCode
|
|
75
|
+
|
|
76
|
+
| Dimension | Plain OpenCode | OpenCode Dispatcher |
|
|
77
|
+
| ------------ | --------------------------------- | --------------------------------------------- |
|
|
78
|
+
| Task scope | Usually carried in chat history | Stored in `.ai/tasks/<NNN>-<id>/task-spec.md` |
|
|
79
|
+
| Agent model | General-purpose agent | Specialist agents with role boundaries |
|
|
80
|
+
| Validation | Often implicit | Explicit validation against the task spec |
|
|
81
|
+
| Resumability | Requires reading chat history | Read the task spec and reports |
|
|
82
|
+
| Audit trail | Chat log | Git-trackable `.ai/` artifacts |
|
|
83
|
+
| Best for | Quick edits and one-off questions | Substantial features and multi-step work |
|
|
84
|
+
|
|
85
|
+
## Core Idea
|
|
86
|
+
|
|
87
|
+
Dispatcher separates live conversation from durable project state.
|
|
46
88
|
|
|
47
89
|
```mermaid
|
|
48
|
-
|
|
49
|
-
|
|
50
|
-
|
|
51
|
-
|
|
52
|
-
|
|
53
|
-
|
|
54
|
-
|
|
55
|
-
|
|
56
|
-
|
|
57
|
-
|
|
58
|
-
|
|
59
|
-
|
|
60
|
-
|
|
61
|
-
|
|
62
|
-
|
|
63
|
-
|
|
64
|
-
|
|
65
|
-
|
|
66
|
-
|
|
67
|
-
|
|
68
|
-
|
|
69
|
-
|
|
70
|
-
|
|
71
|
-
|
|
72
|
-
|
|
|
73
|
-
|
|
|
74
|
-
|
|
|
75
|
-
|
|
76
|
-
|
|
90
|
+
flowchart LR
|
|
91
|
+
Chat[Live chat] -->|Clarify and coordinate| Orchestrator[Orchestrator]
|
|
92
|
+
Orchestrator -->|Writes durable scope through agents| Artifacts[.ai task artifacts]
|
|
93
|
+
Artifacts --> Spec[task-spec.md]
|
|
94
|
+
Artifacts --> Reports[implementation / validation / documentation reports]
|
|
95
|
+
Artifacts --> Context[context.md]
|
|
96
|
+
```
|
|
97
|
+
|
|
98
|
+
The orchestrator stays user-facing. Specialist agents do the scoped work.
|
|
99
|
+
|
|
100
|
+
## Workflow Layers
|
|
101
|
+
|
|
102
|
+
Dispatcher installs several agents, but they are grouped by when they are used.
|
|
103
|
+
|
|
104
|
+
### Always Active
|
|
105
|
+
|
|
106
|
+
| Agent | Role | Used When |
|
|
107
|
+
| ------------ | ------------------------------------------------ | ------------- |
|
|
108
|
+
| Orchestrator | User-facing coordinator and state-machine router | Always active |
|
|
109
|
+
|
|
110
|
+
The orchestrator is the main entry point. It talks with you, clarifies the request, decides whether work is simple or substantial, delegates to the right specialist, and summarizes results.
|
|
111
|
+
|
|
112
|
+
### Fast Path
|
|
113
|
+
|
|
114
|
+
| Agent | Role | Used When |
|
|
115
|
+
| -------- | -------------------------------------- | --------------------------------------- |
|
|
116
|
+
| Executor | Performs tiny single-file atomic edits | For exact, unambiguous one-file changes |
|
|
117
|
+
|
|
118
|
+
The executor is used when a full task spec would be unnecessary.
|
|
119
|
+
|
|
120
|
+
Example:
|
|
121
|
+
|
|
122
|
+
```text
|
|
123
|
+
Change the button label in src/components/SubmitButton.tsx from "Submit" to "Save".
|
|
124
|
+
```
|
|
125
|
+
|
|
126
|
+
If the edit turns out to need multiple files, a new pattern, a dependency, or an architecture decision, the orchestrator escalates the work into the full task workflow.
|
|
127
|
+
|
|
128
|
+
### Full Task Workflow
|
|
129
|
+
|
|
130
|
+
| Agent | Role | Used When |
|
|
131
|
+
| ------------ | ---------------------------------------------------- | --------------------------------- |
|
|
132
|
+
| Task Planner | Creates task specs and decomposes multi-unit work | Before substantial implementation |
|
|
133
|
+
| Implementer | Edits source code according to an approved task spec | After planning |
|
|
134
|
+
| Validator | Checks completed work against the task spec | After non-trivial implementation |
|
|
135
|
+
|
|
136
|
+
This is the main route for substantial development work.
|
|
137
|
+
|
|
138
|
+
```mermaid
|
|
139
|
+
sequenceDiagram
|
|
140
|
+
participant U as User
|
|
141
|
+
participant O as Orchestrator
|
|
142
|
+
participant P as Task Planner
|
|
143
|
+
participant I as Implementer
|
|
144
|
+
participant V as Validator
|
|
145
|
+
|
|
146
|
+
U->>O: Describe feature or fix
|
|
147
|
+
O->>U: Clarify scope if needed
|
|
148
|
+
O->>P: Create task spec
|
|
149
|
+
P-->>O: task-spec.md
|
|
150
|
+
O->>I: Implement approved spec
|
|
151
|
+
I-->>O: implementation-report.md
|
|
152
|
+
O->>V: Validate against task spec
|
|
153
|
+
V-->>O: validation-report.md
|
|
154
|
+
O-->>U: Summary and next step
|
|
155
|
+
```
|
|
156
|
+
|
|
157
|
+
The task planner creates the approved scope:
|
|
158
|
+
|
|
159
|
+
```text
|
|
160
|
+
.ai/tasks/<NNN>-<task-id>/task-spec.md
|
|
161
|
+
```
|
|
162
|
+
|
|
163
|
+
The implementer makes the smallest correct change according to that scope.
|
|
164
|
+
|
|
165
|
+
The validator checks the completed work against the approved scope and writes:
|
|
166
|
+
|
|
167
|
+
```text
|
|
168
|
+
.ai/tasks/<NNN>-<task-id>/validation-report.md
|
|
169
|
+
```
|
|
170
|
+
|
|
171
|
+
### Conditional Agents
|
|
172
|
+
|
|
173
|
+
| Agent | Role | Used When |
|
|
174
|
+
| ------------- | ----------------------------------------------------------- | ------------------------------------- |
|
|
175
|
+
| Test Writer | Writes tests from testable acceptance criteria | When a test-first flow is useful |
|
|
176
|
+
| Documentation | Updates docs, context, decisions, and documentation reports | When documentation work is needed |
|
|
177
|
+
| Research | Gathers external facts, comparisons, and best practices | When source-backed evidence is needed |
|
|
178
|
+
|
|
179
|
+
These agents are not part of every task.
|
|
180
|
+
|
|
181
|
+
The test writer is used when the task has clear testable acceptance criteria and writing tests first would improve correctness.
|
|
182
|
+
|
|
183
|
+
The documentation agent is used when the task needs README updates, project context updates, decision notes, changelog entries, or documentation reports.
|
|
184
|
+
|
|
185
|
+
The research agent is used when a decision depends on external facts such as official documentation, vendor behaviour, pricing, APIs, or current best practices.
|
|
186
|
+
|
|
187
|
+
### Bootstrap and Shipping
|
|
188
|
+
|
|
189
|
+
| Agent | Role | Used When |
|
|
190
|
+
| ------- | -------------------------------- | ------------------------- |
|
|
191
|
+
| Init | Bootstraps `.ai/context.md` | First use in a project |
|
|
192
|
+
| Shipper | Handles git commit and push only | When explicitly requested |
|
|
193
|
+
|
|
194
|
+
The init agent is used when a project does not yet have `.ai/context.md`.
|
|
195
|
+
|
|
196
|
+
The shipper is never used automatically. It only commits or pushes when you explicitly ask for git shipping work.
|
|
197
|
+
|
|
198
|
+
## Common Routes
|
|
199
|
+
|
|
200
|
+
### Ask a Question
|
|
201
|
+
|
|
202
|
+
```mermaid
|
|
203
|
+
flowchart LR
|
|
204
|
+
User --> Orchestrator --> Answer[Direct answer]
|
|
205
|
+
```
|
|
206
|
+
|
|
207
|
+
Used for explanations, reviews, comparisons, and planning advice.
|
|
208
|
+
|
|
209
|
+
### Tiny Edit
|
|
210
|
+
|
|
211
|
+
```mermaid
|
|
212
|
+
flowchart LR
|
|
213
|
+
User --> Orchestrator --> Executor --> Orchestrator --> Summary[Summary]
|
|
214
|
+
```
|
|
215
|
+
|
|
216
|
+
Used for exact, single-file changes.
|
|
217
|
+
|
|
218
|
+
### Substantial Feature or Fix
|
|
219
|
+
|
|
220
|
+
```mermaid
|
|
221
|
+
flowchart LR
|
|
222
|
+
User --> Orchestrator --> Planner[Task Planner]
|
|
223
|
+
Planner --> Spec[task-spec.md]
|
|
224
|
+
Spec --> Implementer
|
|
225
|
+
Implementer --> Report[implementation-report.md]
|
|
226
|
+
Report --> Validator
|
|
227
|
+
Validator --> Validation[validation-report.md]
|
|
228
|
+
Validation --> Orchestrator --> Summary[Summary]
|
|
229
|
+
```
|
|
230
|
+
|
|
231
|
+
Used for substantial implementation work with task artifacts and validation.
|
|
232
|
+
|
|
233
|
+
### Test-First Feature
|
|
234
|
+
|
|
235
|
+
```mermaid
|
|
236
|
+
flowchart LR
|
|
237
|
+
User --> Orchestrator --> Planner[Task Planner]
|
|
238
|
+
Planner --> Spec[task-spec.md]
|
|
239
|
+
Spec --> TestWriter[Test Writer]
|
|
240
|
+
TestWriter --> Tests[Test files]
|
|
241
|
+
Tests --> Implementer
|
|
242
|
+
Implementer --> Validator
|
|
243
|
+
Validator --> Orchestrator --> Summary[Summary]
|
|
244
|
+
```
|
|
245
|
+
|
|
246
|
+
Used when acceptance criteria can be encoded as tests before implementation.
|
|
247
|
+
|
|
248
|
+
### Research-Backed Change
|
|
249
|
+
|
|
250
|
+
```mermaid
|
|
251
|
+
flowchart LR
|
|
252
|
+
User --> Orchestrator --> Research
|
|
253
|
+
Research --> Findings[Findings and recommendation]
|
|
254
|
+
Findings --> Orchestrator
|
|
255
|
+
Orchestrator --> Planner[Task Planner]
|
|
256
|
+
Planner --> Implementer
|
|
257
|
+
Implementer --> Validator
|
|
258
|
+
Validator --> Orchestrator --> Summary[Summary]
|
|
259
|
+
```
|
|
260
|
+
|
|
261
|
+
Used when implementation depends on external facts or source-backed technical decisions.
|
|
262
|
+
|
|
263
|
+
### Documentation Task
|
|
264
|
+
|
|
265
|
+
```mermaid
|
|
266
|
+
flowchart LR
|
|
267
|
+
User --> Orchestrator --> Planner[Task Planner]
|
|
268
|
+
Planner --> Documentation
|
|
269
|
+
Documentation --> DocReport[documentation-report.md]
|
|
270
|
+
DocReport --> Validator
|
|
271
|
+
Validator --> Orchestrator --> Summary[Summary]
|
|
272
|
+
```
|
|
273
|
+
|
|
274
|
+
Used for substantial documentation work that should be scoped and validated.
|
|
275
|
+
|
|
276
|
+
### Commit or Push
|
|
277
|
+
|
|
278
|
+
```mermaid
|
|
279
|
+
flowchart LR
|
|
280
|
+
User --> Orchestrator --> Shipper --> Orchestrator --> Summary[Summary]
|
|
281
|
+
```
|
|
282
|
+
|
|
283
|
+
Used only when explicitly requested.
|
|
284
|
+
|
|
285
|
+
## Project Artifacts
|
|
286
|
+
|
|
287
|
+
Dispatcher stores durable project and task state under `.ai/`.
|
|
288
|
+
|
|
289
|
+
### Project Context
|
|
290
|
+
|
|
291
|
+
```text
|
|
292
|
+
.ai/context.md
|
|
293
|
+
```
|
|
294
|
+
|
|
295
|
+
Stores durable project facts such as:
|
|
296
|
+
|
|
297
|
+
* test framework
|
|
298
|
+
* test runner command
|
|
299
|
+
* test file patterns
|
|
300
|
+
* UI framework
|
|
301
|
+
* styling conventions
|
|
302
|
+
* naming conventions
|
|
303
|
+
* file layout
|
|
304
|
+
* project-specific rules
|
|
305
|
+
* stable decisions
|
|
306
|
+
|
|
307
|
+
### Task Scope
|
|
308
|
+
|
|
309
|
+
```text
|
|
310
|
+
.ai/tasks/<NNN>-<task-id>/task-spec.md
|
|
311
|
+
```
|
|
312
|
+
|
|
313
|
+
Stores the approved task scope, including:
|
|
314
|
+
|
|
315
|
+
* scope
|
|
316
|
+
* non-goals
|
|
317
|
+
* testable acceptance criteria
|
|
318
|
+
* inspectable acceptance criteria
|
|
319
|
+
* relevant files
|
|
320
|
+
* validation plan
|
|
321
|
+
|
|
322
|
+
### Task Reports
|
|
323
|
+
|
|
324
|
+
```text
|
|
325
|
+
.ai/tasks/<NNN>-<task-id>/implementation-report.md
|
|
326
|
+
.ai/tasks/<NNN>-<task-id>/validation-report.md
|
|
327
|
+
.ai/tasks/<NNN>-<task-id>/documentation-report.md
|
|
328
|
+
```
|
|
329
|
+
|
|
330
|
+
Reports capture what changed, what was verified, and what remains open.
|
|
331
|
+
|
|
332
|
+
## First Use in a Project
|
|
333
|
+
|
|
334
|
+
1. Install Dispatcher.
|
|
335
|
+
2. Restart OpenCode.
|
|
336
|
+
3. Open your project in OpenCode.
|
|
337
|
+
4. If the project does not already have `.ai/context.md`, the orchestrator will initialize project context before substantial work.
|
|
338
|
+
5. For substantial work, ask the orchestrator to create a task spec first.
|
|
339
|
+
6. Review or approve the task spec.
|
|
340
|
+
7. Ask the orchestrator to implement and validate the approved task.
|
|
341
|
+
|
|
342
|
+
Example:
|
|
343
|
+
|
|
344
|
+
```text
|
|
345
|
+
Create a task spec for improving the settings page, then wait for approval.
|
|
346
|
+
```
|
|
347
|
+
|
|
348
|
+
After approving the spec:
|
|
349
|
+
|
|
350
|
+
```text
|
|
351
|
+
Implement the approved task spec at .ai/tasks/001-settings-page/task-spec.md and run validation.
|
|
352
|
+
```
|
|
353
|
+
|
|
354
|
+
## Installation
|
|
77
355
|
|
|
78
356
|
Install from the npm registry:
|
|
79
357
|
|
|
@@ -81,9 +359,13 @@ Install from the npm registry:
|
|
|
81
359
|
npx opencode-dispatcher install
|
|
82
360
|
```
|
|
83
361
|
|
|
84
|
-
After installing, restart OpenCode so it reloads
|
|
362
|
+
After installing, restart OpenCode so it reloads your global configuration from:
|
|
85
363
|
|
|
86
|
-
|
|
364
|
+
```text
|
|
365
|
+
~/.config/opencode
|
|
366
|
+
```
|
|
367
|
+
|
|
368
|
+
## Install from Source
|
|
87
369
|
|
|
88
370
|
```bash
|
|
89
371
|
npm run check
|
|
@@ -103,43 +385,62 @@ The default installer command is `install`, so this is also valid:
|
|
|
103
385
|
node ./bin/install.js
|
|
104
386
|
```
|
|
105
387
|
|
|
106
|
-
##
|
|
107
|
-
|
|
108
|
-
1. Run the install command.
|
|
109
|
-
2. Restart OpenCode so it reloads `~/.config/opencode`, then open the project.
|
|
110
|
-
3. If the project does not already have `.ai/context.md`, the orchestrator initializes `.ai/` before substantial work.
|
|
111
|
-
4. For substantial work, ask for a task spec first. Example: `Create a task spec for improving the settings page, then wait for approval.`
|
|
112
|
-
5. After approving the task spec, ask the orchestrator to implement and validate it. Example: `Implement the approved task spec at .ai/tasks/001-settings-page/task-spec.md and run validation.`
|
|
113
|
-
|
|
114
|
-
The workflow treats live chat as coordination. Durable details belong in `.ai/context.md`, `.ai/tasks/<NNN>-<task-id>/task-spec.md`, and task reports such as `implementation-report.md`, `documentation-report.md`, and `validation-report.md`.
|
|
388
|
+
## What Gets Installed
|
|
115
389
|
|
|
116
|
-
|
|
117
|
-
|
|
118
|
-
The installer copies this managed payload into `~/.config/opencode`:
|
|
390
|
+
The installer copies Dispatcher's managed payload into:
|
|
119
391
|
|
|
120
392
|
```text
|
|
121
393
|
~/.config/opencode/agents/
|
|
122
394
|
```
|
|
123
395
|
|
|
124
|
-
Current
|
|
396
|
+
Current payloads include agents for:
|
|
397
|
+
|
|
398
|
+
* orchestration
|
|
399
|
+
* initialization
|
|
400
|
+
* task planning
|
|
401
|
+
* test writing
|
|
402
|
+
* implementation
|
|
403
|
+
* documentation
|
|
404
|
+
* validation
|
|
405
|
+
* research
|
|
406
|
+
* shipping
|
|
407
|
+
* tiny atomic edits
|
|
125
408
|
|
|
126
|
-
|
|
409
|
+
The installer does **not** install or manage:
|
|
127
410
|
|
|
128
|
-
|
|
411
|
+
* provider configuration
|
|
412
|
+
* model settings
|
|
413
|
+
* secrets
|
|
414
|
+
* project dependencies
|
|
415
|
+
* git configuration
|
|
416
|
+
* `opencode.jsonc`
|
|
417
|
+
* `node_modules`
|
|
418
|
+
* global skills
|
|
419
|
+
* project templates
|
|
129
420
|
|
|
130
|
-
## Install
|
|
421
|
+
## Install Safety
|
|
131
422
|
|
|
132
|
-
Before copying a managed path, the installer backs up any existing path beside it
|
|
423
|
+
Before copying a managed path, the installer backs up any existing path beside it using a timestamped `.bak-*` suffix.
|
|
133
424
|
|
|
134
|
-
Example backup
|
|
425
|
+
Example backup:
|
|
135
426
|
|
|
136
427
|
```text
|
|
137
428
|
~/.config/opencode/agents.bak-2026-06-07T12-34-56-789Z
|
|
138
429
|
```
|
|
139
430
|
|
|
140
|
-
|
|
431
|
+
The installer then overlays the Dispatcher payload into the managed path.
|
|
432
|
+
|
|
433
|
+
This means:
|
|
434
|
+
|
|
435
|
+
* same-named files may be overwritten
|
|
436
|
+
* unrelated pre-existing files may remain
|
|
437
|
+
* backups are kept beside the managed path
|
|
438
|
+
|
|
439
|
+
Your global `~/.config/opencode/AGENTS.md` is user-owned.
|
|
440
|
+
|
|
441
|
+
OpenCode Dispatcher does not install, overwrite, back up, restore, remove, or rename it.
|
|
141
442
|
|
|
142
|
-
## Restore or
|
|
443
|
+
## Restore or Uninstall
|
|
143
444
|
|
|
144
445
|
To restore a backed-up managed path:
|
|
145
446
|
|
|
@@ -148,16 +449,18 @@ To restore a backed-up managed path:
|
|
|
148
449
|
3. Move the matching `.bak-*` path back to its original name.
|
|
149
450
|
4. Restart OpenCode.
|
|
150
451
|
|
|
151
|
-
Example
|
|
452
|
+
Example:
|
|
152
453
|
|
|
153
454
|
```bash
|
|
154
455
|
mv ~/.config/opencode/agents ~/.config/opencode/agents.dispatcher
|
|
155
456
|
mv ~/.config/opencode/agents.bak-<timestamp> ~/.config/opencode/agents
|
|
156
457
|
```
|
|
157
458
|
|
|
158
|
-
To uninstall Dispatcher, restore your backups if you had pre-existing global agents.
|
|
459
|
+
To uninstall Dispatcher, restore your backups if you had pre-existing global agents.
|
|
159
460
|
|
|
160
|
-
|
|
461
|
+
Only remove managed paths outright if you do not need any current contents, including files that may have existed before Dispatcher was installed.
|
|
462
|
+
|
|
463
|
+
## Package Commands
|
|
161
464
|
|
|
162
465
|
From `package.json`:
|
|
163
466
|
|
|
@@ -166,7 +469,7 @@ npm run check # node ./bin/install.js check
|
|
|
166
469
|
npm run install:local # node ./bin/install.js install
|
|
167
470
|
```
|
|
168
471
|
|
|
169
|
-
|
|
472
|
+
When installed as an npm package, Dispatcher provides this binary:
|
|
170
473
|
|
|
171
474
|
```bash
|
|
172
475
|
opencode-dispatcher [install|check]
|
|
@@ -174,9 +477,15 @@ opencode-dispatcher [install|check]
|
|
|
174
477
|
|
|
175
478
|
Invalid commands print usage and exit with a non-zero status.
|
|
176
479
|
|
|
177
|
-
## Publication
|
|
480
|
+
## Publication Status
|
|
481
|
+
|
|
482
|
+
This package is published on the npm registry as:
|
|
483
|
+
|
|
484
|
+
```text
|
|
485
|
+
opencode-dispatcher
|
|
486
|
+
```
|
|
178
487
|
|
|
179
|
-
|
|
488
|
+
Install it from any project with:
|
|
180
489
|
|
|
181
490
|
```bash
|
|
182
491
|
npx opencode-dispatcher install
|
|
@@ -184,7 +493,21 @@ npx opencode-dispatcher install
|
|
|
184
493
|
|
|
185
494
|
## Limitations
|
|
186
495
|
|
|
187
|
-
|
|
188
|
-
|
|
189
|
-
|
|
190
|
-
|
|
496
|
+
* Managed global agent paths are backed up, then overlaid with Dispatcher files.
|
|
497
|
+
* Unrelated pre-existing files in managed directories may remain.
|
|
498
|
+
* OpenCode must be restarted after install, restore, or uninstall so global config is reloaded.
|
|
499
|
+
* Providers, models, secrets, project dependencies, and git remotes are not configured by this package.
|
|
500
|
+
* Dispatcher is designed for substantial tasks with scope, artifacts, and validation.
|
|
501
|
+
* Dispatcher may be unnecessary overhead for tiny edits, quick questions, or exploratory coding.
|
|
502
|
+
|
|
503
|
+
## When Not to Use Dispatcher
|
|
504
|
+
|
|
505
|
+
Dispatcher is probably unnecessary when you only need:
|
|
506
|
+
|
|
507
|
+
* a quick explanation
|
|
508
|
+
* a tiny one-off edit
|
|
509
|
+
* exploratory prototyping
|
|
510
|
+
* casual code suggestions
|
|
511
|
+
* work where formal task artifacts would slow you down
|
|
512
|
+
|
|
513
|
+
Use Dispatcher when the structure is worth it. Use the fast path or plain OpenCode when it is not.
|
package/package.json
CHANGED
|
@@ -3,11 +3,11 @@ description: Executes simple single-file atomic edits that do not need a task sp
|
|
|
3
3
|
mode: subagent
|
|
4
4
|
hidden: true
|
|
5
5
|
permission:
|
|
6
|
+
bash:
|
|
7
|
+
"*": allow
|
|
6
8
|
edit:
|
|
7
9
|
"*": allow
|
|
8
10
|
".ai/**": deny
|
|
9
|
-
bash: "*": allow
|
|
10
|
-
task: "*": deny
|
|
11
11
|
---
|
|
12
12
|
|
|
13
13
|
You are the Executor Agent.
|