opencode-dispatcher 0.1.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 +425 -96
- package/bin/install.js +100 -22
- package/package.json +2 -2
- package/workflow/agents/documentation.md +4 -4
- package/workflow/agents/executor.md +32 -0
- package/workflow/agents/implementer.md +10 -8
- package/workflow/agents/init.md +30 -0
- package/workflow/agents/orchestrator.md +82 -55
- package/workflow/agents/shipper.md +8 -3
- package/workflow/agents/task-planner.md +45 -7
- package/workflow/agents/test-writer.md +45 -0
- package/workflow/agents/validator.md +8 -9
- package/workflow/AGENTS.md +0 -40
- package/workflow/skills/task-artifact-workflow/SKILL.md +0 -52
- package/workflow/templates/task-artifact-workflow/documentation-report.md +0 -21
- package/workflow/templates/task-artifact-workflow/implementation-report.md +0 -21
- package/workflow/templates/task-artifact-workflow/task-spec.md +0 -25
- package/workflow/templates/task-artifact-workflow/validation-report.md +0 -21
package/README.md
CHANGED
|
@@ -1,72 +1,371 @@
|
|
|
1
1
|
# OpenCode Dispatcher
|
|
2
2
|
|
|
3
|
-
|
|
3
|
+
OpenCode Dispatcher is a workflow pack for OpenCode that adds specialist development agents coordinated through file-based task artifacts.
|
|
4
4
|
|
|
5
|
-
|
|
6
|
-
- [What It Does](#what-it-does)
|
|
7
|
-
- [Install from a local clone](#install-from-a-local-clone)
|
|
8
|
-
- [First use in a project](#first-use-in-a-project)
|
|
9
|
-
- [What gets installed](#what-gets-installed)
|
|
10
|
-
- [Install safety](#install-safety)
|
|
11
|
-
- [Restore or uninstall](#restore-or-uninstall)
|
|
12
|
-
- [Package commands](#package-commands)
|
|
13
|
-
- [Publication status](#publication-status)
|
|
14
|
-
- [Limitations](#limitations)
|
|
5
|
+
It is designed for substantial coding work where you want the agent workflow to be easier to inspect, resume, and validate.
|
|
15
6
|
|
|
16
|
-
|
|
7
|
+
Instead of relying on long chat history, Dispatcher keeps durable task state in your project:
|
|
17
8
|
|
|
18
|
-
|
|
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.
|
|
88
|
+
|
|
89
|
+
```mermaid
|
|
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.
|
|
19
217
|
|
|
20
|
-
|
|
21
|
-
- durable project facts in `.ai/context.md`
|
|
22
|
-
- role boundaries between planning, implementation, documentation, validation, research, and shipping work
|
|
23
|
-
- short handoffs in chat, with details kept in task artifacts
|
|
24
|
-
- validation reports checked against the approved scope
|
|
218
|
+
### Substantial Feature or Fix
|
|
25
219
|
|
|
26
|
-
|
|
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.
|
|
27
247
|
|
|
28
|
-
|
|
248
|
+
### Research-Backed Change
|
|
29
249
|
|
|
30
|
-
|
|
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
|
+
```
|
|
31
260
|
|
|
32
|
-
|
|
261
|
+
Used when implementation depends on external facts or source-backed technical decisions.
|
|
33
262
|
|
|
34
|
-
|
|
35
|
-
|---|---|---|
|
|
36
|
-
| Orchestrator | User-facing coordinator; routes work, synthesizes results | Always active |
|
|
37
|
-
| Task Planner | Creates auditable `.ai/tasks/<id>/task-spec.md` | Used before implementation |
|
|
38
|
-
| Implementer | Edits source code per approved task spec | Used after spec is approved |
|
|
39
|
-
| Validator | Checks results against task spec and writes `validation-report.md` | Used after implementation |
|
|
40
|
-
| Documentation | Updates docs, context, decision artifacts | Used when docs are needed |
|
|
41
|
-
| Research | Gathers external facts, comparisons, best practices | Used when facts are needed |
|
|
42
|
-
| Release / Shipper | Git commit and push only | Used when explicitly requested |
|
|
263
|
+
### Documentation Task
|
|
43
264
|
|
|
44
265
|
```mermaid
|
|
45
|
-
|
|
46
|
-
|
|
47
|
-
|
|
48
|
-
|
|
49
|
-
|
|
50
|
-
|
|
51
|
-
|
|
52
|
-
|
|
53
|
-
|
|
54
|
-
|
|
55
|
-
|
|
56
|
-
|
|
57
|
-
|
|
58
|
-
|
|
59
|
-
|
|
60
|
-
|
|
61
|
-
|
|
62
|
-
|
|
63
|
-
|
|
64
|
-
|
|
65
|
-
|
|
66
|
-
|
|
67
|
-
|
|
68
|
-
|
|
69
|
-
|
|
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
|
|
355
|
+
|
|
356
|
+
Install from the npm registry:
|
|
357
|
+
|
|
358
|
+
```bash
|
|
359
|
+
npx opencode-dispatcher install
|
|
360
|
+
```
|
|
361
|
+
|
|
362
|
+
After installing, restart OpenCode so it reloads your global configuration from:
|
|
363
|
+
|
|
364
|
+
```text
|
|
365
|
+
~/.config/opencode
|
|
366
|
+
```
|
|
367
|
+
|
|
368
|
+
## Install from Source
|
|
70
369
|
|
|
71
370
|
```bash
|
|
72
371
|
npm run check
|
|
@@ -86,50 +385,62 @@ The default installer command is `install`, so this is also valid:
|
|
|
86
385
|
node ./bin/install.js
|
|
87
386
|
```
|
|
88
387
|
|
|
89
|
-
|
|
90
|
-
|
|
91
|
-
## First use in a project
|
|
92
|
-
|
|
93
|
-
1. Open a project in OpenCode after restarting.
|
|
94
|
-
2. If the project does not already have `.ai/` artifacts, ask the orchestrator to run `/ai-init`.
|
|
95
|
-
3. For substantial work, ask for a task spec first. Example: `Create a task spec for improving the settings page, then wait for approval.`
|
|
96
|
-
4. After approving the task spec, ask the orchestrator to implement and validate it. Example: `Implement the approved task spec at .ai/tasks/settings-page/task-spec.md and run validation.`
|
|
97
|
-
|
|
98
|
-
The workflow treats live chat as coordination. Durable details belong in `.ai/context.md`, `.ai/tasks/<task-id>/task-spec.md`, and task reports such as `implementation-report.md`, `documentation-report.md`, and `validation-report.md`.
|
|
99
|
-
|
|
100
|
-
## What gets installed
|
|
388
|
+
## What Gets Installed
|
|
101
389
|
|
|
102
|
-
The installer copies
|
|
390
|
+
The installer copies Dispatcher's managed payload into:
|
|
103
391
|
|
|
104
392
|
```text
|
|
105
393
|
~/.config/opencode/agents/
|
|
106
|
-
~/.config/opencode/skills/
|
|
107
|
-
~/.config/opencode/templates/
|
|
108
394
|
```
|
|
109
395
|
|
|
110
|
-
Current
|
|
396
|
+
Current payloads include agents for:
|
|
111
397
|
|
|
112
|
-
|
|
113
|
-
|
|
114
|
-
|
|
398
|
+
* orchestration
|
|
399
|
+
* initialization
|
|
400
|
+
* task planning
|
|
401
|
+
* test writing
|
|
402
|
+
* implementation
|
|
403
|
+
* documentation
|
|
404
|
+
* validation
|
|
405
|
+
* research
|
|
406
|
+
* shipping
|
|
407
|
+
* tiny atomic edits
|
|
115
408
|
|
|
116
|
-
The installer does not install or manage
|
|
409
|
+
The installer does **not** install or manage:
|
|
117
410
|
|
|
118
|
-
|
|
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
|
|
119
420
|
|
|
120
|
-
|
|
421
|
+
## Install Safety
|
|
121
422
|
|
|
122
|
-
|
|
423
|
+
Before copying a managed path, the installer backs up any existing path beside it using a timestamped `.bak-*` suffix.
|
|
424
|
+
|
|
425
|
+
Example backup:
|
|
123
426
|
|
|
124
427
|
```text
|
|
125
428
|
~/.config/opencode/agents.bak-2026-06-07T12-34-56-789Z
|
|
126
|
-
~/.config/opencode/skills.bak-2026-06-07T12-34-56-789Z
|
|
127
|
-
~/.config/opencode/templates.bak-2026-06-07T12-34-56-789Z
|
|
128
429
|
```
|
|
129
430
|
|
|
130
|
-
|
|
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.
|
|
131
440
|
|
|
132
|
-
|
|
441
|
+
OpenCode Dispatcher does not install, overwrite, back up, restore, remove, or rename it.
|
|
442
|
+
|
|
443
|
+
## Restore or Uninstall
|
|
133
444
|
|
|
134
445
|
To restore a backed-up managed path:
|
|
135
446
|
|
|
@@ -138,18 +449,18 @@ To restore a backed-up managed path:
|
|
|
138
449
|
3. Move the matching `.bak-*` path back to its original name.
|
|
139
450
|
4. Restart OpenCode.
|
|
140
451
|
|
|
141
|
-
Example
|
|
452
|
+
Example:
|
|
142
453
|
|
|
143
454
|
```bash
|
|
144
455
|
mv ~/.config/opencode/agents ~/.config/opencode/agents.dispatcher
|
|
145
456
|
mv ~/.config/opencode/agents.bak-<timestamp> ~/.config/opencode/agents
|
|
146
457
|
```
|
|
147
458
|
|
|
148
|
-
|
|
459
|
+
To uninstall Dispatcher, restore your backups if you had pre-existing global agents.
|
|
149
460
|
|
|
150
|
-
|
|
461
|
+
Only remove managed paths outright if you do not need any current contents, including files that may have existed before Dispatcher was installed.
|
|
151
462
|
|
|
152
|
-
## Package
|
|
463
|
+
## Package Commands
|
|
153
464
|
|
|
154
465
|
From `package.json`:
|
|
155
466
|
|
|
@@ -158,7 +469,7 @@ npm run check # node ./bin/install.js check
|
|
|
158
469
|
npm run install:local # node ./bin/install.js install
|
|
159
470
|
```
|
|
160
471
|
|
|
161
|
-
|
|
472
|
+
When installed as an npm package, Dispatcher provides this binary:
|
|
162
473
|
|
|
163
474
|
```bash
|
|
164
475
|
opencode-dispatcher [install|check]
|
|
@@ -166,19 +477,37 @@ opencode-dispatcher [install|check]
|
|
|
166
477
|
|
|
167
478
|
Invalid commands print usage and exit with a non-zero status.
|
|
168
479
|
|
|
169
|
-
## Publication
|
|
480
|
+
## Publication Status
|
|
170
481
|
|
|
171
|
-
This package is
|
|
482
|
+
This package is published on the npm registry as:
|
|
172
483
|
|
|
173
|
-
|
|
484
|
+
```text
|
|
485
|
+
opencode-dispatcher
|
|
486
|
+
```
|
|
487
|
+
|
|
488
|
+
Install it from any project with:
|
|
174
489
|
|
|
175
490
|
```bash
|
|
176
|
-
|
|
491
|
+
npx opencode-dispatcher install
|
|
177
492
|
```
|
|
178
493
|
|
|
179
494
|
## Limitations
|
|
180
495
|
|
|
181
|
-
|
|
182
|
-
|
|
183
|
-
|
|
184
|
-
|
|
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.
|