@sjawhar/pi-envoy 10.6.1 → 10.6.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.
|
@@ -18,9 +18,10 @@ follows is a document on the same issue. This skill replaces superpowers' `brain
|
|
|
18
18
|
- There is no approval after each section, only the one at the end.
|
|
19
19
|
- A small change gets a short spec, never a design in chat: its size shortens the spec and changes
|
|
20
20
|
nothing about where the conversation happens.
|
|
21
|
-
-
|
|
22
|
-
`docs/superpowers/
|
|
23
|
-
|
|
21
|
+
- The spec is the issue's primary document and the plan is its `plan.md` document, in place of
|
|
22
|
+
superpowers' spec and plan files (`docs/superpowers/specs/`, `docs/superpowers/plans/`). A copy
|
|
23
|
+
also goes in the repository only when the person, the issue, its spec or the repository asks for
|
|
24
|
+
one.
|
|
24
25
|
|
|
25
26
|
The brainstorming stages still shape what you ask: clarifying questions, then two or three
|
|
26
27
|
approaches with a recommendation, then the design section by section. A question that depends on
|
|
@@ -28,8 +29,8 @@ no open answer goes out at once, whatever its stage.
|
|
|
28
29
|
|
|
29
30
|
Read `skill://dispatch` before the first version: its "Writing a spec", "Decision blocks",
|
|
30
31
|
"Writing for the human" and "Approval of a spec" sections define the spec's shape, each block's
|
|
31
|
-
shape, and when approval is requested. A Legion phase worker never writes the spec
|
|
32
|
-
decision to its architect (`skill://legion-worker`).
|
|
32
|
+
shape, and when approval is requested. A Legion phase worker never writes the issue's spec
|
|
33
|
+
document; it sends a decision to its architect (`skill://legion-worker`).
|
|
33
34
|
|
|
34
35
|
## Where the spec lives
|
|
35
36
|
|
|
@@ -98,7 +99,7 @@ reactions, and so do corrections to it. Neither your model nor theirs is the sta
|
|
|
98
99
|
|
|
99
100
|
Once the spec is approved — or, when the issue needed no spec at all (a bug fix with no design
|
|
100
101
|
decision), once you have enough to plan from — the implementation plan is the issue's `plan.md`
|
|
101
|
-
document, never its spec
|
|
102
|
+
document, never its spec:
|
|
102
103
|
|
|
103
104
|
```bash
|
|
104
105
|
dispatch artifact --issue <KEY> --name plan.md --content-file - <<'EOF'
|
|
@@ -108,7 +109,9 @@ EOF
|
|
|
108
109
|
|
|
109
110
|
Uploading `plan.md` again writes its next version. `writing-plans`'s content rules still apply in
|
|
110
111
|
full — file structure, task right-sizing, bite-sized steps, no placeholders, the header, and its
|
|
111
|
-
self-review — only where the plan lives changes: the issue's `plan.md`,
|
|
112
|
+
self-review — only where the plan lives changes: the issue's `plan.md`, in place of a plan file.
|
|
113
|
+
A copy in the repository, or spec code there, goes in only when the person, the issue, its spec or
|
|
114
|
+
the repository asks for it.
|
|
112
115
|
Technical choices inside the approved design are made in the plan and need no question. A plan
|
|
113
116
|
never changes a decision the human made in the spec: a change to one goes back to the spec as a
|
|
114
117
|
decision block, with the evidence for it.
|