@codyswann/lisa 2.195.4 → 2.195.6

package/plugins/lisa-openclaw/.codex-plugin/skills/lisa-connect-staff-telegram/SKILL.md

@@ -0,0 +1,13 @@
+---
+name: lisa-connect-staff-telegram
+description: "Connect staff roles to Telegram…"
+---
+## Lisa Command Compatibility
+
+- Original Claude command: `/lisa:connect-staff-telegram`
+- Codex invocation: `$lisa-connect-staff-telegram` or a plain-English request that matches this skill.
+- Treat the user's surrounding request as the command arguments.
+- Claude argument hint: `<facilitator role + specialists, e.g. Chief of Staff with Legal, Finance, Sales>`
+
+Use the lisa-openclaw-connect-staff skill with platform `telegram`. Connect the named facilitator and
+specialists to a Telegram facilitator topic via OpenClaw. Use the user's surrounding request as this command's arguments.

package/plugins/lisa-openclaw/.codex-plugin/skills/lisa-connect-staff-telegram/agents/openai.yaml

@@ -0,0 +1,4 @@
+display_name: "Connect Staff Telegram"
+short_description: "Connect staff roles to Telegram…"
+default_prompt:
+  - "Use $lisa-connect-staff-telegram: Connect staff roles to Telegram…."

package/plugins/lisa-openclaw/.codex-plugin/skills/lisa-openclaw-connect-repo-topic/SKILL.md

@@ -0,0 +1,163 @@
+---
+name: lisa-openclaw-connect-repo-topic
+description: "Bind a Telegram forum topic to…"
+---
+
+# lisa-openclaw-connect-repo-topic
+
+Turn a Telegram forum topic into a repeatable OpenClaw entrypoint for code work. A **dispatcher**
+agent receives the request and delegates; a **worker** agent runs the local coding CLI in a safe
+target directory and relays the result.
+
+This SKILL.md is complete and runnable under both Claude Code and Codex (no command/`$ARGUMENTS`
+layer in Codex). Keep real ids/handles/paths out of committed files — they go only in
+`~/.openclaw/openclaw.json`. For exact config shapes read
+[references/repo-topic-config.md](references/repo-topic-config.md).
+
+## Prerequisites
+
+- `lisa-openclaw-setup` has run and its capability probes passed.
+- A Telegram supergroup with forum topics, and a bot that is (or can be promoted to) a **group
+  admin** — bot presence alone is not enough for topic routing.
+
+## Boundaries (apply every time)
+
+- groups = the human trust boundary
+- topics = the project-routing boundary
+- native-reply roots = the short-term session boundary inside a topic
+- agents = the capability boundary
+- Do not mix admin-only repos with broader-collaboration repos in one group. If two repos need
+  different member lists, use separate groups, not topic-only separation.
+
+## Scope modes (pick exactly one per topic)
+
+- **`single-repo`** — the topic is pinned to one repo directory; the dispatcher never asks which repo.
+- **`folder-scoped`** — the topic is pinned to a parent folder containing multiple repos; the
+  dispatcher must confirm the inferred repo(s) unless the user named them explicitly.
+
+Do not mix both behaviors in one topic.
+
+## Required inputs
+
+- trust boundary: `admin` or `developer`
+- scope mode: `single-repo` or `folder-scoped`
+- access surface: Telegram group + topic (by name; ids captured during the run)
+- the bot handle to bind
+- workspace root on disk (repo dir for single-repo; parent folder for folder-scoped)
+- allowed Telegram user ids
+- completion policy:
+  - `admin` topics may request change + docs + commit + PR + merge
+  - `developer` topics default to change + docs + commit + PR only
+- for `folder-scoped`: a repo catalog (label, absolute path, a few matching keyword hints)
+
+## Workflow
+
+### 1. Resolve the contract
+
+Confirm the trust boundary, scope mode, workspace root, bot handle, and (for folder-scoped) the repo
+catalog. If a needed agent doesn't exist yet, create it in step 3.
+
+### 2. Provision / reuse the Telegram surface
+
+Reuse the trust-matched group and the exact topic if they already exist; otherwise create them (enable
+forum/topics mode first). Ensure the bot is in the group and **promoted to admin**. Telegram Bot API
+cannot list groups by name — discover ids from a logged-in Telegram client, an existing route in
+`~/.openclaw/openclaw.json`, or a received Bot API update. If browser/UI automation blocks on a human
+confirmation step, give the user only the blocked step, wait, then resume.
+
+### 3. Implement the dispatcher + worker pair
+
+Create or update two agents (exact tool-deny shapes in
+[references/repo-topic-config.md](references/repo-topic-config.md)):
+
+- **`<topic-slug>-dispatch`** — skill-aware entrypoint; tools restricted to delegation/session tools
+  (+ optional `read`); denies file writes, shell/exec, browser, gateway, automation; may delegate
+  only to `<topic-slug>-codex`.
+- **`<topic-slug>-codex`** — restricted worker; keeps `read` + `exec`; denies session spawning,
+  browser, gateway, and direct file-write tools; runs the local coding CLI for the actual work.
+
+### 4. Repo-selection behavior
+
+- `single-repo`: treat the repo as decided; pass the fixed repo path to the worker; never ask.
+- `folder-scoped`: infer candidates from the catalog. If the user named repo(s) explicitly, skip
+  confirmation; otherwise ask before spawning:
+  - one likely repo: `This looks like <repo>. Is that correct?`
+  - multiple: `This may belong to <repo-1> or <repo-2>. Is that correct, or which repo(s)?`
+  On confirmation of multiple repos, spawn one worker run per repo (or ask the user to split a
+  too-coupled change). Never skip confirmation in folder-scoped mode unless selection was explicit.
+
+### 5. Worker safety contract
+
+Every worker task receives an explicit repo path and:
+
+1. inspects `git status --short --branch` in the selected repo
+2. if the primary checkout is dirty or already on a feature branch, creates a temporary worktree from
+   `main` under `/tmp`
+3. trusts local tool config in a fresh worktree if required (e.g. `mise trust <target_dir>`)
+4. runs the coding CLI in the foreground in the target directory
+5. cleans up the temporary worktree after success when safe
+
+The worker prepares the safe target and launches the CLI; it does not edit files directly.
+
+### 6. Bind the topic
+
+Route the topic to the dispatcher. In single-account Telegram configs, set
+`channels.telegram.groups.<group-id>.topics.<topic-id>.agentId = <topic-slug>-dispatch`. In
+multi-account Telegram configs, set the same route under the owning bot account:
+`channels.telegram.accounts.<account-id>.groups.<group-id>.topics.<topic-id>.agentId =
+<topic-slug>-dispatch`. Account configs do not inherit root `channels.telegram.groups` routes, so a
+root-only route can validate while the actual bot still ignores the topic-level `requireMention`,
+`agentId`, and prompt. When in doubt, mirror the route under the owning account and keep any existing
+root group route only as a fallback/documentation shape.
+
+Account-scoped topic `agentId` routes also require an OpenClaw runtime that treats the topic agent as
+an explicit group route for non-default Telegram accounts. If the self-test logs
+`drop non-default account requires explicit binding`, update or rebuild OpenClaw before adding config
+workarounds; do not create persistent ACP bindings solely to bypass that guard.
+
+Keep allowlist policy, and add `allowFrom` only when membership must be narrower than the group.
+Leave the topic-level `requireMention = false` (the default) so the agent activates on any message —
+the topic is bound 1:1 to this dispatcher, so an @mention carries no routing information and is pure
+friction. Set it to `true` only for a shared-workspace topic where humans also coordinate with each
+other and you don't want every line to spawn a run; the group-level `requireMention` stays `true`
+regardless. See "Mention gating" in [references/repo-topic-config.md](references/repo-topic-config.md)
+for the tradeoff. The topic `systemPrompt` must state the scope mode, treat each native-reply root as
+an independent request context, confirm repo selection only in folder-scoped mode, spawn the worker
+with an explicit repo path, and return the worker result to the topic. If the route may return
+generated files, the prompt must also say to write or copy returnable artifacts under
+`~/.openclaw/media` before calling `message(action="send")`, because outbound local media delivery
+rejects arbitrary `/tmp` paths. Back up `~/.openclaw/openclaw.json` before editing and preserve
+unrelated routes.
+
+### 7. Validate + self-test
+
+```sh
+openclaw config validate
+openclaw gateway restart
+openclaw gateway status
+openclaw channels status --probe
+```
+
+Then from the target topic, send a plain message with **no** @mention (the default
+`requireMention = false` means the agent must activate without one) asking for an exact-token reply
+with **no** file changes, commits, PRs, or merges, e.g. `reply with exactly TELEGRAM-ROUTE-OK`.
+Confirm the visible reply, that the dispatcher spawned the worker, and that the worker ran in the
+intended repo. If there is no dispatcher session, inspect `/tmp/openclaw/openclaw-YYYY-MM-DD.log`;
+`drop non-default account requires explicit binding` means the OpenClaw runtime is too old for
+account-scoped topic-agent routing. If the topic was deliberately left at `requireMention = true`,
+mention the bot instead (`<bot-handle> reply with exactly TELEGRAM-ROUTE-OK`) and additionally
+confirm that an un-mentioned message is **ignored**. For folder-scoped topics, also send a request
+that implies but doesn't name a repo and confirm the dispatcher asks for confirmation before
+proceeding. Do **not** treat `openclaw agent --agent <id> ...` as proof a topic route works — use the
+visible topic reply.
+
+## Output standard
+
+Finish with: group id + topic id used; scope mode; workspace root and repo path or catalog;
+dispatcher + worker agent ids; whether the bot is confirmed group admin; validation results; whether
+the self-test passed; and any remaining manual follow-up or trust caveat.
+
+## Related
+
+`lisa-openclaw-setup` (run first), `lisa-openclaw-connect-staff` (facilitator/specialist staff on
+Telegram or Slack).

package/plugins/lisa-openclaw/.codex-plugin/skills/lisa-openclaw-connect-repo-topic/agents/openai.yaml

@@ -0,0 +1,4 @@
+display_name: "Openclaw Connect Repo Topic"
+short_description: "Bind a Telegram forum topic to…"
+default_prompt:
+  - "Use $lisa-openclaw-connect-repo-topic: Bind a Telegram forum topic to…."

package/plugins/lisa-openclaw/.codex-plugin/skills/lisa-openclaw-connect-repo-topic/references/repo-topic-config.md

@@ -0,0 +1,185 @@
+# Repo-coding topic config shapes
+
+Placeholder-only. Real ids/paths/handles go only into `~/.openclaw/openclaw.json` (machine-local,
+never committed). Back up that file before editing; change only the intended keys.
+
+## Trust model
+
+- `admin` group: highly trusted people; machine-config/infra repos allowed; topics may request merge
+  after PR.
+- `developer` group: broader collaborators; topics stop at change + docs + commit + PR unless
+  explicitly raised.
+
+If two repos need different member lists, use different groups even if both are `developer`.
+
+## Folder-scoped repo catalog
+
+```yaml
+repos:
+  - name: repo-1
+    path: /absolute/path/to/repo-1
+    hints: [billing, invoices]
+  - name: repo-2
+    path: /absolute/path/to/repo-2
+    hints: [login, mobile-app]
+```
+
+## Naming
+
+- topic slug: derived from the topic purpose or workspace name
+- dispatcher agent id: `<topic-slug>-dispatch`
+- worker agent id: `<topic-slug>-codex`
+
+## Dispatcher agent
+
+```json5
+{
+  "id": "<topic-slug>-dispatch",
+  "workspace": "/absolute/path/to/repo-or-parent",
+  "skills": ["acp-router"],
+  "subagents": { "allowAgents": ["<topic-slug>-codex"] },
+  "tools": {
+    "profile": "coding",
+    "deny": [
+      "group:ui", "group:automation", "group:nodes",
+      "bash", "exec", "process", "browser", "canvas", "cron",
+      "gateway", "write", "edit", "apply_patch"
+    ]
+  },
+  "elevated": { "enabled": false }
+}
+```
+
+## Worker agent
+
+```json5
+{
+  "id": "<topic-slug>-codex",
+  "workspace": "/absolute/path/to/repo-or-parent",
+  "tools": {
+    "profile": "coding",
+    "deny": [
+      "group:ui", "group:automation", "group:nodes", "group:sessions",
+      "subagents", "process", "browser", "canvas", "cron",
+      "gateway", "write", "edit", "apply_patch"
+    ]
+  },
+  "elevated": { "enabled": false }
+}
+```
+
+## Topic route
+
+Use `channels.telegram.groups` for a single-account Telegram setup. If
+`channels.telegram.accounts` is configured, bind the route under the owning bot account instead:
+`channels.telegram.accounts.<account-id>.groups.<group-id>`. Account-scoped Telegram configs do not
+inherit root `channels.telegram.groups` 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 topic self-test is delivered to the
+bot but the logs show `drop non-default account requires explicit binding`, update or rebuild
+OpenClaw. Do not add a persistent ACP binding as a workaround; the configured topic `agentId` is the
+intended route.
+
+### Single-account route
+
+```json5
+{
+  "channels": {
+    "telegram": {
+      "groups": {
+        "<group-id>": {
+          "groupPolicy": "allowlist",
+          // Group-level gate stays on: messages in the group that are NOT inside a
+          // routed topic still require an explicit mention.
+          "requireMention": true,
+          "allowFrom": ["<telegram-user-id>"],
+          "topics": {
+            "<topic-id>": {
+              "agentId": "<topic-slug>-dispatch",
+              // Default false: the topic is bound 1:1 to this agent, so every message
+              // in it is already addressed to the agent — an @mention carries no routing
+              // information. Flip to true only for shared-workspace topics where humans
+              // also coordinate with each other (see "Mention gating" below).
+              "requireMention": false,
+              "systemPrompt": "Use the topic's configured scope mode. For single-repo, pass the fixed repo path to <topic-slug>-codex. For folder-scoped, confirm the inferred repo or repo set unless the user already named it explicitly, then pass the explicit repo path(s) to <topic-slug>-codex. Treat each native reply root as an independent request context."
+            }
+          }
+        }
+      }
+    }
+  }
+}
+```
+
+### Multi-account route
+
+```json5
+{
+  "channels": {
+    "telegram": {
+      "accounts": {
+        "<account-id>": {
+          "groups": {
+            "<group-id>": {
+              "groupPolicy": "allowlist",
+              "requireMention": true,
+              "allowFrom": ["<telegram-user-id>"],
+              "topics": {
+                "<topic-id>": {
+                  "agentId": "<topic-slug>-dispatch",
+                  "requireMention": false,
+                  "systemPrompt": "Use the topic's configured scope mode. For single-repo, pass the fixed repo path to <topic-slug>-codex. For folder-scoped, confirm the inferred repo or repo set unless the user already named it explicitly, then pass the explicit repo path(s) to <topic-slug>-codex. Treat each native reply root as an independent request context. If generated files need to be returned as Telegram attachments, write or copy them under ~/.openclaw/media before calling message(action=\"send\"), because outbound local media delivery rejects arbitrary /tmp paths."
+                }
+              }
+            }
+          }
+        }
+      }
+    }
+  }
+}
+```
+
+## File return path
+
+When a repo-topic agent returns generated files to Telegram, use the OpenClaw `message` tool with
+real local file paths. Write or copy returnable artifacts under `~/.openclaw/media` before sending;
+outbound local media delivery rejects arbitrary `/tmp` paths even when the file exists.
+
+## Mention gating
+
+`requireMention` controls whether a message must @-mention the bot before the agent activates. It is
+set independently at the group level and the topic level; the topic-level value wins for messages
+inside a routed topic.
+
+- **Topic level — default `false`.** A repo-coding topic is bound 1:1 to its dispatcher
+  (`agentId`), so the topic itself already determines the agent. Every message in the topic is
+  addressed to that agent and the @mention adds nothing but friction. This is the "inbox topic"
+  shape: the topic *is* the conversation with the agent.
+- **Set the topic level to `true`** only for a **shared-workspace topic** — one where humans also
+  talk *to each other* (status updates, coordination) and you do not want every stray line to spawn
+  an agent run. The mention then acts as an explicit "this one is for the bot" intent signal.
+- **Group level — keep `true`.** It gates messages posted in the group but outside any routed
+  topic, where there is no 1:1 agent binding to lean on.
+
+Tradeoff to weigh before leaving a topic at `false`: with no mention required, **every** top-level
+message and **every** native reply in the topic wakes the dispatcher (and can spawn a worker run). In
+an inbox topic that is exactly what you want; in a topic people also chat in, it is noise and cost.
+When in doubt, keep code-work topics as dedicated inbox topics (`false`) and push human coordination
+to a separate topic or the group body.
+
+## Worker launcher form
+
+```sh
+PATH="$HOME/bin:/opt/homebrew/bin:/opt/homebrew/sbin:/usr/local/bin:/usr/bin:/bin" \
+  "$HOME/bin/<coding-cli>" exec -C <target_dir> "<prompt>"
+```
+
+## Id rules
+
+- Telegram Bot API `chat_id` for a supergroup is the full signed id (usually starts `-100`); the short
+  positive number is not a valid substitute.
+- Topic id is the Telegram `message_thread_id`.
+- Discover ids from a logged-in Telegram client, an existing route in `~/.openclaw/openclaw.json`, or a
+  received Bot API update — the Bot API cannot list groups by name.

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

