@codyswann/lisa 2.176.8 → 2.176.10

package/plugins/lisa-cursor/rules/pre-flight-autofill-reference.mdc

@@ -0,0 +1,147 @@
+---
+description: "Pre-Flight Spec Autofill (Draft-Then-Block)"
+alwaysApply: false
+---
+
+# Pre-Flight Spec Autofill (Draft-Then-Block)
+
+When the pre-flight gate (`*-agent` Step 2) returns `FAIL` on **ticket-quality**
+gaps, the agent does **not** bounce a raw "here is everything you must write"
+checklist back to the reporter. Most "missing required spec content" gaps are
+**authorable** from material already on the work item (title, description,
+screenshots, design links, reproduction steps) plus the codebase. The agent
+drafts a best-effort version of every authorable gap, writes it into the work
+item as clearly-labeled **assumptions and recommendations**, and only **then**
+blocks — turning the human ask from *"author all of this from scratch"* into
+*"confirm or correct my draft, then flip it back to Ready."*
+
+This is the same shape as the `repo-scope-split` exception: the agent does the
+work it can and reserves the human for what only a human can decide. It does
+**not** widen the gate — every required section must still exist before build;
+autofill just supplies a defensible first draft instead of an empty demand.
+
+## Why this exists
+
+The build + screenshot-diff verification pipeline needs **structured,
+machine-readable** sections — Gherkin acceptance criteria, a Validation Journey
+with `[SCREENSHOT:]`/`[EVIDENCE:]` markers, Sign-in Required, Target Backend
+Environment, Repository. A bug report routinely contains all of that
+*information* in prose, screenshots, or a Figma link, but not the *structure*.
+Dumping the checklist straight back produces a ping-pong loop: the item bounces
+`Ready → Blocked → Ready` on every intake cycle because nobody re-types the
+existing information into headings, and the reporter reasonably objects that the
+information is already there. Drafting the structure breaks the loop and
+respects the reporter's time — the human reviews a draft instead of authoring a
+spec.
+
+## Two tiers of gap
+
+**Tier A — authorable (always attempt a draft):**
+
+- **Technical Approach** — locate the affected component/files in the repo (the
+  title and description usually name the surface, e.g. "Player modal"); state
+  which files likely change and the expected layout. Flag inferences as
+  assumptions.
+- **Out of Scope** — a one-line boundary derived from the fix list.
+- **Acceptance Criteria (Gherkin)** — convert each described fix / expected
+  behavior into `Given/When/Then`. One scenario per discrete fix.
+- **Expected-vs-actual + environment** — restate the bug as explicit expected
+  vs actual, naming the environment the screenshots/description came from.
+- **Repository** — resolve per `config-resolution` repo scoping and state it.
+- **Relationship Search** — actually **run** the git + tracker search; record
+  the queries and results and link anything found. Do not fabricate a
+  "none found" note.
+- **Validation Journey (draft)** — run the vendor `*-add-journey` skill to draft
+  the click-path, markers, and viewports from the reproduction steps. This is a
+  draft for human approval, not the final ratified contract.
+- **Target Backend Environment** — recommend a default from `deploy.branches` /
+  config (the backend the FE points at for verification) and state it as a
+  recommendation.
+
+**Tier B — irreducibly human (cannot invent — but still propose a default):**
+
+- **Real credentials / access** that exist nowhere on the item or in the repo's
+  known test-user docs. (If credentials are present in prose, that is Tier A —
+  lift them into a Sign-in Required section.)
+- **A genuine product / scoping decision** with no defensible default — the
+  exact expected behavior when the ticket is internally contradictory or the
+  design reference is missing.
+
+For Tier B, still propose a **recommended default** wherever one is defensible,
+and ask a **specific question** only where none is. Never reduce a Tier B item
+to a bare demand.
+
+## Procedure
+
+1. **Enumerate the FAIL categories** from `*-verify`.
+2. **Run `repo-scope-split` first** if S10 (single-repo scope) failed — that is
+   a split, not an autofill. Autofill handles the remaining quality gaps.
+3. **Draft each Tier-A gap** grounded in the work-item material + codebase.
+   Every inferred value is explicitly tagged as an assumption/recommendation
+   (lead the drafted block with a note: *"Drafted by Claude — assumptions
+   flagged inline; please confirm or correct."*). **Never overwrite
+   human-authored prose** — add the missing structured sections; if a section
+   exists but is thin, augment it without discarding the human's words.
+4. **Write the draft into the work item** via the vendor write skill
+   (`jira-write-ticket` / `github-write-issue` / `linear-write-issue`) so
+   relationship and metadata gates stay enforced. Draft the Validation Journey
+   via the vendor `*-add-journey` skill.
+5. **Re-run `*-verify`.** The structural gates should now PASS (the content
+   exists, even if assumed). Any gate that still FAILs is Tier B — leave it and
+   name it precisely in the comment.
+6. **Block as usual** — transition/relabel to the configured `blocked` status,
+   add the `human_needed` marker, reassign to the **Reporter** — but post the
+   **confirmation comment** (below), not a remediation checklist.
+7. **Idempotency / loop-safety.** If the item already carries the agent's draft
+   from a prior cycle, do **not** redraft from scratch — refine only the gaps
+   still failing and refresh the confirmation comment. When the reporter flips
+   the item back to Ready, the next claim re-runs `*-verify`; if it now PASSes,
+   build proceeds on the draft the reporter approved by re-readying it. That is
+   what breaks the `Ready ↔ Blocked` loop.
+
+## The confirmation comment (replaces the remediation checklist)
+
+- **Disclose**: posted by Claude (AI build agent); identify the content as a
+  draft.
+- **Frame it**: the item had the right information but lacked the structured
+  sections the pipeline needs, so the agent drafted them — the report's validity
+  was never in question.
+- **One line per drafted section**, naming the section and the key assumption
+  (e.g. *"Acceptance Criteria — drafted 4 Gherkin scenarios from the fix list;
+  assumed 'Search result' restores the prior query terms."*).
+- **Tier-B items still required**, each as a specific question with a
+  recommended default where one exists.
+- **Close with the action**: *"Review the drafted sections in the description.
+  Correct anything wrong, then flip back to Ready and it builds immediately — or
+  reply with corrections and I'll revise."* Keep the `human_needed` marker until
+  then.
+
+## When you genuinely cannot autofill (fall back to the plain block)
+
+If the item is so underspecified that drafting would be fabrication — no fix or
+expected behavior described, no usable design reference, an uninformative title,
+and the codebase gives no anchor — block as before. Even then, phrase **each gap
+as a specific question** and propose a default wherever one is defensible (the
+"Human-Needed is a last resort" principle). Never bounce a bare checklist when a
+defensible draft is possible.
+
+## Disclosure & safety
+
+- Agent-drafted content is **always attributed to Claude and marked as
+  assumptions**, so a human never mistakes a guess for their own ratified spec.
+- The agent writes **spec/criteria, never code**, at this gate. Drafting
+  acceptance criteria and a validation journey is authoring, not implementation
+  — explicitly permitted here. This **supersedes** the older "the build agent
+  does not author the missing spec content" stance, which produced the
+  bounce-loop.
+
+## Vendor mechanics
+
+- **JIRA** — draft sections via `jira-write-ticket`; Validation Journey via
+  `jira-add-journey`; block + label + reassign + comment via the `jira-agent`
+  Step 2 exception (`transitionJiraIssue`, `editJiraIssue` for the label and
+  assignee, `addCommentToJiraIssue`).
+- **GitHub** — `github-write-issue`; `github-add-journey`; relabel + reassign +
+  comment via `gh`.
+- **Linear** — `linear-write-issue`; `linear-add-journey`; `save_issue` +
+  `save_comment`.

package/plugins/lisa-cursor/rules/pre-flight-autofill.mdc

@@ -0,0 +1,70 @@
+---
+description: "Pre-Flight Spec Autofill — Draft-Then-Block (load-bearing)"
+alwaysApply: true
+---
+
+# Pre-Flight Spec Autofill — Draft-Then-Block (load-bearing)
+
+When the pre-flight gate (`*-agent` Step 2) returns `FAIL` on **ticket-quality**
+gaps, do **not** bounce a raw checklist back to the reporter. Most "missing
+required spec content" gaps are **authorable** from material already on the work
+item (title, description, screenshots, design links, repro steps) plus the
+codebase. **Draft** a best-effort version of every authorable gap, write it into
+the item as clearly-labeled **assumptions/recommendations**, and only **then**
+block — turning the human ask from *"author all this"* into *"confirm or correct
+my draft, then flip back to Ready."* Same shape as `repo-scope-split`: the agent
+does the work it can; the human decides only what only a human can.
+
+This does **not** widen the gate — every required section must still exist
+before build. It replaces an empty demand with a defensible first draft, and it
+breaks the `Ready ↔ Blocked` ping-pong loop that a raw checklist causes (the
+information was already on the ticket; only the structure was missing).
+
+## Two tiers
+
+- **Tier A — authorable (always draft):** Technical Approach, Out of Scope,
+  Gherkin Acceptance Criteria (one scenario per fix), expected-vs-actual +
+  environment, Repository, Relationship Search (actually run the git+tracker
+  search — don't fabricate "none found"), Validation Journey **draft** (via the
+  vendor `*-add-journey` skill), Target Backend Environment (recommend a default
+  from `deploy.branches`/config).
+- **Tier B — irreducibly human:** real credentials/access that exist nowhere on
+  the item or in repo test-user docs; a genuine product/scoping decision with no
+  defensible default. Still propose a recommended default where one exists; ask
+  a specific question only where none does.
+
+## Procedure
+
+1. Enumerate FAIL categories from `*-verify`. If S10 failed, run
+   `repo-scope-split` first (split, not autofill).
+2. Draft each Tier-A gap grounded in item material + codebase; tag every
+   inference as an assumption. **Never overwrite human prose** — add/augment
+   sections only.
+3. Write the draft via the vendor write skill (`jira-write-ticket` /
+   `github-write-issue` / `linear-write-issue`); draft the Validation Journey
+   via `*-add-journey`.
+4. Re-run `*-verify`. Structural gates should now PASS; anything still failing
+   is Tier B — name it in the comment.
+5. Block as usual (`blocked` status + `human_needed` marker + reassign to
+   Reporter) but post the **confirmation comment**, not a checklist: disclose
+   it's a Claude draft, one line per drafted section + its key assumption,
+   Tier-B items as specific questions with defaults, and close with *"correct
+   anything wrong, then flip back to Ready and it builds — or reply with
+   corrections."*
+6. **Loop-safety:** if the item already carries the agent's draft, refine only
+   the still-failing gaps; don't redraft. Re-readying after review is the
+   human's approval — the next claim's `*-verify` PASSes and build proceeds.
+
+## When you genuinely cannot autofill
+
+If drafting would be fabrication (no fix/expected behavior described, no usable
+design ref, uninformative title, no codebase anchor), block as before — but
+phrase each gap as a specific question with a default where defensible. Never a
+bare checklist when a defensible draft is possible.
+
+The agent writes **spec/criteria, never code**, at this gate — authoring AC and
+a validation journey is explicitly permitted here (this supersedes the older
+"the build agent does not author the missing spec content" stance).
+
+Full procedure, tier detail, confirmation-comment template, and vendor mechanics:
+[reference/pre-flight-autofill.md](pre-flight-autofill-reference.mdc).

package/plugins/lisa-cursor/skills/github-build-intake/SKILL.md

@@ -256,9 +256,31 @@ This is the idempotency lock — a re-entrant cycle's `--label $READY` filter wi
 
 If the relabel fails (permission, race), log under "Errors" in the cycle summary and skip this issue. **Do not invoke the build flow on an issue you didn't successfully claim.**
 
-#### 3c. Run the build flow
+#### 3c. Return or run the build delegation
+
+After the claim succeeds, the per-issue build must run under `lisa:github-agent` (the per-issue lifecycle agent), but a teammate running this skill must not spawn that named peer itself. Claude teams are flat: only the lead can add a named teammate. Therefore:
+
+- If you are the team lead/root agent, spawn or invoke `lisa:github-agent` with the issue ref and wait for its structured result.
+- If you are a teammate, stop this skill's direct work and return a structured `delegation-request` to the lead instead of calling `Agent` with `name` or otherwise spawning `github-agent` as a named peer.
+- A private anonymous helper is allowed only when the helper is not a roster peer and the `Agent` call omits `name`; it must not replace this `github-agent` delegation.
+
+Return this payload shape to the lead:
+
+```json
+{
+  "type": "delegation-request",
+  "agent": "github-agent",
+  "workItem": "<org>/<repo>#<number>",
+  "context": {
+    "claimedLabel": "$CLAIMED",
+    "doneResolution": "Resolve $DONE from the PR base branch per this skill's Workflow resolution section"
+  },
+  "onSuccess": "Confirm the returned PR is merged, then apply Phase 3d and Phase 3d.1",
+  "onBlockedOrError": "Leave the issue where github-agent left it and record the surfaced outcome"
+}
+```
 
-Invoke `lisa:github-agent` (the per-issue lifecycle agent) with the issue ref. `lisa:github-agent` owns:
+`lisa:github-agent` owns:
 - Reading the full issue graph (`lisa:github-read-issue`)
 - Running its own pre-flight quality gate (`lisa:github-verify`)
 - Running issue triage (`lisa:ticket-triage`)
@@ -266,7 +288,7 @@ Invoke `lisa:github-agent` (the per-issue lifecycle agent) with the issue ref. `
 - Posting progress comments via `lisa:github-sync`
 - Posting evidence via `lisa:github-evidence`
 
-Wait for `lisa:github-agent` to return. Capture its outcome:
+The lead waits for `lisa:github-agent` to return, then resumes this scanner with the returned outcome:
 
 - **Success** — the build flow completed and a PR exists; evidence posted. The PR may already be **merged** or still **open** (auto-merge enabled, awaiting checks/merge). "Success" means the build work is sound — it does **not** assert the change reached an environment. The env transition in 3d gates on the PR actually being merged; an open PR does not advance the issue to a `done` env status.
 - **Blocked by github-verify pre-flight gate** — `lisa:github-agent` itself relabels the issue to `status:blocked` (or removes `$CLAIMED` and reassigns to the original author). This is correct and expected — let it stand. Record and move on.

package/plugins/lisa-cursor/skills/jira-build-intake/SKILL.md

@@ -203,9 +203,31 @@ Transition the ticket from `$READY` to `$CLAIMED` by invoking `lisa:atlassian-ac
 
 If the transition fails (permission, missing transition, race), log under "Errors" in the cycle summary and skip this ticket. **Do not invoke the build flow on a ticket you didn't successfully claim.**
 
-#### 3c. Run the build flow
+#### 3c. Return or run the build delegation
+
+After the claim succeeds, the per-ticket build must run under `lisa:jira-agent` (the per-ticket lifecycle agent), but a teammate running this skill must not spawn that named peer itself. Claude teams are flat: only the lead can add a named teammate. Therefore:
+
+- If you are the team lead/root agent, spawn or invoke `lisa:jira-agent` with the ticket key and wait for its structured result.
+- If you are a teammate, stop this skill's direct work and return a structured `delegation-request` to the lead instead of calling `Agent` with `name` or otherwise spawning `jira-agent` as a named peer.
+- A private anonymous helper is allowed only when the helper is not a roster peer and the `Agent` call omits `name`; it must not replace this `jira-agent` delegation.
+
+Return this payload shape to the lead:
+
+```json
+{
+  "type": "delegation-request",
+  "agent": "jira-agent",
+  "workItem": "<TICKET>",
+  "context": {
+    "claimedStatus": "$CLAIMED",
+    "doneResolution": "Resolve $DONE from the PR base branch per this skill's Workflow resolution section"
+  },
+  "onSuccess": "Confirm the returned PR is merged, then apply Phase 3d and Phase 3d.1",
+  "onBlockedOrError": "Leave the ticket where jira-agent left it and record the surfaced outcome"
+}
+```
 
-Invoke the `lisa:jira-agent` (existing per-ticket lifecycle agent) with the ticket key. `lisa:jira-agent` owns:
+`lisa:jira-agent` owns:
 - Reading the full ticket graph (`lisa:jira-read-ticket`)
 - Running its own pre-flight quality gate (`lisa:jira-verify`)
 - Running ticket triage (`lisa:ticket-triage`)
@@ -213,7 +235,7 @@ Invoke the `lisa:jira-agent` (existing per-ticket lifecycle agent) with the tick
 - Posting progress comments via `lisa:jira-sync`
 - Posting evidence via `lisa:jira-evidence`
 
-Wait for `lisa:jira-agent` to return. Capture its outcome:
+The lead waits for `lisa:jira-agent` to return, then resumes this scanner with the returned outcome:
 - **Success** — the build flow completed and a PR exists; evidence posted. The PR may already be **merged** or still **open** (auto-merge enabled, awaiting checks/merge). "Success" means the build work is sound — it does **not** assert the change reached an environment. The env transition in 3d gates on the PR actually being merged; an open PR does not advance the ticket to a `done` env status.
 - **Blocked by jira-verify pre-flight gate** — `lisa:jira-agent` itself transitions the ticket to `Blocked` and reassigns to Reporter. This is correct and expected — let it stand. Record the outcome and move on.
 - **Duplicate already fixed** — `lisa:jira-agent` / `lisa:ticket-triage` returned `DUPLICATE_ALREADY_FIXED` with a canonical ticket reference and empirical base-branch evidence. Post the triage finding, ensure the native `duplicates <canonical>` link exists, transition to the terminal `$DONE` status with resolution `Duplicate`, and do not open a PR. If the canonical fix is merged but not yet on the production branch, the close comment must say the production error can recur until the canonical ticket promotes and that recurrence is tracked by the canonical ticket; do not reopen this duplicate for that recurrence.

package/plugins/lisa-cursor/skills/linear-build-intake/SKILL.md

@@ -196,9 +196,31 @@ This is the idempotency lock — a re-entrant cycle's `label: $READY` filter wil
 
 If the relabel fails (permission, race), record under "Errors" and skip. **Do not invoke the build flow on an Issue you didn't successfully claim.**
 
-#### 3c. Run the build flow
+#### 3c. Return or run the build delegation
+
+After the claim succeeds, the per-Issue build must run under `lisa:linear-agent` (the per-Issue lifecycle agent), but a teammate running this skill must not spawn that named peer itself. Claude teams are flat: only the lead can add a named teammate. Therefore:
+
+- If you are the team lead/root agent, spawn or invoke `lisa:linear-agent` with the Issue identifier and wait for its structured result.
+- If you are a teammate, stop this skill's direct work and return a structured `delegation-request` to the lead instead of calling `Agent` with `name` or otherwise spawning `linear-agent` as a named peer.
+- A private anonymous helper is allowed only when the helper is not a roster peer and the `Agent` call omits `name`; it must not replace this `linear-agent` delegation.
+
+Return this payload shape to the lead:
+
+```json
+{
+  "type": "delegation-request",
+  "agent": "linear-agent",
+  "workItem": "<ISSUE-ID>",
+  "context": {
+    "claimedLabel": "$CLAIMED",
+    "doneResolution": "Resolve $DONE from the PR base branch per this skill's Workflow resolution section"
+  },
+  "onSuccess": "Confirm the returned PR is merged, then apply Phase 3d and Phase 3d.1",
+  "onBlockedOrError": "Leave the Issue where linear-agent left it and record the surfaced outcome"
+}
+```
 
-Invoke `lisa:linear-agent` (per-Issue lifecycle agent) with the Issue identifier. `lisa:linear-agent` owns:
+`lisa:linear-agent` owns:
 - Reading the full Issue graph (`lisa:linear-read-issue`)
 - Running its own pre-flight quality gate (`lisa:linear-verify`)
 - Running ticket triage (`lisa:ticket-triage`)
@@ -206,7 +228,7 @@ Invoke `lisa:linear-agent` (per-Issue lifecycle agent) with the Issue identifier
 - Posting progress comments via `lisa:linear-sync`
 - Posting evidence via `lisa:linear-evidence`
 
-Wait for the agent to return. Capture its outcome:
+The lead waits for `lisa:linear-agent` to return, then resumes this scanner with the returned outcome:
 - **Success** — the build flow completed and a PR exists; evidence posted. The PR may already be **merged** or still **open** (auto-merge enabled, awaiting checks/merge). "Success" means the build work is sound — it does **not** assert the change reached an environment. The env transition in 3d gates on the PR actually being merged; an open PR does not advance the Issue to a `done` env status.
 - **Blocked by linear-verify pre-flight gate** — `lisa:linear-agent` itself relabels to `status:blocked` and assigns to creator. Let it stand. Record and move on.
 - **Duplicate already fixed** — `lisa:linear-agent` / `lisa:ticket-triage` returned `DUPLICATE_ALREADY_FIXED` with a canonical Issue reference and empirical base-branch evidence. Post the triage finding, ensure the native `duplicates <canonical>` relationship exists when Linear exposes it (otherwise leave an explicit relation/comment reference), apply the terminal `$DONE` label, move the native Issue to the configured canceled-as-duplicate or completed terminal state, and do not open a PR. If the canonical fix is merged but not yet on the production branch, the close comment must say the production error can recur until the canonical Issue promotes and that recurrence is tracked by the canonical Issue; do not reopen this duplicate for that recurrence.

package/plugins/lisa-cursor/skills/repair-intake/SKILL.md

@@ -334,8 +334,11 @@ If the PR is healthy in-flight and no blocker is found, the work simply died mid
 the vendor build-intake runs**, skipping the claim transition (the item is already `claimed`):
 
 1. Dispatch the item to the vendor agent — `lisa:jira-agent` / `lisa:github-agent` /
-   `lisa:linear-agent` (matching the queue's tracker) — with the item ref. This resumes the work
-   in place, preserving its existing branch/PR and prior comments.
+   `lisa:linear-agent` (matching the queue's tracker) — with the item ref. If repair-intake is
+   running as a teammate rather than the lead/root agent, return a structured `delegation-request`
+   to the lead instead of spawning that named peer yourself; only the lead can add named teammates
+   in Claude's flat roster. This resumes the work in place, preserving its existing branch/PR and
+   prior comments.
 2. **On agent success**, apply the scanner's post-agent transition yourself: `claimed → done`,
    where `done` is **env-resolved** exactly as `lisa:<tracker>-build-intake` resolves it (per
    `config-resolution` env-keyed `done`: explicit `target_env` arg wins; else reverse-lookup the

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.176.8",
+  "version": "2.176.10",
   "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.176.8",
+  "version": "2.176.10",
   "description": "Expo and React Native-specific skills, agents, rules, and MCP servers.",
   "author": {
     "name": "Cody Swann"

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

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

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

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

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.176.8",
+  "version": "2.176.10",
   "description": "Expo/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.176.8",
+  "version": "2.176.10",
   "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.176.8",
+  "version": "2.176.10",
   "description": "Harper/Fabric-specific Lisa rules for TypeScript component apps.",
   "author": {
     "name": "Cody Swann"

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

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

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

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

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.176.8",
+  "version": "2.176.10",
   "description": "Harper/Fabric-specific 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.176.8",
+  "version": "2.176.10",
   "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.176.8",
+  "version": "2.176.10",
   "description": "NestJS-specific skills and migration write-protection hooks.",
   "author": {
     "name": "Cody Swann"

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

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

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

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

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

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

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.176.8",
+  "version": "2.176.10",
   "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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.176.8",
+  "version": "2.176.10",
   "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"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.176.8",
+  "version": "2.176.10",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.176.8",
+  "version": "2.176.10",
   "description": "Ruby on Rails-specific skills and hooks for RuboCop and ast-grep scanning on edit.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.176.8",
+  "version": "2.176.10",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.176.8",
+  "version": "2.176.10",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"