@sjawhar/claude-envoy 1.11.0 → 1.11.2

package/.claude-plugin/plugin.json

@@ -2,5 +2,5 @@
   "name": "claude-envoy",
   "description": "Deliver Envoy events as Claude Code channel notifications and expose Envoy MCP tools.",
   "mcpServers": "./.mcp.json",
-  "version": "1.11.0"
+  "version": "1.11.2"
 }

package/.omp-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "claude-envoy",
-  "version": "1.11.0",
+  "version": "1.11.2",
   "description": "Deliver Envoy events as Claude Code channel notifications and expose Envoy MCP tools.",
   "mcpServers": {}
 }

package/dist/envoy-channel.js

@@ -55133,7 +55133,7 @@ var import_nats2 = __toESM(require_mod4(), 1);
 
 // package.json
 var name = "@sjawhar/claude-envoy";
-var version2 = "1.11.0";
+var version2 = "1.11.2";
 var legion = {
   daemonApiVersion: 54
 };

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sjawhar/claude-envoy",
-  "version": "1.11.0",
+  "version": "1.11.2",
   "license": "Apache-2.0",
   "description": "Claude Code channel plugin for Legion's Envoy bus",
   "type": "module",

package/skills/dispatch/SKILL.md

@@ -10,6 +10,7 @@ Dispatch is a record for the people who decide, never a log of your work.
 - Use the `dispatch` command; the HTTP API only for what no command does. `dispatch <command> --help` gives its rules and an example.
 - Put long text on stdin: `--<field>-file -` with a quoted here-document (`<<'EOF'`); give object and list fields as JSON.
 - Exit 1 is a refusal, 2 a usage error. A refusal lists each problem: fix them all, then call once.
+- A Dispatch command hard to use, or storing or losing something wrongly, is a defect to report, not work around: open an issue in the owning project's code and tell that project's controller; a Legion role tells its architect (`skill://legion-worker/references/findings.md`).
 
 ## Asks and ask blocks
 
@@ -45,7 +46,7 @@ Outside Legion, claim your issue (`dispatch claim`) and move it and your childre
 
 `unresponsive` holders keep their claims 20 minutes (`skill://envoy`).
 
-A claim, or `dispatch issue-update --route session:<your id>` (`--route ''` on release), brings a person's answers, comments and messages; for agents' activity, `envoy_subscribe notifications.dispatch.issue.<KEY>.>`, which shows no quiet event.
+A claim (or `dispatch issue-update --route session:<your id>`, `--route ''` to release) brings a person's answers, comments and messages; `envoy_subscribe notifications.dispatch.issue.<KEY>.>` adds agents' activity, no quiet event.
 
 ## Close what you opened
 
