@amsterdamdatalabs/enact-extensions 0.1.34 → 0.1.37

package/extensions/enact-factory/skills/cmux-leader/SKILL.md

@@ -36,11 +36,13 @@ cmux tree                                    # process/Surface tree (optional)
 # Read a follower
 cmux read-screen --surface surface:N [--lines 40] [--scrollback]
 
-# Drive a follower  (\n = Enter)
+# Drive a follower  (send → 2×Enter → ctrl+b → verify EMPTY box)
 cmux send --surface surface:N "text\n"
-cmux send-key --surface surface:N enter      # submit a parked message
+cmux send-key --surface surface:N enter      # Enter #1
+cmux send-key --surface surface:N enter      # Enter #2 — one Enter often does NOT land
+cmux send-key --surface surface:N ctrl+b     # flush a QUEUED msg — no-op while only thinking
+cmux read-screen --surface surface:N --lines 6   # confirm the ❯ box is EMPTY (it landed)
 cmux send-key --surface surface:N ctrl+c     # interrupt a runaway
-cmux send-key --surface surface:N ctrl+b     # flush a QUEUED msg — only if a command is running
 
 # Spawn a follower (root it correctly, THEN launch claude)
 cmux new-split right --focus false                 # -> surface:N
@@ -56,8 +58,9 @@ cmux close-surface --surface surface:N
 
 Every follower briefing must tell the follower to use the **cmux-send** skill. Each message: prefix
 `[LEADER] to [FOLLOWER-<name>] `, end with `Respond back once you are done with using prefix
-"[FOLLOWER-<name>] to [LEADER] "`. After every `send`, `read-screen` to confirm it submitted; if it's
-parked in the `❯` box, `send-key … enter` (NOT `ctrl+b`).
+"[FOLLOWER-<name>] to [LEADER] "`. After every `send`, fire **two** `send-key … enter` (one Enter
+often does not land) + one `ctrl+b`, then `read-screen` and confirm the `❯` box is **empty** — an
+empty inbox is the only proof it submitted.
 
 ## Leader loop
 
@@ -65,6 +68,7 @@ parked in the `❯` box, `send-key … enter` (NOT `ctrl+b`).
 2. **Spawn & brief** — split → `cd <repo>` (verify pwd) → `claude` → self-contained briefing (role,
    scope, exit criteria, "use cmux-send to reply, report in one line").
 3. **Poll on a ~15-min cadence** — never go idle while followers run. Re-discover topology, `read-screen`
-   each, classify (working / idle-done / parked / blocked / ctx≥80%), and act: parked → `send-key enter`;
-   ctx≥80% → tell it to `/compact`; blocked → answer; idle-done → assign next or `close-surface`.
+   each, classify (working / idle-done / parked / blocked / ctx≥80%), and act: parked → `send-key enter`
+   ×2 + `ctrl+b`, then verify the `❯` box is empty; ctx≥80% → tell it to `/compact`; blocked → answer;
+   idle-done → assign next or `close-surface`.
 4. **Verify & gate** — confirm real output before treating a slice as green; drive merges from the leader.

package/extensions/enact-factory/skills/cmux-send/SKILL.md

@@ -7,19 +7,27 @@ description: "How to correctly message a cmux surface — the send→verify→en
 
 Two parts are easy to get wrong: **submitting** the message and **wrapping** it.
 
-## 1. Submit protocol (always verify the Enter landed)
+## 1. Submit protocol (send → 2×Enter → ctrl+b → verify empty box)
 
 ```bash
-cmux send --surface surface:N "<one-line message>\n"   # \n = Enter
-cmux read-screen --surface surface:N --lines 12         # VERIFY it submitted
-cmux send-key --surface surface:N enter                 # if still in the ❯ box (booting/thinking)
+cmux send --surface surface:N "<one-line message>\n"   # \n = Enter (often not enough alone)
+cmux send-key --surface surface:N enter                 # Enter #1
+cmux send-key --surface surface:N enter                 # Enter #2 — one Enter frequently does NOT land
+cmux send-key --surface surface:N ctrl+b                 # flush if a bash command is running
+cmux read-screen --surface surface:N --lines 6          # VERIFY: the ❯ box is EMPTY (message left)
 ```
 
-- **Always `read-screen` after `send`.** A `\n` may not submit while the follower is booting or
-  thinking — the text parks in the `❯` box.
-- **To submit a parked message use `send-key … enter`, NOT `ctrl+b`.** `ctrl+b` only flushes a *queued*
-  message when the follower has a **running bash command** to background; while it is purely thinking,
-  `ctrl+b` does nothing — just wait.
+- **Send TWO Enter keys, not one.** A single `send-key … enter` (or the trailing `\n`) frequently
+  fails to submit while the follower is booting or thinking — the text parks in the `❯` box. Two
+  Enters is the reliable default; a leftover empty Enter is harmless.
+- **Then one `ctrl+b`.** It flushes a *queued* message only when the follower has a **running bash
+  command** to background; while it is purely thinking `ctrl+b` is a harmless no-op. Sending it
+  unconditionally costs nothing and frees the queue the moment a command is running.
+- **Always confirm an EMPTY inbox.** `read-screen` after submitting and check the `❯` box is clear
+  (no parked text, no "Press up to edit queued messages"). An empty box is the only proof it landed —
+  do not assume submission, verify it.
+- **To submit a parked message, `send-key … enter` (×2), NOT `ctrl+b` alone.** `ctrl+b` does nothing
+  while the follower is only thinking.
 - **One line only.** Every literal `\n` submits, so a multi-line prompt fires early and fragments.
 - `read-screen` takes `--surface`, not `--pane`.
 
@@ -35,6 +43,8 @@ with `cmux list-pane-surfaces [--pane pane:N]`.
 
 ```bash
 cmux send --surface surface:3 "[LEADER] to [FOLLOWER-enact-wiki] <instruction on one line>. Respond back once you are done with using prefix \"[FOLLOWER-enact-wiki] to [LEADER] \"\n"
