@codyswann/lisa 2.127.0 → 2.128.0

package/plugins/lisa-cursor/skills/jira-validate-ticket/SKILL.md

@@ -162,9 +162,9 @@ If the spec doesn't set `authenticated_surface`, infer it: scan the description
 
 #### S10 — Repository section, single-repo scope
 
-When `issue_type ∈ {Bug, Task, Sub-task, Improvement}`, description must contain `h2. Repository` naming exactly one repo. Multiple repos OR cross-repo references in AC: FAIL with recommendation `"Split into per-repo work units under a shared parent Story (see lisa:task-decomposition step 1.5)"`.
+When `issue_type ∈ {Bug, Task, Sub-task, Improvement}` — or a **build-ready childless Story/Spike** (a claimable leaf per `leaf-only-lifecycle`) — description must contain `h2. Repository` naming exactly one repo. Multiple repos OR cross-repo references in AC: FAIL with recommendation `"Split into per-repo work units under a shared parent Story (see lisa:task-decomposition step 1.5)"`.
 
-Story / Epic / Spike: skipped (may span repos — these are coordination containers, not work units).
+An **Epic**, or a **Story/Spike that still holds child work** (or is not build-ready): skipped (may span repos — coordination containers, not claimable leaf work units).
 
 This gate is `product_relevant: false` because cross-repo work units are not a product question — they are a decomposition error. Callers (`lisa:notion-to-tracker`, `lisa:confluence-to-tracker`, `lisa:linear-to-tracker`, `lisa:github-to-tracker`) MUST pre-split cross-repo work into per-repo work units during the decomposition phase per `lisa:task-decomposition` step 1.5; an S10 failure here indicates the agent skipped that step and must auto-split + revalidate before writing, not surface a clarifying comment to product.
 
