@sjawhar/opencode-legion-envoy 8.7.1 → 8.8.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sjawhar/opencode-legion-envoy",
-  "version": "8.7.1",
+  "version": "8.8.1",
   "license": "Apache-2.0",
   "type": "module",
   "main": "dist/src/server.js",

package/skills/dispatch-brainstorming/SKILL.md

@@ -18,9 +18,10 @@ follows is a document on the same issue. This skill replaces superpowers' `brain
 - There is no approval after each section, only the one at the end.
 - A small change gets a short spec, never a design in chat: its size shortens the spec and changes
   nothing about where the conversation happens.
-- No spec or plan file goes in the repository (`docs/superpowers/specs/`,
-  `docs/superpowers/plans/`, `docs/plans/`): the spec is the issue's primary document and the plan
-  is its `plan.md` document.
+- The spec is the issue's primary document and the plan is its `plan.md` document, in place of
+  superpowers' spec and plan files (`docs/superpowers/specs/`, `docs/superpowers/plans/`). A copy
+  also goes in the repository only when the person, the issue, its spec or the repository asks for
+  one.
 
 The brainstorming stages still shape what you ask: clarifying questions, then two or three
 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.
 
 Read `skill://dispatch` before the first version: its "Writing a spec", "Decision blocks",
 "Writing for the human" and "Approval of a spec" sections define the spec's shape, each block's
-shape, and when approval is requested. A Legion phase worker never writes the spec; it sends a
-decision to its architect (`skill://legion-worker`).
+shape, and when approval is requested. A Legion phase worker never writes the issue's spec
+document; it sends a decision to its architect (`skill://legion-worker`).
 
 ## Where the spec lives
 
@@ -98,7 +99,7 @@ reactions, and so do corrections to it. Neither your model nor theirs is the sta
 
 Once the spec is approved — or, when the issue needed no spec at all (a bug fix with no design
 decision), once you have enough to plan from — the implementation plan is the issue's `plan.md`
-document, never its spec and never a repository file:
+document, never its spec:
 
 ```bash
 dispatch artifact --issue <KEY> --name plan.md --content-file - <<'EOF'
@@ -108,7 +109,9 @@ EOF
 
 Uploading `plan.md` again writes its next version. `writing-plans`'s content rules still apply in
 full — file structure, task right-sizing, bite-sized steps, no placeholders, the header, and its
-self-review — only where the plan lives changes: the issue's `plan.md`, never a repository file.
+self-review — only where the plan lives changes: the issue's `plan.md`, in place of a plan file.
+A copy in the repository, or spec code there, goes in only when the person, the issue, its spec or
+the repository asks for it.
 Technical choices inside the approved design are made in the plan and need no question. A plan
 never changes a decision the human made in the spec: a change to one goes back to the spec as a
 decision block, with the evidence for it.

package/skills/legion-worker/SKILL.md

@@ -248,17 +248,15 @@ gh pr comment <pr-number> \
 ## Planner artifact
 
 The plan lives in `.legion/<issue>/plan.json` and the issue's `plan.md` document, never in the issue's
-primary document, which is its spec; never commit a plan or spec file to the repository.
-No `docs/plans/*`, `docs/superpowers/plans/*`, or spec markdown goes into the pull request: plan
-and spec content goes into the issue, never into a PR (the root `AGENTS.md`
-calls its own `docs/plans/` human-authored design history, not a Legion artifact). A skill step that says "save the plan
-to a file" is satisfied by the handoff write in the completion gate below; the planner's only
-commit is `plan: record handoff`.
+primary document, which is its spec. Legion sets no rule on whether a plan or spec goes in the
+repository: the planner commits a plan, a spec or spec code when the issue, its spec or the
+repository asks for it. Otherwise, a skill step that says "save the plan to a file" is satisfied by
+the handoff write in the completion gate below.
 
 A plan that departs from the spec's design records the departure in `plan.md` and in the required
 `.legion/<issue>/plan.json` `specDepartures`: `[]` means no departure; otherwise each bounded record names
 the spec, plan, evidence and outcome. The planner's role prompt defines that record. The planner
-never edits the spec. Whether the spec changes is the architect's decision
+never edits the issue's spec document. Whether the spec changes is the architect's decision
 (`skill://legion-architect`, section 1), and the reviewer reads the plan beside the spec.
 
 ## Implementer push and pull request

package/skills/legion-worker/references/review-threads.md

@@ -15,7 +15,7 @@ Three facts govern every thread, whoever opened it.
 - **Resolve each thread you have answered, one thread per call, never in bulk, never a thread you
   have not read.** GitHub grants `resolveReviewThread` to the pull request's author, and the
   implementer opens every Legion pull request (`docs/site/src/content/docs/legion/running-legion.md`,
-  "The two GitHub Apps"), so the implementer resolves every thread, its own and the ones the
+  "The GitHub Apps"), so the implementer resolves every thread, its own and the ones the
   reviewer accepted:
   - The **implementer**, after every push that answers a review and before its `handoff_complete`,
     resolves each thread it answered with its own `gh`, one thread per call: