@codyswann/lisa 2.127.0 → 2.128.0

package/plugins/lisa-agy/skills/parity-skill-creator/SKILL.md

@@ -0,0 +1,149 @@
+---
+name: parity-skill-creator
+description: "Author a new Lisa skill end-to-end — scaffold the SKILL.md frontmatter (name/description/allowed-tools), write the pass-through command, follow hyphen naming, place files under plugins/src/base, and rebuild plugins. Lisa-native reimplementation of the upstream skill-creator plugin. NO drift pin: upstream publishes no semver, so it is not drift-trackable."
+allowed-tools: ["Read", "Edit", "Write", "Bash"]
+---
+
+# Skill Creator
+
+Author a new, working Lisa skill (and its pass-through command) from a one-line
+description. This is the Lisa-native equivalent of the upstream
+`skill-creator@claude-plugins-official` plugin, reimplemented from scratch
+against Lisa's conventions so the same capability is available to the Codex,
+agy, and Copilot runtimes (Cursor reads `.claude-plugin/` natively).
+
+## Not drift-trackable
+
+This skill intentionally carries **no `synced-from` pin**. The upstream
+`skill-creator` plugin publishes **no semver** (its cache version resolves to
+`unknown`), so a `@unknown` pin would be unparseable and meaningless to
+`scripts/plugin-parity-drift.mjs`. **Drift is tracked manually** — re-review the
+upstream plugin by hand whenever the curated plugin set is refreshed. Do **not**
+add a `synced-from` line to skills generated by this skill unless they
+reimplement a semver-versioned upstream plugin.
+
+## When to use
+
+- A reusable workflow, checklist, or piece of domain knowledge keeps recurring
+  and deserves a named, invokable skill.
+- You are reimplementing an upstream third-party plugin command/skill for
+  cross-agent parity (see `analyze-plugin` / `implement-plugin-parity`).
+- The user asks to "create a skill", "add a command", or "scaffold a skill".
+
+If the knowledge is narrow or one-off, prefer a rule in `.claude/rules/` instead
+— skills are for broad, repeatable capabilities. When unsure whether content
+warrants a skill, run it past the `skill-evaluator` agent first.
+
+## Where skills live
+
+Lisa skills are **build output** for downstream projects. The source of truth is
+`plugins/src/`, never the generated `plugins/lisa*` artifacts:
+
+| Source directory | Builds artifact | Use for |
+| --- | --- | --- |
+| `plugins/src/base/` | `plugins/lisa` | Skills that ship to **every** stack |
+| `plugins/src/<stack>/` | `plugins/lisa-<stack>` | Stack-specific (typescript, expo, nestjs, cdk, harper-fabric, rails) |
+
+Lisa-repo-only skills (parity tooling, wiki ingestion, `lisa-*` meta-skills) live
+at the **root** `.claude/skills/` and `.claude/commands/`, NOT under
+`plugins/src` — they are not relevant to downstream projects. Decide placement
+first:
+
+- Ships to downstream projects → `plugins/src/base/skills/<name>/SKILL.md`
+- Only meaningful inside the Lisa monorepo → `.claude/skills/<name>/SKILL.md`
+
+## Naming
+
+- Use **hyphen-separated** names: `git-commit`, `tracker-write`,
+  `parity-sentry-seer`. No spaces, no camelCase, no underscores.
+- The directory name, the frontmatter `name`, and the command filename must all
+  match exactly.
+- Commands map to colon-separated UI names via directory nesting:
+  `commands/git/commit.md` → `/lisa:git:commit`; a flat
+  `commands/plan.md` → `/lisa:plan`.
+
+## SKILL.md frontmatter
+
+Skills support **only** these frontmatter keys (they do **not** support
+`argument-hint` or `$ARGUMENTS` substitution — those belong on the command):
+
+```yaml
+---
+name: my-skill                       # required — matches the directory name
+description: "One or two sentences."  # required — when to use + what it does
+allowed-tools: ["Read", "Edit", "Write", "Bash"]  # optional — least privilege
+synced-from: <plugin>@<marketplace>@<version>      # ONLY for semver upstream reimplementations
+---
+```
+
+- **`name`** — the hyphen identifier, byte-identical to the directory.
+- **`description`** — write it so the model knows *when* to reach for the skill,
+  not just what it does. Lead with the trigger. This is the single most
+  important field for discoverability.
+- **`allowed-tools`** — grant the minimum set. A read-only review skill needs no
+  `Write`/`Edit`. Omit the key entirely to inherit the caller's tools.
+- **`synced-from`** — add **only** when the skill reimplements an upstream plugin
+  that publishes a real semver. Grammar: `name@marketplace@version`
+  (e.g. `sentry@claude-plugins-official@1.0.0`). Omit for upstreams with no
+  semver (note that in the body instead, as this skill does).
+
+## The command pass-through pattern
+
+Every skill should have a thin command that is the user-facing entry point.
+Commands support `description`, `argument-hint`, and `$ARGUMENTS`; they delegate
+straight to the skill:
+
+```markdown
+---
+description: "Same human-facing summary as the skill, phrased for the picker."
+argument-hint: "<what the user should type after the command>"
+---
+
+Use the /lisa:my-skill skill to <do the thing>. $ARGUMENTS
+```
+
+The command carries the `argument-hint` and forwards `$ARGUMENTS`; the SKILL.md
+carries the actual logic. Keep the two descriptions consistent.
+
+## Scaffolding walkthrough
+
+1. **Decide placement** — downstream (`plugins/src/base`) vs. Lisa-only
+   (`.claude`). For base, both a skill and a command directory entry are needed.
+2. **Pick the name** — hyphenated, unique. Check it does not collide:
+   `ls plugins/src/base/skills/` and `ls plugins/src/base/commands/`.
+3. **Create the skill** at
+   `plugins/src/base/skills/<name>/SKILL.md` with the frontmatter above and a
+   body that follows house style — see `plugins/src/base/skills/quality-review/SKILL.md`
+   for the canonical shape (title, "When to use", numbered checklist/steps,
+   explicit "Rules"/"Output" sections). Write real, actionable guidance, not
+   TODOs.
+4. **Create the command** at `plugins/src/base/commands/<name>.md` (or a nested
+   `commands/<namespace>/<name>.md` for a colon-namespaced command) using the
+   pass-through template.
+5. **Rebuild the artifacts** so the generated plugins match source:
+   ```bash
+   bun run build:plugins
+   ```
+   Then commit **both** `plugins/src/...` and the regenerated `plugins/lisa*`.
+   The `🧩 Plugins Sync` CI check (and `bun run check:plugins` locally) fails if
+   artifacts drift from source — never hand-edit `plugins/lisa*`.
+6. **Verify discoverability** — confirm the skill appears in the skill list and
+   the command resolves to `/lisa:<name>`.
+
+## Body house style
+
+- Open with an `#` H1 title in Title Case.
+- Add a `## When to use` section that names the triggers.
+- Use numbered steps for procedures, checklists for review-style skills.
+- End with an explicit `## Rules` (hard constraints) and/or `## Output` section.
+- Write in plain, imperative English. Prefer concrete examples over abstraction.
+- Reference sibling skills by their hyphen name (e.g. "delegate to `git-commit`").
+
+## Rules
+
+- Never edit `plugins/lisa*` directly — edit `plugins/src/` and rebuild.
+- Skill frontmatter must not contain `argument-hint` or `$ARGUMENTS`.
+- The directory name, `name` field, and command filename must match exactly.
+- Add `synced-from` **only** for semver-versioned upstream reimplementations.
+- Do not include `/coding-philosophy` in task `skills` metadata — it auto-loads.
+- One skill, one responsibility. If a skill grows two jobs, split it.

