@codyswann/lisa 4.4.1 → 4.4.3

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

@@ -1,263 +0,0 @@
----
-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@1.0.6
----
-
-# 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.** Upstream 0.9.0 shipped two rule-management
-> skills (`set-custom-rules` + `verify-custom-rules`), which this skill
-> consolidates. Upstream 1.0.6 consolidated them too (into `cc-safety-net`) and
-> moved custom rules to a JSON rulebook system driven by the
-> `npx cc-safety-net rule` CLI. Lisa **deliberately keeps** its simpler
-> ERE-lines-file design: the Lisa hook must run identically on Codex, agy,
-> Copilot, Cursor, and Claude without an npx dependency, and a flat regex file
-> is auditable in any of those runtimes. 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@1.0.6`.
-> `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.**
->
-> **2.0.3 review.** Upstream 2.0.2–2.0.3 added Kimi Code and Amp installation
-> support and release tooling. Those changes do not alter the upstream
-> rule-management skill or Lisa's project-local ERE rule contract, and Lisa does
-> not currently ship hooks for those runtimes, so no behavior is absorbed here.
->
-> **2.0.4 review.** Method, so the next person can re-run it rather than trust
-> it: hash the sorted (relative path, content) manifest of every rule-bearing
-> directory in the plugin cache under both versions, then diff the trees
-> excluding `dist/`, `.git/`, and `node_modules/`. Result — `src/` (230 files),
-> `skills/` (1), and `hooks/` (1) are byte-identical across 2.0.3 and 2.0.4
-> (`src` digest `7e346e205fbd1aa7` both sides). The only non-generated
-> differences are the `version` string in `package.json`, `kimi.plugin.json`,
-> and `.claude-plugin/plugin.json`, plus a test-harness fix in
-> `tests/cli/cli-statusline.test.ts` that tolerates EPIPE when an oversized
-> payload is flushed at the bounded reader's cap. Everything else is rebuilt
-> `dist/` output. No rule, guard family, or skill surface moved, so nothing is
-> absorbed here — and, critically, **2.0.4 does not close the gap recorded
-> below**, which therefore carries forward unchanged rather than being dropped
-> at the new pin.
->
-> **Known gap at the 2.0.4 pin.** Upstream 2.0.0 rebuilt its engine and added two
-> guard families this hook does **not** mirror: `secret.*` (blocks reading or
-> copying SSH keys, `.env` files, cloud credentials, and coding-CLI credential
-> stores) and `rm.git-metadata` (blocks deleting the `.git` control plane). Both
-> were measured against this hook rather than assumed — see the probe table in
-> `parity/plugin-routing/safety-net@cc-marketplace.md`. Absorbing `secret.*` also
-> needs a matcher change, because this hook is registered on `Bash` only while
-> upstream also screens file tools. That work is tracked separately in
-> `parity/FOLLOWUPS.md` §5; **do not treat this skill's built-in guard list as
-> covering secret access.**
-
-## 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 — with
-   quote-aware boundaries, so wrapper/interpreter forms like
-   `bash -c "rm -rf /"` and `python -c "… os.system('rm -rf /')"` match too.
-   Path-prefixed spellings (`/bin/rm`, `./rm`) count as `rm` for every rm
-   guard.
-2. `rm -rf` target hardening: the cwd itself (`.`/`./`), `..`-traversal paths,
-   home-anchored `~/…` paths, absolute paths outside the project (`/tmp`,
-   `/var/tmp`, and `$TMPDIR` are allowed), `$VAR` targets other than `$TMPDIR`,
-   and **any** recursive forced delete while the working directory is `$HOME`.
-3. Force-pushing a protected branch
-   (`main`/`master`/`production`/`prod`/`release`). `--force-with-lease` is
-   intentionally allowed, and so is force-pushing a feature branch (sanctioned
-   rebase workflow). Acceptable parity divergence: a refspec force-push
-   (`git push origin +main`) is not blocked — upstream 1.0.6 allows it too.
-4. `git reset --hard` / `git reset --merge` while the working tree is **dirty**
-   (would discard work). Clean-tree resets are intentionally allowed.
-5. `git rebase --abort` / `git rebase --quit` while the in-progress rebase
-   holds human-made conflict resolutions (they would be discarded). A clean or
-   untouched rebase state stays abortable — an agent-recoverable wedge; the
-   apply backend and a missing `AUTO_MERGE` ref fail closed. Deliberate
-   divergence: upstream blocks `rebase --abort` unconditionally.
-6. `git checkout` discards: the `--` pathspec form (with or without a ref),
-   `-f`/`--force`, `--pathspec-from-file`, and bare `git checkout .`.
-   Branch switching and `-b`/`-B` creation stay allowed.
-7. `git switch --discard-changes` / `-f`/`--force`.
-8. `git restore` touching the worktree — only `git restore --staged <path>`
-   without `--worktree` is allowed (unstaging is safe).
-9. `git stash drop` / `git stash clear` (push/pop/list/apply stay allowed).
-10. `git clean` with a force flag and no dry-run — `-n`/`--dry-run` anywhere
-    makes it a safe preview.
-11. `git branch -D` (or `-d` combined with `-f`, clustered or split);
-    safe `-d` and rename `-m` stay allowed.
-12. `git tag -d`, `git reflog delete`, `git worktree remove --force`.
-13. Deletion via `find … -delete`, `find … -exec rm -rf`, and `xargs … rm -rf`
-    (plain non-recursive `rm` on find/xargs output stays allowed).
-14. Disk destroyers: `dd of=/dev/…`, `mkfs … /dev/…`, `shred`.
-15. Destructive SQL — `DROP DATABASE/SCHEMA/TABLE`, `TRUNCATE TABLE`.
-
-Every git guard sees through leading git **global options** (`-C <path>`,
-`-c <k>=<v>`, `--git-dir[=…]`, `--no-pager`, …), so `git -C /path <destructive>`
-is screened the same as `git <destructive>`.
-
-Malformed hook input fails **closed** (exit 2 denies the command). A text-scan
-hook cannot exempt display commands, so prose like
-`echo "docs about rm -rf /"` can false-positive — quote-break the string or use
-the gh-writer heredoc form (payload is stripped before the guards run). For the
-same reason the rm guard treats substitution-wrapping as verdict-neutral (issue
-#1982): an executable `echo "$(rm -rf /)"` is blocked, and so are inert twins the
-shell would never expand — a single-quoted `echo '$(rm -rf /)'` or an escaped
-`echo "\$(rm -rf /)"` — since the scan has no quote-context awareness. The same
-quote-break or heredoc workaround applies. Spell that heredoc workaround with a
-**quote-pair** delimiter (`gh issue create --body-file - <<'EOF'`) — only that
-spelling reaches the payload-strip path. `<<"EOF"` and `<<\EOF` do not, and a
-`gh … <<\EOF` writer now fails closed instead.
-
-## What this does and does not defend against
-
-Read this before treating the safety net as a wall.
-
-**What it is for:** stopping *accidental* catastrophic commands — an agent (or a
-human) that reaches for `rm -rf /`, force-pushes `main`, drops a table, or writes
-to a raw device by mistake. Within that job the guards above are the floor and
-they are always on.
-
-**What it is not:** a security boundary against a deliberate adversary. Two
-structural reasons, both accepted rather than open bugs:
-
-- **It is a text scan, not a shell engine.** It has no quote-context awareness,
-  which produces the false positives described above and means an operation
-  spelled in a way the patterns do not anticipate is not matched.
-- **The here-doc classifier re-implements bash's lexer in Python** to decide
-  which payload text is inert data. Every divergence from real bash is a shape it
-  mis-classifies. Eight distinct divergences were found and fixed across issues
-  #1958 and #1993; the class is open-ended, so it is now closed as an accepted
-  limitation rather than chased indefinitely.
-
-**Why that is tolerable:** a here-doc mis-classification degrades to the content
-guards rather than bypassing them. Only the narrow `gh issue|pr` writer form ever
-strips payload text; every other path passes the **raw** command to the guards,
-and since issue #1982 those guards see through substitution wrappers. So a
-mis-read here-doc costs no guard coverage for any destructive class listed above.
-
-**The honest bottom line:** an agent that is actively trying to run something
-destructive has many paths that never involve a here-doc at all — the safety net
-does not claim to close them. Do not rely on it as the only control over what an
-agent may execute; treat it as the last line of defence against mistakes, and
-keep the real boundary (credentials, permissions, environment isolation) outside
-the agent.
-
-## 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-cursor/commands/lisa/parity-safety-net-rules.md

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

@@ -1,263 +0,0 @@
----
-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@1.0.6
----
-
-# 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.** Upstream 0.9.0 shipped two rule-management
-> skills (`set-custom-rules` + `verify-custom-rules`), which this skill
-> consolidates. Upstream 1.0.6 consolidated them too (into `cc-safety-net`) and
-> moved custom rules to a JSON rulebook system driven by the
-> `npx cc-safety-net rule` CLI. Lisa **deliberately keeps** its simpler
-> ERE-lines-file design: the Lisa hook must run identically on Codex, agy,
-> Copilot, Cursor, and Claude without an npx dependency, and a flat regex file
-> is auditable in any of those runtimes. 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@1.0.6`.
-> `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.**
->
-> **2.0.3 review.** Upstream 2.0.2–2.0.3 added Kimi Code and Amp installation
-> support and release tooling. Those changes do not alter the upstream
-> rule-management skill or Lisa's project-local ERE rule contract, and Lisa does
-> not currently ship hooks for those runtimes, so no behavior is absorbed here.
->
-> **2.0.4 review.** Method, so the next person can re-run it rather than trust
-> it: hash the sorted (relative path, content) manifest of every rule-bearing
-> directory in the plugin cache under both versions, then diff the trees
-> excluding `dist/`, `.git/`, and `node_modules/`. Result — `src/` (230 files),
-> `skills/` (1), and `hooks/` (1) are byte-identical across 2.0.3 and 2.0.4
-> (`src` digest `7e346e205fbd1aa7` both sides). The only non-generated
-> differences are the `version` string in `package.json`, `kimi.plugin.json`,
-> and `.claude-plugin/plugin.json`, plus a test-harness fix in
-> `tests/cli/cli-statusline.test.ts` that tolerates EPIPE when an oversized
-> payload is flushed at the bounded reader's cap. Everything else is rebuilt
-> `dist/` output. No rule, guard family, or skill surface moved, so nothing is
-> absorbed here — and, critically, **2.0.4 does not close the gap recorded
-> below**, which therefore carries forward unchanged rather than being dropped
-> at the new pin.
->
-> **Known gap at the 2.0.4 pin.** Upstream 2.0.0 rebuilt its engine and added two
-> guard families this hook does **not** mirror: `secret.*` (blocks reading or
-> copying SSH keys, `.env` files, cloud credentials, and coding-CLI credential
-> stores) and `rm.git-metadata` (blocks deleting the `.git` control plane). Both
-> were measured against this hook rather than assumed — see the probe table in
-> `parity/plugin-routing/safety-net@cc-marketplace.md`. Absorbing `secret.*` also
-> needs a matcher change, because this hook is registered on `Bash` only while
-> upstream also screens file tools. That work is tracked separately in
-> `parity/FOLLOWUPS.md` §5; **do not treat this skill's built-in guard list as
-> covering secret access.**
-
-## 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 — with
-   quote-aware boundaries, so wrapper/interpreter forms like
-   `bash -c "rm -rf /"` and `python -c "… os.system('rm -rf /')"` match too.
-   Path-prefixed spellings (`/bin/rm`, `./rm`) count as `rm` for every rm
-   guard.
-2. `rm -rf` target hardening: the cwd itself (`.`/`./`), `..`-traversal paths,
-   home-anchored `~/…` paths, absolute paths outside the project (`/tmp`,
-   `/var/tmp`, and `$TMPDIR` are allowed), `$VAR` targets other than `$TMPDIR`,
-   and **any** recursive forced delete while the working directory is `$HOME`.
-3. Force-pushing a protected branch
-   (`main`/`master`/`production`/`prod`/`release`). `--force-with-lease` is
-   intentionally allowed, and so is force-pushing a feature branch (sanctioned
-   rebase workflow). Acceptable parity divergence: a refspec force-push
-   (`git push origin +main`) is not blocked — upstream 1.0.6 allows it too.
-4. `git reset --hard` / `git reset --merge` while the working tree is **dirty**
-   (would discard work). Clean-tree resets are intentionally allowed.
-5. `git rebase --abort` / `git rebase --quit` while the in-progress rebase
-   holds human-made conflict resolutions (they would be discarded). A clean or
-   untouched rebase state stays abortable — an agent-recoverable wedge; the
-   apply backend and a missing `AUTO_MERGE` ref fail closed. Deliberate
-   divergence: upstream blocks `rebase --abort` unconditionally.
-6. `git checkout` discards: the `--` pathspec form (with or without a ref),
-   `-f`/`--force`, `--pathspec-from-file`, and bare `git checkout .`.
-   Branch switching and `-b`/`-B` creation stay allowed.
-7. `git switch --discard-changes` / `-f`/`--force`.
-8. `git restore` touching the worktree — only `git restore --staged <path>`
-   without `--worktree` is allowed (unstaging is safe).
-9. `git stash drop` / `git stash clear` (push/pop/list/apply stay allowed).
-10. `git clean` with a force flag and no dry-run — `-n`/`--dry-run` anywhere
-    makes it a safe preview.
-11. `git branch -D` (or `-d` combined with `-f`, clustered or split);
-    safe `-d` and rename `-m` stay allowed.
-12. `git tag -d`, `git reflog delete`, `git worktree remove --force`.
-13. Deletion via `find … -delete`, `find … -exec rm -rf`, and `xargs … rm -rf`
-    (plain non-recursive `rm` on find/xargs output stays allowed).
-14. Disk destroyers: `dd of=/dev/…`, `mkfs … /dev/…`, `shred`.
-15. Destructive SQL — `DROP DATABASE/SCHEMA/TABLE`, `TRUNCATE TABLE`.
-
-Every git guard sees through leading git **global options** (`-C <path>`,
-`-c <k>=<v>`, `--git-dir[=…]`, `--no-pager`, …), so `git -C /path <destructive>`
-is screened the same as `git <destructive>`.
-
-Malformed hook input fails **closed** (exit 2 denies the command). A text-scan
-hook cannot exempt display commands, so prose like
-`echo "docs about rm -rf /"` can false-positive — quote-break the string or use
-the gh-writer heredoc form (payload is stripped before the guards run). For the
-same reason the rm guard treats substitution-wrapping as verdict-neutral (issue
-#1982): an executable `echo "$(rm -rf /)"` is blocked, and so are inert twins the
-shell would never expand — a single-quoted `echo '$(rm -rf /)'` or an escaped
-`echo "\$(rm -rf /)"` — since the scan has no quote-context awareness. The same
-quote-break or heredoc workaround applies. Spell that heredoc workaround with a
-**quote-pair** delimiter (`gh issue create --body-file - <<'EOF'`) — only that
-spelling reaches the payload-strip path. `<<"EOF"` and `<<\EOF` do not, and a
-`gh … <<\EOF` writer now fails closed instead.
-
-## What this does and does not defend against
-
-Read this before treating the safety net as a wall.
-
-**What it is for:** stopping *accidental* catastrophic commands — an agent (or a
-human) that reaches for `rm -rf /`, force-pushes `main`, drops a table, or writes
-to a raw device by mistake. Within that job the guards above are the floor and
-they are always on.
-
-**What it is not:** a security boundary against a deliberate adversary. Two
-structural reasons, both accepted rather than open bugs:
-
-- **It is a text scan, not a shell engine.** It has no quote-context awareness,
-  which produces the false positives described above and means an operation
-  spelled in a way the patterns do not anticipate is not matched.
-- **The here-doc classifier re-implements bash's lexer in Python** to decide
-  which payload text is inert data. Every divergence from real bash is a shape it
-  mis-classifies. Eight distinct divergences were found and fixed across issues
-  #1958 and #1993; the class is open-ended, so it is now closed as an accepted
-  limitation rather than chased indefinitely.
-
-**Why that is tolerable:** a here-doc mis-classification degrades to the content
-guards rather than bypassing them. Only the narrow `gh issue|pr` writer form ever
-strips payload text; every other path passes the **raw** command to the guards,
-and since issue #1982 those guards see through substitution wrappers. So a
-mis-read here-doc costs no guard coverage for any destructive class listed above.
-
-**The honest bottom line:** an agent that is actively trying to run something
-destructive has many paths that never involve a here-doc at all — the safety net
-does not claim to close them. Do not rely on it as the only control over what an
-agent may execute; treat it as the last line of defence against mistakes, and
-keep the real boundary (credentials, permissions, environment isolation) outside
-the agent.
-
-## 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/src/base/commands/parity-safety-net-rules.md

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