@@ -59,7 +60,7 @@ A claim, or `dispatch issue-update --route session:<your id>` (`--route ''` on r
 
 ## Architecture components
 
-Attach each architectural issue to its components (`--components-json`), the root before decomposing it. Change code and `.dispatch/architecture/<id>.md` in the same review.
+Attach each architectural issue to its components (`--components-json`), the root first; change code and `.dispatch/architecture/<id>.md` together.
 
 ## References
 
@@ -81,7 +82,7 @@ dispatch://PROJECT/artifact/<slug>/ask/<id>
 dispatch://PROJECT/artifact/<slug>/comment/<id>#b-<block>[@vN]
 ```
 
-A bare id, filename or path is no reference, nor `dispatch://` outside Dispatch: give `dispatch`'s `https://` link. Write ids whole; a unique short id resolves.
+A bare id or path, or `dispatch://` outside Dispatch, is no link: give the `https://` one. Write ids whole.
 
 ## Setup and the HTTP API
 

package/skills/dispatch-first/SKILL.md

@@ -30,8 +30,8 @@ dispatch search --query 'reviewer threads OR review comments'
 
 ## Research before you ask
 
-- Research when a file, command or document can show the answer (a pattern, a convention, a solved problem, a technical approach), because a person must not answer twice what the repository already records.
-- Ask a person only for what their authority, taste or risk appetite settles, because no file holds that. Where a file already records the decision, cite it (`file:line`) and follow it; ask again only when the facts it rested on changed.
+- Research when a file, command or document can show the answer (a pattern, a convention, a solved problem, a technical approach).
+- Ask a person only for what their authority, taste or risk appetite settles, because no file holds that. Where a file records the decision, cite it (`file:line`) and follow it; ask again only when the facts it rested on changed.
 - Say what you searched: each part you found with its source, and each part you did not, with the queries you ran. Ask only the part no search answered.
 
 ## Reach a person only through Dispatch

package/skills/dispatch-writing-specs/SKILL.md

@@ -7,7 +7,7 @@ description: "Use in a session with Dispatch before you write or change a spec,
 
 ## The conversation
 
-Reach shared understanding with the person at the least cost of their time. A spec is a conversation, not a document you write and then ask about. A Legion phase worker writes none (`skill://legion-worker`). In order:
+Reach shared understanding at the least cost of the person's time. A spec is a conversation, not a document you write and then ask about. A Legion phase worker writes none (`skill://legion-worker`). In order:
 
 1. Read the issue, the code and what the person wrote.
 2. Send what you found and the questions it leaves open, a few at a time, before the spec states a design.
@@ -38,7 +38,7 @@ For each spec, ask, comment and message:
 - Write about the current design, never the person or how people reached it, and never quote or upload their words.
 - Link each source where the person wrote it, each id whole. With no link, state the design.
 - In a spec, cite code by file and symbol, never a line number: it goes stale at the next edit.
-- A sentence that cites a gate passing (test, review, check) also says what the pass does not show: "Tests pass: a wrong verdict, not a missing one."
+- A sentence citing a gate passing (test, review, check) also says what the pass does not show: "Tests pass: a wrong verdict, not a missing one."
 - Keep only text a reader needs to understand, decide, build or check, and say what each issue you name does for them (`skill://plain-words`).
 - In an ask, ask block, comment or message, name a requirement or check by what it is, never its number.
 
@@ -48,14 +48,14 @@ For each spec, ask, comment and message:
 - A choice inside what the person asked for, one their messages favour, routine cleanup, sequencing, naming, a choice between equivalent options, and a fix you can make are yours.
 - Ask only for the person's authority, taste or risk appetite, when options differ on what they care about.
 - Ask with an [ask block](skill://dispatch/SKILL.md#asks-and-ask-blocks): 2 to 4 options, answerable on a phone, and name nothing the reader cannot see from it ("the message above").
-- For each technical term you coined in this session, count the files that hold it, in the repositories the work touches and in Dispatch, by exact match; a single-digit count means expand the term or drop it, because a term you coined reads as familiar to you. A count misses a coinage made of common words, so read the draft for those too.
-- Measure each claim the ask rests on, its premise and each option's precondition. Where you cannot, mark the claim unverified and name the measurement that is missing; call an option unavailable only where a precondition is shown to fail. A premise can go stale within the hour, and no unmeasured number goes in one.
-- Before you pass a question on as one only an attended or privileged act answers, name the source that answers it and try that source, then the other records that hold it, because a 403 or an unfamiliar surface does not make a fact unknowable. Keep a privileged read for what only the live system knows.
+- For each technical term you coined in this session, count by exact match the files holding it, in the repositories the work touches and in Dispatch; a single-digit count means expand the term or drop it, because a coinage reads as familiar to you. A count misses a coinage of common words, so read the draft for those too.
+- Measure each claim the ask rests on, its premise and each option's precondition. Where you cannot, mark the claim unverified and name the missing measurement; call an option unavailable only where a precondition demonstrably fails. A premise can go stale within the hour; no unmeasured number goes in one.
+- Before you pass a question on as one only an attended or privileged act answers, name the source that answers it and try it, then the other records holding it, because a 403 or an unfamiliar surface does not make a fact unknowable. Keep a privileged read for what only the live system knows.
 
 ## Each version
 
 1. After a person's answer, comment or edit, reread the problem and rewrite what the answer touches, deleting what it contradicts: an answer is integrated, never appended. Answer each comment in its thread. Never narrate an edit: versions and comments hold the history.
-2. Before each spec write, paste the whole spec, never a path, into a fresh subagent: it lists gaps, conflicts, uncheckable requirements, unclear text and needless questions. Fix or record each.
+2. Before each spec write, paste the whole spec, never a path, into a fresh subagent to list gaps, conflicts, uncheckable requirements, unclear text and needless questions. Fix or record each.
 3. Before each approval request, `wait` for a read-only fact check: `task(agent="scout")`.
 4. Name each version with `dispatch doc-edit --summary`.
 
@@ -65,7 +65,7 @@ Choices—answered asks included—earn `decisions.md` `##` sections only if a d
 
 - The heading names the choice; the text gives the reason and the options weighed.
 - Link each spec block it shaped, `dispatch://KEY/spec#b-<id>`, and a person's decision its ask, `dispatch://KEY/ask/<id>`.
-- An unsure section adds a paragraph that starts `Unsure:`: what would change your mind.
+- An unsure section adds a paragraph starting `Unsure:`: what would change your mind.
 - A replaced section moves under a final `## Replaced` as a `###`.
 
 ## Old specs

package/skills/outside-message/SKILL.md

@@ -31,6 +31,10 @@ to the company before.
 Everything else waits for the operator: a first contact with a project that has not enrolled, a bug
 report, a disclosure, and a reply to a maintainer who wrote first.
 
+Hold an extremely high bar. Optimise every upstream report, patch or public post for a human
+reader and for being received well, so each one builds the company's reputation rather than a
+name for slop.
+
 ## The four steps
 
 1. **Research the audience.** Read the repository's contributing guide, its issue and pull-request
@@ -84,6 +88,15 @@ An ask for an outside message has, in this order:
 Link the research, not the message. An ask with no removal line has not had step 4, whatever it
 says.
 
+## One batch, not one ask at a time
+
+An upstream bug report, patch or public post that needs the operator's approval goes into one
+review batch, never a per-message "can I send this" ask. Write its entry — what it is and how
+serious; who receives it and what they do; the exact text or patch; its evidence; a non-author
+reviewer's APPROVE under your stream's reviewer-model rule; what the operator decides; its owner
+— into the batch, add it under the batch's Waiting list, and tell the batch owner. Your stream's
+brief names the batch and its owner.
+
 ## What this skill does not cover
 
 - Text written in a person's own name, which that person signs off.