package/plugins/lisa-agy/skills/repair-intake/SKILL.md

@@ -30,7 +30,7 @@ close-out** roles and moves work *unstuck* or *fully closed*:
   out) **and** the *intermediate-env* case (all children shipped to an env like `On Stg`, but the
   parent never advanced — including a parent left stranded in a status it should never carry).
 - **Stale-`ready` container** — a parent/container (open child work, or a childless
-  Epic/Story/Spike) wrongly carrying the build-ready role. This is a leaf-only-invariant violation
+  **Epic**) wrongly carrying the build-ready role. This is a leaf-only-invariant violation
   the build-intake claim gate deliberately leaves for a human; repair-intake reconciles it by
   rolling the parent up from its children (with an audit note), so a container never sits in `ready`
   indefinitely.
@@ -364,7 +364,7 @@ native-open / active / unresolved:
 
 ### Build parent rollup reconciliation (intermediate-env or terminal close-out)
 
-For each parent/container item (Epic, Story, Spike, Project, or any item with child work),
+For each parent/container item (an Epic, a Linear Project, or any item — of any type — with open child work),
 reconcile its lifecycle state with the roll-up of its children — **including the intermediate-env
 case**, not only fully-terminal close-out. This is the recovery-side complement to the forward
 rollup the `*-sync --rollup` skills perform; it catches a parent that was never rolled up (or was

package/plugins/lisa-agy/skills/tracker-build-intake/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: tracker-build-intake
-description: "Vendor-neutral wrapper for the build-queue scanner. Reads `tracker` from .lisa.config.json (default: jira) and dispatches to lisa:jira-build-intake (JQL/project-key queue), lisa:github-build-intake (GitHub repo queue keyed off the `status:ready` label), or lisa:linear-build-intake (Linear team queue keyed off the `status:ready` label). Every vendor scanner processes at most one eligible item per cycle and enforces the claim-time arm of the `leaf-only-lifecycle` rule — dispatch leaf work units only; move or safe-block a container with open child work (or a childless Epic/Story/Spike) that carries a stale build-ready role according to the vendor's lifecycle semantics. Counterpart to lisa:intake's PRD-side dispatchers."
+description: "Vendor-neutral wrapper for the build-queue scanner. Reads `tracker` from .lisa.config.json (default: jira) and dispatches to lisa:jira-build-intake (JQL/project-key queue), lisa:github-build-intake (GitHub repo queue keyed off the `status:ready` label), or lisa:linear-build-intake (Linear team queue keyed off the `status:ready` label). Every vendor scanner processes at most one eligible item per cycle and enforces the claim-time arm of the `leaf-only-lifecycle` rule — dispatch leaf work units only; move or safe-block a container with open child work (or a childless Epic) that carries a stale build-ready role according to the vendor's lifecycle semantics. Counterpart to lisa:intake's PRD-side dispatchers."
 allowed-tools: ["Skill", "Bash", "Read"]
 ---
 
@@ -26,8 +26,8 @@ The vendor scanners also own the terminal native-closure step from `leaf-only-li
 
 This shim is dispatch only — it does not reclassify or re-gate items — but the contract it forwards is part of the build-intake API, so it is documented here once and the three vendor scanners implement it identically. Per the vendor-neutral `leaf-only-lifecycle` rule, **build intake claims only independently implementable leaf work units**:
 
-- A **leaf work unit** (Bug, Task, Sub-task, Improvement with no open child work) is claimed and built.
-- A **container** — anything with open child work, or a childless Epic/Story/Spike — that still carries a stale build-ready role is **never dispatched**. The GitHub scanner moves it out of the pickup queue by replacing `status:ready` with `status:in-progress` and posting an idempotent lifecycle-repair comment; other vendor scanners skip or safe-block according to their native lifecycle semantics.
+- A **leaf work unit** (Bug, Task, Sub-task, Improvement, or a childless Story/Spike — anything with no open child work except an Epic) is claimed and built.
+- A **container** — anything with open child work, or a childless Epic — that still carries a stale build-ready role is **never dispatched**. The GitHub scanner moves it out of the pickup queue by replacing `status:ready` with `status:in-progress` and posting an idempotent lifecycle-repair comment; other vendor scanners skip or safe-block according to their native lifecycle semantics.
 
 This is the claim-time arm of the rule. Its siblings are the write-time labeling (`lisa:tracker-write` → the vendor `*-write-*` skills apply build-ready to leaves only) and the validate-time S15 gate (`lisa:tracker-validate` → the vendor `*-validate-*` skills FAIL a build-ready container). All three arms cite `leaf-only-lifecycle` so no vendor drifts. Each vendor scanner implements the gate against its own hierarchy:
 
@@ -59,6 +59,6 @@ Intermediate env states are not native closure. A vendor scanner that resolves `
 
 - Single cycle per invocation — the vendor skill processes at most one eligible `Ready` item and exits. Scheduler repetition works the rest of the queue.
 - The vendor skills run their own pre-flight checks (JIRA workflow transitions for the JIRA path; label namespace adoption for the GitHub and Linear paths) before processing items. Never bypass.
-- **Leaf-only dispatch, every vendor.** Per the `leaf-only-lifecycle` rule, each vendor scanner dispatches leaf work units only and moves or safe-blocks a container (open child work, or a childless Epic/Story/Spike) carrying a stale build-ready role according to its lifecycle semantics. This shim does not re-implement the gate — it relies on the vendor scanner's Phase 3a — but the contract is uniform across `jira`, `github`, and `linear` so behavior never drifts by tracker.
+- **Leaf-only dispatch, every vendor.** Per the `leaf-only-lifecycle` rule, each vendor scanner dispatches leaf work units only and moves or safe-blocks a container (open child work, or a childless Epic) carrying a stale build-ready role according to its lifecycle semantics. This shim does not re-implement the gate — it relies on the vendor scanner's Phase 3a — but the contract is uniform across `jira`, `github`, and `linear` so behavior never drifts by tracker.
 - **Terminal native closure, every capable vendor.** Per the same rule, each vendor scanner finalizes native open/closed state only at the true terminal `done` value. This shim never performs native closure itself, but callers can rely on the dispatched vendor scanner to apply the contract.
 - Never run two intake cycles concurrently against overlapping queues — the scheduling layer is responsible for serialization.

package/plugins/lisa-cdk/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.127.0",
+  "version": "2.128.0",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-cdk/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.127.0",
+  "version": "2.128.0",
   "description": "AWS CDK-specific Lisa plugin.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-cdk-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.127.0",
+  "version": "2.128.0",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-cdk-copilot/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.127.0",
+  "version": "2.128.0",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-cdk-cursor/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.127.0",
+  "version": "2.128.0",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-copilot/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa",
-  "version": "2.127.0",
+  "version": "2.128.0",
   "description": "Universal governance — agents, skills, commands, hooks, and rules for all projects",
   "author": {
     "name": "Cody Swann"
@@ -13,6 +13,10 @@
           {
             "type": "command",
             "command": "${CLAUDE_PLUGIN_ROOT}/hooks/block-no-verify.sh"
+          },
+          {
+            "type": "command",
+            "command": "${CLAUDE_PLUGIN_ROOT}/hooks/parity-safety-net.sh"
           }
         ]
       }

