@sjawhar/opencode-legion-envoy 9.5.0 → 9.5.2
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/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: dispatch-writing-specs
|
|
3
|
-
description: "Use in a session with Dispatch before you write or change a spec, and before an ask, comment or message a person reads. It replaces superpowers' brainstorming there.
|
|
3
|
+
description: "Use in a session with Dispatch before you write or change a spec, and before an ask, comment or message a person reads. It replaces superpowers' brainstorming there."
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Writing specs
|
|
@@ -11,7 +11,7 @@ Reach shared understanding with the person at the least cost of their time. A Le
|
|
|
11
11
|
|
|
12
12
|
## The outline
|
|
13
13
|
|
|
14
|
-
|
|
14
|
+
Find the issue's project with `dispatch projects` or `dispatch search`, never the environment. The spec's `##` parts, in order:
|
|
15
15
|
|
|
16
16
|
Part | Content
|
|
17
17
|
--- | ---
|
|
@@ -23,7 +23,7 @@ Part | Content
|
|
|
23
23
|
`Decisions` | Your own choices
|
|
24
24
|
`Acceptance` | `**A1.**` on, each naming the requirements it tests
|
|
25
25
|
|
|
26
|
-
Another agent can build and check the work from the spec alone.
|
|
26
|
+
Another agent can build and check the work from the spec alone. A small change gets a few sentences per part, no matrix. Split a large design into child issues.
|
|
27
27
|
|
|
28
28
|
## Rules for the text
|
|
29
29
|
|
|
@@ -32,10 +32,12 @@ For each spec, ask, comment and message:
|
|
|
32
32
|
- Write in `skill://asd-ste100`'s strict mode.
|
|
33
33
|
- State the current design, never how people reached it.
|
|
34
34
|
- Link each source where the person wrote it: `dispatch://KEY/comment/<id>`, `/ask/<id>`, `/message/<id>`, or a Slack URL. With no link, state the design.
|
|
35
|
+
- In a spec, cite code by file and symbol, never a line number: it goes stale at the next edit.
|
|
36
|
+
- A sentence that cites a gate passing (a test, review, check or proof) also says, in that sentence, what the pass does not show: "The tests pass; they catch a wrong verdict, not a proof of a contradiction."
|
|
35
37
|
- Write about the design, never the person. Never quote people or upload their words.
|
|
36
38
|
- Name your session only if a reader must reach it.
|
|
37
39
|
- Keep only text that helps a reader understand, decide, build, check.
|
|
38
|
-
- Explain each name or term a new reader may not know.
|
|
40
|
+
- Explain each name or term a new reader may not know. Say in a clause what each issue you name does for this reader.
|
|
39
41
|
- In an ask, ask block, comment or message, name a requirement or check by what it is, never its number.
|
|
40
42
|
|
|
41
43
|
## Questions
|
|
@@ -48,9 +50,9 @@ For each spec, ask, comment and message:
|
|
|
48
50
|
|
|
49
51
|
## Each version
|
|
50
52
|
|
|
51
|
-
1. After a person's answer, comment or edit, rewrite what it touches; delete what it contradicts.
|
|
53
|
+
1. After a person's answer, comment or edit, rewrite what it touches; delete what it contradicts. Never narrate an edit or what used to be here; versions and comments hold the history. Reply in a comment's thread.
|
|
52
54
|
2. Before each spec write, paste the whole spec, never a path, into a fresh subagent's assignment. It lists gaps, conflicts, uncheckable requirements, unclear text, and missing or needless questions. Fix or record each.
|
|
53
|
-
3. Before each approval request, a read-only agent checks its facts: `task(agent="scout")
|
|
55
|
+
3. Before each approval request, a read-only agent checks its facts: `task(agent="scout")`.
|
|
54
56
|
4. Name each version with `dispatch doc-edit --summary`.
|
|
55
57
|
|
|
56
58
|
## Decisions
|
|
@@ -67,9 +69,7 @@ At your next edit, rewrite a spec outside the outline whole, in one version. Mov
|
|
|
67
69
|
## Approval
|
|
68
70
|
|
|
69
71
|
- Request approval once, when each ask block is answered or waived, each claim is checked, and this version is unapproved. Unbuilt acceptance checks never delay it.
|
|
70
|
-
- When their answer is the whole change since approval, Dispatch carries it.
|
|
71
72
|
- After approval, version only a change to scope, acceptance, cost, risk or a person's decision, all at once. Put other fixes in the plan or a comment.
|
|
72
|
-
- A Legion root spec's design gate follows `skill://legion-architect`.
|
|
73
73
|
|
|
74
74
|
## The plan
|
|
75
75
|
|
|
@@ -51,12 +51,13 @@ When the gate is armed, run this exact sequence before the tree's work starts:
|
|
|
51
51
|
them to answer: give such a point its own decision block first, or take it out of the spec.
|
|
52
52
|
|
|
53
53
|
```bash
|
|
54
|
-
dispatch request-approval --issue <root issue> --summary '<what the human is approving> Reviews: <gap result>, <claim result>.'
|
|
54
|
+
dispatch request-approval --issue <root issue> --summary '<what the human is approving> Reviews: <gap result>, <claim result>; <what they do not show>.'
|
|
55
55
|
```
|
|
56
56
|
|
|
57
57
|
`--summary` says in one to three sentences what the human is approving and nothing else (no
|
|
58
|
-
commentary and no open question), then one sentence with both reviews' results
|
|
59
|
-
`Reviews: no open gap, 14 of 14 claims verified
|
|
58
|
+
commentary and no open question), then one sentence with both reviews' results and what they do
|
|
59
|
+
not show, for example `Reviews: no open gap, 14 of 14 claims verified; neither shows that the
|
|
60
|
+
design works once built.` The primary document is the default; the
|
|
60
61
|
command prints `Approval requested for spec.md (document id <UUID>) at version <N> (ask <id>)`.
|
|
61
62
|
5. Register that document version with the daemon:
|
|
62
63
|
|