@@ -200,7 +200,7 @@ When `issue_type ∈ {Bug, Task, Sub-task, Improvement}` AND `runtime_behavior_c
 
 FAIL when the Validation Journey is present but declares zero `[EVIDENCE: name]` markers, or when any marker name is empty, duplicated, or not kebab-case. A behavior-changing work unit SHOULD declare both a success marker and an error/edge marker; a journey with only one marker passes but the remediation should recommend adding the error/edge case.
 
-This gate depends on S11. It is `N/A` for Epic / Story / Spike (coordination containers, not work units) and for leaf units with `runtime_behavior_change = false` (doc-only / config-only / type-only). If S11 fails because the Validation Journey is absent, S14 also FAILs (there is no manifest to bind) with remediation pointing back to `lisa:jira-add-journey`.
+This gate depends on S11. It is `N/A` for containers — an **Epic**, or any item with open child work (coordination containers, not work units) — and for leaf units with `runtime_behavior_change = false` (doc-only / config-only / type-only). If S11 fails because the Validation Journey is absent, S14 also FAILs (there is no manifest to bind) with remediation pointing back to `lisa:jira-add-journey`.
 
 #### S15 — Leaf-only build-ready
 
@@ -212,20 +212,19 @@ Enforces the build-side of the vendor-neutral `leaf-only-lifecycle` rule: **only
 
 Apply this decision and FAIL the two invariant-violating cases:
 
-1. **Container with child work + build-ready** — `issue_type ∈ {Epic, Story, Spike}` OR child work is present (any type that has children), AND build-ready. FAIL. A parent organizes work; it is never claimed and implemented directly. Its lifecycle state rolls up from its children.
-2. **Childless container-type + build-ready** — `issue_type ∈ {Epic, Story, Spike}` with **no** child work, AND build-ready. Still FAIL: these types are coordination containers by design, and an empty one is an incomplete decomposition, not an implementable unit (the childless-parent exception in `leaf-only-lifecycle` does **not** promote an Epic/Story/Spike to build-ready).
+1. **Container with child work + build-ready** — child work is present (any type that has open children), AND build-ready. FAIL. A parent organizes work; it is never claimed and implemented directly. Its lifecycle state rolls up from its children.
+2. **Childless Epic + build-ready** — `issue_type = Epic` with **no** child work, AND build-ready. Still FAIL: an Epic is a pure rollup container by design, and a childless one is an incomplete decomposition or a mis-applied role, not an implementable unit. (A childless Story or Spike is **not** failed here — the childless-parent exception in `leaf-only-lifecycle` promotes every childless non-Epic type to a build-ready leaf.)
 
-PASS (the childless-parent exception) when the ticket is build-ready and is a **leaf work unit**: `issue_type ∈ {Bug, Task, Sub-task, Improvement}` AND has **no** child work. A flat Task or Bug with no sub-tasks is a valid build-ready leaf and must not be stranded.
+PASS (the childless-parent exception) when the ticket is build-ready and is a **leaf work unit**: it has **no** open child work and `issue_type ≠ Epic` (i.e. `Bug, Task, Sub-task, Improvement`, or a childless `Story` / `Spike`). A flat Task/Bug, or a childless Story/Spike with no sub-tasks, is a valid build-ready leaf and must not be stranded.
 
 | issue_type | has child work | build-ready | S15 |
 |---|---|---|---|
-| Bug / Task / Sub-task / Improvement | no | yes | **PASS** (leaf) |
-| Bug / Task / Sub-task / Improvement | yes | yes | **FAIL** (structurally a container) |
-| Epic / Story / Spike | yes | yes | **FAIL** (container with children) |
-| Epic / Story / Spike | no | yes | **FAIL** (childless container-type, exception does not apply) |
+| Bug / Task / Sub-task / Improvement / Story / Spike | no | yes | **PASS** (leaf) |
+| any type | yes | yes | **FAIL** (structurally a container) |
+| Epic | no | yes | **FAIL** (childless Epic — pure rollup container, exception does not apply) |
 | any | any | no | **N/A** (not build-ready) |
 
-Remediation: `"Build-ready (status:ready) is leaf-only per leaf-only-lifecycle. Move status:ready off this container onto its leaf children (or, for a childless Epic/Story/Spike, decompose it into leaf children or reclassify it to a leaf type); a parent's lifecycle state rolls up from its children and is never set to ready directly."`
+Remediation: `"Build-ready (status:ready) is leaf-only per leaf-only-lifecycle. Move status:ready off this container onto its leaf children (or, for a childless Epic, decompose it into leaf children or reclassify it to a leaf type); a parent's lifecycle state rolls up from its children and is never set to ready directly."`
 
 `product_relevant: false` — a build-ready container is a lifecycle/decomposition error for the caller to repair, not a product question.
 

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

@@ -1,6 +1,6 @@
 ---
 name: linear-build-intake
-description: "Symmetric counterpart to lisa:jira-build-intake on the Linear side. Scans a Linear team for Issues carrying the configured `ready` build label, claims the first eligible Issue by relabeling to the configured `claimed` label, runs the implementation/build flow via lisa:linear-agent, relabels to the configured `done` label on completion, then exits. Enforces the claim-time arm of the `leaf-only-lifecycle` rule: a parent/container with open child work (or a childless Epic/Story/Spike) that still carries a stale build-ready label is skipped or safe-blocked with a lifecycle-repair comment, never claimed. The `ready` label is the human-flipped signal that an Issue is truly ready for development — mirroring how Notion PRDs work Draft → Ready → (us) In Review → Blocked|Ticketed."
+description: "Symmetric counterpart to lisa:jira-build-intake on the Linear side. Scans a Linear team for Issues carrying the configured `ready` build label, claims the first eligible Issue by relabeling to the configured `claimed` label, runs the implementation/build flow via lisa:linear-agent, relabels to the configured `done` label on completion, then exits. Enforces the claim-time arm of the `leaf-only-lifecycle` rule: a parent/container with open child work (or a childless Epic) that still carries a stale build-ready label is skipped or safe-blocked with a lifecycle-repair comment, never claimed. The `ready` label is the human-flipped signal that an Issue is truly ready for development — mirroring how Notion PRDs work Draft → Ready → (us) In Review → Blocked|Ticketed."
 allowed-tools: ["Skill", "Bash", "mcp__linear-server__list_teams", "mcp__linear-server__list_issues", "mcp__linear-server__get_issue", "mcp__linear-server__save_issue", "mcp__linear-server__save_comment", "mcp__linear-server__list_issue_labels", "mcp__linear-server__create_issue_label"]
 ---
 
@@ -167,17 +167,17 @@ Classify and act (first match wins). The type comes from the Issue's `type:` lab
 | Condition | Class | Action |
 |---|---|---|
 | `OPEN_CHILDREN > 0` (open child work, any type) | **Container** | **Skip / safe-block — do NOT claim** |
-| no open children AND type ∈ {Epic, Story, Spike} | **Childless container-type** | **Skip / safe-block — do NOT claim** |
-| no open children AND type ∈ {Bug, Task, Sub-task, Improvement} (or no `type:` label) | **Leaf work unit** | **Proceed to 3b claim** |
+| no open children AND type = Epic (a Linear Project) | **Childless Epic/Project (pure rollup container)** | **Skip / safe-block — do NOT claim** |
+| no open children AND type ≠ Epic (Bug, Task, Sub-task, Improvement, Story, Spike, or no `type:` label) | **Leaf work unit** | **Proceed to 3b claim** |
 
-The childless-parent exception is narrow: childlessness enables a claim **only** for types that are leaf work units to begin with. A childless Epic/Story/Spike is an incomplete decomposition, not an implementable unit — it is never claimed.
+The childless-parent exception promotes every childless type **except Epic** to a claimable leaf: a childless Story is a directly shippable increment and a childless Spike *is* the investigation unit, so neither is stranded. Only a childless **Epic** (a Linear Project) stays unclaimed — it is a pure rollup container by design, and a childless one is an incomplete decomposition or a mis-applied role, never an implementable unit.
 
 **Safe-block (default action for a flagged container).** Leave the build-ready label in place (don't silently strip it — that hides the lifecycle error), post a single lifecycle-repair comment, record the Issue under "Skipped (container)" in the summary, and end the cycle. Do NOT relabel to `$CLAIMED`. Keep the comment idempotent — skip posting if an identical `[claude-build-intake]` lifecycle-repair comment already exists on the Issue, so a re-entrant cycle doesn't spam it.
 
 Post via `mcp__linear-server__save_comment` with:
 
 ```text
