@codyswann/lisa 2.189.6 → 2.189.8

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

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

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

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

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

package/plugins/lisa/skills/parity-coderabbit/agents/openai.yaml

@@ -1,4 +0,0 @@
-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 $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/parity-safety-net-rules/SKILL.md

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

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

@@ -1,4 +0,0 @@
-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 $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/parity-sentry-sdk-setup/SKILL.md

@@ -1,211 +0,0 @@
----
-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

@@ -1,4 +0,0 @@
-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

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