@@ -0,0 +1,175 @@
+---
+name: lisa-openclaw-connect-staff
+description: "Connect staff roles to a human…"
+---
+
+# lisa-openclaw-connect-staff
+
+Wire existing staff roles into a working hub-and-spoke chat deployment on **Telegram** or **Slack**
+through OpenClaw. Humans talk only to the **facilitator** (the "chief of staff"); the facilitator
+consults **specialists** internally and synthesizes one answer back to the human.
+
+This SKILL.md is the complete, runnable definition for **both Claude Code and Codex**. Codex has no
+command or `$ARGUMENTS` layer, so every behavior — including platform selection — is specified here.
+Keep all real values (org names, ids, handles, tokens, paths) out of any committed file; they belong
+only in `~/.openclaw/openclaw.json` (machine-local, never committed).
+
+## Prerequisites
+
+1. `lisa-openclaw-setup` has run (an `openclaw` section exists in `.lisa.config.json`, and the
+   required gateway capabilities — `sessions_spawn`, native-reply session scoping, `NO_REPLY` — are
+   confirmed). If a capability is unmet, **fail closed**: do not create routes that would post
+   duplicates or bleed cross-thread context.
+2. The staff roles to connect exist in `config.staff[]` and each has a dual-runtime subagent
+   (`.claude/agents/<id>.md` + `.codex/agents/<id>.toml`). If a role or its subagent is missing:
+   - Claude Code: run `/lisa:add-role <Role>` first.
+   - Codex: invoke `$lisa-wiki:lisa-wiki-add-role` first.
+   Only auto-delegate if that skill is available in the active runtime; otherwise print the exact
+   next step and stop. **Never infer agent ids from display names** — always use `config.staff[].id`.
+
+## Platform selection (identical in both runtimes)
+
+Resolve the platform with this precedence:
+
+1. An explicit platform in the user's request (the Claude commands pre-state `telegram` or `slack`).
+2. `openclaw.defaultPlatform` from `.lisa.config.json`.
+3. If still unknown, ask exactly one question: `Connect staff via telegram or slack?`
+
+## Hub-and-spoke contract (both platforms)
+
+- Humans speak only to the facilitator; specialists never take direct human work.
+- The facilitator consults specialists via internal OpenClaw `sessions_spawn` with **explicit**
+  `agentId`s — never by messaging another bot on the chat platform (bot-to-bot delivery is
+  unreliable; treat any visible specialist "workroom" as an audit copy, not proof of delivery).
+- Each visible human request thread is its own short-term session boundary.
+- The facilitator acknowledges after starting consultation, waits/yields for specialist results,
+  evaluates them (asking follow-ups when weak/incomplete/conflicting), synthesizes one answer, and
+  replies in the original thread / native reply.
+- After any explicit message-tool send, the agent returns exactly `NO_REPLY` as its assistant final
+  so the gateway does not post a duplicate loose message.
+- Do not instruct agents to add bracketed self-labels like `[Facilitator]`; the platform shows
+  identity.
+
+## Required inputs
+
+- platform (resolved above)
+- facilitator: staff id, display name, title, human-facing surface name
+- specialists: list of staff ids + roles to attach to this facilitator
+- surface visibility: Slack channel `private` (default) or `public`; for Telegram, whether any
+  specialist audit topics are wanted (default: none)
+- visible bot/app identities (display names, usernames/handles) if separate avatars are needed
+- communication rules (who may talk to whom)
+
+For exact route shapes and the facilitator/specialist prompt text, read
+[references/platform-routing.md](references/platform-routing.md) and
+[references/prompts.md](references/prompts.md).
+
+## Workflow
+
+### 1. Inspect existing state
+
+Read only what you need; never print token contents:
+
+- `~/.openclaw/openclaw.json` (existing agents, channels, groups, topics, routes)
+- `config.staff[]` and the staff subagent files
+- existing chat surfaces, apps, and bot accounts (reuse before creating)
+
+### 2. Plan the platform shape
+
+**Telegram:** create or reuse one organization supergroup with forum topics enabled; create one
+human-facing facilitator topic; create one bot per visible identity only when separate names/avatars
+are needed; specialist audit topics only if explicitly requested. The Bot API `chat_id` for a
+supergroup is the **signed** id (usually starting `-100`); the topic id is the
+`message_thread_id`.
+
+**Slack:** use Socket Mode for a workstation-hosted gateway unless told otherwise; create or reuse one
+human-facing facilitator channel (default `<organization-slug>-chief-of-staff`, private/invite-only
+unless public is requested); bind routes by stable channel **id**, not channel name; optional
+specialist workrooms are audit-only.
+
+Telegram bot-to-bot and bot-originated-topic messages can fail to wake other bots — this is exactly
+why internal `sessions_spawn` is the default route.
+
+### 3. Register apps / bots and store tokens
+
+- Telegram: create bots with the agreed names/usernames; add visible bots to the supergroup, promote
+  as needed, and disable privacy mode when topic messages must reach them.
+- Slack: create or reuse the org app; grant only required scopes; save `xoxb`/`xapp` tokens.
+- Store every token via the configured secret provider (or `0600` local files outside the repo).
+  **Never** print/paste tokens into chat, logs, docs, or any committed file. After saving, verify the
+  token via an OpenClaw probe or platform API check without exposing it.
+- If creation is rate-limited (e.g. BotFather) or needs a human confirmation step, wire what
+  completed, record what is pending plus the retry time, and ask only for the specific approval/code
+  needed.
+
+### 4. Create or update agent files
+
+For the facilitator and each specialist, ensure the OpenClaw agent exists and its prompt encodes the
+hub-and-spoke contract. Use the prompt templates in [references/prompts.md](references/prompts.md).
+The facilitator prompt must require: consult ≥1 specialist before substantive answers; treat the
+current thread/native-reply root as the session boundary; route via `sessions_spawn` with explicit
+`agentId`s; acknowledge → yield/wait → evaluate → synthesize → reply in the original thread; return
+`NO_REPLY` after any message-tool send; isolate/clear/archive consulted specialist context after the
+investigation. Specialist prompts must require: accept work only via internal dispatch; return
+concise structured results; never post to human-facing surfaces.
+
+### 5. Wire OpenClaw routing
+
+Edit `~/.openclaw/openclaw.json` carefully (see [references/platform-routing.md](references/platform-routing.md)
+for exact shapes). **Back up the file first.** Parse JSON, change only the intended keys, and preserve
+all unrelated agents, channels, routes, and tokens:
+
+- add/update each agent in `agents.list`
+- give the facilitator `subagents.allowAgents` = the specialist ids; set
+  `subagents.requireAgentId = true` when supported
+- bind the human-facing surface (Telegram topic / Slack channel) to the facilitator
+- bind optional audit surfaces as visibility-only
+- for Slack, set `channels.slack.replyToModeByChatType.channel = "all"` so acknowledgements and final
+  answers are real thread replies
+- disable any default-bot fallback that would answer instead of the facilitator
+
+Show the exact route keys you will change before writing.
+
+### 6. Validate
+
+Run, waiting for the gateway to warm up before declaring success:
+
+```sh
+openclaw config validate
+openclaw gateway restart
+openclaw channels status --probe --timeout 90000
+```
+
+### 7. Reset stale sessions (when changing an existing route's behavior)
+
+Archive (don't delete) affected session files under `~/.openclaw/session-archive/`, remove active
+session pointers for the changed routes, restart the gateway, and re-probe. Old session history can
+preserve stale routing instructions after a prompt/config change.
+
+### 8. End-to-end route test
+
+Do not call the work complete until the live loop passes. Acceptance criteria:
+
+1. A human post reaches the facilitator surface.
+2. The facilitator acknowledges as a thread reply / native reply to the original message.
+3. A second post in the same channel/topic but a different visible thread gets a **distinct** session
+   context (no cross-thread bleed).
+4. The facilitator starts internal `sessions_spawn` consultation with ≥1 explicit specialist id.
+5. A specialist returns an internal result.
+6. The facilitator evaluates and asks a follow-up if needed.
+7. The facilitator synthesizes and replies in the original thread / native reply.
+8. No duplicate loose message appears after the message-tool send (the `NO_REPLY` rule held).
+
+If the test fails, inspect gateway logs and sessions before changing config; check the bot's admin
+rights (Telegram) / app channel membership and scopes (Slack), and mention-gating, first.
+
+## Output standard
+
+Finish with: platform and human-facing surface; surfaces created/reused; apps/bots registered and any
+pending; token storage location (no values); facilitator + specialist agents created/updated;
+validation results; end-to-end test result; and any remaining manual or cooldown follow-up.
+
+## Related
+
+`lisa-openclaw-setup` (run first), `lisa-openclaw-connect-repo-topic` (Telegram repo-coding topics).
+Staff "brains" come from the `lisa-wiki` plugin's `add-role`.

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

@@ -0,0 +1,4 @@
+display_name: "Openclaw Connect Staff"
+short_description: "Connect staff roles to a human…"
+default_prompt:
+  - "Use $lisa-openclaw-connect-staff: Connect staff roles to a human…."