@codyswann/lisa 2.127.1 → 2.128.1

package/plugins/lisa/skills/parity-sentry-sdk-setup/SKILL.md

@@ -0,0 +1,211 @@
+---
+name: parity-sentry-sdk-setup
+description: "Install and configure the Sentry SDK for a project — detect the framework/runtime, add the correct @sentry/<framework> package, initialize the client, wire the DSN through env, enable error + performance monitoring, and set up source map upload for readable stack traces. One consolidated skill covering react, nextjs, node, nestjs, express, python, django, react-native, and more. Lisa-native reimplementation of Sentry's SDK-setup suite. Use when adding Sentry to a project or fixing an existing Sentry install."
+allowed-tools: ["Read", "Edit", "Write", "Bash"]
+synced-from: sentry@claude-plugins-official@1.0.0
+---
+
+# Sentry SDK Setup
+
+Detect a project's framework and runtime, then install and configure the correct
+Sentry SDK with sensible, production-ready defaults: client initialization, DSN
+via environment variable, error capture, performance/tracing, and source map
+upload so stack traces are readable.
+
+## Consolidation note
+
+The upstream `sentry@claude-plugins-official` plugin ships **~30 separate
+per-SDK setup skills** (one per framework/runtime). This **single** Lisa-native
+skill consolidates all of them: instead of one thin skill per SDK, it detects the
+framework and applies the matching case below. The behavior is reimplemented from
+scratch against Lisa conventions — it is **not** a translation of the upstream
+skills. Pinned to `sentry@claude-plugins-official@1.0.0` via `synced-from` so the
+parity drift detector tracks it as one unit.
+
+## Step 1 — Detect framework & runtime
+
+Inspect the project before choosing an SDK. Read `package.json`
+(dependencies/scripts), config files, and lockfiles:
+
+- `next` dependency or `next.config.*` → **Next.js**
+- `@nestjs/core` → **NestJS**
+- `react-native` / `expo` → **React Native / Expo**
+- `react` + a bundler (vite/webpack) without Next → **React (browser)**
+- `express` / `fastify` / `koa` and a Node entrypoint → **Node server**
+- `vue` / `@angular/core` / `svelte` → that browser framework
+- `pyproject.toml` / `requirements.txt`; `django`/`flask`/`fastapi` →
+  **Python** (and which web framework)
+- A plain Node library/CLI → **Node**
+
+If the runtime is genuinely ambiguous, ask which app to instrument rather than
+guessing. Respect the project's package manager (bun/npm/pnpm/yarn — match the
+lockfile) and module system (ESM vs CJS).
+
+## Step 2 — Install the package
+
+Use the project's package manager. Examples (swap `bun add` for your manager):
+
+| Framework | Package |
+| --- | --- |
+| React (browser) | `@sentry/react` |
+| Next.js | `@sentry/nextjs` |
+| Node / Express / Fastify | `@sentry/node` (+ `@sentry/profiling-node` for profiling) |
+| NestJS | `@sentry/nestjs` (+ `@sentry/node`) |
+| React Native / Expo | `@sentry/react-native` |
+| Vue | `@sentry/vue` |
+| Angular | `@sentry/angular` |
+| Svelte / SvelteKit | `@sentry/svelte` / `@sentry/sveltekit` |
+| Python (generic) | `sentry-sdk` |
+| Django | `sentry-sdk[django]` |
+| Flask | `sentry-sdk[flask]` |
+| FastAPI | `sentry-sdk[fastapi]` |
+
+For Next.js, prefer the official wizard when available — it scaffolds the config
+files and source-map upload for you:
+
+```bash
+npx @sentry/wizard@latest -i nextjs
+```
+
+## Step 3 — Initialize the client
+
+Initialize **as early as possible** in the app's lifecycle, before other code
+runs. Always read the DSN from the environment (see Step 4) — never hard-code it.
+
+**React (browser)** — `src/instrument.ts`, imported first in the entrypoint:
+
+```ts
+import * as Sentry from "@sentry/react";
+
+Sentry.init({
+  dsn: import.meta.env.VITE_SENTRY_DSN,
+  environment: import.meta.env.MODE,
+  integrations: [Sentry.browserTracingIntegration()],
+  tracesSampleRate: 0.1, // tune per traffic; 1.0 in dev
+});
+```
+
+**Node / Express** — `instrument.ts`, required at the very top of the entrypoint
+(`import "./instrument";` must be the first import):
+
+```ts
+import * as Sentry from "@sentry/node";
+
+Sentry.init({
+  dsn: process.env.SENTRY_DSN,
+  environment: process.env.NODE_ENV,
+  tracesSampleRate: 0.1,
+});
+```
+
+Then, after routes are defined: `Sentry.setupExpressErrorHandler(app);`
+
+**NestJS** — import `./instrument` first in `main.ts`, then add Sentry's module:
+
+```ts
+// main.ts — FIRST line
+import "./instrument";
+// ...
+// app.module.ts
+import { SentryModule } from "@sentry/nestjs/setup";
+@Module({ imports: [SentryModule.forRoot()] })
+export class AppModule {}
+```
+
+**Next.js** — config lives in `sentry.client.config.ts`,
+`sentry.server.config.ts`, `sentry.edge.config.ts`, and `next.config.js` is
+wrapped with `withSentryConfig`. The wizard (Step 2) writes these; verify the DSN
+is read from `process.env.NEXT_PUBLIC_SENTRY_DSN` / `process.env.SENTRY_DSN`.
+
+**React Native / Expo** — wrap the root component:
+
+```ts
+import * as Sentry from "@sentry/react-native";
+Sentry.init({
+  dsn: process.env.EXPO_PUBLIC_SENTRY_DSN,
+  tracesSampleRate: 0.2,
+});
+export default Sentry.wrap(App);
+```
+
+**Python (Django/Flask/FastAPI/generic)** — initialize at startup
+(`settings.py`, app factory, or main module):
+
+```python
+import os
+import sentry_sdk
+
+sentry_sdk.init(
+    dsn=os.environ["SENTRY_DSN"],
+    environment=os.environ.get("ENVIRONMENT", "production"),
+    traces_sample_rate=0.1,
+    send_default_pii=False,
+)
+```
+
+Framework-specific integrations (e.g. `DjangoIntegration`, `FastApiIntegration`)
+are auto-enabled by the matching extra installed in Step 2.
+
+## Step 4 — DSN via environment
+
+- Store the DSN in an environment variable, never in committed source.
+- Add it to `.env.example` (with a placeholder) so the requirement is documented,
+  but keep the real value in `.env`/secrets and confirm `.env` is gitignored.
+- Use the framework's public-env convention for client-side code:
+  `NEXT_PUBLIC_SENTRY_DSN` (Next.js), `VITE_SENTRY_DSN` (Vite),
+  `EXPO_PUBLIC_SENTRY_DSN` (Expo). Server-only code uses `SENTRY_DSN`.
+- For source-map upload (Step 6) the build also needs `SENTRY_AUTH_TOKEN`,
+  `SENTRY_ORG`, and `SENTRY_PROJECT` — these are **build/CI** secrets, not
+  shipped to the client.
+
+## Step 5 — Error + performance monitoring
+
+- **Errors**: unhandled exceptions/rejections are captured automatically once
+  `init` runs; add the framework error handler where required (Express:
+  `setupExpressErrorHandler`; React: an error boundary via
+  `Sentry.ErrorBoundary`; NestJS: `SentryModule`). Use
+  `Sentry.captureException(err)` for caught-but-notable errors.
+- **Performance/tracing**: set a `tracesSampleRate` (start ~0.1 in production,
+  `1.0` in dev) and enable the framework tracing integration (browser tracing,
+  HTTP/DB auto-instrumentation on the server). Optionally add profiling on Node
+  via `@sentry/profiling-node` and `profilesSampleRate`.
+- Set `environment` and (ideally) `release` so issues are grouped per deploy.
+
+## Step 6 — Source maps (readable stack traces)
+
+Minified/transpiled traces are useless without source maps. Configure upload at
+build time:
+
+- **Next.js**: handled by `withSentryConfig` in `next.config.js` (the wizard sets
+  it up); ensure `SENTRY_AUTH_TOKEN`/`SENTRY_ORG`/`SENTRY_PROJECT` exist in CI.
+- **Vite/Webpack/Rollup/esbuild**: add the Sentry bundler plugin
+  (`@sentry/vite-plugin`, `@sentry/webpack-plugin`, etc.) with `sourcemaps`
+  upload enabled and the same auth env vars.
+- **Node**: build with source maps emitted and upload via
+  `sentry-cli sourcemaps upload` (or the bundler plugin) in the release step.
+- **React Native**: source maps upload through the Sentry Metro/Gradle/Xcode
+  integration added by the SDK's setup.
+- Tie uploads to a **release** identifier (commit SHA or version) and inject the
+  same release into `Sentry.init({ release })` so traces map to the right build.
+
+## Step 7 — Verify
+
+- Build/typecheck to confirm the SDK wiring compiles:
+  `bun run build` / `bun run typecheck` (or the project's equivalents).
+- Trigger a deliberate test error in a non-production environment and confirm it
+  appears in Sentry with a **readable** (source-mapped) stack trace.
+- Confirm a transaction/trace shows up to validate performance monitoring.
+- Remove the test error afterward.
+
+## Rules
+
+- **Do not port or copy upstream plugin code** — reimplement from scratch.
+- Never hard-code or commit a DSN or `SENTRY_AUTH_TOKEN`; route everything
+  through env/secrets and update `.env.example`.
+- Match the project's package manager and module system; do not introduce a new
+  one to install Sentry.
+- Initialize Sentry before any other application code runs.
+- Tune sample rates for the environment — do not ship `tracesSampleRate: 1.0` to
+  high-traffic production by default.
+- Verify with a real captured event and a source-mapped trace before declaring
+  setup complete.

package/plugins/lisa/skills/parity-sentry-sdk-setup/agents/openai.yaml

@@ -0,0 +1,4 @@
+display_name: "Parity Sentry SDK Setup"
+short_description: "Install and configure the Sentry SDK for a project — detect the framework/runtime, add the correct @sentry/<framework> package, initialize…"
+default_prompt:
+  - "Use $parity-sentry-sdk-setup: Install and configure the Sentry SDK for a project — detect the framework/runtime, add the correct @sentry/<framework> package, initialize…."

package/plugins/lisa/skills/parity-sentry-seer/SKILL.md

@@ -0,0 +1,135 @@
+---
+name: parity-sentry-seer
+description: "AI debugging — given an error message, stack trace, or failing test, analyze the signal, 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, available across all agent runtimes. Use when handed an exception, crash, regression, or red test and asked to find and fix the cause."
+allowed-tools: ["Read", "Grep", "Glob", "Bash", "Edit"]
+synced-from: sentry@claude-plugins-official@1.0.0
+---
+
+# Seer — AI Root-Cause Debugging
+
+Take a failure signal (exception, stack trace, failing test, log excerpt, or a
+Sentry issue) and drive it to a proven root cause and a proposed fix. This is the
+Lisa-native reimplementation of the upstream `sentry@claude-plugins-official`
+plugin's `seer` command, rebuilt from scratch so the AI-debugging workflow is
+available to the Codex, agy, and Copilot runtimes (Cursor loads upstream
+natively).
+
+> The Sentry MCP itself (for pulling live issue data) is re-pointed per agent
+> separately by the parity subsystem — this skill works **with or without** it.
+> When the MCP is connected, use it to fetch issue details, breadcrumbs, and
+> event context; when it is not, work from the error text the user pastes in.
+
+## Drift tracking
+
+Pinned to `sentry@claude-plugins-official@1.0.0` via `synced-from`. SDK install
+& configuration is a separate concern owned by `parity-sentry-sdk-setup`.
+
+## Inputs this handles
+
+- A raw stack trace or exception message.
+- A failing test (name + assertion output, or the command to reproduce it).
+- A log excerpt or error ID from CloudWatch / project logging.
+- A Sentry issue URL or ID (resolve via the Sentry MCP when available).
+
+If the signal is too thin to act on (no message, no location, not reproducible),
+ask for the one missing thing — the exact error text, the failing command, or a
+repro step — before guessing.
+
+## Workflow
+
+### 1. Capture & normalize the signal
+
+- Read the full error: type, message, and the **complete** stack trace.
+- Identify the **deepest frame that belongs to this codebase** (ignore
+  node_modules / stdlib frames) — that file:line is your primary anchor.
+- Note the runtime, environment, and any IDs (request id, user id, release).
+- If a Sentry issue is referenced and the MCP is connected, fetch the event,
+  breadcrumbs, tags, and first/last-seen + frequency.
+
+### 2. Reproduce (or pin down why you cannot)
+
+- For a failing test, run it in isolation and read the actual vs. expected:
+  ```bash
+  bun run test -- <test-file-or-pattern>
+  ```
+- For a runtime error, find the smallest command/route/input that triggers it.
+- A reliably reproduced failure is the strongest evidence; if it is flaky or
+  environment-only, say so explicitly and treat hypotheses as provisional.
+
+### 3. Form ranked hypotheses
+
+List 2–4 candidate causes, **most likely first**, each with the reasoning that
+makes it plausible and a concrete way to confirm or refute it. Common classes:
+
+- Null/undefined or unexpected shape reaching the failing frame.
+- Off-by-one / boundary / empty-collection edge case.
+- Async race, unawaited promise, or ordering assumption.
+- Contract drift — a caller and callee disagree after a recent change.
+- Bad input validation / unhandled external response.
+- Config/env divergence (works locally, fails in the target environment).
+
+### 4. Locate the root cause with evidence
+
+Walk the code to confirm or kill each hypothesis, highest-ranked first:
+
+- `Grep`/`Glob` for the failing symbol, message string, and the function in the
+  anchor frame; read the surrounding code, not just the one line.
+- Trace the data **backward** from the failure point to where the bad value
+  originates — the crash site is usually a symptom, not the cause.
+- Use `git log`/`git blame` on the anchor file to find a correlated recent change:
+  ```bash
+  git log -n 5 --oneline -- <path/to/anchor/file>
+  git blame -L <line>,<line> -- <path/to/anchor/file>
+  ```
+- When a value is uncertain, add a **temporary** strategic log/assert to confirm
+  the actual value, run, observe, then remove it. State the observed value as
+  evidence. (For deeper investigations, the `debug-specialist` agent owns
+  log-placement and CloudWatch tracing.)
+
+Stop when one hypothesis is **proven** — you can point to the exact line where
+the wrong value/behavior originates and explain the mechanism.
+
+### 5. Propose the fix
+
+- Describe the **minimal** change that addresses the root cause, not the symptom.
+- Prefer fixing where the bad value originates over masking it at the crash site.
+- Note any other call sites affected by the same root cause.
+- Recommend a regression test that would have caught it (a failing test that the
+  fix turns green) — pair with `reproduce-bug` / `tdd-implementation` to land it
+  TDD-style, and `codify-verification` to lock it in.
+- Do not silently broaden scope; if you spot adjacent issues, list them
+  separately as follow-ups.
+
+## Output
+
+Report in this shape:
+
+```
+## Signal
+<error type/message + anchor frame file:line + repro status>
+
+## Root cause
+<the proven cause, in plain English, with the mechanism>
+
+## Evidence
+- <file:line> — <what it shows>
+- <observed value / test output / blame commit> — <why it confirms the cause>
+
+## Proposed fix
+<minimal change, where, and why it addresses the cause not the symptom>
+
+## Regression test
+<the test that should be added to prevent recurrence>
+
+## Follow-ups (if any)
+<adjacent issues found but out of scope>
+```
+
+## Rules
+
+- **Do not port or copy upstream plugin code.** This is a native reimplementation.
+- Prove the cause before proposing a fix — no speculative "try changing this".
+- Cite concrete `file:line` evidence for every claim.
+- Remove any temporary debug logging you add before finishing.
+- Fix the root cause, not the symptom; flag, don't smuggle in, scope creep.
+- Never weaken a test to make it pass, and never use `--no-verify`.

package/plugins/lisa/skills/parity-sentry-seer/agents/openai.yaml

@@ -0,0 +1,4 @@
+display_name: "Parity Sentry Seer"
+short_description: "AI debugging — given an error message, stack trace, or failing test, analyze the signal, form ranked hypotheses, locate the root cause in…"
+default_prompt:
+  - "Use $parity-sentry-seer: AI debugging — given an error message, stack trace, or failing test, analyze the signal, form ranked hypotheses, locate the root cause in…."

package/plugins/lisa/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/skills/parity-skill-creator/agents/openai.yaml

@@ -0,0 +1,4 @@
+display_name: "Parity Skill Creator"
+short_description: "Author a new Lisa skill end-to-end — scaffold the SKILL.md frontmatter (name/description/allowed-tools), write the pass-through command…"
+default_prompt:
+  - "Use $parity-skill-creator: Author a new Lisa skill end-to-end — scaffold the SKILL.md frontmatter (name/description/allowed-tools), write the pass-through command…."

package/plugins/lisa-agy/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-agy/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-agy/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-agy/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-agy/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-agy/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-agy/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-agy/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"

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