-[claude-build-intake] Not claimed: this Issue carries the build-ready label ($READY) but is a container with open child work (or a childless Epic/Story/Spike), which violates the leaf-only-lifecycle rule. Build-ready (status:ready) is leaf-only per leaf-only-lifecycle — an agent claims and implements leaves, never a container. Repair: move $READY off this parent onto its leaf children (or, for a childless Epic/Story/Spike, decompose it into leaf children or reclassify it to a leaf type). A parent's lifecycle state rolls up from its children and is never set to ready directly.
+[claude-build-intake] Not claimed: this Issue carries the build-ready label ($READY) but is a container with open child work (or a childless Epic), which violates the leaf-only-lifecycle rule. Build-ready (status:ready) is leaf-only per leaf-only-lifecycle — an agent claims and implements leaves, never a container. Repair: move $READY off this parent onto its leaf children (or, for a childless Epic, decompose it into leaf children or reclassify it to a leaf type). A parent's lifecycle state rolls up from its children and is never set to ready directly.
 ```
 
 This gate never blocks a legitimate flat Task/Bug: those have no open children and a leaf `type:`, so they fall straight through to the claim in 3b.
@@ -252,7 +252,7 @@ Total PRs opened: <n>
 
 ## Idempotency & safety
 
-- **Leaf-only claim gate runs first**: Phase 3a classifies each candidate before any claim; a container with open child work (or a childless Epic/Story/Spike) is skipped/safe-blocked, never claimed (the `leaf-only-lifecycle` rule's claim-time arm). The safe-block comment is idempotent — a re-entrant cycle does not re-post it.
+- **Leaf-only claim gate runs first**: Phase 3a classifies each candidate before any claim; a container with open child work (or a childless Epic) is skipped/safe-blocked, never claimed (the `leaf-only-lifecycle` rule's claim-time arm). The safe-block comment is idempotent — a re-entrant cycle does not re-post it.
 - **Claim-first ordering**: `$CLAIMED` set BEFORE agent invocation — no double-pickup.
 - **No writes outside the lifecycle**: this skill only adds/removes `$READY`, `$CLAIMED`, `$DONE`, plus terminal-only native state completion required by `leaf-only-lifecycle`. Every other label change (and non-terminal native state change) is owned by the agent or `lisa:linear-evidence`.
 - **Terminal native closure**: after the `$DONE` label is applied, move the Linear Issue to a native completed state only when `$DONE` is the true terminal done value; intermediate env labels stay open / active.
@@ -273,7 +273,7 @@ If the team hasn't adopted these labels, the first run exits with an adoption hi
 
 ## Rules
 
-- **Claim leaves only.** Per the `leaf-only-lifecycle` rule, never claim a container — an Issue with open child work, or a childless Epic/Story/Spike — even if it carries the build-ready label. Skip or safe-block it (Phase 3a); never silently implement a container.
+- **Claim leaves only.** Per the `leaf-only-lifecycle` rule, never claim a container — an Issue with open child work, or a childless Epic — even if it carries the build-ready label. Skip or safe-block it (Phase 3a); never silently implement a container.
 - Never relabel an Issue the cycle didn't claim. The `$CLAIMED` transition is the signature of cycle ownership.
 - Never bypass `lisa:linear-agent` to do build work directly. The agent owns the per-Issue lifecycle.
 - Never auto-transition past `$DONE`. Downstream labels are owned by QA / product / a future verification-intake skill.

package/plugins/lisa-cursor/skills/linear-validate-issue/SKILL.md

@@ -165,9 +165,9 @@ If the spec doesn't set `authenticated_surface`, infer it: scan the description
 
 #### S10 — Repository section, single-repo scope
 
-When `issue_type ∈ {Bug, Task, Sub-task, Improvement}`, description must contain `## Repository` naming exactly one repo. Multiple repos OR cross-repo references in AC: FAIL with recommendation `"Split into per-repo work units under a shared parent Story (see lisa:task-decomposition step 1.5)"`.
+When `issue_type ∈ {Bug, Task, Sub-task, Improvement}` — or a **build-ready childless Story/Spike** (a claimable leaf per `leaf-only-lifecycle`) — description must contain `## Repository` naming exactly one repo. Multiple repos OR cross-repo references in AC: FAIL with recommendation `"Split into per-repo work units under a shared parent Story (see lisa:task-decomposition step 1.5)"`.
 
-Story / Epic / Spike: skipped (may span repos — these are coordination containers, not work units).
+An **Epic** (a Linear Project), or a **Story/Spike that still holds child work** (or is not build-ready): skipped (may span repos — coordination containers, not claimable leaf work units).
 
 This gate is `product_relevant: false` because cross-repo work units are not a product question — they are a decomposition error. Callers (`lisa:linear-to-tracker`, `lisa:notion-to-tracker`, etc.) MUST pre-split cross-repo work into per-repo work units during the decomposition phase per `lisa:task-decomposition` step 1.5; an S10 failure here indicates the agent skipped that step and must auto-split + revalidate before writing, not surface a clarifying comment to product.
 
