@codyswann/lisa 2.127.1 → 2.128.1

package/plugins/lisa-cursor/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-cursor/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-cursor/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-cursor/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-cursor/hooks/hooks.json

@@ -5,6 +5,10 @@
       {
         "command": "${CURSOR_PLUGIN_ROOT}/hooks/block-no-verify.sh",
         "matcher": "Bash"
+      },
+      {
+        "command": "${CURSOR_PLUGIN_ROOT}/hooks/parity-safety-net.sh",
+        "matcher": "Bash"
       }
     ],
     "sessionStart": [

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

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

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

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

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

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

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

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

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

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