@codyswann/lisa 2.127.1 → 2.128.1

package/plugins/lisa-agy/skills/parity-skill-creator/SKILL.md

@@ -0,0 +1,149 @@
+---
+name: parity-skill-creator
+description: "Author a new Lisa skill end-to-end — scaffold the SKILL.md frontmatter (name/description/allowed-tools), write the pass-through command, follow hyphen naming, place files under plugins/src/base, and rebuild plugins. Lisa-native reimplementation of the upstream skill-creator plugin. NO drift pin: upstream publishes no semver, so it is not drift-trackable."
+allowed-tools: ["Read", "Edit", "Write", "Bash"]
+---
+
+# Skill Creator
+
+Author a new, working Lisa skill (and its pass-through command) from a one-line
+description. This is the Lisa-native equivalent of the upstream
+`skill-creator@claude-plugins-official` plugin, reimplemented from scratch
+against Lisa's conventions so the same capability is available to the Codex,
+agy, and Copilot runtimes (Cursor reads `.claude-plugin/` natively).
+
+## Not drift-trackable
+
+This skill intentionally carries **no `synced-from` pin**. The upstream
+`skill-creator` plugin publishes **no semver** (its cache version resolves to
+`unknown`), so a `@unknown` pin would be unparseable and meaningless to
+`scripts/plugin-parity-drift.mjs`. **Drift is tracked manually** — re-review the
+upstream plugin by hand whenever the curated plugin set is refreshed. Do **not**
+add a `synced-from` line to skills generated by this skill unless they
+reimplement a semver-versioned upstream plugin.
+
+## When to use
+
+- A reusable workflow, checklist, or piece of domain knowledge keeps recurring
+  and deserves a named, invokable skill.
+- You are reimplementing an upstream third-party plugin command/skill for
+  cross-agent parity (see `analyze-plugin` / `implement-plugin-parity`).
+- The user asks to "create a skill", "add a command", or "scaffold a skill".
+
+If the knowledge is narrow or one-off, prefer a rule in `.claude/rules/` instead
+— skills are for broad, repeatable capabilities. When unsure whether content
+warrants a skill, run it past the `skill-evaluator` agent first.
+
+## Where skills live
+
+Lisa skills are **build output** for downstream projects. The source of truth is
+`plugins/src/`, never the generated `plugins/lisa*` artifacts:
+
+| Source directory | Builds artifact | Use for |
+| --- | --- | --- |
+| `plugins/src/base/` | `plugins/lisa` | Skills that ship to **every** stack |
+| `plugins/src/<stack>/` | `plugins/lisa-<stack>` | Stack-specific (typescript, expo, nestjs, cdk, harper-fabric, rails) |
+
+Lisa-repo-only skills (parity tooling, wiki ingestion, `lisa-*` meta-skills) live
+at the **root** `.claude/skills/` and `.claude/commands/`, NOT under
+`plugins/src` — they are not relevant to downstream projects. Decide placement
+first:
+
+- Ships to downstream projects → `plugins/src/base/skills/<name>/SKILL.md`
+- Only meaningful inside the Lisa monorepo → `.claude/skills/<name>/SKILL.md`
+
+## Naming
+
+- Use **hyphen-separated** names: `git-commit`, `tracker-write`,
+  `parity-sentry-seer`. No spaces, no camelCase, no underscores.
+- The directory name, the frontmatter `name`, and the command filename must all
+  match exactly.
+- Commands map to colon-separated UI names via directory nesting:
+  `commands/git/commit.md` → `/lisa:git:commit`; a flat
+  `commands/plan.md` → `/lisa:plan`.
+
+## SKILL.md frontmatter
+
+Skills support **only** these frontmatter keys (they do **not** support
+`argument-hint` or `$ARGUMENTS` substitution — those belong on the command):
+
+```yaml
+---
+name: my-skill                       # required — matches the directory name
+description: "One or two sentences."  # required — when to use + what it does
+allowed-tools: ["Read", "Edit", "Write", "Bash"]  # optional — least privilege
+synced-from: <plugin>@<marketplace>@<version>      # ONLY for semver upstream reimplementations
+---
+```
+
+- **`name`** — the hyphen identifier, byte-identical to the directory.
+- **`description`** — write it so the model knows *when* to reach for the skill,
+  not just what it does. Lead with the trigger. This is the single most
+  important field for discoverability.
+- **`allowed-tools`** — grant the minimum set. A read-only review skill needs no
+  `Write`/`Edit`. Omit the key entirely to inherit the caller's tools.
+- **`synced-from`** — add **only** when the skill reimplements an upstream plugin
+  that publishes a real semver. Grammar: `name@marketplace@version`
+  (e.g. `sentry@claude-plugins-official@1.0.0`). Omit for upstreams with no
+  semver (note that in the body instead, as this skill does).
+
+## The command pass-through pattern
+
+Every skill should have a thin command that is the user-facing entry point.
+Commands support `description`, `argument-hint`, and `$ARGUMENTS`; they delegate
+straight to the skill:
+
+```markdown
+---
+description: "Same human-facing summary as the skill, phrased for the picker."
+argument-hint: "<what the user should type after the command>"
+---
+
+Use the /lisa:my-skill skill to <do the thing>. $ARGUMENTS
+```
+
+The command carries the `argument-hint` and forwards `$ARGUMENTS`; the SKILL.md
+carries the actual logic. Keep the two descriptions consistent.
+
+## Scaffolding walkthrough
+
+1. **Decide placement** — downstream (`plugins/src/base`) vs. Lisa-only
+   (`.claude`). For base, both a skill and a command directory entry are needed.
+2. **Pick the name** — hyphenated, unique. Check it does not collide:
+   `ls plugins/src/base/skills/` and `ls plugins/src/base/commands/`.
+3. **Create the skill** at
+   `plugins/src/base/skills/<name>/SKILL.md` with the frontmatter above and a
+   body that follows house style — see `plugins/src/base/skills/quality-review/SKILL.md`
+   for the canonical shape (title, "When to use", numbered checklist/steps,
+   explicit "Rules"/"Output" sections). Write real, actionable guidance, not
+   TODOs.
+4. **Create the command** at `plugins/src/base/commands/<name>.md` (or a nested
+   `commands/<namespace>/<name>.md` for a colon-namespaced command) using the
+   pass-through template.
+5. **Rebuild the artifacts** so the generated plugins match source:
+   ```bash
+   bun run build:plugins
+   ```
+   Then commit **both** `plugins/src/...` and the regenerated `plugins/lisa*`.
+   The `🧩 Plugins Sync` CI check (and `bun run check:plugins` locally) fails if
+   artifacts drift from source — never hand-edit `plugins/lisa*`.
+6. **Verify discoverability** — confirm the skill appears in the skill list and
+   the command resolves to `/lisa:<name>`.
+
+## Body house style
+
+- Open with an `#` H1 title in Title Case.
+- Add a `## When to use` section that names the triggers.
+- Use numbered steps for procedures, checklists for review-style skills.
+- End with an explicit `## Rules` (hard constraints) and/or `## Output` section.
+- Write in plain, imperative English. Prefer concrete examples over abstraction.
+- Reference sibling skills by their hyphen name (e.g. "delegate to `git-commit`").
+
+## Rules
+
+- Never edit `plugins/lisa*` directly — edit `plugins/src/` and rebuild.
+- Skill frontmatter must not contain `argument-hint` or `$ARGUMENTS`.
+- The directory name, `name` field, and command filename must match exactly.
+- Add `synced-from` **only** for semver-versioned upstream reimplementations.
+- Do not include `/coding-philosophy` in task `skills` metadata — it auto-loads.
+- One skill, one responsibility. If a skill grows two jobs, split it.

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.127.1",
+  "version": "2.128.1",
   "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.127.1",
