@codyswann/lisa 2.134.10 → 2.136.0

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

@@ -103,8 +103,13 @@ The worker prepares the safe target and launches the CLI; it does not edit files
 
 Route the topic to the dispatcher: set
 `channels.telegram.groups.<group-id>.topics.<topic-id>.agentId = <topic-slug>-dispatch`, keep
-`requireMention = true` and allowlist policy, and add `allowFrom` only when membership must be
-narrower than the group. The topic `systemPrompt` must state the scope mode, treat each native-reply
+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. Back up
 `~/.openclaw/openclaw.json` before editing and preserve unrelated routes.
@@ -118,11 +123,14 @@ openclaw gateway status
 openclaw channels status --probe
 ```
 
-Then from the target topic: mention the bot and ask for an exact-token reply with **no** file
-changes, commits, PRs, or merges, e.g. `<bot-handle> 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. 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
+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 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

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

@@ -77,12 +77,18 @@ repos:
       "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",
-              "requireMention": true,
+              // 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."
             }
           }
@@ -93,6 +99,28 @@ repos:
 }
 ```
 
+## 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

package/plugins/src/rails/skills/exploratory-qa/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: exploratory-qa
-description: First-time-user exploratory QA walkthrough for web apps that FEEDS THE LIFECYCLE. Use when asked to experience an app the way a brand-new human user would — landing cold on the home page and clicking through to find anything confusing, broken, or hard to understand (human-facing jargon, contextless extracted data, machine-style labels, slow or unclear loads, late meaningful content, cramped or cut-off UI, inconsistent/non-standard UX, awkward scroll behavior, unclear affordances) across all breakpoints. Instead of writing a report file, it files every finding as a tracked work item via lisa:tracker-write (bugs and usability/UX issues). A `ready` parameter controls whether those tickets are created build-ready (auto-picked-up by lisa:intake) or left in the backlog for human triage (default). For gaps in the automated Playwright test suite, use the e2e-coverage-gaps skill instead.
+description: First-time-user exploratory QA walkthrough for web apps that FEEDS THE LIFECYCLE. Use when asked to experience an app the way a brand-new human user would — landing cold on the home page and clicking through to find anything confusing, broken, or hard to understand (human-facing jargon, contextless extracted data, machine-style labels, slow or unclear loads, late meaningful content, cramped or cut-off UI, inconsistent/non-standard UX, awkward scroll behavior, unclear affordances, dead-end flows that strand a user — e.g. a login page with no way to register or recover a password) across all breakpoints. Instead of writing a report file, it files every finding as a tracked work item via lisa:tracker-write (bugs and usability/UX issues). A `ready` parameter controls whether those tickets are created build-ready (auto-picked-up by lisa:intake) or left in the backlog for human triage (default). For gaps in the automated Playwright test suite, use the e2e-coverage-gaps skill instead.
 ---
 
 # Exploratory QA
@@ -63,8 +63,28 @@ mistakes, and tries the obvious thing. Cover at least these dimensions unless th
   from the default UI or add context such as excerpts, labels, grouping, or provenance.
 - **Navigation clarity:** is it obvious how to get somewhere and back? Dead ends, hidden entry points,
   surprising redirects, broken links, no clear "home".
+- **Flow completeness & expected counterparts:** a screen that gates access or shows one side of a
+  standard paired flow must offer the other side — or a clear path to it. A brand-new user must never
+  hit a dead end with no next step. Flag missing companion actions, especially on auth and entry
+  screens:
+  - **Sign-in with no sign-up:** a login page with no "Create account" / "Register" link strands
+    anyone who does not already have an account; likewise a registration page with no link back to
+    sign in.
+  - **No account recovery:** login with no "Forgot password?", no way to reset, and no way to resend a
+    verification email.
+  - **No exit from a state:** a signed-in app with no visible sign-out, or a modal / wizard / detail
+    view with no back, close, or cancel.
+  - **One-way actions:** create/add with no matching edit or delete (or the reverse) where a user
+    would reasonably expect both.
+  - **Unreachable entry points:** a feature only reachable by guessing a URL, or an empty state with
+    no primary action to populate it.
+  When the missing counterpart makes a core task impossible for a whole class of users (e.g. a new
+  user literally cannot create an account), file a `Bug`; otherwise file a usability `Improvement`.
 - **Visual/layout quality:** cut-off or truncated text, overlap, cramped/crowded density, offscreen or
-  unreachable controls, accidental horizontal scroll, awkward empty space.
+  unreachable controls, accidental horizontal scroll, awkward empty space. **Do not judge this by
+  eyeballing a screenshot alone** — a control clipped by a few pixels or pushed just past a container
+  edge looks fine in a thumbnail. Confirm it with the programmatic layout-integrity sweep in §5 at
+  every width.
 - **Consistency / standard UX:** components, spacing, button styles, terminology, and interaction
   patterns should be consistent across the app and follow common conventions. Flag anything
   non-standard or that differs screen-to-screen.
@@ -84,11 +104,39 @@ mistakes, and tries the obvious thing. Cover at least these dimensions unless th
 
 - Discover breakpoints from the app (design tokens, CSS, responsive layout changes) when possible; if
   unknown, use a practical baseline: phone, tablet/narrow, desktop, plus any app-specific cutoff.
-- At each breakpoint, walk the key paths again and confirm the experience holds: expected
+- **Do not test only the named breakpoints.** Clipping and overflow most often appear at the
+  *in-between* widths — where a row can no longer fit its contents but has not yet collapsed to the
+  next layout. Sweep a range of widths (e.g. 360, 390, 414, 600, 768, 834, 1024, 1280, 1440) plus a
+  few intermediate steps (e.g. ~900–1180) and re-check the key paths at each.
+- At each width, walk the key paths again and confirm the experience holds: expected
   shell/navigation variant, critical controls visible and reachable, no unintended horizontal
   overflow, intentional scroll containers still usable, nothing cut off or crowded.
 
-### 5. Watch Load & Latency
+### 5. Run Layout-Integrity Checks — Don't Eyeball Alone
+
+A screenshot glance misses controls clipped by a few pixels or pushed just past a container edge. At
+**every width**, in addition to looking, take DOM measurements via the browser automation tool
+(Playwright, Chrome MCP, etc.) and treat any of these as a finding:
+
+- **Document / container overflow:** `document.documentElement.scrollWidth > clientWidth`, or a
+  horizontal scrollbar on a container that should not scroll → accidental horizontal overflow.
+- **Clipped or offscreen controls:** for every interactive control (buttons, links, inputs, selects,
+  menu items), compare its `getBoundingClientRect()` against the viewport and against each ancestor
+  that has `overflow: hidden | clip | auto | scroll`. If any edge of the control falls outside those
+  bounds, it is partially or fully clipped / unreachable — even when the page looks fine in a thumbnail.
+  This is exactly the case that gets missed: a submit/apply button whose right edge is cut off by its
+  filter card.
+- **Truncated meaningful text:** an element whose `scrollWidth > clientWidth` (or that renders an
+  ellipsis) where the hidden text carries meaning — e.g. a select showing "Any CRD state" jammed into
+  its chevron, a label cut mid-word.
+- **Colliding controls:** a label or value overlapping an adjacent control (icon, chevron, button)
+  with no gap between them.
+
+Record which width(s) trigger each, the offending element, and a screenshot. **A primary or
+interactive control that is clipped, offscreen, or unreachable is a `Bug`, not merely an
+Improvement** — a user literally cannot see or click all of it.
+
+### 6. Watch Load & Latency
 
 - Measure separate milestones: visible app shell, `document.readyState`, first meaningful
   route-specific content, and visually stable/full route content.
@@ -122,6 +170,10 @@ validation gate; never call a vendor `*-write-*` skill directly). Map each findi
 | User-visible **bug** (broken behavior) | `Bug` | the `ready` flag (default `false`) |
 | **Usability / UX / clarity issue** | `Improvement` | the `ready` flag (default `false`) |
 
+A control that is **clipped, offscreen, or otherwise unreachable** (per §5) counts as broken behavior
+→ file it as a `Bug`, not an `Improvement`. Pure crowding/clarity with the control still fully usable
+is an `Improvement`.
+
 Each finding is a flat leaf (no children), so `build_ready` applies directly — pass it explicitly on
 every create. Each ticket MUST be a complete spec (the validator rejects thin tickets):