@codyswann/lisa 2.195.3 → 2.195.6

package/plugins/lisa-openclaw/.codex-plugin/skills/lisa-openclaw-connect-staff/references/platform-routing.md

@@ -0,0 +1,123 @@
+# OpenClaw routing shapes (Telegram & Slack)
+
+Placeholder-only. Real ids/handles/tokens go only into `~/.openclaw/openclaw.json` (machine-local,
+never committed). Always back up that file before editing, change only the intended keys, and preserve
+all unrelated agents, channels, routes, and tokens.
+
+## Identity & session-scoping rules
+
+- **Telegram** `chat_id`: the signed supergroup id (usually starts with `-100`), not the short
+  positive number. Topic id is the `message_thread_id`. Session boundary = supergroup + topic + root
+  human `message_id`; native replies continue that session.
+- **Slack** routes bind by stable channel **id**, not channel name. Session boundary = channel + root
+  `thread_ts`; later replies in that thread reuse the same session key.
+
+## Telegram — facilitator topic route
+
+Use `channels.telegram.groups` for a single-account Telegram setup. If the OpenClaw config has
+`channels.telegram.accounts`, put the route under the owning bot account at
+`channels.telegram.accounts.<account-id>.groups.<telegram-supergroup-id>`; account-scoped Telegram
+configs do not inherit root group routes.
+
+Account-scoped topic `agentId` routes require an OpenClaw runtime that treats the topic agent as an
+explicit group route for non-default Telegram accounts. If a real Telegram topic test reaches the bot
+but logs `drop non-default account requires explicit binding`, update or rebuild OpenClaw before
+adding config workarounds; the topic `agentId` is the intended route.
+
+### Single-account route
+
+```json5
+{
+  "channels": {
+    "telegram": {
+      "groups": {
+        "<telegram-supergroup-id>": {
+          "groupPolicy": "allowlist",
+          "requireMention": true,
+          "allowFrom": ["<telegram-user-id>"],
+          "topics": {
+            "<facilitator-topic-id>": {
+              "agentId": "<facilitator-agent-id>",
+              "requireMention": true
+            }
+          }
+        }
+      }
+    }
+  }
+}
+```
+
+### Multi-account route
+
+```json5
+{
+  "channels": {
+    "telegram": {
+      "accounts": {
+        "<account-id>": {
+          "groups": {
+            "<telegram-supergroup-id>": {
+              "groupPolicy": "allowlist",
+              "requireMention": true,
+              "allowFrom": ["<telegram-user-id>"],
+              "topics": {
+                "<facilitator-topic-id>": {
+                  "agentId": "<facilitator-agent-id>",
+                  "requireMention": true
+                }
+              }
+            }
+          }
+        }
+      }
+    }
+  }
+}
+```
+
+## Slack — facilitator channel route
+
+```json5
+{
+  "channels": {
+    "slack": {
+      "replyToModeByChatType": { "channel": "all" },
+      "channelRoutes": {
+        "<slack-channel-id>": {
+          "agentId": "<facilitator-agent-id>",
+          "requireMention": true
+        }
+      }
+    }
+  }
+}
+```
+
+## Facilitator agent + specialist allow-list
+
+```json5
+{
+  "agents": {
+    "list": [
+      {
+        "id": "<facilitator-agent-id>",
+        "workspace": "<wiki-or-repo-path>",
+        "subagents": {
+          "allowAgents": ["<specialist-agent-id-1>", "<specialist-agent-id-2>"],
+          "requireAgentId": true
+        }
+      },
+      { "id": "<specialist-agent-id-1>", "workspace": "<wiki-or-repo-path>" },
+      { "id": "<specialist-agent-id-2>", "workspace": "<wiki-or-repo-path>" }
+    ]
+  }
+}
+```
+
+## Notes
+
+- Optional specialist audit topics/workrooms are visibility surfaces only; do not treat a post there
+  as proof of delivery. The operational route is internal `sessions_spawn`.
+- Disable any default-bot fallback that would answer instead of the facilitator.
+- Set `allowFrom` only when membership must be narrower than the whole group/channel.

package/plugins/lisa-openclaw/.codex-plugin/skills/lisa-openclaw-connect-staff/references/prompts.md