+  "version": "2.128.1",
   "description": "AWS CDK-specific Lisa plugin.",
   "author": {
     "name": "Cody Swann"

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

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

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

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

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

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

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa",
-  "version": "2.127.1",
+  "version": "2.128.1",
   "description": "Universal governance — agents, skills, commands, hooks, and rules for all projects",
   "author": {
     "name": "Cody Swann"
@@ -13,6 +13,10 @@
           {
             "type": "command",
             "command": "${CLAUDE_PLUGIN_ROOT}/hooks/block-no-verify.sh"
+          },
+          {
+            "type": "command",
+            "command": "${CLAUDE_PLUGIN_ROOT}/hooks/parity-safety-net.sh"
           }
         ]
       }

package/plugins/lisa-copilot/commands/parity-code-review.md

@@ -0,0 +1,6 @@
+---
+description: "Lisa-native code review of the current git diff — correctness bugs, security issues, and obvious defects, reported as severity-ranked findings with file:line references. Vendor-neutral cross-agent equivalent of the upstream code-review command."
+argument-hint: "[optional: path or scope hint]"
+---
+
+Use the /lisa:parity-code-review skill to review the current branch and working-tree diff for correctness bugs, security issues, and obvious defects, and report findings ranked by severity with file:line references. $ARGUMENTS

package/plugins/lisa-copilot/commands/parity-code-simplifier.md

@@ -0,0 +1,6 @@
+---
+description: "Behavior-preserving simplification of recently-changed code — dedup, reuse, readability, and dead-code removal, quality only (never a bug hunt). Vendor-neutral cross-agent equivalent of the upstream code-simplifier agent."
+argument-hint: "[optional: path or scope hint]"
+---
+
+Use the /lisa:parity-code-simplifier skill to simplify the recently-changed code — removing duplication and dead code, reusing existing utilities, and improving readability — without altering behavior, then verify tests still pass. $ARGUMENTS