package/plugins/lisa-copilot/commands/parity-code-review.md

@@ -0,0 +1,6 @@
+---
+description: "Lisa-native code review of the current git diff — correctness bugs, security issues, and obvious defects, reported as severity-ranked findings with file:line references. Vendor-neutral cross-agent equivalent of the upstream code-review command."
+argument-hint: "[optional: path or scope hint]"
+---
+
+Use the /lisa:parity-code-review skill to review the current branch and working-tree diff for correctness bugs, security issues, and obvious defects, and report findings ranked by severity with file:line references. $ARGUMENTS

package/plugins/lisa-copilot/commands/parity-code-simplifier.md

@@ -0,0 +1,6 @@
+---
+description: "Behavior-preserving simplification of recently-changed code — dedup, reuse, readability, and dead-code removal, quality only (never a bug hunt). Vendor-neutral cross-agent equivalent of the upstream code-simplifier agent."
+argument-hint: "[optional: path or scope hint]"
+---
+
+Use the /lisa:parity-code-simplifier skill to simplify the recently-changed code — removing duplication and dead code, reusing existing utilities, and improving readability — without altering behavior, then verify tests still pass. $ARGUMENTS

package/plugins/lisa-copilot/commands/parity-coderabbit.md

@@ -0,0 +1,6 @@
+---
+description: "Thorough PR-style review of the full diff — bugs, security, performance, and maintainability — with concrete fixes and a structured summary. An independent Lisa-native review (does NOT call CodeRabbit's service); vendor-neutral cross-agent equivalent of the upstream coderabbit plugin."
+argument-hint: "[optional: PR number, path, or scope hint]"
+---
+
+Use the /lisa:parity-coderabbit skill to run a thorough PR-style review of the full diff — flagging bugs, security, performance, and maintainability issues with concrete suggested fixes — and produce a structured summary with a verdict. $ARGUMENTS