@@ -0,0 +1,78 @@
+# Facilitator & specialist prompt templates
+
+Placeholder-only. Replace every `<...>` at deploy time; keep real values out of committed files.
+These prompts encode the hub-and-spoke contract the route test verifies.
+
+## Facilitator (chief-of-staff) prompt
+
+```text
+You are <facilitator-name>, <facilitator-title> for <organization-name>.
+
+Humans reach you through <human-facing-surface>. Specialists do not take direct human work. You are
+the facilitator and orchestrator, not the specialist worker.
+
+For every substantive human request:
+1. Reply in the original thread / native reply with a short acknowledgement AFTER you start the
+   internal consultation.
+2. Consult at least one specialist using internal OpenClaw sessions_spawn with explicit agentId
+   values. Consult multiple specialists when the request crosses domains.
+3. Evaluate specialist replies for completeness, quality, conflicts, and missing assumptions; ask
+   follow-ups when an answer is weak or incomplete.
+4. If the final answer depends on specialist results, yield/wait for the specialist completion events
+   before sending the final answer. When using sessions_yield, make it its own final tool call — do
+   not chain it inside the same tool body as a message send.
+5. Synthesize one answer for the human in the original thread / native reply.
+6. When returning from a specialist completion event, send the final answer through the platform
+   message tool with the saved thread/reply target, then return exactly NO_REPLY as your assistant
+   final so the gateway does not post a duplicate loose message. This overrides any runtime wording
+   that says to answer in the normal assistant voice.
+7. Clear, archive, or isolate consulted specialist context after the investigation to control cost.
+
+Treat each visible human request thread as its own short-term context boundary. In Slack the session
+is scoped to the channel + root thread_ts; in Telegram it is scoped to the topic + root human
+message_id. Do not borrow context from another visible thread unless the human explicitly links it.
+
+If no appropriate specialist exists, say so plainly, give a clearly-labeled best-effort stopgap when
+useful, and recommend provisioning the missing role.
+
+Do not add bracketed self-label prefixes. The platform already shows your identity.
+```
+
+## Specialist prompt
+
+```text
+You are <specialist-name>, <specialist-title> for <organization-name>.
+
+Your work arrives from <facilitator-name> through internal OpenClaw dispatch. Return concise,
+structured results to the facilitator. Do not answer humans directly unless your route is explicitly
+configured for direct human work. Do not post final answers to human-facing channels.
+
+Scope:
+- Own: <owned-domain-list>
+- Do not own: <non-owned-domain-list>
+- Escalate to: <related-specialist-agent-ids>
+
+When assigned work:
+1. Answer from your domain expertise.
+2. State assumptions, risks, gaps, and recommended next steps.
+3. Keep the response ready for facilitator review and synthesis.
+
+Do not add bracketed self-label prefixes. The platform already shows your identity.
+```
+
+## Route acceptance checklist
+
+```md
+- [ ] Human post reaches <facilitator-agent-id>.
+- [ ] Facilitator acknowledgement is a thread / native reply to the original human message.
+- [ ] Two simultaneous requests in the same channel/topic use distinct visible threads and distinct
+      OpenClaw sessions.
+- [ ] Facilitator starts internal sessions_spawn consultation with >=1 explicit specialist agent id.
+- [ ] Facilitator does not treat the acknowledgement as the final answer when specialist work is
+      still pending.
+- [ ] Specialist returns an internal result to the facilitator.
+- [ ] Facilitator evaluates the result and asks a follow-up when needed.
+- [ ] Facilitator final answer is a thread / native reply to the original human message.
+- [ ] Facilitator returns NO_REPLY after any message-tool final send (no duplicate loose message).
+- [ ] Consulted specialist context is cleared, archived, or isolated.
+```

package/plugins/lisa-openclaw/.codex-plugin/skills/lisa-openclaw-setup/SKILL.md

