@codyswann/lisa 2.189.7 → 2.189.9

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

@@ -0,0 +1,76 @@
+---
+name: lisa-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/skills/lisa-parity-code-simplifier/agents/openai.yaml

@@ -0,0 +1,4 @@
+display_name: "Parity Code Simplifier"
+short_description: "Lisa-native, behavior-preserving simplification of recently-changed code"
+default_prompt:
+  - "Use $lisa-parity-code-simplifier: Lisa-native, behavior-preserving simplification of recently-changed code."

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

@@ -0,0 +1,77 @@
+---
+name: lisa-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/skills/lisa-parity-coderabbit/agents/openai.yaml

@@ -0,0 +1,4 @@
+display_name: "Parity Coderabbit"
+short_description: "Thorough PR-style review of the full diff — bugs, security, performance, and maintainability — with concrete suggested fixes and a…"
+default_prompt:
+  - "Use $lisa-parity-coderabbit: Thorough PR-style review of the full diff — bugs, security, performance, and maintainability — with concrete suggested fixes and a…."

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

@@ -0,0 +1,144 @@
+---
+name: lisa-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.

package/plugins/lisa/skills/lisa-parity-safety-net-rules/agents/openai.yaml

@@ -0,0 +1,4 @@
+display_name: "Parity Safety Net Rules"
+short_description: "View, set, and verify the custom guard rules enforced by Lisa's safety-net PreToolUse Bash hook (parity-safety-net.sh)"
+default_prompt:
+  - "Use $lisa-parity-safety-net-rules: View, set, and verify the custom guard rules enforced by Lisa's safety-net PreToolUse Bash hook (parity-safety-net.sh)."

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

@@ -0,0 +1,211 @@
+---
+name: lisa-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/lisa-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 $lisa-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/lisa-parity-sentry-seer/SKILL.md

@@ -0,0 +1,135 @@
+---
+name: lisa-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`.