package/plugins/lisa-copilot/commands/parity-coderabbit.md

@@ -0,0 +1,6 @@
+---
+description: "Thorough PR-style review of the full diff — bugs, security, performance, and maintainability — with concrete fixes and a structured summary. An independent Lisa-native review (does NOT call CodeRabbit's service); vendor-neutral cross-agent equivalent of the upstream coderabbit plugin."
+argument-hint: "[optional: PR number, path, or scope hint]"
+---
+
+Use the /lisa:parity-coderabbit skill to run a thorough PR-style review of the full diff — flagging bugs, security, performance, and maintainability issues with concrete suggested fixes — and produce a structured summary with a verdict. $ARGUMENTS

package/plugins/lisa-copilot/commands/parity-safety-net-rules.md

@@ -0,0 +1,6 @@
+---
+description: "View, set, and verify the custom guard rules enforced by Lisa's safety-net PreToolUse Bash hook — the cross-agent equivalent of the upstream safety-net plugin's set/verify-custom-rules skills."
+argument-hint: "[view | set <regex> | verify]"
+---
+
+Use the /lisa:parity-safety-net-rules skill to view, set, or verify the project-local custom guard rules enforced by Lisa's safety-net Bash hook (`parity-safety-net.sh`). $ARGUMENTS

package/plugins/lisa-copilot/commands/parity-sentry-sdk-setup.md

@@ -0,0 +1,6 @@
+---
+description: "Install and configure the Sentry SDK for a project — detect the framework, add the right @sentry/<framework> package, init the client, wire the DSN via env, enable error + performance monitoring, and set up source maps. One consolidated skill covering react, nextjs, node, nestjs, python, react-native, and more."
+argument-hint: "[framework override, e.g. nextjs | node | python] (auto-detected if omitted)"
+---
+
+Use the /lisa:parity-sentry-sdk-setup skill to detect the framework and install + configure the correct Sentry SDK with error and performance monitoring and source maps. $ARGUMENTS

package/plugins/lisa-copilot/commands/parity-sentry-seer.md

@@ -0,0 +1,6 @@
+---
+description: "AI debugging — given an error, stack trace, or failing test, analyze it, form ranked hypotheses, locate the root cause in the codebase with file:line evidence, and propose a minimal fix. Lisa-native reimplementation of Sentry's seer workflow."
+argument-hint: "<error message | stack trace | failing test | Sentry issue URL>"
+---
+
+Use the /lisa:parity-sentry-seer skill to root-cause the failure and propose an evidence-backed fix. $ARGUMENTS

package/plugins/lisa-copilot/commands/parity-skill-creator.md

@@ -0,0 +1,6 @@
+---
+description: "Author a new Lisa skill end-to-end — scaffold the SKILL.md frontmatter, write the pass-through command, follow hyphen naming and placement under plugins/src, and rebuild plugins. Lisa-native equivalent of the upstream skill-creator plugin."
+argument-hint: "<skill-name and a one-line description of what it should do>"
+---
+
+Use the /lisa:parity-skill-creator skill to scaffold a new Lisa skill and its pass-through command, following frontmatter, naming, placement, and build conventions. $ARGUMENTS

package/plugins/lisa-copilot/hooks/parity-safety-net.sh