@@ -0,0 +1,141 @@
+---
+name: lisa-openclaw-setup
+description: "Set up OpenClaw as the…"
+---
+
+# lisa-openclaw-setup
+
+Verify the OpenClaw runtime prerequisites and record a minimal, placeholder-safe pointer in
+`.lisa.config.json` so the connect skills have what they need. **This skill writes only setup-level
+pointers** — never tokens, channel/topic/group ids, bot handles, or route tables. Those live in
+`~/.openclaw/openclaw.json` (OpenClaw's own machine-local source of truth) and are written by the
+connect skills, never committed.
+
+This SKILL.md is self-contained and runs identically under Claude Code and Codex. There is no
+command/argument layer in Codex, so do not rely on one.
+
+## What OpenClaw is (so the checks make sense)
+
+OpenClaw is a locally-hosted multi-agent gateway. A **CLI** (`openclaw`, usually at
+`~/.local/bin/openclaw`) manages a **config file** (`~/.openclaw/openclaw.json`) that defines agents,
+chat-channel bindings (Telegram groups/topics, Slack channels), and routing. A long-running
+**gateway** process delivers chat messages to agents and back. Agents reach other agents internally
+via `sessions_spawn` rather than by messaging each other on the chat platform.
+
+## Required inputs
+
+Gather (ask only for what is missing):
+
+- **platform** the project will default to: `telegram` or `slack`
+- **facilitator agent id** — the single human-facing "chief of staff" agent id (a staff role id; see
+  the soft dependency below)
+- **secret provider** — how OpenClaw stores bot/app tokens (e.g. the OS keychain, a named secret
+  manager, or `0600` local token files). Capture only its *type* and a *reference*, never a value.
+
+## Soft dependency on staff roles
+
+The facilitator and specialists are **staff roles**. A companion plugin (`lisa-wiki`) scaffolds a
+staff role's "brain" (a `wiki/staff/<id>.md` doc page plus a dual-runtime subagent at
+`.claude/agents/<id>.md` and `.codex/agents/<id>.toml`) from a `config.staff[]` entry. This plugin
+wires that role to a chat surface — the "body".
+
+If `config.staff[]` (in `.lisa.config.json`) has no entries yet, tell the user to define their staff
+first:
+
+- In Claude Code: run `/lisa:add-role <Role>` (e.g. `/lisa:add-role Chief of Staff`).
+- In Codex: invoke `$lisa-wiki:lisa-wiki-add-role` with the role.
+
+Only auto-delegate if that skill is actually available in the active runtime; otherwise just print the
+exact next step and stop.
+
+## Workflow
+
+### 1. Locate the OpenClaw CLI
+
+Resolve a usable `openclaw` binary, in order:
+
+1. `~/.local/bin/openclaw`
+2. `openclaw` on `PATH`
+3. a path the user supplies
+
+If none is found, stop and tell the user to install OpenClaw and re-run. Record the resolved path for
+the config's `configPath`/CLI discovery only if it is non-standard.
+
+### 2. Verify the config file
+
+Confirm `~/.openclaw/openclaw.json` exists and is valid JSON. Do **not** print token values found
+inside it. If it is missing, instruct the user to initialize OpenClaw (its own init flow creates the
+file) before continuing.
+
+### 3. Verify a secret provider
+
+Confirm a token-storage mechanism is configured. Acceptable: the OpenClaw-configured secret provider,
+an OS keychain entry, or `0600`-permissioned local token files outside the repo. Capture the provider
+*type* and a non-secret *reference* only.
+
+### 4. Probe required gateway capabilities
+
+The connect skills depend on three OpenClaw behaviors. Probe for them and **fail closed** (warn
+loudly, do not silently proceed) if any is missing:
+
+- **`sessions_spawn`** — internal agent-to-agent dispatch (how the facilitator consults specialists).
+- **Native-reply session scoping** — a top-level human request seeds a session keyed to its thread
+  root (Slack channel + root `thread_ts`; Telegram supergroup + forum topic + root `message_id`), and
+  replies in that thread continue the same session, so concurrent threads don't share short-term
+  context.
+- **Account-scoped Telegram topic agents** — in multi-account Telegram configs,
+  `channels.telegram.accounts.<account-id>.groups.<group-id>.topics.<topic-id>.agentId` routes group
+  messages as an explicit topic route instead of dropping them as a non-default account fallback.
+- **`NO_REPLY` sentinel** — after an agent sends a message with the platform message tool, returning
+  exactly `NO_REPLY` as its assistant final prevents the gateway from posting a duplicate loose
+  message.
+
+Probe via the OpenClaw CLI/version and a non-mutating validate, e.g.:
+
+```sh
+openclaw --version
+openclaw config validate
+```
+
+If a capability cannot be confirmed, record it as an unmet prerequisite. The connect skills must
+refuse to create routes that would post duplicates or leak cross-thread context.
+
+### 5. Write the lean config section
+
+Update **only** the `openclaw` section of `.lisa.config.json`. Parse the existing JSON, preserve all
+other keys and formatting as much as practical, and write structurally (never string-splice). Shape:
+
+```json
+{
+  "openclaw": {
+    "defaultPlatform": "telegram",
+    "facilitatorAgentId": "<facilitator-agent-id>",
+    "secretProvider": {
+      "type": "<secret-provider-type>",
+      "ref": "<secret-provider-ref>"
+    },
+    "configPath": "~/.openclaw/openclaw.json"
+  }
+}
+```
+
+Rules for this section:
+
+- `defaultPlatform`: `"telegram"` or `"slack"`.
+- `facilitatorAgentId`: the default facilitator/chief id only — **not** per-surface routing.
+- `secretProvider`: a pointer only; never token material.
+- `configPath`: optional; default `~/.openclaw/openclaw.json`. Set only for non-standard installs.
+- **Reject** writing tokens, channel ids, topic ids, group ids, Slack thread roots, bot handles, or
+  repo paths here. If the user offers them, decline and explain they belong in
+  `~/.openclaw/openclaw.json`.
+
+### 6. Report
+
+Finish with: resolved CLI path, config-file status, secret-provider type/ref, each capability probe
+result (pass / warn / unknown), the `openclaw` section written, and the exact next command/skill
+(`lisa-openclaw-connect-staff` or `lisa-openclaw-connect-repo-topic`).
+
+## Related
+
+`lisa-openclaw-connect-staff`, `lisa-openclaw-connect-repo-topic`. Staff "brains" come from the
+`lisa-wiki` plugin's `add-role`.

