@codyswann/lisa 2.135.0 → 2.136.0
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/package.json +1 -1
- package/plugins/lisa/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-agy/plugin.json +1 -1
- package/plugins/lisa-cdk/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-cdk/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-cdk-agy/plugin.json +1 -1
- package/plugins/lisa-cdk-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-cdk-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-expo/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-expo/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-expo-agy/plugin.json +1 -1
- package/plugins/lisa-expo-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-expo-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-harper-fabric/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-harper-fabric/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-harper-fabric-agy/plugin.json +1 -1
- package/plugins/lisa-harper-fabric-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-harper-fabric-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-nestjs/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-nestjs/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-nestjs-agy/plugin.json +1 -1
- package/plugins/lisa-nestjs-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-nestjs-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-openclaw/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-openclaw/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-openclaw/skills/lisa-openclaw-connect-repo-topic/SKILL.md +15 -7
- package/plugins/lisa-openclaw/skills/lisa-openclaw-connect-repo-topic/references/repo-topic-config.md +29 -1
- package/plugins/lisa-openclaw-agy/plugin.json +1 -1
- package/plugins/lisa-openclaw-agy/skills/lisa-openclaw-connect-repo-topic/SKILL.md +15 -7
- package/plugins/lisa-openclaw-agy/skills/lisa-openclaw-connect-repo-topic/references/repo-topic-config.md +29 -1
- package/plugins/lisa-openclaw-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-openclaw-copilot/skills/lisa-openclaw-connect-repo-topic/SKILL.md +15 -7
- package/plugins/lisa-openclaw-copilot/skills/lisa-openclaw-connect-repo-topic/references/repo-topic-config.md +29 -1
- package/plugins/lisa-openclaw-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-openclaw-cursor/skills/lisa-openclaw-connect-repo-topic/SKILL.md +15 -7
- package/plugins/lisa-openclaw-cursor/skills/lisa-openclaw-connect-repo-topic/references/repo-topic-config.md +29 -1
- package/plugins/lisa-rails/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-rails/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-rails-agy/plugin.json +1 -1
- package/plugins/lisa-rails-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-rails-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-typescript/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-typescript/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-typescript-agy/plugin.json +1 -1
- package/plugins/lisa-typescript-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-typescript-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-wiki/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-wiki/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-wiki-agy/plugin.json +1 -1
- package/plugins/lisa-wiki-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-wiki-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/src/openclaw/skills/lisa-openclaw-connect-repo-topic/SKILL.md +15 -7
- package/plugins/src/openclaw/skills/lisa-openclaw-connect-repo-topic/references/repo-topic-config.md +29 -1
package/package.json
CHANGED
|
@@ -83,7 +83,7 @@
|
|
|
83
83
|
"lodash": ">=4.18.1"
|
|
84
84
|
},
|
|
85
85
|
"name": "@codyswann/lisa",
|
|
86
|
-
"version": "2.
|
|
86
|
+
"version": "2.136.0",
|
|
87
87
|
"description": "Claude Code governance framework that applies guardrails, guidance, and automated enforcement to projects",
|
|
88
88
|
"main": "dist/index.js",
|
|
89
89
|
"exports": {
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "lisa-openclaw",
|
|
3
|
-
"version": "2.
|
|
3
|
+
"version": "2.136.0",
|
|
4
4
|
"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",
|
|
5
5
|
"author": {
|
|
6
6
|
"name": "Cody Swann"
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "lisa-openclaw",
|
|
3
|
-
"version": "2.
|
|
3
|
+
"version": "2.136.0",
|
|
4
4
|
"description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, across Claude and Codex.",
|
|
5
5
|
"author": {
|
|
6
6
|
"name": "Cody Swann"
|
|
@@ -103,8 +103,13 @@ The worker prepares the safe target and launches the CLI; it does not edit files
|
|
|
103
103
|
|
|
104
104
|
Route the topic to the dispatcher: set
|
|
105
105
|
`channels.telegram.groups.<group-id>.topics.<topic-id>.agentId = <topic-slug>-dispatch`, keep
|
|
106
|
-
|
|
107
|
-
|
|
106
|
+
allowlist policy, and add `allowFrom` only when membership must be narrower than the group. Leave the
|
|
107
|
+
topic-level `requireMention = false` (the default) so the agent activates on any message — the topic
|
|
108
|
+
is bound 1:1 to this dispatcher, so an @mention carries no routing information and is pure friction.
|
|
109
|
+
Set it to `true` only for a shared-workspace topic where humans also coordinate with each other and
|
|
110
|
+
you don't want every line to spawn a run; the group-level `requireMention` stays `true` regardless.
|
|
111
|
+
See "Mention gating" in [references/repo-topic-config.md](references/repo-topic-config.md) for the
|
|
112
|
+
tradeoff. The topic `systemPrompt` must state the scope mode, treat each native-reply
|
|
108
113
|
root as an independent request context, confirm repo selection only in folder-scoped mode, spawn the
|
|
109
114
|
worker with an explicit repo path, and return the worker result to the topic. Back up
|
|
110
115
|
`~/.openclaw/openclaw.json` before editing and preserve unrelated routes.
|
|
@@ -118,11 +123,14 @@ openclaw gateway status
|
|
|
118
123
|
openclaw channels status --probe
|
|
119
124
|
```
|
|
120
125
|
|
|
121
|
-
Then from the target topic
|
|
122
|
-
|
|
123
|
-
|
|
124
|
-
|
|
125
|
-
the
|
|
126
|
+
Then from the target topic, send a plain message with **no** @mention (the default
|
|
127
|
+
`requireMention = false` means the agent must activate without one) asking for an exact-token reply
|
|
128
|
+
with **no** file changes, commits, PRs, or merges, e.g. `reply with exactly TELEGRAM-ROUTE-OK`.
|
|
129
|
+
Confirm the visible reply, that the dispatcher spawned the worker, and that the worker ran in the
|
|
130
|
+
intended repo. If the topic was deliberately left at `requireMention = true`, mention the bot instead
|
|
131
|
+
(`<bot-handle> reply with exactly TELEGRAM-ROUTE-OK`) and additionally confirm that an un-mentioned
|
|
132
|
+
message is **ignored**. For folder-scoped topics, also send a request that implies but doesn't name a
|
|
133
|
+
repo and confirm the dispatcher asks for confirmation before proceeding. Do **not** treat `openclaw agent --agent
|
|
126
134
|
<id> ...` as proof a topic route works — use the visible topic reply.
|
|
127
135
|
|
|
128
136
|
## Output standard
|
|
@@ -77,12 +77,18 @@ repos:
|
|
|
77
77
|
"groups": {
|
|
78
78
|
"<group-id>": {
|
|
79
79
|
"groupPolicy": "allowlist",
|
|
80
|
+
// Group-level gate stays on: messages in the group that are NOT inside a
|
|
81
|
+
// routed topic still require an explicit mention.
|
|
80
82
|
"requireMention": true,
|
|
81
83
|
"allowFrom": ["<telegram-user-id>"],
|
|
82
84
|
"topics": {
|
|
83
85
|
"<topic-id>": {
|
|
84
86
|
"agentId": "<topic-slug>-dispatch",
|
|
85
|
-
|
|
87
|
+
// Default false: the topic is bound 1:1 to this agent, so every message
|
|
88
|
+
// in it is already addressed to the agent — an @mention carries no routing
|
|
89
|
+
// information. Flip to true only for shared-workspace topics where humans
|
|
90
|
+
// also coordinate with each other (see "Mention gating" below).
|
|
91
|
+
"requireMention": false,
|
|
86
92
|
"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."
|
|
87
93
|
}
|
|
88
94
|
}
|
|
@@ -93,6 +99,28 @@ repos:
|
|
|
93
99
|
}
|
|
94
100
|
```
|
|
95
101
|
|
|
102
|
+
## Mention gating
|
|
103
|
+
|
|
104
|
+
`requireMention` controls whether a message must @-mention the bot before the agent activates. It is
|
|
105
|
+
set independently at the group level and the topic level; the topic-level value wins for messages
|
|
106
|
+
inside a routed topic.
|
|
107
|
+
|
|
108
|
+
- **Topic level — default `false`.** A repo-coding topic is bound 1:1 to its dispatcher
|
|
109
|
+
(`agentId`), so the topic itself already determines the agent. Every message in the topic is
|
|
110
|
+
addressed to that agent and the @mention adds nothing but friction. This is the "inbox topic"
|
|
111
|
+
shape: the topic *is* the conversation with the agent.
|
|
112
|
+
- **Set the topic level to `true`** only for a **shared-workspace topic** — one where humans also
|
|
113
|
+
talk *to each other* (status updates, coordination) and you do not want every stray line to spawn
|
|
114
|
+
an agent run. The mention then acts as an explicit "this one is for the bot" intent signal.
|
|
115
|
+
- **Group level — keep `true`.** It gates messages posted in the group but outside any routed
|
|
116
|
+
topic, where there is no 1:1 agent binding to lean on.
|
|
117
|
+
|
|
118
|
+
Tradeoff to weigh before leaving a topic at `false`: with no mention required, **every** top-level
|
|
119
|
+
message and **every** native reply in the topic wakes the dispatcher (and can spawn a worker run). In
|
|
120
|
+
an inbox topic that is exactly what you want; in a topic people also chat in, it is noise and cost.
|
|
121
|
+
When in doubt, keep code-work topics as dedicated inbox topics (`false`) and push human coordination
|
|
122
|
+
to a separate topic or the group body.
|
|
123
|
+
|
|
96
124
|
## Worker launcher form
|
|
97
125
|
|
|
98
126
|
```sh
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "lisa-openclaw",
|
|
3
|
-
"version": "2.
|
|
3
|
+
"version": "2.136.0",
|
|
4
4
|
"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",
|
|
5
5
|
"author": {
|
|
6
6
|
"name": "Cody Swann"
|
|
@@ -103,8 +103,13 @@ The worker prepares the safe target and launches the CLI; it does not edit files
|
|
|
103
103
|
|
|
104
104
|
Route the topic to the dispatcher: set
|
|
105
105
|
`channels.telegram.groups.<group-id>.topics.<topic-id>.agentId = <topic-slug>-dispatch`, keep
|
|
106
|
-
|
|
107
|
-
|
|
106
|
+
allowlist policy, and add `allowFrom` only when membership must be narrower than the group. Leave the
|
|
107
|
+
topic-level `requireMention = false` (the default) so the agent activates on any message — the topic
|
|
108
|
+
is bound 1:1 to this dispatcher, so an @mention carries no routing information and is pure friction.
|
|
109
|
+
Set it to `true` only for a shared-workspace topic where humans also coordinate with each other and
|
|
110
|
+
you don't want every line to spawn a run; the group-level `requireMention` stays `true` regardless.
|
|
111
|
+
See "Mention gating" in [references/repo-topic-config.md](references/repo-topic-config.md) for the
|
|
112
|
+
tradeoff. The topic `systemPrompt` must state the scope mode, treat each native-reply
|
|
108
113
|
root as an independent request context, confirm repo selection only in folder-scoped mode, spawn the
|
|
109
114
|
worker with an explicit repo path, and return the worker result to the topic. Back up
|
|
110
115
|
`~/.openclaw/openclaw.json` before editing and preserve unrelated routes.
|
|
@@ -118,11 +123,14 @@ openclaw gateway status
|
|
|
118
123
|
openclaw channels status --probe
|
|
119
124
|
```
|
|
120
125
|
|
|
121
|
-
Then from the target topic
|
|
122
|
-
|
|
123
|
-
|
|
124
|
-
|
|
125
|
-
the
|
|
126
|
+
Then from the target topic, send a plain message with **no** @mention (the default
|
|
127
|
+
`requireMention = false` means the agent must activate without one) asking for an exact-token reply
|
|
128
|
+
with **no** file changes, commits, PRs, or merges, e.g. `reply with exactly TELEGRAM-ROUTE-OK`.
|
|
129
|
+
Confirm the visible reply, that the dispatcher spawned the worker, and that the worker ran in the
|
|
130
|
+
intended repo. If the topic was deliberately left at `requireMention = true`, mention the bot instead
|
|
131
|
+
(`<bot-handle> reply with exactly TELEGRAM-ROUTE-OK`) and additionally confirm that an un-mentioned
|
|
132
|
+
message is **ignored**. For folder-scoped topics, also send a request that implies but doesn't name a
|
|
133
|
+
repo and confirm the dispatcher asks for confirmation before proceeding. Do **not** treat `openclaw agent --agent
|
|
126
134
|
<id> ...` as proof a topic route works — use the visible topic reply.
|
|
127
135
|
|
|
128
136
|
## Output standard
|
|
@@ -77,12 +77,18 @@ repos:
|
|
|
77
77
|
"groups": {
|
|
78
78
|
"<group-id>": {
|
|
79
79
|
"groupPolicy": "allowlist",
|
|
80
|
+
// Group-level gate stays on: messages in the group that are NOT inside a
|
|
81
|
+
// routed topic still require an explicit mention.
|
|
80
82
|
"requireMention": true,
|
|
81
83
|
"allowFrom": ["<telegram-user-id>"],
|
|
82
84
|
"topics": {
|
|
83
85
|
"<topic-id>": {
|
|
84
86
|
"agentId": "<topic-slug>-dispatch",
|
|
85
|
-
|
|
87
|
+
// Default false: the topic is bound 1:1 to this agent, so every message
|
|
88
|
+
// in it is already addressed to the agent — an @mention carries no routing
|
|
89
|
+
// information. Flip to true only for shared-workspace topics where humans
|
|
90
|
+
// also coordinate with each other (see "Mention gating" below).
|
|
91
|
+
"requireMention": false,
|
|
86
92
|
"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."
|
|
87
93
|
}
|
|
88
94
|
}
|
|
@@ -93,6 +99,28 @@ repos:
|
|
|
93
99
|
}
|
|
94
100
|
```
|
|
95
101
|
|
|
102
|
+
## Mention gating
|
|
103
|
+
|
|
104
|
+
`requireMention` controls whether a message must @-mention the bot before the agent activates. It is
|
|
105
|
+
set independently at the group level and the topic level; the topic-level value wins for messages
|
|
106
|
+
inside a routed topic.
|
|
107
|
+
|
|
108
|
+
- **Topic level — default `false`.** A repo-coding topic is bound 1:1 to its dispatcher
|
|
109
|
+
(`agentId`), so the topic itself already determines the agent. Every message in the topic is
|
|
110
|
+
addressed to that agent and the @mention adds nothing but friction. This is the "inbox topic"
|
|
111
|
+
shape: the topic *is* the conversation with the agent.
|
|
112
|
+
- **Set the topic level to `true`** only for a **shared-workspace topic** — one where humans also
|
|
113
|
+
talk *to each other* (status updates, coordination) and you do not want every stray line to spawn
|
|
114
|
+
an agent run. The mention then acts as an explicit "this one is for the bot" intent signal.
|
|
115
|
+
- **Group level — keep `true`.** It gates messages posted in the group but outside any routed
|
|
116
|
+
topic, where there is no 1:1 agent binding to lean on.
|
|
117
|
+
|
|
118
|
+
Tradeoff to weigh before leaving a topic at `false`: with no mention required, **every** top-level
|
|
119
|
+
message and **every** native reply in the topic wakes the dispatcher (and can spawn a worker run). In
|
|
120
|
+
an inbox topic that is exactly what you want; in a topic people also chat in, it is noise and cost.
|
|
121
|
+
When in doubt, keep code-work topics as dedicated inbox topics (`false`) and push human coordination
|
|
122
|
+
to a separate topic or the group body.
|
|
123
|
+
|
|
96
124
|
## Worker launcher form
|
|
97
125
|
|
|
98
126
|
```sh
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "lisa-openclaw",
|
|
3
|
-
"version": "2.
|
|
3
|
+
"version": "2.136.0",
|
|
4
4
|
"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",
|
|
5
5
|
"author": {
|
|
6
6
|
"name": "Cody Swann"
|
|
@@ -103,8 +103,13 @@ The worker prepares the safe target and launches the CLI; it does not edit files
|
|
|
103
103
|
|
|
104
104
|
Route the topic to the dispatcher: set
|
|
105
105
|
`channels.telegram.groups.<group-id>.topics.<topic-id>.agentId = <topic-slug>-dispatch`, keep
|
|
106
|
-
|
|
107
|
-
|
|
106
|
+
allowlist policy, and add `allowFrom` only when membership must be narrower than the group. Leave the
|
|
107
|
+
topic-level `requireMention = false` (the default) so the agent activates on any message — the topic
|
|
108
|
+
is bound 1:1 to this dispatcher, so an @mention carries no routing information and is pure friction.
|
|
109
|
+
Set it to `true` only for a shared-workspace topic where humans also coordinate with each other and
|
|
110
|
+
you don't want every line to spawn a run; the group-level `requireMention` stays `true` regardless.
|
|
111
|
+
See "Mention gating" in [references/repo-topic-config.md](references/repo-topic-config.md) for the
|
|
112
|
+
tradeoff. The topic `systemPrompt` must state the scope mode, treat each native-reply
|
|
108
113
|
root as an independent request context, confirm repo selection only in folder-scoped mode, spawn the
|
|
109
114
|
worker with an explicit repo path, and return the worker result to the topic. Back up
|
|
110
115
|
`~/.openclaw/openclaw.json` before editing and preserve unrelated routes.
|
|
@@ -118,11 +123,14 @@ openclaw gateway status
|
|
|
118
123
|
openclaw channels status --probe
|
|
119
124
|
```
|
|
120
125
|
|
|
121
|
-
Then from the target topic
|
|
122
|
-
|
|
123
|
-
|
|
124
|
-
|
|
125
|
-
the
|
|
126
|
+
Then from the target topic, send a plain message with **no** @mention (the default
|
|
127
|
+
`requireMention = false` means the agent must activate without one) asking for an exact-token reply
|
|
128
|
+
with **no** file changes, commits, PRs, or merges, e.g. `reply with exactly TELEGRAM-ROUTE-OK`.
|
|
129
|
+
Confirm the visible reply, that the dispatcher spawned the worker, and that the worker ran in the
|
|
130
|
+
intended repo. If the topic was deliberately left at `requireMention = true`, mention the bot instead
|
|
131
|
+
(`<bot-handle> reply with exactly TELEGRAM-ROUTE-OK`) and additionally confirm that an un-mentioned
|
|
132
|
+
message is **ignored**. For folder-scoped topics, also send a request that implies but doesn't name a
|
|
133
|
+
repo and confirm the dispatcher asks for confirmation before proceeding. Do **not** treat `openclaw agent --agent
|
|
126
134
|
<id> ...` as proof a topic route works — use the visible topic reply.
|
|
127
135
|
|
|
128
136
|
## Output standard
|
|
@@ -77,12 +77,18 @@ repos:
|
|
|
77
77
|
"groups": {
|
|
78
78
|
"<group-id>": {
|
|
79
79
|
"groupPolicy": "allowlist",
|
|
80
|
+
// Group-level gate stays on: messages in the group that are NOT inside a
|
|
81
|
+
// routed topic still require an explicit mention.
|
|
80
82
|
"requireMention": true,
|
|
81
83
|
"allowFrom": ["<telegram-user-id>"],
|
|
82
84
|
"topics": {
|
|
83
85
|
"<topic-id>": {
|
|
84
86
|
"agentId": "<topic-slug>-dispatch",
|
|
85
|
-
|
|
87
|
+
// Default false: the topic is bound 1:1 to this agent, so every message
|
|
88
|
+
// in it is already addressed to the agent — an @mention carries no routing
|
|
89
|
+
// information. Flip to true only for shared-workspace topics where humans
|
|
90
|
+
// also coordinate with each other (see "Mention gating" below).
|
|
91
|
+
"requireMention": false,
|
|
86
92
|
"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."
|
|
87
93
|
}
|
|
88
94
|
}
|
|
@@ -93,6 +99,28 @@ repos:
|
|
|
93
99
|
}
|
|
94
100
|
```
|
|
95
101
|
|
|
102
|
+
## Mention gating
|
|
103
|
+
|
|
104
|
+
`requireMention` controls whether a message must @-mention the bot before the agent activates. It is
|
|
105
|
+
set independently at the group level and the topic level; the topic-level value wins for messages
|
|
106
|
+
inside a routed topic.
|
|
107
|
+
|
|
108
|
+
- **Topic level — default `false`.** A repo-coding topic is bound 1:1 to its dispatcher
|
|
109
|
+
(`agentId`), so the topic itself already determines the agent. Every message in the topic is
|
|
110
|
+
addressed to that agent and the @mention adds nothing but friction. This is the "inbox topic"
|
|
111
|
+
shape: the topic *is* the conversation with the agent.
|
|
112
|
+
- **Set the topic level to `true`** only for a **shared-workspace topic** — one where humans also
|
|
113
|
+
talk *to each other* (status updates, coordination) and you do not want every stray line to spawn
|
|
114
|
+
an agent run. The mention then acts as an explicit "this one is for the bot" intent signal.
|
|
115
|
+
- **Group level — keep `true`.** It gates messages posted in the group but outside any routed
|
|
116
|
+
topic, where there is no 1:1 agent binding to lean on.
|
|
117
|
+
|
|
118
|
+
Tradeoff to weigh before leaving a topic at `false`: with no mention required, **every** top-level
|
|
119
|
+
message and **every** native reply in the topic wakes the dispatcher (and can spawn a worker run). In
|
|
120
|
+
an inbox topic that is exactly what you want; in a topic people also chat in, it is noise and cost.
|
|
121
|
+
When in doubt, keep code-work topics as dedicated inbox topics (`false`) and push human coordination
|
|
122
|
+
to a separate topic or the group body.
|
|
123
|
+
|
|
96
124
|
## Worker launcher form
|
|
97
125
|
|
|
98
126
|
```sh
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "lisa-openclaw",
|
|
3
|
-
"version": "2.
|
|
3
|
+
"version": "2.136.0",
|
|
4
4
|
"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",
|
|
5
5
|
"author": {
|
|
6
6
|
"name": "Cody Swann"
|
|
@@ -103,8 +103,13 @@ The worker prepares the safe target and launches the CLI; it does not edit files
|
|
|
103
103
|
|
|
104
104
|
Route the topic to the dispatcher: set
|
|
105
105
|
`channels.telegram.groups.<group-id>.topics.<topic-id>.agentId = <topic-slug>-dispatch`, keep
|
|
106
|
-
|
|
107
|
-
|
|
106
|
+
allowlist policy, and add `allowFrom` only when membership must be narrower than the group. Leave the
|
|
107
|
+
topic-level `requireMention = false` (the default) so the agent activates on any message — the topic
|
|
108
|
+
is bound 1:1 to this dispatcher, so an @mention carries no routing information and is pure friction.
|
|
109
|
+
Set it to `true` only for a shared-workspace topic where humans also coordinate with each other and
|
|
110
|
+
you don't want every line to spawn a run; the group-level `requireMention` stays `true` regardless.
|
|
111
|
+
See "Mention gating" in [references/repo-topic-config.md](references/repo-topic-config.md) for the
|
|
112
|
+
tradeoff. The topic `systemPrompt` must state the scope mode, treat each native-reply
|
|
108
113
|
root as an independent request context, confirm repo selection only in folder-scoped mode, spawn the
|
|
109
114
|
worker with an explicit repo path, and return the worker result to the topic. Back up
|
|
110
115
|
`~/.openclaw/openclaw.json` before editing and preserve unrelated routes.
|
|
@@ -118,11 +123,14 @@ openclaw gateway status
|
|
|
118
123
|
openclaw channels status --probe
|
|
119
124
|
```
|
|
120
125
|
|
|
121
|
-
Then from the target topic
|
|
122
|
-
|
|
123
|
-
|
|
124
|
-
|
|
125
|
-
the
|
|
126
|
+
Then from the target topic, send a plain message with **no** @mention (the default
|
|
127
|
+
`requireMention = false` means the agent must activate without one) asking for an exact-token reply
|
|
128
|
+
with **no** file changes, commits, PRs, or merges, e.g. `reply with exactly TELEGRAM-ROUTE-OK`.
|
|
129
|
+
Confirm the visible reply, that the dispatcher spawned the worker, and that the worker ran in the
|
|
130
|
+
intended repo. If the topic was deliberately left at `requireMention = true`, mention the bot instead
|
|
131
|
+
(`<bot-handle> reply with exactly TELEGRAM-ROUTE-OK`) and additionally confirm that an un-mentioned
|
|
132
|
+
message is **ignored**. For folder-scoped topics, also send a request that implies but doesn't name a
|
|
133
|
+
repo and confirm the dispatcher asks for confirmation before proceeding. Do **not** treat `openclaw agent --agent
|
|
126
134
|
<id> ...` as proof a topic route works — use the visible topic reply.
|
|
127
135
|
|
|
128
136
|
## Output standard
|
|
@@ -77,12 +77,18 @@ repos:
|
|
|
77
77
|
"groups": {
|
|
78
78
|
"<group-id>": {
|
|
79
79
|
"groupPolicy": "allowlist",
|
|
80
|
+
// Group-level gate stays on: messages in the group that are NOT inside a
|
|
81
|
+
// routed topic still require an explicit mention.
|
|
80
82
|
"requireMention": true,
|
|
81
83
|
"allowFrom": ["<telegram-user-id>"],
|
|
82
84
|
"topics": {
|
|
83
85
|
"<topic-id>": {
|
|
84
86
|
"agentId": "<topic-slug>-dispatch",
|
|
85
|
-
|
|
87
|
+
// Default false: the topic is bound 1:1 to this agent, so every message
|
|
88
|
+
// in it is already addressed to the agent — an @mention carries no routing
|
|
89
|
+
// information. Flip to true only for shared-workspace topics where humans
|
|
90
|
+
// also coordinate with each other (see "Mention gating" below).
|
|
91
|
+
"requireMention": false,
|
|
86
92
|
"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."
|
|
87
93
|
}
|
|
88
94
|
}
|
|
@@ -93,6 +99,28 @@ repos:
|
|
|
93
99
|
}
|
|
94
100
|
```
|
|
95
101
|
|
|
102
|
+
## Mention gating
|
|
103
|
+
|
|
104
|
+
`requireMention` controls whether a message must @-mention the bot before the agent activates. It is
|
|
105
|
+
set independently at the group level and the topic level; the topic-level value wins for messages
|
|
106
|
+
inside a routed topic.
|
|
107
|
+
|
|
108
|
+
- **Topic level — default `false`.** A repo-coding topic is bound 1:1 to its dispatcher
|
|
109
|
+
(`agentId`), so the topic itself already determines the agent. Every message in the topic is
|
|
110
|
+
addressed to that agent and the @mention adds nothing but friction. This is the "inbox topic"
|
|
111
|
+
shape: the topic *is* the conversation with the agent.
|
|
112
|
+
- **Set the topic level to `true`** only for a **shared-workspace topic** — one where humans also
|
|
113
|
+
talk *to each other* (status updates, coordination) and you do not want every stray line to spawn
|
|
114
|
+
an agent run. The mention then acts as an explicit "this one is for the bot" intent signal.
|
|
115
|
+
- **Group level — keep `true`.** It gates messages posted in the group but outside any routed
|
|
116
|
+
topic, where there is no 1:1 agent binding to lean on.
|
|
117
|
+
|
|
118
|
+
Tradeoff to weigh before leaving a topic at `false`: with no mention required, **every** top-level
|
|
119
|
+
message and **every** native reply in the topic wakes the dispatcher (and can spawn a worker run). In
|
|
120
|
+
an inbox topic that is exactly what you want; in a topic people also chat in, it is noise and cost.
|
|
121
|
+
When in doubt, keep code-work topics as dedicated inbox topics (`false`) and push human coordination
|
|
122
|
+
to a separate topic or the group body.
|
|
123
|
+
|
|
96
124
|
## Worker launcher form
|
|
97
125
|
|
|
98
126
|
```sh
|
|
@@ -103,8 +103,13 @@ The worker prepares the safe target and launches the CLI; it does not edit files
|
|
|
103
103
|
|
|
104
104
|
Route the topic to the dispatcher: set
|
|
105
105
|
`channels.telegram.groups.<group-id>.topics.<topic-id>.agentId = <topic-slug>-dispatch`, keep
|
|
106
|
-
|
|
107
|
-
|
|
106
|
+
allowlist policy, and add `allowFrom` only when membership must be narrower than the group. Leave the
|
|
107
|
+
topic-level `requireMention = false` (the default) so the agent activates on any message — the topic
|
|
108
|
+
is bound 1:1 to this dispatcher, so an @mention carries no routing information and is pure friction.
|
|
109
|
+
Set it to `true` only for a shared-workspace topic where humans also coordinate with each other and
|
|
110
|
+
you don't want every line to spawn a run; the group-level `requireMention` stays `true` regardless.
|
|
111
|
+
See "Mention gating" in [references/repo-topic-config.md](references/repo-topic-config.md) for the
|
|
112
|
+
tradeoff. The topic `systemPrompt` must state the scope mode, treat each native-reply
|
|
108
113
|
root as an independent request context, confirm repo selection only in folder-scoped mode, spawn the
|
|
109
114
|
worker with an explicit repo path, and return the worker result to the topic. Back up
|
|
110
115
|
`~/.openclaw/openclaw.json` before editing and preserve unrelated routes.
|
|
@@ -118,11 +123,14 @@ openclaw gateway status
|
|
|
118
123
|
openclaw channels status --probe
|
|
119
124
|
```
|
|
120
125
|
|
|
121
|
-
Then from the target topic
|
|
122
|
-
|
|
123
|
-
|
|
124
|
-
|
|
125
|
-
the
|
|
126
|
+
Then from the target topic, send a plain message with **no** @mention (the default
|
|
127
|
+
`requireMention = false` means the agent must activate without one) asking for an exact-token reply
|
|
128
|
+
with **no** file changes, commits, PRs, or merges, e.g. `reply with exactly TELEGRAM-ROUTE-OK`.
|
|
129
|
+
Confirm the visible reply, that the dispatcher spawned the worker, and that the worker ran in the
|
|
130
|
+
intended repo. If the topic was deliberately left at `requireMention = true`, mention the bot instead
|
|
131
|
+
(`<bot-handle> reply with exactly TELEGRAM-ROUTE-OK`) and additionally confirm that an un-mentioned
|
|
132
|
+
message is **ignored**. For folder-scoped topics, also send a request that implies but doesn't name a
|
|
133
|
+
repo and confirm the dispatcher asks for confirmation before proceeding. Do **not** treat `openclaw agent --agent
|
|
126
134
|
<id> ...` as proof a topic route works — use the visible topic reply.
|
|
127
135
|
|
|
128
136
|
## Output standard
|
package/plugins/src/openclaw/skills/lisa-openclaw-connect-repo-topic/references/repo-topic-config.md
CHANGED
|
@@ -77,12 +77,18 @@ repos:
|
|
|
77
77
|
"groups": {
|
|
78
78
|
"<group-id>": {
|
|
79
79
|
"groupPolicy": "allowlist",
|
|
80
|
+
// Group-level gate stays on: messages in the group that are NOT inside a
|
|
81
|
+
// routed topic still require an explicit mention.
|
|
80
82
|
"requireMention": true,
|
|
81
83
|
"allowFrom": ["<telegram-user-id>"],
|
|
82
84
|
"topics": {
|
|
83
85
|
"<topic-id>": {
|
|
84
86
|
"agentId": "<topic-slug>-dispatch",
|
|
85
|
-
|
|
87
|
+
// Default false: the topic is bound 1:1 to this agent, so every message
|
|
88
|
+
// in it is already addressed to the agent — an @mention carries no routing
|
|
89
|
+
// information. Flip to true only for shared-workspace topics where humans
|
|
90
|
+
// also coordinate with each other (see "Mention gating" below).
|
|
91
|
+
"requireMention": false,
|
|
86
92
|
"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."
|
|
87
93
|
}
|
|
88
94
|
}
|
|
@@ -93,6 +99,28 @@ repos:
|
|
|
93
99
|
}
|
|
94
100
|
```
|
|
95
101
|
|
|
102
|
+
## Mention gating
|
|
103
|
+
|
|
104
|
+
`requireMention` controls whether a message must @-mention the bot before the agent activates. It is
|
|
105
|
+
set independently at the group level and the topic level; the topic-level value wins for messages
|
|
106
|
+
inside a routed topic.
|
|
107
|
+
|
|
108
|
+
- **Topic level — default `false`.** A repo-coding topic is bound 1:1 to its dispatcher
|
|
109
|
+
(`agentId`), so the topic itself already determines the agent. Every message in the topic is
|
|
110
|
+
addressed to that agent and the @mention adds nothing but friction. This is the "inbox topic"
|
|
111
|
+
shape: the topic *is* the conversation with the agent.
|
|
112
|
+
- **Set the topic level to `true`** only for a **shared-workspace topic** — one where humans also
|
|
113
|
+
talk *to each other* (status updates, coordination) and you do not want every stray line to spawn
|
|
114
|
+
an agent run. The mention then acts as an explicit "this one is for the bot" intent signal.
|
|
115
|
+
- **Group level — keep `true`.** It gates messages posted in the group but outside any routed
|
|
116
|
+
topic, where there is no 1:1 agent binding to lean on.
|
|
117
|
+
|
|
118
|
+
Tradeoff to weigh before leaving a topic at `false`: with no mention required, **every** top-level
|
|
119
|
+
message and **every** native reply in the topic wakes the dispatcher (and can spawn a worker run). In
|
|
120
|
+
an inbox topic that is exactly what you want; in a topic people also chat in, it is noise and cost.
|
|
121
|
+
When in doubt, keep code-work topics as dedicated inbox topics (`false`) and push human coordination
|
|
122
|
+
to a separate topic or the group body.
|
|
123
|
+
|
|
96
124
|
## Worker launcher form
|
|
97
125
|
|
|
98
126
|
```sh
|