@sjawhar/claude-envoy 1.20.2 → 1.20.3
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/.omp-plugin/plugin.json
CHANGED
package/dist/envoy-channel.js
CHANGED
|
@@ -55262,7 +55262,7 @@ var import_nats2 = __toESM(require_mod4(), 1);
|
|
|
55262
55262
|
|
|
55263
55263
|
// package.json
|
|
55264
55264
|
var name = "@sjawhar/claude-envoy";
|
|
55265
|
-
var version2 = "1.20.
|
|
55265
|
+
var version2 = "1.20.3";
|
|
55266
55266
|
var legion = {
|
|
55267
55267
|
daemonApiVersion: 56
|
|
55268
55268
|
};
|
|
@@ -11,6 +11,8 @@ A lead raises the stream's numbers by making its agents faster, and is not a gat
|
|
|
11
11
|
|
|
12
12
|
In a Legion tree, the daemon's workflow and your role prompt decide who starts a worker, who accepts the work and how it merges. This skill does not change that sequence. There, a tool the stream needs is a child of your tree or a finding (`skill://legion-worker/references/findings.md`), not an agent you start on your own. Why each rule below works: [sources.md](skill://leading-a-work-stream/references/sources.md).
|
|
13
13
|
|
|
14
|
+
Once Legion runs a stream, its controller is that stream's lead; there is no separate lead beside it. Hand an idle stream to Legion as one short-lived agent per issue, each with a handoff comment on its issue, and never hand-apply a program taken from a lead's session, because the program's reasons stayed in that session.
|
|
15
|
+
|
|
14
16
|
## What a lead does
|
|
15
17
|
|
|
16
18
|
1. **Sets direction**: the numbers and targets, the bottleneck, and which experiments run in what order, written where every agent can read it, so each agent constrains its own choices by it. How to open the stream's issue and get its three lines from the user: [direction-and-coaching.md](skill://leading-a-work-stream/references/direction-and-coaching.md).
|
|
@@ -90,6 +92,7 @@ From records you read yourself (GitHub, Dispatch, the numbers), answer: what is
|
|
|
90
92
|
- When agents keep losing time to the same chore, start an agent to build the tool that removes it. Do not wait to be asked.
|
|
91
93
|
- Do not build, file or ask for a restriction, guard or gate against a failure nobody has seen. Fix a real failure at its cause, after it happens.
|
|
92
94
|
- When the user asks the stream for an explainer video, you own it: have a subagent make it with the `making-explainer-videos` skill.
|
|
95
|
+
- When a problem is named, fix it now — run the audit, apply the label, change the thing — instead of another round of agents agreeing it is a problem. Routing every change through you for review is a slowdown, not safety; the stream's own peer review and tests stay. When a neighbour names a problem, swarm on it rather than file an issue and wait.
|
|
93
96
|
|
|
94
97
|
## Improving this skill
|
|
95
98
|
|
package/package.json
CHANGED
|
@@ -36,7 +36,8 @@ For each spec, ask, comment and message:
|
|
|
36
36
|
|
|
37
37
|
- Write in `skill://asd-ste100`'s strict mode.
|
|
38
38
|
- Write about the current design, never the person or how people reached it, and never quote or upload their words.
|
|
39
|
-
- Link each source where the person wrote it
|
|
39
|
+
- Link each source where the person wrote it. With no link, state the design.
|
|
40
|
+
- Treat a person's stated preference or past answer as evidence of their taste, never as a ruling that settles the question: an answer given once is not a standing rule. A commit attributed to a person is not their decision, because agents commit the work.
|
|
40
41
|
- In a spec, cite code by file and symbol, never a line number: it goes stale at the next edit.
|
|
41
42
|
- 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."
|
|
42
43
|
- 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`).
|
|
@@ -46,7 +47,6 @@ For each spec, ask, comment and message:
|
|
|
46
47
|
|
|
47
48
|
- Name the concrete case and its numbers, then the choice in those terms, never "Which option?".
|
|
48
49
|
- 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.
|
|
49
|
-
- Ask only for the person's authority, taste or risk appetite, when options differ on what they care about.
|
|
50
50
|
- 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").
|
|
51
51
|
- 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.
|
|
52
52
|
- 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.
|
|
@@ -70,7 +70,7 @@ Choices—answered asks included—earn `decisions.md` `##` sections only if a d
|
|
|
70
70
|
|
|
71
71
|
## Old specs
|
|
72
72
|
|
|
73
|
-
Rewrite a spec outside the outline whole in one version, its ask blocks moved with `doc-edit`'s `move
|
|
73
|
+
Rewrite a spec outside the outline whole in one version, its ask blocks moved with `doc-edit`'s `move`.
|
|
74
74
|
|
|
75
75
|
## Approval
|
|
76
76
|
|