package/plugins/lisa-copilot/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-copilot/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-copilot/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-copilot/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-copilot/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-copilot/rules/eager/base-rules.md

@@ -43,7 +43,7 @@ Do not begin work if there are blockers, ambiguities, access requirements, or un
 - Read **all** comments on a ticket, not just the description.
 - When clarifying, comment via ADF and @mention the Reporter.
 - Establish issue link relationships (`blocks`, `is blocked by`, `relates to`) — search git history AND Jira before declaring "no related work."
-- Single-repo invariant: Bug/Task/Sub-task MUST be single-repo. Epic/Story/Spike MAY span repos. Cross-repo leaves are split per the `repo-scope-split` rule.
+- Single-repo invariant: Bug/Task/Sub-task/Improvement (and any childless Story/Spike — a leaf per `leaf-only-lifecycle`) MUST be single-repo. An Epic, or any Story/Spike that still holds child work, MAY span repos. Cross-repo leaves are split per the `repo-scope-split` rule.
 - Pre-flight gate: BLOCK + reassign-to-Reporter if a ticket is missing target backend env, sign-in credentials, Gherkin acceptance criteria, epic parent (non-bug/non-epic), or relationship discovery evidence.
 
 ## Pace

package/plugins/lisa-copilot/rules/eager/leaf-only-lifecycle.md

@@ -2,7 +2,7 @@
 
 **Build-ready means a directly implementable leaf work unit.** Containers never carry build-ready.
 
-A leaf is structurally defined: **no child work** AND a leaf-typed item (Bug, Task, Sub-task, Improvement). A container is a parent with children — Epic, Story, Spike, or any item that has acquired sub-items.
+A leaf is structurally defined: **no open children** AND not an Epic — the by-design leaf types (Bug, Task, Sub-task, Improvement) plus a childless Story or Spike. A container is an **Epic**, or any item of any type that has acquired open child work.
 
 ## Invariant
 