package/plugins/lisa-openclaw/.codex-plugin/skills/lisa-openclaw-setup/agents/openai.yaml

@@ -0,0 +1,4 @@
+display_name: "Openclaw Setup"
+short_description: "Set up OpenClaw as the…"
+default_prompt:
+  - "Use $lisa-openclaw-setup: Set up OpenClaw as the…."

package/plugins/lisa-openclaw/.codex-plugin/skills/lisa-setup-openclaw/SKILL.md

@@ -0,0 +1,13 @@
+---
+name: lisa-setup-openclaw
+description: "Set up OpenClaw as the…"
+---
+## Lisa Command Compatibility
+
+- Original Claude command: `/lisa:setup-openclaw`
+- Codex invocation: `$lisa-setup-openclaw` or a plain-English request that matches this skill.
+- Treat the user's surrounding request as the command arguments.
+- Claude argument hint: `[telegram|slack]`
+
+Use the lisa-openclaw-setup skill to verify OpenClaw prerequisites and write the lean `openclaw`
+section to .lisa.config.json. If a platform is given, use it as the defaultPlatform. Use the user's surrounding request as this command's arguments.

package/plugins/lisa-openclaw/.codex-plugin/skills/lisa-setup-openclaw/agents/openai.yaml

@@ -0,0 +1,4 @@
+display_name: "Setup Openclaw"
+short_description: "Set up OpenClaw as the…"
+default_prompt:
+  - "Use $lisa-setup-openclaw: Set up OpenClaw as the…."

package/plugins/lisa-openclaw-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.195.3",
+  "version": "2.195.6",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-openclaw-copilot/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.195.3",
+  "version": "2.195.6",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-openclaw-cursor/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.195.3",
+  "version": "2.195.6",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-phaser/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "2.195.3",
+  "version": "2.195.6",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-phaser/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "2.195.3",
+  "version": "2.195.6",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"
@@ -11,7 +11,7 @@
   "dependencies": [
     "lisa-typescript"
   ],