@@ -0,0 +1,102 @@
+#!/usr/bin/env bash
+# PreToolUse hook for Bash: a safety net that blocks destructive shell commands
+# before they run. Lisa-native reimplementation of the upstream
+# `safety-net@cc-marketplace` plugin's PreToolUse Bash-guard (parity work, issue
+# #1059). It does NOT port upstream code — it re-expresses the behavior in Lisa's
+# hook conventions, modeled on block-no-verify.sh.
+#
+# It reads the hook stdin JSON, inspects the proposed Bash command, and EXITS
+# NON-ZERO (2) to BLOCK when a known-destructive pattern matches:
+#   - `rm -rf /` (recursive forced delete of a root / home / wildcard path)
+#   - force-pushing a protected branch (main/master/production/release)
+#   - `git reset --hard` while the working tree is dirty (would discard work)
+#   - dropping or truncating a database/schema/table
+# Otherwise it exits 0 and the command proceeds.
+#
+# Operators extend the built-in rules with a project-local rule file — one
+# extended-regex (ERE) per line, blank lines and `#` comments ignored — managed
+# by the parity-safety-net-rules skill. Default location (overridable via
+# SAFETY_NET_RULES_FILE):
+#   ${CLAUDE_PROJECT_DIR:-$PWD}/.claude/safety-net-rules.txt
+set -euo pipefail
+
+input="$(cat)"
+
+tool_name="$(printf '%s' "$input" | jq -r '.tool_name // empty')"
+if [ "$tool_name" != "Bash" ]; then
+  exit 0
+fi
+
+command_str="$(printf '%s' "$input" | jq -r '.tool_input.command // empty')"
+if [ -z "$command_str" ]; then
+  exit 0
+fi
+
+# block() prints the reason to stderr (surfaced to the model) and exits 2 so the
+# Bash tool call is denied. $1 = human-readable reason for the block.
+block() {
+  cat >&2 <<EOF
+Blocked by safety-net: $1
+
+This command matched a destructive-operation guard. If it is genuinely safe and
+intentional, ask the user to confirm, then run it manually outside the agent, or
+narrow the command so it no longer matches the guard.
+EOF
+  exit 2
+}
+
+# 1. Recursive forced delete (`rm -rf`) of a filesystem root, home, or top-level
+#    wildcard. Two gates ANDed: the command must invoke `rm` with BOTH a
+#    recursive and a force flag, AND name a catastrophic target. Splitting the
+#    flag check from the target check keeps each regex legible and testable.
+if printf '%s' "$command_str" \
+  | grep -Eiq '(^|[^[:alnum:]_./-])rm([[:space:]]+-[[:alnum:]-]+)*[[:space:]]+(-[[:alnum:]]*r[[:alnum:]]*f|-[[:alnum:]]*f[[:alnum:]]*r)([[:space:]]|$)' \
+  || printf '%s' "$command_str" \
+  | grep -Eiq '(^|[^[:alnum:]_./-])rm[[:space:]].*(-r\b.*[[:space:]]-f\b|-f\b.*[[:space:]]-r\b|--recursive\b.*--force\b|--force\b.*--recursive\b)'; then
+  if printf '%s' "$command_str" \
+    | grep -Eq '([[:space:]]|=)(/|/\*|/\.\*?|~|~/\*?|\$HOME\b|\$\{HOME\}|\*)([[:space:]]|/?\*?$)'; then
+    block "recursive forced delete of a root, home, or wildcard path (rm -rf)"
+  fi
+fi
+
+# 2. Force-pushing a protected branch. `--force-with-lease` is the safe,
+#    non-clobbering alternative and is intentionally NOT blocked.
+if printf '%s' "$command_str" | grep -Eiq '(^|[^[:alnum:]_-])git[[:space:]]+push\b'; then
+  if printf '%s' "$command_str" | grep -Eiq '(--force([[:space:]]|=|$)|[[:space:]]-f([[:space:]]|$))' \
+    && ! printf '%s' "$command_str" | grep -Eiq -- '--force-with-lease'; then
+    if printf '%s' "$command_str" | grep -Eiq '(^|[^[:alnum:]_/-])(main|master|production|prod|release)([^[:alnum:]_/-]|$)'; then
+      block "force-pushing a protected branch (use --force-with-lease, or push a feature branch)"
+    fi
+  fi
+fi
+
+# 3. `git reset --hard` while the working tree has uncommitted changes — this
+#    silently discards them. Only blocks when the tree is actually dirty, so a
+#    clean-tree reset (a legitimate workflow) still passes.
+if printf '%s' "$command_str" | grep -Eiq '(^|[^[:alnum:]_-])git[[:space:]]+reset\b.*--hard\b'; then
+  if git rev-parse --is-inside-work-tree >/dev/null 2>&1 \
+    && [ -n "$(git status --porcelain 2>/dev/null)" ]; then
+    block "git reset --hard on a dirty working tree would discard uncommitted changes (stash or commit first)"
+  fi
+fi
+
+# 4. Dropping or truncating a database / schema / table.
+if printf '%s' "$command_str" \
+  | grep -Eiq '\b(drop[[:space:]]+(database|schema|table)|truncate[[:space:]]+(table[[:space:]]+)?[[:alnum:]_."`]+)\b'; then
+  block "destructive SQL (DROP/TRUNCATE) detected"
+fi
+
+# 5. Project-local custom rules. Each non-comment line is an ERE; a match blocks.
+rules_file="${SAFETY_NET_RULES_FILE:-${CLAUDE_PROJECT_DIR:-$PWD}/.claude/safety-net-rules.txt}"
+if [ -f "$rules_file" ]; then
+  while IFS= read -r rule || [ -n "$rule" ]; do
+    case "$rule" in
+      '' | '#'*) continue ;;
+    esac
+    if printf '%s' "$command_str" | grep -Eiq -- "$rule"; then
+      block "matched a project custom safety rule (${rules_file##*/}): $rule"
+    fi
+  done <"$rules_file"
+fi
+
+exit 0

package/plugins/lisa-copilot/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-copilot/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-copilot/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.