@@ -201,7 +201,7 @@ When `issue_type ∈ {Bug, Task, Sub-task, Improvement}` AND `runtime_behavior_c
 
 FAIL when the Validation Journey is present but declares zero `[EVIDENCE: name]` markers, or when any marker name is empty, duplicated, or not kebab-case. A behavior-changing work unit SHOULD declare both a success marker and an error/edge marker; a journey with only one marker passes but the remediation should recommend adding the error/edge case.
 
-This gate depends on S11. It is `N/A` for Project / Story / Spike (coordination containers, not work units) and for leaf units with `runtime_behavior_change = false` (doc-only / config-only / type-only). If S11 fails because the Validation Journey is absent, S14 also FAILs (there is no manifest to bind) with remediation pointing back to `lisa:linear-add-journey`.
+This gate depends on S11. It is `N/A` for containers — a **Project** (the Epic equivalent), or any item with open child work (coordination containers, not work units) — and for leaf units with `runtime_behavior_change = false` (doc-only / config-only / type-only). If S11 fails because the Validation Journey is absent, S14 also FAILs (there is no manifest to bind) with remediation pointing back to `lisa:linear-add-journey`.
 
 #### S15 — Leaf-only build-ready
 
@@ -213,20 +213,19 @@ Enforces the build-side of the vendor-neutral `leaf-only-lifecycle` rule: **only
 
 Apply this decision and FAIL the two invariant-violating cases:
 
-1. **Container with child work + build-ready** — `issue_type ∈ {Epic, Story, Spike}` OR child work is present (any type that has children), AND build-ready. FAIL. A parent organizes work; it is never claimed and implemented directly. Its lifecycle state rolls up from its children.
-2. **Childless container-type + build-ready** — `issue_type ∈ {Epic, Story, Spike}` with **no** child work, AND build-ready. Still FAIL: these types are coordination containers by design, and an empty one is an incomplete decomposition, not an implementable unit (the childless-parent exception in `leaf-only-lifecycle` does **not** promote an Epic/Story/Spike to build-ready).
+1. **Container with child work + build-ready** — child work is present (any type that has open children), AND build-ready. FAIL. A parent organizes work; it is never claimed and implemented directly. Its lifecycle state rolls up from its children.
+2. **Childless Epic/Project + build-ready** — `issue_type = Epic` (a Linear Project) with **no** child work, AND build-ready. Still FAIL: an Epic/Project is a pure rollup container by design, and a childless one is an incomplete decomposition or a mis-applied role, not an implementable unit. (A childless Story or Spike is **not** failed here — the childless-parent exception in `leaf-only-lifecycle` promotes every childless non-Epic type to a build-ready leaf.)
 
-PASS (the childless-parent exception) when the item is build-ready and is a **leaf work unit**: `issue_type ∈ {Bug, Task, Sub-task, Improvement}` AND has **no** child work. A flat Task or Bug with no sub-issues is a valid build-ready leaf and must not be stranded.
+PASS (the childless-parent exception) when the item is build-ready and is a **leaf work unit**: it has **no** open child work and `issue_type ≠ Epic` (i.e. `Bug, Task, Sub-task, Improvement`, or a childless `Story` / `Spike`). A flat Task/Bug, or a childless Story/Spike with no sub-issues, is a valid build-ready leaf and must not be stranded.
 
 | issue_type | has child work | build-ready | S15 |
 |---|---|---|---|
-| Bug / Task / Sub-task / Improvement | no | yes | **PASS** (leaf) |
-| Bug / Task / Sub-task / Improvement | yes | yes | **FAIL** (structurally a container) |
-| Epic / Story / Spike | yes | yes | **FAIL** (container with children) |
-| Epic / Story / Spike | no | yes | **FAIL** (childless container-type, exception does not apply) |
+| Bug / Task / Sub-task / Improvement / Story / Spike | no | yes | **PASS** (leaf) |
+| any type | yes | yes | **FAIL** (structurally a container) |
+| Epic (Project) | no | yes | **FAIL** (childless Epic/Project — pure rollup container, exception does not apply) |
 | any | any | no | **N/A** (not build-ready) |
 
-Remediation: `"Build-ready (status:ready) is leaf-only per leaf-only-lifecycle. Move status:ready off this container onto its leaf children (or, for a childless Epic/Story/Spike, decompose it into leaf children or reclassify it to a leaf type); a parent's lifecycle state rolls up from its children and is never set to ready directly."`
+Remediation: `"Build-ready (status:ready) is leaf-only per leaf-only-lifecycle. Move status:ready off this container onto its leaf children (or, for a childless Epic, decompose it into leaf children or reclassify it to a leaf type); a parent's lifecycle state rolls up from its children and is never set to ready directly."`
 
 `product_relevant: false` — a build-ready container is a lifecycle/decomposition error for the caller to repair, not a product question.
 

package/plugins/lisa-cursor/skills/parity-code-review/SKILL.md

@@ -0,0 +1,83 @@
+---
+name: parity-code-review
+description: "Lisa-native code review of the current git diff. Walks every changed hunk and reports correctness bugs, security issues, and obvious defects as severity-ranked findings with file:line references. Vendor-neutral — the cross-agent equivalent of the upstream code-review command, runnable on Codex, agy, Copilot, Cursor, and Claude."
+allowed-tools: ["Read", "Bash", "Grep", "Glob"]
+---
+
+# Parity Code Review
+
+Review the code that is *about to ship* — the current uncommitted/branch diff — for defects a reviewer would block on. This is a focused **defect hunt**: correctness, security, and obvious mistakes. It is not a style audit and not a refactor pass (use `parity-code-simplifier` for quality-only cleanup).
+
+> **Not drift-trackable.** This skill intentionally carries **no `synced-from` pin**. The upstream `code-review@claude-plugins-official` plugin publishes **no semver** (its cache version resolves to `unknown`), so a pin would be unparseable and meaningless to `scripts/plugin-parity-drift.mjs`. Drift is tracked **manually** — re-review the upstream command by hand when the curated plugin set is refreshed. This is a Lisa-native reimplementation, **not** a port of upstream code.
+
+## Step 1: Establish the diff
+
+Determine exactly what changed. Prefer the broadest accurate view of the work-in-progress:
+
+```bash
+# Branch changes vs the merge base (preferred for a PR-style review)
+git merge-base HEAD origin/main 2>/dev/null && \
+  git diff "$(git merge-base HEAD origin/main)"...HEAD
+
+# Plus anything still uncommitted in the working tree
+git diff HEAD
+git status --short
+```
+
+If there is no diff at all, say so plainly and stop — do not invent findings. If the diff is enormous, review in full but prioritize the files with the most logic changes; never silently skip files (note any you deprioritized).
+
+## Step 2: Read for real context
+
+Do **not** review hunks in isolation. For each changed file, open enough surrounding code to understand:
+
+- What the function/module is supposed to do and who calls it.
+- Invariants and preconditions the change might violate.
+- Error/edge paths touched by the change.
+
+Use `Read`, `Grep`, and `Glob` to follow call sites and trace data flow. A finding you can't ground in the actual code is a guess — drop it.
+
+## Step 3: Hunt for defects
+
+For every changed hunk, evaluate against these lenses:
+
+1. **Correctness** — Off-by-one errors, inverted conditions, wrong operator, missing `await`, unhandled `null`/`undefined`, incorrect default, broken control flow, type coercion bugs, mutation of shared state, race conditions.
+2. **Security** — Unsanitized input at trust boundaries; injection (SQL/shell/template); secrets, tokens, or keys committed or logged; missing authn/authz on new endpoints; unsafe deserialization; path traversal; overly broad permissions; SSRF.
+3. **Edge cases & failure modes** — Empty collections, zero, negative numbers, very large input, concurrent calls, partial failures, timeouts, retries that aren't idempotent.
+4. **Obvious defects** — Dead code paths, unreachable branches, swallowed errors, resource leaks (unclosed handles/connections), `TODO`/`FIXME` left in shipping code, debug logging left on, broken or missing tests for the new behavior.
+5. **Contract & API** — Breaking changes to public signatures, changed return shapes, altered error semantics callers depend on.
+
+## Step 4: Output — severity-ranked findings
+
+Group findings by severity. Within each group, list the most impactful first. Every finding **must** carry a `file:line` reference.
+
+### Critical (must fix before merge)
+Bugs that break correctness, leak/expose data, or introduce a security hole.
+
+### Warning (should fix)
+Likely to cause problems later, or a real defect with limited blast radius.
+
+### Suggestion (nice to have)
+Minor correctness nits or defensive improvements.
+
+### Finding format
+
+For each finding:
+
+- **What** — precise description of the defect.
+- **Where** — `path/to/file.ts:42` (and a span if it covers multiple lines).
+- **Why** — the concrete failure it causes, with an example input or sequence that triggers it.
+- **Fix** — a specific, actionable suggestion (or a short code sketch).
+
+Example:
+
+> **Critical — Unhandled null dereference**
+> **Where:** `src/auth/session.ts:88`
+> **Why:** `findUser()` returns `null` when the id is unknown, but line 88 reads `user.roles` directly. An unknown session id (expired token replay) throws and 500s instead of returning 401.
+> **Fix:** Guard `if (!user) return unauthorized()` before reading `user.roles`.
+
+## Rules
+
+- **Ground every finding in the diff.** No speculative findings, no generic best-practice lectures unrelated to the change.
+- **Be honest about coverage.** If you deprioritized files or couldn't fully trace a path, say so.
+- **If the diff is clean, say so clearly** — "No blocking issues found across N changed files" — do not manufacture problems.
+- This is review-only: report findings, do **not** edit files. Apply fixes via the normal implementation flow or `parity-code-simplifier` (quality) after triage.

package/plugins/lisa-cursor/skills/parity-code-simplifier/SKILL.md

@@ -0,0 +1,76 @@
+---
+name: parity-code-simplifier
+description: "Lisa-native, behavior-preserving simplification of recently-changed code. Removes duplication and dead code, reuses existing utilities, and improves readability without altering behavior — quality only, never a bug hunt. Vendor-neutral cross-agent equivalent of the upstream code-simplifier agent, runnable on Codex, agy, Copilot, Cursor, and Claude."
+allowed-tools: ["Read", "Bash", "Grep", "Glob", "Edit", "Write"]
+synced-from: code-simplifier@claude-plugins-official@1.0.0
+---
+
+# Parity Code Simplifier
+
+Make the **recently-changed** code simpler and easier to maintain **without changing what it does**. This is a quality pass: deduplication, reuse, readability, and dead-code removal. It is explicitly **not** a bug hunt — if you spot a likely defect, note it for a reviewer (or `parity-code-review`) and leave the behavior intact.
+
+> **Drift tracking.** Pinned to `code-simplifier@claude-plugins-official@1.0.0`. `scripts/plugin-parity-drift.mjs` compares this pin against the upstream version in the plugin cache and flags staleness. This is a Lisa-native reimplementation written from scratch — **do not port or copy upstream plugin code.**
+
+## Scope: recently-changed code only
+
+Default to the current diff, not the whole repository. Establish scope first:
+
+```bash
+git merge-base HEAD origin/main 2>/dev/null && \
+  git diff --stat "$(git merge-base HEAD origin/main)"...HEAD
+git diff HEAD --stat
+git status --short
+```
+
+Simplify the files that changed and the immediate code they touch. Do not embark on a repo-wide refactor unless explicitly asked.
+
+## The prime directive: preserve behavior
+
+Every edit must be behavior-preserving. Before changing anything, understand the current contract — inputs, outputs, side effects, error paths, public signatures. After changing it, the observable behavior must be identical. When in doubt, **don't** — leave a note instead of risking a semantic change.
+
+## What to simplify
+
+1. **Duplication (DRY)** — Collapse copy-pasted blocks into a single function or shared helper. Prefer delegating to an existing canonical implementation over re-deriving logic (see the repo's DRY rule: a function that reproduces a sequence should call the shared generator, not reimplement it).
+2. **Reuse over reinvention** — Search for existing utilities (`Grep`/`Glob`) before introducing new code. If the project already has a helper for what the change hand-rolls, use it.
+3. **Readability** — Clearer names; flatten needless nesting with early returns/guard clauses; replace clever one-liners with obvious code; split overly long functions along natural seams.
+4. **Dead code** — Remove unreachable branches, unused variables/imports/exports, and commented-out blocks introduced or exposed by the change.
+5. **Idiomatic constructs** — Prefer immutable transformations (`map`/`filter`/`reduce`) over mutable accumulation where it's clearer; remove redundant intermediate state.
+
+## Respect project conventions
+
+This repo enforces specific patterns — honor them so your simplification doesn't trip the linter or hooks:
+
+- **Immutability / functional style** — avoid `let` and in-place mutation; prefer `const` and pure transformations.
+- **Statement order** — do not place expression-statement helper calls before `const` definitions; inline validation as `if` guard clauses (exempt from `enforce-statement-order`).
+- **eslint-disable directives** must include a `-- description`.
+- **Barrel-export constraint** — if you delete a file referenced by an `index.ts`, update the barrel in the same change so lint/typecheck stays green.
+- **Never edit generated plugin artifacts** (`plugins/lisa`, `plugins/lisa-*`); the source of truth is `plugins/src/`.
+
+## Workflow
+
+1. Read each changed file and enough of its callers to know the contract.
+2. Identify simplification opportunities; rank by value-to-risk. Skip anything that risks behavior.
+3. Apply edits with `Edit`/`Write`, one coherent change at a time.
+4. **Verify behavior is unchanged** — run the project's checks:
+   ```bash
+   bun run test
+   bun run typecheck 2>/dev/null || true
+   bun run lint 2>/dev/null || true
+   ```
+   If any check fails, fix or revert the offending edit before continuing. Never leave the tree worse than you found it.
+
+## Output
+
+Summarize what you changed and why, grouped by file with `file:line` anchors:
+
+- **Simplified** — the edits applied (dedup / reuse / readability / dead-code), each with a one-line rationale.
+- **Left alone** — opportunities you deliberately skipped because they risked behavior, with the reason.
+- **Flagged for review** — any suspected bugs noticed in passing (not fixed here — quality pass only).
+- **Verification** — which checks you ran and that they pass.
+
+## Rules
+
+- **Behavior-preserving only.** No bug fixes, no feature changes, no API changes disguised as cleanup.
+- **Quality only** — if the only "simplification" would change behavior, don't make it.
+- **Tests must stay green.** A simplification that breaks a test is a behavior change — revert it.
+- If there is nothing worth simplifying, say so clearly rather than churning the code.

package/plugins/lisa-cursor/skills/parity-coderabbit/SKILL.md

@@ -0,0 +1,77 @@
+---
+name: parity-coderabbit
+description: "Thorough PR-style review of the full diff — bugs, security, performance, and maintainability — with concrete suggested fixes and a structured summary. An independent Lisa-native review skill that does NOT call CodeRabbit's service or port its code. Vendor-neutral cross-agent equivalent of the upstream coderabbit plugin, runnable on Codex, agy, Copilot, Cursor, and Claude."
+allowed-tools: ["Read", "Bash", "Grep", "Glob"]
+synced-from: coderabbit@claude-plugins-official@1.1.1
+---
+
+# Parity CodeRabbit
+
+A comprehensive, PR-grade code review of the **entire diff** — the kind of pass a senior reviewer (or an automated reviewer like CodeRabbit) gives before approving. Where `parity-code-review` is a tight defect hunt, this skill is **broad and thorough**: it covers bugs, security, performance, *and* maintainability, suggests concrete fixes, and ends with a reviewer-style summary and verdict.
+
+> **Independent reimplementation.** This skill is **not** a wrapper around CodeRabbit's hosted service and does **not** port or invoke CodeRabbit's code. It is a Lisa-native review that produces a comparable artifact using only the model and local tooling. No network calls to any review SaaS are made.
+>
+> **Drift tracking.** Pinned to `coderabbit@claude-plugins-official@1.1.1`. `scripts/plugin-parity-drift.mjs` compares this pin against the upstream version in the plugin cache and flags staleness. Reimplemented from scratch — **do not port or copy upstream plugin code.**
+
+## Step 1: Assemble the full review surface
+
+Gather the complete change set the way a PR review would see it:
+
+```bash
+# Full branch diff vs merge base
+BASE="$(git merge-base HEAD origin/main 2>/dev/null)"
+git diff "$BASE"...HEAD
+git diff "$BASE"...HEAD --stat        # file-by-file overview
+git log "$BASE"..HEAD --oneline       # commit narrative
+git diff HEAD                         # uncommitted work
+```
+
+Read the commit messages and (if available) the PR/ticket description to understand **intent** — a review judges the change against what it was meant to do, not just what it does.
+
+## Step 2: Build context per file
+
+For each changed file, `Read` the surrounding code and use `Grep`/`Glob` to follow callers, dependents, and tests. Note the change's blast radius: public API, shared modules, migrations, config, and anything downstream consumers rely on.
+
+## Step 3: Review across all dimensions
+
+Walk every meaningful hunk and evaluate each dimension. A finding in any dimension is fair game.
+
+1. **Correctness / bugs** — Logic errors, off-by-one, inverted conditions, missing `await`, null/undefined handling, type coercion, broken control flow, incorrect defaults, mutation of shared state, race conditions, broken or missing tests for new behavior.
+2. **Security** — Injection (SQL/shell/template), unsanitized boundary input, secrets/keys/tokens in code or logs, missing or broken authn/authz, unsafe deserialization, path traversal, SSRF, overly broad permissions, dependency vulnerabilities introduced by the change.
+3. **Performance** — N+1 queries, work inside hot loops, unnecessary allocations or re-renders, missing indexes, blocking I/O on hot paths, unbounded growth, accidental O(n²), redundant network/database round-trips, large bundle additions.
+4. **Maintainability** — Duplication, dead code, unclear naming, overly long/complex functions, missing or misleading docs, leaky abstractions, inconsistent patterns, hidden coupling, magic numbers, and violations of the project's conventions (immutability/functional style, statement order, barrel-export integrity, "never edit generated plugin artifacts").
+5. **Test coverage** — Are the new branches and edge cases tested? Do tests assert behavior rather than implementation? Are failure paths covered?
+
+## Step 4: Suggest concrete fixes
+
+For each finding, give a **specific, actionable** fix — ideally a short code sketch or a `diff`-style suggestion, not vague advice. The reader should be able to act on it without re-deriving the problem.
+
+## Step 5: Output — structured review
+
+Produce a review document with these sections:
+
+### Summary
+2–4 sentences: what the change does, overall quality, and the headline risks. State a verdict: **Approve**, **Approve with nits**, or **Request changes**.
+
+### Findings by severity
+Group as **Critical → Major → Minor → Nit**. Every finding includes:
+
+- **What** — the issue, and which dimension it falls under (bug / security / perf / maintainability / tests).
+- **Where** — `path/to/file.ts:line`.
+- **Why** — the concrete consequence, with a triggering example where relevant.
+- **Fix** — a concrete suggestion or code snippet.
+
+### Walkthrough (optional but encouraged)
+A brief per-file note on what changed and any file-specific observations — the orientation a human reviewer leaves so the next reader understands the diff quickly.
+
+### Strengths
+Call out what's done well. A credible review is balanced, not only critical.
+
+## Rules
+
+- **Cover the whole diff.** If you deprioritize anything for size, say which files and why — never imply full coverage you didn't give.
+- **Ground every finding in the code.** No generic checklists detached from the actual change; no speculative findings you can't point to.
+- **Concrete fixes only.** "Consider improving error handling" is not a finding; "wrap the `fetch` in try/catch and return a 502 on network error at `api/proxy.ts:31`" is.
+- **No external review service.** Use only local git/tooling and the model — this is an independent review, not a CodeRabbit proxy.
+- **Review-only.** Report findings; do not edit files. Route fixes through the implementation flow, `parity-code-simplifier` (quality), or a follow-up.
+- **If the diff is clean, approve it plainly** and say why — do not invent problems to look thorough.

package/plugins/lisa-cursor/skills/parity-safety-net-rules/SKILL.md

@@ -0,0 +1,144 @@
+---
+name: parity-safety-net-rules
+description: "View, set, and verify the custom guard rules enforced by Lisa's safety-net PreToolUse Bash hook (parity-safety-net.sh). The consolidated cross-agent equivalent of the upstream safety-net plugin's set-custom-rules + verify-custom-rules skills — manages a project-local list of extended-regex patterns that block destructive shell commands, on Codex, agy, Copilot, Cursor, and Claude."
+allowed-tools: ["Read", "Edit", "Write", "Bash"]
+synced-from: safety-net@cc-marketplace@0.9.0
+---
+
+# Parity Safety-Net Rules
+
+Manage the **custom guard rules** that Lisa's safety-net hook enforces on every
+Bash command. The hook (`hooks/parity-safety-net.sh`, registered as a
+`PreToolUse` matcher on `Bash`) ships with built-in guards against catastrophic
+commands; this skill lets a project **view**, **set**, and **verify** *additional*
+project-specific rules on top of those built-ins.
+
+> **Lisa-native reimplementation.** This consolidates the upstream
+> `safety-net@cc-marketplace` plugin's two rule-management skills
+> (`set-custom-rules` + `verify-custom-rules`) into one. It is reimplemented from
+> scratch against Lisa conventions — it does **not** port or invoke upstream
+> plugin code.
+>
+> **Drift tracking.** Pinned to `safety-net@cc-marketplace@0.9.0`.
+> `scripts/plugin-parity-drift.mjs` compares this pin against the upstream
+> version in the plugin cache and flags staleness. **Do not port or copy upstream
+> plugin code.**
+
+## How the rules work
+
+- The hook always enforces its **built-in guards** (see below). These cannot be
+  disabled from the rules file — they are the floor.
+- **Custom rules** live in a project-local file, one **POSIX extended regular
+  expression (ERE)** per line. Blank lines and lines beginning with `#` are
+  ignored. Matching is case-insensitive (`grep -Ei`).
+- If *any* built-in guard or custom rule matches the proposed command, the hook
+  exits non-zero and the Bash call is **blocked**, with the reason shown to the
+  agent.
+
+### Rules file location
+
+Resolved in this order:
+
+1. `$SAFETY_NET_RULES_FILE` (explicit override), else
+2. `${CLAUDE_PROJECT_DIR:-$PWD}/.claude/safety-net-rules.txt`
+
+```bash
+RULES_FILE="${SAFETY_NET_RULES_FILE:-${CLAUDE_PROJECT_DIR:-$PWD}/.claude/safety-net-rules.txt}"
+```
+
+### Built-in guards (always on)
+
+1. `rm -rf` of a filesystem root, `$HOME`/`~`, or a top-level wildcard.
+2. Force-pushing a protected branch (`main`/`master`/`production`/`release`).
+   `--force-with-lease` is intentionally allowed.
+3. `git reset --hard` while the working tree is **dirty** (would discard work).
+4. Destructive SQL — `DROP DATABASE/SCHEMA/TABLE`, `TRUNCATE TABLE`.
+
+## View the current rules
+
+```bash
+RULES_FILE="${SAFETY_NET_RULES_FILE:-${CLAUDE_PROJECT_DIR:-$PWD}/.claude/safety-net-rules.txt}"
+if [ -f "$RULES_FILE" ]; then
+  echo "Custom safety-net rules ($RULES_FILE):"
+  grep -vE '^[[:space:]]*(#|$)' "$RULES_FILE" || echo "(no active rules)"
+else
+  echo "No custom rules file yet ($RULES_FILE). Only built-in guards are active."
+fi
+```
+
+`Read` the file to show comments and structure as well.
+
+## Set (add or edit) a rule
+
+A rule is an ERE matched against the full command string. Keep rules **specific**
+to avoid blocking legitimate work — anchor on the dangerous verb and its target.
+
+1. Ensure the file exists, then **append** a commented rule (use `Edit`/`Write`,
+   or append from the shell):
+
+   ```bash
+   RULES_FILE="${SAFETY_NET_RULES_FILE:-${CLAUDE_PROJECT_DIR:-$PWD}/.claude/safety-net-rules.txt}"
+   mkdir -p "$(dirname "$RULES_FILE")"
+   {
+     echo "# Block deleting a Kubernetes namespace"
+     echo 'kubectl[[:space:]]+delete[[:space:]]+namespace'
+   } >> "$RULES_FILE"
+   ```
+
+2. **Always verify** the new rule (next section) before considering it set —
+   confirm it blocks what it should and allows what it shouldn't.
+
+Editing/removing: open the file with `Edit` and change or delete the line.
+Removing a rule never affects the built-in guards.
+
+## Verify the rules
+
+Two checks — both should pass before you trust a rule.
+
+### 1. The ERE is valid
+
+An invalid regex would make the hook error on every command. Validate it:
+
+```bash
+printf '%s' "$RULE" | grep -Eq -- "$RULE" 2>/dev/null && echo "valid ERE" \
+  || echo "INVALID ERE — fix before saving"
+```
+
+### 2. The rule behaves as intended
+
+Drive the **actual hook** with a fake `PreToolUse` payload and assert the exit
+code (non-zero = blocked, 0 = allowed). Build the JSON with `jq` so the test
+command line itself never contains the dangerous literal:
+
+```bash
+HOOK="${CLAUDE_PLUGIN_ROOT}/hooks/parity-safety-net.sh"
+
+check() { # check <expect: block|allow> <command>
+  jq -nc --arg c "$2" '{tool_name:"Bash",tool_input:{command:$c}}' \
+    | bash "$HOOK" >/dev/null 2>&1
+  local code=$?
+  local got=allow; [ "$code" -ne 0 ] && got=block
+  printf '%-5s want=%-5s got=%-5s  %s\n' \
+    "$([ "$got" = "$1" ] && echo OK || echo FAIL)" "$1" "$got" "$2"
+}
+
+# Should block (matches the new rule):
+check block "kubectl delete namespace prod"
+# Should allow (must not over-match):
+check allow "kubectl get pods"
+```
+
+Report a table of cases with want/got/verdict. If any case disagrees, tighten the
+ERE and re-verify.
+
+## Rules
+
+- **Built-in guards are the floor** — custom rules only *add* blocks; they cannot
+  weaken the built-ins.
+- **Prefer specific over broad** — a rule that blocks too much trains users to
+  bypass the safety net. Anchor on verb + target.
+- **Verify every rule against the real hook** before saving — never ship an
+  unverified or syntactically invalid ERE.
+- **Never weaken the net to unblock yourself.** If a built-in guard fires on a
+  command that is genuinely safe, run it manually outside the agent after the
+  user confirms — do not edit the hook to remove the guard.