-cmux read-screen --surface surface:3 --lines 12
-# still in the ❯ box? -> cmux send-key --surface surface:3 enter
+cmux send-key --surface surface:3 enter      # ×2 — one Enter often does not land
+cmux send-key --surface surface:3 enter
+cmux send-key --surface surface:3 ctrl+b      # flush if a command is running (no-op while thinking)
+cmux read-screen --surface surface:3 --lines 6   # confirm the ❯ box is EMPTY
 ```

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@amsterdamdatalabs/enact-extensions",
-  "version": "0.1.34",
+  "version": "0.1.37",
   "description": "Create and validate Enact multi-platform plugin manifests",
   "license": "UNLICENSED",
   "type": "module",

package/scripts/enact-extensions.mjs

@@ -938,6 +938,8 @@ if (command === "serve") {
 //     Reads a UserPromptSubmit hook payload from stdin, extracts the prompt,
 //     builds the skill catalog from the bundled extensions dir, routes the
 //     prompt, and writes the hook response to stdout.
+//     Set ENACT_EXTENSIONS_UPS_ROUTER=0 to disable this hook locally without
+//     removing the installed plugin.
 //
 // Output contract (Claude Code hooks):
 //   Match:    { continue: true, hookSpecificOutput: { hookEventName: "UserPromptSubmit", additionalContext: <string> } }
@@ -973,6 +975,11 @@ if (command === "hook") {
       process.exit(0);
     }
 
+    if (process.env.ENACT_EXTENSIONS_UPS_ROUTER === "0") {
+      process.stdout.write(JSON.stringify({ continue: true }) + "\n");
+      process.exit(0);
+    }
+
     // Read stdin to get the hook payload JSON.
     let payload;
     try {

package/scripts/lib/ups-router.mjs

@@ -1,8 +1,8 @@
 /**
  * ups-router.mjs — pure, testable module for the UserPromptSubmit keyword-router.
  *
- * Discovers plugin bundles and their skills, extracts trigger keywords from
- * SKILL.md frontmatter, and routes a user prompt to matching skills.
+ * Discovers plugin bundles and their skills, extracts explicit trigger phrases
+ * from SKILL.md frontmatter, and routes a user prompt to matching skills.
  *
  * Two exports:
  *   buildSkillCatalog(extensionsDir)  → CatalogEntry[]
@@ -147,49 +147,11 @@ function extractExplicitTriggers(description) {
   return quoted;
 }
 
-/**
- * Derive salient keywords from a skill's description text.
- *
- * Conservative: only extracts tokens that are plausibly skill identifiers:
- *   - Hyphenated compound tokens (e.g. "contract-runner", "test-driven")
- *   - $skill-name mentions (e.g. "$loop", "$tdd")
- *   - Quoted short phrases other than the "Triggers on" section
- *   - Unquoted tokens that are longer (>=6 chars) and not stop-words
- *
- * @param {string} description
- * @returns {string[]}
- */
-function descriptionKeywords(description) {
-  const tokens = new Set();
-
-  // $skill mentions: "$foo", "$foo-bar"
-  const dollarRe = /\$([a-z][a-z0-9-]+)/gi;
-  let m;
-  while ((m = dollarRe.exec(description)) !== null) {
-    tokens.add(m[1].toLowerCase());
-  }
-
-  // Hyphenated compound tokens: at least two segments, each 2+ chars
-  const hyphenRe = /\b([a-z][a-z0-9]*(?:-[a-z][a-z0-9]*)+)\b/gi;
-  while ((m = hyphenRe.exec(description)) !== null) {
-    const tok = m[1].toLowerCase();
-    if (!isStopWord(tok)) tokens.add(tok);
-  }
-
-  // Longer bare words (>=6 chars) that don't look like common English prose.
-  const longWordRe = /\b([a-z]{6,})\b/gi;
-  while ((m = longWordRe.exec(description)) !== null) {
-    const tok = m[1].toLowerCase();
-    if (!isStopWord(tok)) tokens.add(tok);
-  }
-
-  return [...tokens];
-}
-
 /**
  * Derive the full keyword set for a single skill.
- * Priority: explicit "Triggers on" > skill name > salient description terms.
- * Deduplicates and excludes stop-words.
+ * Only explicit `Triggers on "..."` phrases and the skill name are used.
+ * Do not mine arbitrary words from descriptions; that makes everyday prompts
+ * like "change this contract" trigger unrelated skill hints.
  *
  * @param {string} skillName
  * @param {string|null} description
@@ -208,8 +170,6 @@ function deriveKeywords(skillName, description) {
   if (description) {
     // Explicit triggers have highest priority.
     for (const t of extractExplicitTriggers(description)) push(t);
-    // Salient terms from the description.
-    for (const t of descriptionKeywords(description)) push(t);
   }
 
   return [...seen];