@@ -12,10 +12,10 @@ A leaf is structurally defined: **no child work** AND a leaf-typed item (Bug, Ta
 
 ## Childless-parent exception
 
-A container *type* with no children is structurally a leaf — and may be build-ready iff its type is itself a leaf type:
+A childless item is structurally a leaf — and may be build-ready **unless its type is Epic**:
 
-- **Task or Bug with no children** → leaf → may be build-ready.
-- **Epic, Story, or Spike with no children** → still NOT build-ready. These are coordination containers by design; an empty one is incomplete decomposition. Repair: decompose into leaves, or reclassify to a leaf type.
+- **Task, Bug, Story, Spike, or Improvement with no children** → leaf → may be build-ready. A Story ships directly as one increment and a Spike *is* the investigation unit; neither needs sub-items to be implementable, so a childless one must not be stranded.
+- **Epic with no children** → still NOT build-ready. An Epic is a pure rollup container by design — its body is a high-level summary, never directly implementable — so a childless build-ready Epic is an incomplete decomposition or a mis-applied role. Repair: decompose into leaves, or reclassify to a leaf type.
 
 ## Parent state rollup (priority order, first match wins)
 

package/plugins/lisa-copilot/rules/eager/repo-scope-split.md

@@ -1,6 +1,6 @@
 # Repo Scope & Work-Time Splitting (load-bearing)
 
-**Leaf work units are single-repo.** A leaf is an individually implementable ticket with no children — types **Bug, Task, Sub-task, Improvement**. Each names exactly one repo. **Epic, Story, Spike** are coordination containers and may span repos.
+**Leaf work units are single-repo.** A leaf is an individually implementable ticket with no open children — the by-design leaf types **Bug, Task, Sub-task, Improvement**, plus a childless **Story** or **Spike** (structurally a leaf per `leaf-only-lifecycle`). Each names exactly one repo. An **Epic**, and any **Story/Spike that still holds child work**, are coordination containers and may span repos.
 
 Enforced at four points: gate **S10** (`*-validate-*`, write time), `task-decomposition` step 1.5 (PRD-decomposition time), claim-time repo scoping (`*-build-intake`), and the work-time split procedure (an existing ticket about to be implemented).
 

package/plugins/lisa-copilot/rules/reference/config-resolution.md

@@ -647,7 +647,7 @@ A ticketing system can oversee **multiple repos** — e.g. one JIRA project (or
 
 ### The `repo:<name>` label (the repo marker)
 
-A work item's target repo is recorded as a **label** `repo:<name>`, where `<name>` is the repo's short name (e.g. `repo:frontend`). The convention is uniform across trackers (JIRA / GitHub / Linear), consistent with the other namespaced labels (`status:`, `type:`, `component:`). On JIRA a **component** equal to the repo name is accepted as an alias (matches the legacy `component = "frontend"` JQL pattern). A leaf work unit carries **exactly one** `repo:<name>` (leaves are single-repo per `repo-scope-split`); a container (Epic/Story/Spike) may carry several or none.
+A work item's target repo is recorded as a **label** `repo:<name>`, where `<name>` is the repo's short name (e.g. `repo:frontend`). The convention is uniform across trackers (JIRA / GitHub / Linear), consistent with the other namespaced labels (`status:`, `type:`, `component:`). On JIRA a **component** equal to the repo name is accepted as an alias (matches the legacy `component = "frontend"` JQL pattern). A leaf work unit carries **exactly one** `repo:<name>` (leaves are single-repo per `repo-scope-split`); a container (an Epic, or any item with open child work) may carry several or none.
 
 The label is not required to exist up front: build-intake **determines** the target repo from the ticket's content + code surfaces when the label is absent and **stamps** `repo:<name>` so later cycles filter cheaply (see `repo-scope-split` "claim-time repo scoping").
 

package/plugins/lisa-copilot/rules/reference/leaf-only-lifecycle.md

@@ -16,16 +16,16 @@ The fix is not vendor-specific. It belongs here, in a cross-vendor rule, and eve
 
 ## Container vs. leaf taxonomy
 
-A **leaf work unit** is an individually implementable item with **no child work** — issue types **Bug, Task, Sub-task, Improvement**. These are what an agent claims and implements. This is the same definition used by the `repo-scope-split` rule (a leaf work unit is also single-repo).
+A **leaf work unit** is an individually implementable item with **no open child work**. Structurally, that is *any work item with no open children except an Epic*: the by-design leaf types **Bug, Task, Sub-task, Improvement**, plus a **childless Story or Spike** (a Story is a directly shippable increment and a Spike is itself the investigation unit — neither needs sub-items to be implementable). These are what an agent claims and implements. A leaf work unit is also single-repo (the `repo-scope-split` rule).
 
 A **container** organizes other work and is never directly implemented:
 
 | Class | Examples by type | May carry build-ready? |
 |---|---|---|
-| **Leaf work unit** | Bug, Task, Sub-task, Improvement — with no children | **Yes** |
-| **Container** | Epic, Story, Spike, or *any* item that has child work | **No** — state rolls up from children |
+| **Leaf work unit** | Bug, Task, Sub-task, Improvement, or a childless Story / Spike — anything with no open children **except an Epic** | **Yes** |
+| **Container** | An **Epic**, or *any* item (of any type) that has open child work | **No** — state rolls up from children |
 
-The classification is **structural, not nominal**: an item is a container if it has child work, regardless of its declared type. A "Task" that has acquired sub-tasks is a container for rollup purposes. The type label is a strong default (Epic/Story/Spike are containers by design), but the presence of children is decisive. See the childless-parent exception below for the converse case.
+The classification is **structural, not nominal**: an item is a container if it has open child work, regardless of its declared type. A "Task" that has acquired sub-tasks is a container for rollup purposes. The single nominal exception is the **Epic**, which is a pure rollup container by design and is treated as a container even when childless; for every other type the presence of children is decisive. See the childless-parent exception below for the converse case.
 
 ### How each vendor encodes hierarchy
 
@@ -49,12 +49,12 @@ The permission boundary is the maintainer-applied build-ready role, not authorsh
 
 ## Childless-parent exception
 
-A container *type* with **no child work** is, structurally, a leaf — and may be build-ready **iff its issue type is itself a valid leaf work unit**.
+A childless item is, structurally, a leaf — and may be build-ready **unless its issue type is Epic**.
 
-- A **Task** or **Bug** with no children → leaf → may be build-ready. (Many real tickets are flat Tasks with no sub-tasks; this rule must not strand them.)
-- An **Epic, Story, or Spike** with no children → still **not** build-ready. These types are coordination containers by design; an empty one is an incomplete decomposition, not an implementable unit. The correct repair is to decompose it (add leaf children) or reclassify it to a leaf type — not to claim it.
+- A **Task, Bug, Story, Spike,** or **Improvement** with no children → leaf → may be build-ready. Many real tickets are flat Tasks with no sub-tasks; just as common, a **Story** is implemented directly as a single shippable increment and a **Spike** *is* the investigation work unit. None of these need to be decomposed to be claimable, and this rule must not strand them. (A childless Story/Spike promoted to a leaf this way is single-repo like any other leaf — see `repo-scope-split`.)
+- An **Epic** with no children → still **not** build-ready. An Epic is a pure rollup container by design: its body is a high-level summary, never a directly implementable unit, so a childless Epic carrying the build-ready role is an incomplete decomposition or a mis-applied role — not work. The correct repair is to decompose it (add leaf children) or reclassify it to a leaf type — not to claim it.
 
-So the exception is narrow: childlessness *enables* build-ready only for types that are leaf work units to begin with. It never promotes an Epic/Story/Spike to directly implementable.
+So the exception is narrow only at the top: childlessness promotes every type **except Epic** to a build-ready leaf. A childless Epic is never directly implementable; everything else, when childless, is.
 
 ## Parent status rollup (the state machine)
 
@@ -112,7 +112,7 @@ This action is **terminal-only**:
 Skills that enforce this invariant or perform rollup cite this rule by slug (the `leaf-only-lifecycle` rule) instead of restating it:
 
 - **Decomposition / write** (`*-to-tracker`, `*-write-*`) — apply the `ready` role to leaves only; never to containers.
-- **Validate** (`*-validate-*`) — FAIL a container carrying the build-ready role; FAIL a childless Epic/Story/Spike marked build-ready.
+- **Validate** (`*-validate-*`) — FAIL a container carrying the build-ready role; FAIL a childless **Epic** marked build-ready (a childless Story/Spike is a valid leaf and passes).
 - **Build intake** (`*-build-intake`, `tracker-build-intake`) — dispatch leaves only; move or safe-block containers with stale build-ready roles according to vendor lifecycle semantics.
 - **Rollup** — derive parent state from children per the state machine above. `repair-intake`
   also uses this rule to close out parent/container rollups that were left open after every

package/plugins/lisa-copilot/rules/reference/repo-scope-split.md

@@ -1,6 +1,6 @@
 # Repo Scope & Work-Time Splitting
 
-Leaf work units are single-repo. A **leaf work unit** is an individually implementable ticket with no child tickets — issue types **Bug, Task, Sub-task, Improvement**. Each must name exactly one repository. **Epic, Story, Spike** are coordination containers and may span repos.
+Leaf work units are single-repo. A **leaf work unit** is an individually implementable ticket with no open child tickets — the by-design leaf types **Bug, Task, Sub-task, Improvement**, plus a childless **Story** or **Spike** (a childless Story/Spike is structurally a leaf — see `leaf-only-lifecycle`). Each must name exactly one repository. An **Epic**, and any **Story or Spike that still holds child work**, are coordination containers and may span repos.
 
 This invariant is enforced at four points: gate **S10** in the `*-validate-*` skills (write time), `task-decomposition` step 1.5 (PRD-decomposition time), **claim-time repo scoping** in the build-intake skills (when intake decides whether to claim a ready ticket for the current repo — see below), and the work-time split procedure below (when an agent picks up an existing ticket to implement it).
 
@@ -47,7 +47,7 @@ Resolve the current repo per the `config-resolution` "Repo scoping" section (con
 
 **Cost.** Only **unlabeled** candidates need content determination; once stamped, wrong-repo candidates are skipped by label alone. Prefer candidates already labeled `repo:<current>` first (cheap claim), falling through to unlabeled candidates (determine + stamp) only when no pre-labeled current-repo leaf is ready.
 
-A container (Epic/Story/Spike) is handled by the leaf-only gate, not here — containers may span repos, may keep multiple `repo:<name>` labels for visibility, and are never claimed/built directly. Only a leaf work unit is split or skipped by repo scope.
+A container (an Epic, or any item with open child work) is handled by the leaf-only gate, not here — containers may span repos, may keep multiple `repo:<name>` labels for visibility, and are never claimed/built directly. Only a leaf work unit — including a now-childless Story/Spike that the leaf-only gate treats as a leaf — is split or skipped by repo scope.
 
 ## Vendor mechanics
 

package/plugins/lisa-copilot/skills/github-build-intake/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: github-build-intake
-description: "GitHub counterpart to lisa:jira-build-intake. Scans a GitHub repository for issues carrying the configured `ready` build label, processes the first eligible issue, runs leaf work via lisa:github-agent, relabels to the configured `done` label on completion, then exits. Enforces the claim-time arm of the `leaf-only-lifecycle` rule: a parent/container with open child work (or a childless Epic/Story/Spike) that still carries a stale build-ready label is moved out of the ready pickup queue into the configured `claimed` label with a lifecycle-repair comment, never dispatched to lisa:github-agent. The `ready` label is the human-flipped signal that an issue is truly ready for direct development pickup — mirroring how Notion PRDs work product Draft → Ready → (us) In Review → Blocked|Ticketed."
+description: "GitHub counterpart to lisa:jira-build-intake. Scans a GitHub repository for issues carrying the configured `ready` build label, processes the first eligible issue, runs leaf work via lisa:github-agent, relabels to the configured `done` label on completion, then exits. Enforces the claim-time arm of the `leaf-only-lifecycle` rule: a parent/container with open child work (or a childless Epic) that still carries a stale build-ready label is moved out of the ready pickup queue into the configured `claimed` label with a lifecycle-repair comment, never dispatched to lisa:github-agent. The `ready` label is the human-flipped signal that an issue is truly ready for direct development pickup — mirroring how Notion PRDs work product Draft → Ready → (us) In Review → Blocked|Ticketed."
 allowed-tools: ["Skill", "Bash"]
 ---
 
@@ -209,16 +209,16 @@ Classify and act (first match wins). `type:` is read from the issue's labels (`t
 | Condition | Class | Action |
 |---|---|---|
 | `OPEN_CHILDREN > 0` (open child work, any type) | **Container** | **Move to `$CLAIMED` as lifecycle repair — do NOT dispatch** |
-| no open children AND `type ∈ {Epic, Story, Spike}` | **Childless container-type** | **Move to `$CLAIMED` as lifecycle repair — do NOT dispatch** |
-| no open children AND `type ∈ {Bug, Task, Sub-task, Improvement}` (or no `type:` label) | **Leaf work unit** | **Proceed to 3b claim** |
+| no open children AND `type = Epic` | **Childless Epic (pure rollup container)** | **Move to `$CLAIMED` as lifecycle repair — do NOT dispatch** |
+| no open children AND `type ≠ Epic` (Bug, Task, Sub-task, Improvement, Story, Spike, or no `type:` label) | **Leaf work unit** | **Proceed to 3b claim** |
 
-The childless-parent exception is narrow: childlessness enables direct build-agent dispatch **only** for types that are leaf work units to begin with. A childless Epic/Story/Spike is an incomplete decomposition, not an implementable unit — it is moved out of the ready pickup queue for repair/rollup and never dispatched.
+The childless-parent exception promotes every childless type **except Epic** to a dispatchable leaf: a childless Story is a directly shippable increment and a childless Spike *is* the investigation unit, so neither is stranded. Only a childless **Epic** is held back — an Epic is a pure rollup container by design, and a childless one is an incomplete decomposition or a mis-applied role, moved out of the ready pickup queue for repair/rollup and never dispatched.
 
 **Lifecycle repair (default action for a flagged container).** Move the issue out of the pickup queue by removing `$READY` and adding `$CLAIMED`, post a single lifecycle-repair comment, and record the issue under "Repaired (container)" in the summary. Do NOT invoke `lisa:github-agent`. Keep the comment idempotent — skip posting if an identical `[claude-build-intake]` lifecycle-repair comment already exists on the issue, so a re-entrant cycle doesn't spam it.
 
 ```bash
 gh issue edit <number> --repo <org>/<repo> --remove-label "$READY" --add-label "$CLAIMED"
-gh issue comment <number> --repo <org>/<repo> --body "[claude-build-intake] Lifecycle repair: this issue carried the build-ready role ($READY) but is a parent/container with open child work (or a childless Epic/Story/Spike). I moved it to $CLAIMED without invoking the build agent. For parent/container issues, $CLAIMED means rollup/build-lane progress through child/leaf work; direct implementation must happen on leaf issues. Build-ready is leaf-only per leaf-only-lifecycle — move $READY onto its leaf children, or decompose/reclassify a childless Epic/Story/Spike."
+gh issue comment <number> --repo <org>/<repo> --body "[claude-build-intake] Lifecycle repair: this issue carried the build-ready role ($READY) but is a parent/container with open child work (or a childless Epic). I moved it to $CLAIMED without invoking the build agent. For parent/container issues, $CLAIMED means rollup/build-lane progress through child/leaf work; direct implementation must happen on leaf issues. Build-ready is leaf-only per leaf-only-lifecycle — move $READY onto its leaf children, or decompose/reclassify a childless Epic."
 ```
 
 This gate never blocks a legitimate flat Task/Bug: those have no open children and a leaf `type:`, so they fall straight through to the claim in 3b.
@@ -326,7 +326,7 @@ Total PRs opened: <n>
 
 ## Idempotency & safety
 
-- **Leaf-only claim gate runs first**: Phase 3a classifies each candidate before any leaf claim; a container with open child work (or a childless Epic/Story/Spike) is moved `$READY` → `$CLAIMED` as lifecycle repair and never dispatched. The lifecycle-repair comment is idempotent — a re-entrant cycle does not re-post it.
+- **Leaf-only claim gate runs first**: Phase 3a classifies each candidate before any leaf claim; a container with open child work (or a childless Epic) is moved `$READY` → `$CLAIMED` as lifecycle repair and never dispatched. The lifecycle-repair comment is idempotent — a re-entrant cycle does not re-post it.
 - **Dependency hold runs before leaf claim**: explicit `Blocked by:` relationships are resolved after container repair is ruled out but before `$READY → $CLAIMED`; active blockers leave the leaf candidate in `$READY` and are reported as skipped, not blocked.
 - **Claim-first ordering**: `$CLAIMED` set BEFORE `lisa:github-agent` invocation for leaves; containers are also moved to `$CLAIMED` to leave the ready pickup queue, but are not dispatched.
 - **No writes outside the lifecycle**: this skill only relabels `$READY → $CLAIMED` and `$CLAIMED → $DONE`. For containers, `$READY → $CLAIMED` is a lifecycle repair, not a direct build claim. Every other label change is owned by `lisa:github-agent`.
@@ -351,7 +351,7 @@ If the repo has not adopted the `status:*` label namespace, this skill cannot ru
 
 ## Rules
 
-- **Dispatch leaves only.** Per the `leaf-only-lifecycle` rule, never dispatch a container — an issue with open child work, or a childless Epic/Story/Spike — even if it carries the build-ready role. Move it `$READY → $CLAIMED` as lifecycle repair (Phase 3a); never silently implement a container.
+- **Dispatch leaves only.** Per the `leaf-only-lifecycle` rule, never dispatch a container — an issue with open child work, or a childless Epic — even if it carries the build-ready role. Move it `$READY → $CLAIMED` as lifecycle repair (Phase 3a); never silently implement a container.
 - Never relabel an issue outside the cycle's allowed transitions. The `$CLAIMED` label is the signature of cycle ownership for leaves, and the parent/container progress state for lifecycle repairs.
 - Never bypass `lisa:github-agent` to do build work directly. `lisa:github-agent` owns the per-issue lifecycle.
 - Never auto-transition past `$DONE`. Downstream labels (terminal `status:done`, etc.) are owned by QA / PM / merge automation.