-  "skills": "./skills/",
+  "skills": "./.codex-plugin/skills/",
   "hooks": "./.codex-plugin/hooks.json",
   "interface": {
     "displayName": "lisa-phaser",

package/plugins/lisa-phaser/.codex-plugin/skills/phaser-accessibility/SKILL.md

@@ -0,0 +1,135 @@
+---
+name: phaser-accessibility
+description: "making a Phaser 4 game…"
+---
+
+# Phaser 4 Accessibility
+
+## Overview
+
+The canvas is opaque to assistive tech, so accessibility is something you build
+in, not get for free. Five pillars carry most of the value: respect
+`prefers-reduced-motion`, pause when the window loses focus, make menus fully
+keyboard-navigable with visible focus, use colorblind-safe palettes, and mirror
+game state into a DOM **live region** for screen readers. These wire through the
+shared services ([[phaser-services]]) and use translated strings ([[phaser-i18n]]).
+
+## prefers-reduced-motion
+
+Read the media query once and gate non-essential motion (screen shake, parallax,
+big tweens, particle bursts) behind it. Reduced motion means "convey the same
+information with less movement", not "remove feedback".
+
+```ts
+// src/services/a11y.ts
+export const reduceMotion = window.matchMedia("(prefers-reduced-motion: reduce)").matches;
+
+// in a scene
+if (!reduceMotion) this.cameras.main.shake(120, 0.004);
+this.tweens.add({ targets: panel, alpha: 1, duration: reduceMotion ? 0 : 250 });
+```
+
+Expose it as a togglable setting too (some players want it on regardless of OS),
+stored via SaveService ([[phaser-services]]).
+
+## Pause on blur
+
+A game that keeps running while the tab is hidden drains battery, desyncs audio,
+and is hostile to players who switch away. Phaser already exposes blur/focus
+events — pause the loop and audio, resume on focus.
+
+```ts
+this.game.events.on(Phaser.Core.Events.BLUR, () => { this.scene.pause(); this.sound.pauseAll(); });
+this.game.events.on(Phaser.Core.Events.FOCUS, () => { this.scene.resume(); this.sound.resumeAll(); });
+```
+
+Set `Phaser.Types.Core.GameConfig.autoFocus` and `disableContextMenu` as needed.
+(These are listeners — remove them in `shutdown` per the on/off discipline in
+[[phaser-services]].) For competitive/timed play, pausing on blur is also the
+fair behavior.
+
+## Keyboard navigation and visible focus
+
+Every menu must be operable without a pointer: arrow keys / Tab move focus, Enter
+or Space activates, Escape backs out. Keep a focus index over a typed list of
+items and render an unmistakable focus indicator (outline/scale, not color alone).
+
+```ts
+private items: MenuItem[] = [];
+private focus = 0;
+
+private move(delta: number) {
+  this.items[this.focus].setFocused(false);
+  this.focus = Phaser.Math.Wrap(this.focus + delta, 0, this.items.length);
+  this.items[this.focus].setFocused(true);          // visible outline + announce
+  this.announce(this.items[this.focus].label);
+}
+create() {
+  this.input.keyboard!.on("keydown-DOWN", () => this.move(1));
+  this.input.keyboard!.on("keydown-UP",   () => this.move(-1));
+  this.input.keyboard!.on("keydown-ENTER",() => this.items[this.focus].activate());
+}
+```
+
+Use the semantic InputService actions ([[phaser-services]]) so the same bindings
+serve gamepad and touch. Never rely on hover-only affordances.
+
+## Colorblind-safe palettes
+
+Never encode meaning in hue alone — pair every color cue with a shape, icon,
+label, or pattern (red enemy *and* a spike icon; green/red status *and* a check/x).
+Choose palettes that stay distinguishable across deuteranopia/protanopia
+/tritanopia, and offer a colorblind palette option in settings.
+
+```ts
+// src/logic/palette.ts — pure, testable, no phaser import
+export const palettes = {
+  default: { ally: 0x2e7d32, enemy: 0xc62828, neutral: 0xf9a825 },
+  deuter:  { ally: 0x0072b2, enemy: 0xd55e00, neutral: 0xf0e442 }, // Okabe–Ito, CB-safe
+} as const;
+```
+
+Keep palette selection in `src/logic/**` so contrast/choice logic is unit-tested,
+and store the player's choice via SaveService.
+
+## Screen-reader live region
+
+Mirror important state changes into an ARIA live region in the DOM (outside the
+canvas) so screen readers announce them. One polite region for status, one
+assertive for urgent events.
+
+```html
+<!-- index.html, alongside the game container -->
+<div id="sr-status" aria-live="polite"   class="sr-only"></div>
+<div id="sr-alert"  aria-live="assertive" class="sr-only"></div>
+```
+
+```ts
+// src/services/a11y.ts
+const status = document.getElementById("sr-status")!;
+export function announce(msg: string, urgent = false) {
+  const el = urgent ? document.getElementById("sr-alert")! : status;
+  el.textContent = ""; el.textContent = msg; // clear+set so identical repeats re-announce
+}
+```
+
+Announce menu focus, score milestones, level changes, and game-over. Messages
+come from the i18n catalog ([[phaser-i18n]]) — never hardcoded — and `.sr-only`
+keeps the region visually hidden but readable by AT.
+
+## Project conventions
+
+- A11y plumbing lives in `src/services/a11y.ts`; palette/choice logic lives in
+  `src/logic/**` (unit-tested).
+- Accessibility settings (reduced motion, colorblind palette) persist via
+  SaveService and apply on boot ([[phaser-services]]).
+- All announced/visible text comes from the i18n catalog ([[phaser-i18n]]).
+
+## Verification
+
+Verified by manual passes that double as runtime checks: tab through every menu
+with the pointer unplugged and confirm visible focus + activation; set the OS to
+reduce-motion and confirm shake/parallax stop while feedback remains; blur the
+tab and confirm the game pauses and audio stops; and run a screen reader (VoiceOver
+/NVDA) to confirm the live region announces menu focus and game state.
+</content>

package/plugins/lisa-phaser/.codex-plugin/skills/phaser-accessibility/agents/openai.yaml

@@ -0,0 +1,4 @@
+display_name: "Phaser Accessibility"
+short_description: "making a Phaser 4 game…"
+default_prompt:
+  - "Use $phaser-accessibility: making a Phaser 4 game…."