@codyswann/lisa 2.30.0 → 2.32.0

package/.agents/plugins/marketplace.json

@@ -87,6 +87,30 @@
         "authentication": "ON_INSTALL"
       },
       "category": "Coding"
+    },
+    {
+      "name": "lisa-wiki",
+      "source": {
+        "source": "local",
+        "path": "./plugins/lisa-wiki"
+      },
+      "policy": {
+        "installation": "AVAILABLE",
+        "authentication": "ON_INSTALL"
+      },
+      "category": "Productivity"
+    },
+    {
+      "name": "lisa-openclaw",
+      "source": {
+        "source": "local",
+        "path": "./plugins/lisa-openclaw"
+      },
+      "policy": {
+        "installation": "AVAILABLE",
+        "authentication": "ON_INSTALL"
+      },
+      "category": "Productivity"
     }
   ]
 }

package/.claude-plugin/marketplace.json

@@ -55,6 +55,12 @@
       "source": "./plugins/lisa-wiki",
       "description": "LLM Wiki — git-native markdown knowledge base: ingest, query, lint, onboard (Claude + Codex)",
       "category": "productivity"
+    },
+    {
+      "name": "lisa-openclaw",
+      "source": "./plugins/lisa-openclaw",
+      "description": "Connect staff to Telegram or Slack via OpenClaw — facilitator/specialist routing and repo-coding topics (Claude + Codex)",
+      "category": "productivity"
     }
   ]
 }

package/package.json

@@ -82,7 +82,7 @@
     "lodash": ">=4.18.1"
   },
   "name": "@codyswann/lisa",
-  "version": "2.30.0",
+  "version": "2.32.0",
   "description": "Claude Code governance framework that applies guardrails, guidance, and automated enforcement to projects",
   "main": "dist/index.js",
   "exports": {

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa",
-  "version": "2.30.0",
+  "version": "2.32.0",
   "description": "Universal governance — agents, skills, commands, hooks, and rules for all projects",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa",
-  "version": "2.30.0",
+  "version": "2.32.0",
   "description": "Universal governance: agents, skills, commands, hooks, and rules for all projects.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa/skills/github-sync/SKILL.md

@@ -62,11 +62,57 @@ Based on the milestone, suggest (but do NOT automatically perform) a label trans
 
 The actual `status:in-progress` flip is owned by `lisa:github-build-intake` (claim) and `lisa:github-agent`. The `status:code-review` flip is owned by `lisa:github-evidence`. The `status:done` flip is typically owned by merge automation or PM. This skill never relabels.
 
+### Step 5: Parent Status Rollup (`--rollup`)
+
+When invoked with `--rollup`, this skill **derives a parent/container issue's `status:*` label from the roll-up of its child sub-issues** instead of posting a milestone update on a leaf. This implements the GitHub sub-issue-completion arm of the **Parent status rollup (the state machine)** section of the `leaf-only-lifecycle` rule — cite that rule, do not restate the policy. It is the sync-side complement to the write-time labeling (`lisa:github-write-issue`), the validate-time S15 gate (`lisa:github-validate-issue`), and the claim-time gate (`lisa:github-build-intake`); all four cite the same rule so the classification never drifts.
+
+**Resolve the child set the same way `lisa:github-read-issue` does** — native sub-issues via GraphQL, each with its `status:*` label and open/closed state:
+
+```bash
+gh api graphql -f query='
+  query($owner:String!,$repo:String!,$number:Int!){
+    repository(owner:$owner,name:$repo){
+      issue(number:$number){
+        number title state
+        subIssues(first:100){ nodes { number state labels(first:20){ nodes { name } } } }
+      }
+    }
+  }' -F owner=<org> -F repo=<repo> -F number=<parent-number>
+```
+
+If the `subIssues` field is unavailable (older GHES), fall back to body parentage exactly as `lisa:github-read-issue` does. If the issue has **no** children it is a leaf, not a parent — rollup is N/A; behave as a normal milestone sync.
+
+**Evaluate the required children in priority order and take the first match** (canonical roles from `config-resolution`; the GitHub label map is `status:blocked`, `status:in-progress`, `status:code-review`, `status:done`):
+
+| If among the required child leaves… | Derived parent role | GitHub label |
+|---|---|---|
+| any child carries `status:blocked` (or is otherwise blocked) | `blocked` | `status:blocked` |
+| else any child carries `status:in-progress` **or** `status:code-review` | `claimed` | `status:in-progress` |
+| else **all** required children are terminal (closed / `status:done`) | `done` | the configured terminal `done` label |
+| else (children exist, none started) | — | unchanged — parent keeps its non-ready container label |
+
+- **Blocked dominates** — a single blocked child surfaces `status:blocked` on the parent even while siblings progress, so a human sees the parent needs attention.
+- **"Required" children only** — a child labelled won't-do / optional does not hold the parent open; only leaves that must ship count toward the all-terminal check.
+- **Recursive** — a parent reaches `done` only when its children are all terminal; an Epic reaches `done` only when its Stories have themselves rolled up to `done`. Evaluate bottom-up.
+- **Never set the parent to `status:ready`** — `ready` is leaf-only (the human "claim this" signal). Rollup only moves the parent between non-ready container labels.
+
+**Single-environment collapse (this repo).** `.lisa.config.json` `deploy.branches` declares only `production: main`, so the terminal `done` resolves to the single label `status:done` — there is no `status:on-dev` / `status:on-stg` and **no dev → staging → prod promotion chain**. Resolve the terminal via the env-keyed `done` logic in `config-resolution`, but in the single-environment case it collapses to the one `status:done` value; the rollup never attempts to resolve a dev or staging `done`. Projects that DO have multiple environments keep the env-keyed map and roll the parent up to whichever `done` matches the environment its leaves shipped to.
+
+**Apply the derived label** (only when it differs from the parent's current `status:*`): remove the parent's existing `status:*` label and add the derived one, keeping exactly one `status:*` label so the build-queue invariant holds. Post an idempotent `[claude-sync] rollup` comment naming the derived state and the child tally (e.g. `3/4 leaves terminal, 1 blocked → status:blocked`); skip the comment if an identical one is already the most recent rollup comment.
+
+```bash
+gh issue edit <parent-number> --repo <org>/<repo> \
+  --remove-label "<current status:*>" --add-label "<derived status:*>"
+```
+
+**Safe default.** If rollup cannot be applied automatically (e.g. ambiguous required-set, GraphQL hierarchy unavailable, or a derived terminal that the env logic cannot resolve), this skill does **not** guess — it posts the derived suggestion as a comment and leaves the parent's label untouched. No unsafe transition is ever made.
+
 ## Important Notes
 
-- **Never auto-transition labels** — always suggest and let the user / pipeline confirm.
-- **Idempotent updates** — the `[claude-sync] <milestone>` prefix on the most-recent comment is the dedupe key.
+- **Never auto-transition labels** — always suggest and let the user / pipeline confirm. The one exception is the explicit `--rollup` parent derivation (Step 5), which moves a *parent's* `status:*` label as the `leaf-only-lifecycle` rule mandates — never a leaf's, and never to `status:ready`.
+- **Idempotent updates** — the `[claude-sync] <milestone>` prefix on the most-recent comment is the dedupe key; the rollup path uses `[claude-sync] rollup`.
 - **Comment format** — use GitHub-flavored markdown (`##` headings, fenced code blocks). The same template is used for the JIRA path (rendered as wiki markup there); keep the markdown source canonical.
+- **Rollup cites the rule by slug** — parent state derivation follows the `leaf-only-lifecycle` rule's state machine; this skill does not restate the policy.
 
 ## Execution
 

package/plugins/lisa/skills/jira-sync/SKILL.md

@@ -58,11 +58,37 @@ Based on the milestone, suggest (but don't automatically perform) a status trans
 | PR ready | "In Review" |
 | PR merged | "Done" |
 
+### Step 5: Parent Status Rollup (`--rollup`)
+
+When invoked with `--rollup`, this skill **derives a parent/container ticket's status from the roll-up of its children** (Stories under an Epic; Sub-tasks under a Story/Task) instead of posting a milestone update on a leaf. This implements the JIRA child/subtask-status arm of the **Parent status rollup (the state machine)** section of the `leaf-only-lifecycle` rule — cite that rule, do not restate the policy.
+
+**Resolve the child set the same way `lisa:jira-read-ticket` does** — the native Epic → Story → Sub-task hierarchy (Epic link / parent field for Stories, the subtask relationship for Sub-tasks), each with its current status. Fetch via `lisa:atlassian-access` (`operation: read-ticket` / `search-issues` with the parent's `"Epic Link" = <KEY>` or `parent = <KEY>` JQL). If the ticket has **no** children it is a leaf — rollup is N/A; behave as a normal milestone sync.
+
+**Evaluate the required children in priority order and take the first match** (canonical roles from `config-resolution`; the JIRA status map defaults to `Blocked`, `In Progress`, `Code Review`, env-keyed `done`):
+
+| If among the required child leaves… | Derived parent role | JIRA status |
+|---|---|---|
+| any child is **blocked** | `blocked` | `Blocked` |
+| else any child is **in progress** (`In Progress` or `Code Review`) | `claimed` | `In Progress` |
+| else **all** required children are terminal (`Done`) | `done` | the configured terminal `done` status |
+| else (children exist, none started) | — | unchanged — parent keeps its non-ready container status |
+
+- **Blocked dominates** — a single blocked child surfaces `Blocked` on the parent even while siblings progress.
+- **"Required" children only** — won't-do / optional children do not hold the parent open.
+- **Recursive** — an Epic reaches `Done` only when its Stories have themselves rolled up to `Done`; a Story reaches `Done` only when its Sub-tasks are all terminal. Evaluate bottom-up.
+- **Never set the parent to the build-ready status** — `ready` is leaf-only. Rollup only moves the parent between non-ready container statuses.
+- **`review` is optional for JIRA** (`config-resolution`) — a project that omits `Code Review` keeps the parent in `In Progress` until terminal; skip the intermediate rollup hop rather than forcing a non-existent status (a `leaf-only-lifecycle` "vendor support varies" note).
+
+**Single-environment collapse (this repo).** The terminal `done` resolves via the env-keyed `done` logic in `config-resolution`. In this repo `deploy.branches` declares only `production: main`, so `done` collapses to a single status and the lifecycle is `Ready → In Progress → Code Review → Done` with **no** dev/staging promotion hops; the rollup never resolves a dev or staging `done`. Multi-environment projects keep the env-keyed map.
+
+**Apply the derived status** (only when it differs from the parent's current status) via `lisa:atlassian-access` `operation: transition`, and post an idempotent rollup comment naming the derived state and the child tally. **Safe default:** if the derived terminal cannot be resolved (ambiguous required-set or unresolvable env `done`), do not guess — post the derived suggestion as a comment and leave the parent's status untouched.
+
 ## Important Notes
 
-- **Never auto-transition ticket status** — always suggest and let the user confirm
+- **Never auto-transition ticket status** — always suggest and let the user confirm. The one exception is the explicit `--rollup` parent derivation (Step 5), which transitions a *parent's* status per the `leaf-only-lifecycle` rule — never a leaf's, and never to the build-ready status.
 - **Idempotent updates** — running sync multiple times at the same milestone should not create duplicate comments
 - **Comment format** — use JIRA markdown with clear headers and bullet points
+- **Rollup cites the rule by slug** — parent state derivation follows the `leaf-only-lifecycle` rule's state machine; this skill does not restate the policy.
 
 ## Execution
 

package/plugins/lisa/skills/linear-sync/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: linear-sync
 description: "Syncs plan progress to a linked Linear Issue. Posts plan contents, progress updates, branch links, and PR links at key milestones. Use this skill throughout the plan lifecycle to keep Linear Issues in sync. The Linear counterpart of lisa:jira-sync and lisa:github-sync."
-allowed-tools: ["Bash", "Skill", "mcp__linear-server__list_teams", "mcp__linear-server__get_issue", "mcp__linear-server__save_comment", "mcp__linear-server__list_issue_labels", "mcp__linear-server__create_issue_label", "mcp__linear-server__save_issue"]
+allowed-tools: ["Bash", "Skill", "mcp__linear-server__list_teams", "mcp__linear-server__get_issue", "mcp__linear-server__list_issues", "mcp__linear-server__save_comment", "mcp__linear-server__list_issue_labels", "mcp__linear-server__create_issue_label", "mcp__linear-server__save_issue"]
 ---
 
 # Sync Plan to Linear: $ARGUMENTS
@@ -81,9 +81,34 @@ Verify exactly one `status:*` label remains after the update — having two simu
 
 Without `--update-label`, this skill posts the comment only and does NOT touch labels.
 
+## Phase 5 — Parent Status Rollup (`--rollup`)
+
+When the caller passes `--rollup`, this skill **derives a parent/container's `status:*` label from the roll-up of its children** instead of acting on a leaf. A **Project** (the Epic equivalent) rolls up from its Issues; an **Issue** rolls up from its sub-Issues. This implements the Linear child-issue-status arm of the **Parent status rollup (the state machine)** section of the `leaf-only-lifecycle` rule — cite that rule, do not restate the policy.
+
+**Resolve the child set the same way `lisa:linear-read-issue` does** — `mcp__linear-server__list_issues({project: <id>})` for a Project's Issues, or `mcp__linear-server__get_issue` per child for an Issue's sub-Issues (via `parentId`). Capture each child's `status:*` label. If the item has **no** children it is a leaf — rollup is N/A; behave as a normal milestone sync.
+
+**Evaluate the required children in priority order and take the first match** (canonical roles from `config-resolution`; Linear label map is `status:blocked`, `status:in-progress`, `status:code-review`, `status:done`):
+
+| If among the required child leaves… | Derived parent role | Linear label |
+|---|---|---|
+| any child carries `status:blocked` | `blocked` | `status:blocked` |
+| else any child carries `status:in-progress` **or** `status:code-review` | `claimed` | `status:in-progress` |
+| else **all** required children carry `status:done` | `done` | the configured terminal `done` label |
+| else (children exist, none started) | — | unchanged — parent keeps its non-ready container label |
+
+- **Blocked dominates** — one blocked child surfaces `status:blocked` on the parent even while siblings progress.
+- **"Required" children only** — won't-do / optional (e.g. `Canceled`) children do not hold the parent open.
+- **Recursive** — a Project reaches `status:done` only when its Issues have themselves rolled up to `status:done`. Evaluate bottom-up.
+- **Never set the parent to `status:ready`** — `ready` is leaf-only. Rollup only moves the parent between non-ready container labels.
+
+**Single-environment collapse (this repo).** The terminal `done` resolves via the env-keyed `done` logic in `config-resolution`. In this repo `deploy.branches` declares only `production: main`, so `done` collapses to the single `status:done` label and the lifecycle is `status:ready → status:in-progress → status:code-review → status:done` with **no** dev/staging promotion hops; the rollup never resolves a dev or staging `done`. Multi-environment projects keep the env-keyed map.
+
+**Apply the derived label** via `mcp__linear-server__save_issue` (Project or Issue), removing the parent's existing `status:*` and adding the derived one so exactly one `status:*` label remains. Post an idempotent rollup comment naming the derived state and the child tally. The native Linear `state` is **not** auto-transitioned — only the `status:*` label, mirroring the `--update-label` rule. **Safe default:** if the derived terminal cannot be resolved (ambiguous required-set or unresolvable env `done`), do not guess — post the derived suggestion as a comment and leave the parent's label untouched.
+
 ## Rules
 
-- Never auto-transition the native Linear `state` — only the label, and only when the caller explicitly asks.
+- Never auto-transition the native Linear `state` — only the label, and only when the caller explicitly asks (`--update-label`, or `--rollup` for parent derivation per the `leaf-only-lifecycle` rule).
+- Rollup derives a *parent's* `status:*` label from its children and never sets a parent to `status:ready`. It cites the `leaf-only-lifecycle` rule by slug rather than restating the state machine.
 - Never post empty or minimal comments — if a milestone has no meaningful content, skip the post.
 - Do not delete prior milestone comments. They are the audit trail.
 - If `save_comment` fails, retry once. If it fails again, surface the error.

package/plugins/lisa/skills/tracker-sync/SKILL.md

@@ -20,9 +20,32 @@ See the `config-resolution` rule for configuration and dispatch table.
    - Anything else → stop and report `"Unknown tracker '<value>' in .lisa.config.json. Expected 'jira', 'github', or 'linear'."`
 3. Pass through the output.
 
+`$ARGUMENTS` is forwarded verbatim, including the optional `--rollup` flag (see "Parent status rollup" below) and `--update-label`. The shim never interprets these — the vendor skill does.
+
 If `$ARGUMENTS` is empty, all vendor skills auto-detect a ticket reference from the active plan file (most recently modified `.md` in `plans/`).
 
+## Parent status rollup (`--rollup`)
+
+When the caller passes `--rollup` after the milestone, the dispatch target additionally **derives the parent/container's lifecycle state from its children** instead of acting on the work item directly. This is the vendor-neutral implementation of the **Parent status rollup (the state machine)** section of the `leaf-only-lifecycle` rule — cite that rule, do not restate the policy here. The shim is dispatch only; the rollup mechanics live in the vendor sync skill (`lisa:github-sync`, `lisa:jira-sync`, `lisa:linear-sync`), which resolves child membership via its `*-read-*` skill and evaluates the state machine below.
+
+The state machine (first match wins, evaluated over the **required** leaves only):
+
+| If among the required leaves… | …the parent rolls up to | Role |
+|---|---|---|
+| any leaf is **blocked** | blocked / attention-needed | `blocked` |
+| else any leaf is **in progress** (claimed or in review) | active / in-progress | `claimed` |
+| else **all** required leaves are **terminal** | the configured rollup terminal | `done` (or `review` where supported) |
+| else (leaves exist, none started) | unchanged | — |
+
+- **Blocked dominates** — one blocked leaf surfaces blocked on the parent even while others progress.
+- **The parent never carries `ready`** — `ready` is a human "claim this leaf" signal; rollup only moves a parent between non-ready container states.
+- **Rollup is recursive** — an Epic rolls up from its Stories, each of which rolls up from its own leaves. Evaluate bottom-up.
+- **The terminal is the configured env-keyed `done`** — multi-env projects roll up to whichever `done` value matches the env their leaves shipped to (see `config-resolution` "Env-keyed `done`"). **Single-environment collapse (this repo):** `deploy.branches` declares only `production: main`, so `done` is a single value and the lifecycle collapses to `ready → claimed (in-progress) → review (code-review) → done`; the rollup terminal is simply `done` (or the PRD-side `ticketed` for PRD containers), with **no** dev/staging promotion hops and **no** env-keyed multi-entry chain to resolve.
+
+**Safe-by-default when not yet supported.** A vendor sync path that has not implemented native rollup MUST be a documented no-op that surfaces the derived state as a suggestion/comment rather than guessing a transition — never an unsafe default. Without `--rollup`, the sync skills behave exactly as before (milestone comment on the work item; no parent derivation).
+
 ## Rules
 
 - Idempotent updates — running sync at the same milestone twice should not produce duplicate comments. Vendor skills enforce this.
 - Never auto-transition the underlying state. Linear's label-based transition (`status:*`) is the canonical signal and is updated only when the caller passes `--update-label`. Native states stay as suggestions.
+- Parent rollup derives state from children per the `leaf-only-lifecycle` rule; it never sets a parent to `ready` and never resolves a dev/staging `done` in this single-environment repo.

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.30.0",
+  "version": "2.32.0",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.30.0",
+  "version": "2.32.0",
   "description": "AWS CDK-specific Lisa plugin.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.30.0",
+  "version": "2.32.0",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.30.0",
+  "version": "2.32.0",
   "description": "Expo and React Native-specific skills, agents, rules, and MCP servers.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-harper-fabric/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.30.0",
+  "version": "2.32.0",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-harper-fabric/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.30.0",
+  "version": "2.32.0",
   "description": "Harper/Fabric-specific Lisa rules for TypeScript component apps.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.30.0",
+  "version": "2.32.0",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.30.0",
+  "version": "2.32.0",
   "description": "NestJS-specific skills and migration write-protection hooks.",
   "author": {
     "name": "Cody Swann"

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

@@ -0,0 +1,8 @@
+{
+  "name": "lisa-openclaw",
+  "version": "2.32.0",
+  "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/.codex-plugin/plugin.json

@@ -0,0 +1,32 @@
+{
+  "name": "lisa-openclaw",
+  "version": "2.32.0",
+  "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, across Claude and Codex.",
+  "author": {
+    "name": "Cody Swann"
+  },
+  "keywords": [
+    "openclaw",
+    "telegram",
+    "slack",
+    "agents",
+    "chat-ops"
+  ],
+  "skills": "./skills/",
+  "interface": {
+    "displayName": "Lisa OpenClaw",
+    "shortDescription": "Staff on Telegram/Slack via OpenClaw",
+    "longDescription": "Wire staff roles to human chat surfaces through OpenClaw: set up the gateway prerequisites, connect a facilitator (chief of staff) and its specialists on Telegram or Slack with hub-and-spoke routing, and bind Telegram forum topics to dispatcher+worker pairs for repo-coding work. Distributed for both Claude Code and Codex.",
+    "developerName": "Cody Swann",
+    "category": "Productivity",
+    "capabilities": [
+      "Interactive",
+      "Write"
+    ],
+    "defaultPrompt": [
+      "Set up OpenClaw for this project",
+      "Connect my chief of staff to Telegram",
+      "Connect staff to Slack via OpenClaw"
+    ]
+  }
+}

package/plugins/lisa-openclaw/commands/connect-repo-topic.md

@@ -0,0 +1,7 @@
+---
+description: "Bind a Telegram forum topic to an OpenClaw dispatcher+worker pair that runs a coding CLI against a repo (single-repo or folder-scoped), so you can drive code work from chat. Requires /lisa:setup-openclaw first."
+argument-hint: "<admin|developer> <single-repo|folder-scoped> <topic name> <workspace path>"
+---
+
+Use the lisa-openclaw-connect-repo-topic skill to provision or update a Telegram repo-coding topic
+(dispatcher + worker pair) and wire it in OpenClaw. $ARGUMENTS

package/plugins/lisa-openclaw/commands/connect-staff-slack.md

@@ -0,0 +1,7 @@
+---
+description: "Connect staff roles to Slack via OpenClaw using a facilitator/specialist hub-and-spoke model — register the app, create/reuse the facilitator channel, wire routes, validate, and run an end-to-end route test. Requires /lisa:setup-openclaw first."
+argument-hint: "<facilitator role + specialists, e.g. Chief of Staff with Legal, Finance, Sales>"
+---
+
+Use the lisa-openclaw-connect-staff skill with platform `slack`. Connect the named facilitator and
+specialists to a Slack facilitator channel via OpenClaw. $ARGUMENTS

package/plugins/lisa-openclaw/commands/connect-staff-telegram.md

@@ -0,0 +1,7 @@
+---
+description: "Connect staff roles to Telegram via OpenClaw using a facilitator/specialist hub-and-spoke model — register bots, create/reuse the facilitator topic, wire routes, validate, and run an end-to-end route test. Requires /lisa:setup-openclaw first."
+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. $ARGUMENTS

package/plugins/lisa-openclaw/commands/setup-openclaw.md

@@ -0,0 +1,7 @@
+---
+description: "Set up OpenClaw as the chat-surface runtime for this project's staff. Verifies the openclaw CLI, ~/.openclaw/openclaw.json, a secret provider, and required gateway capabilities, then writes a lean `openclaw` section to .lisa.config.json. Run before connect-staff / connect-repo-topic."
+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. $ARGUMENTS

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

@@ -0,0 +1,137 @@
+---
+name: lisa-openclaw-connect-repo-topic
+description: Bind a Telegram forum topic to an OpenClaw dispatcher+worker agent pair that runs a coding CLI against a repo, so you can drive code work from chat. Supports single-repo topics and folder-scoped topics (multiple repos with repo-confirmation). Creates/validates the agent pair, ensures the bot is a group admin, captures real group/topic ids, wires the route in ~/.openclaw/openclaw.json, validates the gateway, and runs a no-change self-test. Requires lisa-openclaw-setup first.
+---
+
+# 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: 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
+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.
+
+### 7. Validate + self-test
+
+```sh
+openclaw config validate
+openclaw gateway restart
+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
+<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).