@codyswann/lisa 2.189.7 → 2.189.9

package/plugins/src/base/commands/lisa/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/src/base/commands/lisa/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/src/base/commands/lisa/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/src/base/commands/lisa/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/src/base/commands/lisa/plan.md

@@ -0,0 +1,6 @@
+---
+description: "Plan work from a single PRD or specification. Decomposes into ordered work items in the configured tracker (JIRA, GitHub Issues, or Linear per .lisa.config.json). Source can be a Notion / Confluence / Linear / GitHub Issue URL, a JIRA epic key, a markdown file, or a free-form description. For batch scanning of all Ready PRDs in a queue, use /lisa:intake instead."
+argument-hint: "<single-PRD-url | GitHub-issue-url | @file | ticket-id-or-url | description>"
+---
+
+Use the /lisa-plan skill to decompose the PRD/spec into ordered work items in the configured tracker. $ARGUMENTS

package/plugins/src/base/commands/lisa/plugin-sync-explain.md

@@ -0,0 +1,8 @@
+---
+description: "Explain plugin source/generated drift and marketplace registration gaps without modifying the working tree."
+argument-hint: "[path]"
+---
+
+Use the /lisa-plugin-sync-explain skill to inspect plugin source/generated synchronization for the current Lisa repo. $ARGUMENTS
+
+This command is read-only. It reports source-not-built edits, generated-only edits, marketplace registration drift, and the next source-first remediation step before an operator runs `bun run build:plugins` or `bun run check:plugins`.

package/plugins/src/base/commands/lisa/product-walkthrough.md

@@ -0,0 +1,7 @@
+---
+description: "Walk through the live product via a real browser (Playwright MCP) to ground PRD evaluation or ticket creation in what exists today. Captures current behavior, design-vs-product divergence, reuse candidates, and behavioral surprises."
+allowed-tools: ["Skill"]
+argument-hint: "<route or feature area to walk>"
+---
+
+Use the /lisa-product-walkthrough skill to walk through the live product, capture current state, and produce findings that ground PRD/ticket reasoning. $ARGUMENTS

package/plugins/src/base/commands/lisa/project-ideation.md

@@ -0,0 +1,6 @@
+---
+description: "Generate persona-grounded, verifiable product ideas for the host project, then create PRDs for the selected build-ready ideas via lisa-research. First derives the personas the project actually serves (from its docs, code, data model, and releases — never invented), ideates per persona, and gates each idea on an obtainable data/source path and an empirical verification plan. Creates one PRD by default (top-ranked idea); max_prds widens the batch. prd_ready=true creates them prd-ready for auto-pickup by lisa-intake; default is draft for human review."
+argument-hint: "[target path | external product] [prd_ready=true|false] [max_prds=<n>|all]"
+---
+
+Use the /lisa-project-ideation skill to derive evidence-grounded personas, ideate per persona, gate the ideas, and create PRDs for the selected build-ready ideas via lisa-research — in draft state by default, or prd-ready when prd_ready=true; one PRD by default, more with max_prds. $ARGUMENTS

package/plugins/src/base/commands/lisa/pull-request/review.md

@@ -0,0 +1,7 @@
+---
+description: "Address and resolve PR review comments (human + bot): implement valid feedback, reply to invalid, resolve every thread."
+allowed-tools: ["Skill"]
+argument-hint: "[github-pr-link-or-number]"
+---
+
+Use the /lisa-pull-request-review skill to address and resolve the code review feedback on a pull request — implement valid comments, reply to invalid ones, and resolve every thread via GraphQL. $ARGUMENTS

package/plugins/src/base/commands/lisa/queue-status.md

@@ -0,0 +1,34 @@
+---
+description: "Inspect the current project's PRD and build queues, summarize lifecycle counts, and surface actionable queue-health signals without mutating work."
+---
+
+Use the /lisa-queue-status skill to inspect the current project's configured PRD source and build tracker, report queue-health verdicts, and highlight actionable backlog or stuck-state signals. $ARGUMENTS
+
+Common operator usage:
+
+- `/lisa:queue-status`
+- `/lisa:queue-status queue=prd`
+- `/lisa:queue-status queue=build`
+
+Use this when you need to answer:
+
+- Is the queue actually idle, or is Lisa misconfigured?
+- Which queue item is the most actionable next?
+- Should the next command be `/lisa:intake`, `/lisa:repair-intake`, `/lisa:automation-status`, or `/lisa:verify-prd`?
+
+This surface is read-only in v1. Use it to understand whether the repo's PRD and build queues are idle, healthy, attention-needed, or misconfigured before deciding whether to run `/lisa:intake`, `/lisa:repair-intake`, `/lisa:automation-status`, `/lisa:verify-prd`, or deeper tracker-native investigation.
+
+Quick interpretation guide:
+
+- `IDLE`: the queue resolved correctly and nothing actionable is waiting. No immediate Lisa action is required.
+- `HEALTHY`: the queue resolved correctly and normal work is present. Follow the highlighted next step, usually `/lisa:intake`.
+- `ATTENTION_NEEDED`: blocked, stalled, or aging work needs operator follow-up. Use the highlighted item and remediation hint to choose the next command, usually `/lisa:repair-intake`.
+- `MISCONFIGURED`: queue resolution or lifecycle adoption is broken. Fix config, labels/statuses, or scheduler drift before trusting queue state.
+
+Highlighted-item semantics:
+
+- A highlighted item is the single oldest or most actionable queue item for that section, not a full dump of all matching work.
+- `ready` highlights usually point to `/lisa:intake`.
+- `blocked`, stalled, or long-claimed highlights usually point to `/lisa:repair-intake`.
+- Shipped PRD highlights usually point to `/lisa:verify-prd`.
+- If queue behavior looks wrong for both PRD and build lanes, inspect `/lisa:automation-status` before assuming the queue itself is the problem.

package/plugins/src/base/commands/lisa/repair-intake.md

@@ -0,0 +1,6 @@
+---
+description: "Repair counterpart to /lisa:intake. Vendor-agnostic batch scanner that finds stuck or half-closed work — items left in `blocked`, stalled in an in-progress role (build `claimed`, PRD `in_review`), terminal-labeled items still natively open, rollups whose children are all terminal, GitHub PRDs missing native child links, and GitHub issues missing official Lisa lifecycle labels — across the same queues /lisa:intake serves (Notion / Confluence / Linear / GitHub PRDs; JIRA / GitHub / Linear build issues). Repairs every materially actionable candidate inside the `max_candidates` cap: resumes stalled in-progress work in place — but for a stalled build it first diagnoses the PR/deploy state and, if the PR cannot merge (conflict, rebase, failing checks, unaddressed CodeRabbit/changes-requested) or a deploy failed, files a build-ready fix ticket and moves the item to `blocked` (blocked by it) instead of re-dispatching — re-validates blocked PRDs, re-dispatches blocked build items whose blockers have cleared, performs terminal native closure, repairs missing native GitHub PRD child links from generated-work fallback, reconciles parent rollups to their derived state (including the intermediate-env case — e.g. all children at `On Stg` → parent `On Stg` — and a container wrongly stuck in `ready`), normalizes missing GitHub lifecycle labels to the configured PRD/build `ready` label, and closes out completed rollups. Cron-safe and bounded; default GitHub intake_mode is both and default max_candidates is 100."
+argument-hint: "<Notion-PRD-database-URL | Confluence-space-URL | Confluence-parent-page-URL | Linear-workspace-URL | Linear-team-URL | GitHub-repo-URL | org/repo | JIRA-project-key | JQL-filter> [intake_mode=prd|build|both] [stale_after=2h] [max_candidates=100] [force=true]"
+---
+
+Use the /lisa-repair-intake skill to scan the queue for stuck or half-closed items, repair GitHub PRDs whose generated top-level work is missing native child links, normalize GitHub issues missing official Lisa lifecycle labels into the configured PRD/build `ready` lane, and repair every materially actionable candidate inside `max_candidates` (default 100). For GitHub queues, default `intake_mode` to `both` when the caller omits it. $ARGUMENTS

package/plugins/src/base/commands/lisa/research.md

@@ -0,0 +1,6 @@
+---
+description: "Research a problem space and create a PRD in the configured PRD source. Investigates the codebase, defines user flows, assesses technical feasibility, synthesizes the spec, then creates it in the source (Notion / Confluence / GitHub / Linear) via lisa-prd-source-write — no loose document. prd_ready=true creates it prd-ready for auto-pickup by lisa-intake; default is draft for the Plan flow / human review."
+argument-hint: "<problem-statement-or-feature-idea> [prd_ready=true|false]"
+---
+
+Use the /lisa-research skill to research the problem and create a PRD in the configured source — in draft state by default, or prd-ready when prd_ready=true. $ARGUMENTS

package/plugins/src/base/commands/lisa/review/local.md

@@ -0,0 +1,6 @@
+---
+description: "Review local branch changes compared to main"
+allowed-tools: ["Skill"]
+---
+
+Use the /lisa-review-local skill to review local changes.

package/plugins/src/base/commands/lisa/security/zap-scan.md

@@ -0,0 +1,6 @@
+---
+description: "Run an OWASP ZAP baseline security scan locally using Docker"
+allowed-tools: ["Skill"]
+---
+
+Use the /lisa-security-zap-scan skill to run an OWASP ZAP baseline security scan.

package/plugins/src/base/commands/lisa/setup/atlassian.md

@@ -0,0 +1,7 @@
+---
+description: "Set up Atlassian (cloudId + acli profile) for this project. Writes the `atlassian` section of `.lisa.config.json` and enables the Atlassian MCP and/or installs acli as needed. Prerequisite for /lisa:setup:jira and /lisa:setup:confluence."
+allowed-tools: ["Skill"]
+argument-hint: "[--site=<site>] [--email=<email>]"
+---
+
+Use the /lisa-setup-atlassian skill to configure Atlassian access for this project. $ARGUMENTS

package/plugins/src/base/commands/lisa/setup/confluence.md

@@ -0,0 +1,7 @@
+---
+description: "Set up Confluence as the PRD source for this project. Writes the `confluence` section of `.lisa.config.json` (spaceKey and/or parentPageId) and offers to set top-level `source: \"confluence\"`. Depends on /lisa:setup:atlassian."
+allowed-tools: ["Skill"]
+argument-hint: "[--space=<KEY>] [--parent=<pageId>]"
+---
+
+Use the /lisa-setup-confluence skill to configure Confluence as the PRD source. $ARGUMENTS

package/plugins/src/base/commands/lisa/setup/github.md

@@ -0,0 +1,7 @@
+---
+description: "Set up GitHub Issues as the tracker and/or PRD source for this project. Verifies the gh CLI, resolves org/repo, scaffolds the `status:*` (build) and/or `prd-*` (PRD) label namespaces, writes the `github` section of `.lisa.config.json`, and can document optional GitHub ProjectV2 coordination before offering top-level `tracker: \"github\"` / `source: \"github\"`. No /lisa:setup:atlassian prerequisite."
+allowed-tools: ["Skill"]
+argument-hint: "[--repo=<org/repo>]"
+---
+
+Use the /lisa-setup-github skill to configure GitHub as the tracker and/or PRD source. $ARGUMENTS

package/plugins/src/base/commands/lisa/setup/jira.md

@@ -0,0 +1,7 @@
+---
+description: "Set up JIRA as the tracker for this project. Writes `jira.project` and offers to set top-level `tracker: \"jira\"` in `.lisa.config.json`. Depends on /lisa:setup:atlassian (needs cloudId)."
+allowed-tools: ["Skill"]
+argument-hint: "[--project=<KEY>]"
+---
+
+Use the /lisa-setup-jira skill to configure JIRA as the project tracker. $ARGUMENTS

package/plugins/src/base/commands/lisa/setup/linear.md

@@ -0,0 +1,7 @@
+---
+description: "Set up Linear as the tracker and/or PRD source for this project. Verifies Linear access (MCP OAuth or a personal API key in keychain), resolves the workspace slug and team key, scaffolds the `status:*` issue-label (build) and/or `prd-*` project-label (PRD) namespaces, writes the `linear` section of `.lisa.config.json`, and offers to set top-level `tracker: \"linear\"` / `source: \"linear\"`. No /lisa:setup:atlassian prerequisite."
+allowed-tools: ["Skill"]
+argument-hint: "[--workspace=<slug>] [--team=<KEY>]"
+---
+
+Use the /lisa-setup-linear skill to configure Linear as the tracker and/or PRD source. $ARGUMENTS

package/plugins/src/base/commands/lisa/setup/notion.md

@@ -0,0 +1,7 @@
+---
+description: "Set up Notion as the PRD source for this project. Walks the user through creating a workspace-scoped internal-integration token, sharing the PRD database with it, and stores the token in OS keychain. Writes `notion.workspaceId`, `notion.prdDatabaseId`, and `notion.values` into `.lisa.config.json`. Offers to set top-level `source: \"notion\"`."
+allowed-tools: ["Skill"]
+argument-hint: "[--database=<uuid>] [--workspace=<slug>]"
+---
+
+Use the /lisa-setup-notion skill to configure Notion as the PRD source. $ARGUMENTS

package/plugins/src/base/commands/lisa/setup-automations.md

@@ -0,0 +1,6 @@
+---
+description: "Set up the recurring Lisa automations on the local workstation using the runtime's native scheduler (Codex automations / Claude /schedule): intake-repair (60 min), intake PRD (60 min), intake tickets (10 min), exploratory-bugs (daily), exploratory-prds (daily). A declarative spec — it states what to schedule and how often; the runtime's native automation mechanism does the creating. auto-start-prds / auto-start-tickets control whether ideated PRDs / filed bug tickets are created auto-pickup-ready (default: left for human review)."
+argument-hint: "[auto-start-prds=true|false] [auto-start-tickets=true|false]"
+---
+
+Use the /lisa-setup-automations skill to create the five recurring Lisa automations via this runtime's native scheduler (Codex automations / Claude /schedule), passing the auto-start-prds / auto-start-tickets flags through to the exploratory automations. $ARGUMENTS

package/plugins/src/base/commands/lisa/sync-down.md

@@ -0,0 +1,7 @@
+---
+description: "Back-sync an environment branch down the deploy chain (hotfix propagation) on demand"
+allowed-tools: ["Skill"]
+argument-hint: "[source-env-or-branch]"
+---
+
+Use the /lisa-sync-down skill to back-sync an environment branch down the deploy chain — deriving the source→target chain from `.lisa.config.json` `deploy.order` + `deploy.branches`, then merging, resolving conflicts, opening PRs, and enabling auto-merge for each downward hop. $ARGUMENTS

package/plugins/src/base/commands/lisa/tear-down-automations.md

@@ -0,0 +1,6 @@
+---
+description: "Remove the recurring Lisa automations /setup-automations created for this project (the lisa-auto-<project>-* set) using the runtime's native scheduler (Codex automations / Claude /schedule). A declarative spec — it states which automations to remove; the runtime's native mechanism does the removing. Removes only this project's Lisa automations, never others."
+argument-hint: ""
+---
+
+Use the /lisa-tear-down-automations skill to remove this project's lisa-auto-<project>-* automations via this runtime's native scheduler (Codex automations / Claude /schedule), leaving other projects' and non-Lisa automations untouched. $ARGUMENTS

package/plugins/src/base/commands/lisa/validate-tracker-mapping.md

@@ -0,0 +1,15 @@
+---
+description: "Detect (and optionally repair) drift between a project's configured Lisa status/label mappings and the live tracker/source workflow names. Read-only by default; repairs the config to canonical live names with repair=true. Audits the current repo or sweeps many via projects=/workspaces=."
+argument-hint: "[projects=<glob> | workspaces=<file> [filter=<substr>]] [lane=build|prd|both] [repair=true]"
+---
+
+Use the /lisa-validate-tracker-mapping skill to check whether the status/label names in `.lisa.config.json` still match the live tracker and PRD source — catching renames, deletions, and case drift (e.g. config `On Stg` vs live `ON STG`). Read-only by default; pass `repair=true` to rewrite the config to the canonical live names. $ARGUMENTS
+
+Common usage:
+
+- `/lisa:validate-tracker-mapping` — audit the current repo's mapping (read-only).
+- `/lisa:validate-tracker-mapping repair=true` — audit and repair config drift in the current repo.
+- `/lisa:validate-tracker-mapping projects=~/workspace/geminisportsai/projects/*` — sweep every Lisa project under a directory.
+- `/lisa:validate-tracker-mapping workspaces=~/workspace/lisa/.lisa.workspaces.json filter=geminisportsai` — sweep the projects in a workspaces file whose paths match a substring.
+
+Use this when you suspect a JIRA/GitHub/Linear/Notion status, label, or option was renamed or deleted out from under Lisa — the failure mode that leaves builds unable to find their completion transition and items silently stuck. Run it read-only (or on a schedule) to detect drift; run it with `repair=true` to fix the config. Repair only ever edits the config to match the live names — it never renames anything in the tracker.

package/plugins/src/base/commands/lisa/verify-prd.md

@@ -0,0 +1,6 @@
+---
+description: "Initiative-level PRD acceptance gate. Reads a shipped PRD and its generated child work, confirms all generated top-level work is terminal, then runs spec-conformance against the PRD plus empirical verification of the shipped surface. On a CONFORMS verdict with all checks passing it transitions the PRD shipped → verified with evidence; on a conformance miss (PARTIAL/DIVERGES) or any failing empirical check it re-opens the PRD shipped → ticketed (never blocked), creates build-ready fix tickets for the gaps, and posts a failure report — the fix tickets auto-build, the PRD re-ships, and it re-verifies (a self-healing loop). Idempotent across re-runs."
+argument-hint: "<prd>"
+---
+
+Use the /lisa-verify-prd skill to read the PRD, confirm its generated top-level work is terminal, run spec-conformance against the PRD and empirical verification of the shipped surface, then transition the PRD shipped → verified with evidence on a pass, or — on a fail — re-open it shipped → ticketed (never blocked) and create build-ready fix tickets that auto-build and trigger a re-verify. $ARGUMENTS

package/plugins/src/base/commands/lisa/verify.md

@@ -0,0 +1,6 @@
+---
+description: "Ship and verify code. Commits, opens PR, handles review loop, merges, monitors deploy, and runs remote verification in target environment. Folds in /ship."
+argument-hint: "[commit-message-hint]"
+---
+
+Use the /lisa-verify skill to commit, push, PR, merge, deploy, and verify in the target environment. $ARGUMENTS

package/plugins/src/base/commands/lisa/wiki/install.md

@@ -0,0 +1,7 @@
+---
+description: "Enable the LLM Wiki kernel (lisa-wiki plugin) in this project so its setup skill becomes discoverable. Edits .claude/settings.json to enable lisa-wiki@lisa and confirm the CodySwannGT/lisa marketplace, then verifies the Codex overlay (.codex/skills/lisa) already carries the wiki kernel. Does NOT scaffold the wiki itself — after install, reload the runtime and run /setup:wiki (Claude) or $lisa-wiki-setup (Codex)."
+allowed-tools: ["Skill"]
+argument-hint: ""
+---
+
+Use the /lisa-wiki-install skill to enable the lisa-wiki plugin in this project. $ARGUMENTS

package/plugins/src/base/hooks/enforce-team-first.sh

@@ -53,7 +53,7 @@ find "$STATE_DIR" -maxdepth 1 -type f -mmin +1440 -delete 2>/dev/null || true
 
 is_lifecycle_skill() {
   case "$1" in
-    lisa:research|lisa:plan|lisa:implement|lisa:intake|lisa:debrief) return 0 ;;
+    lisa-research|lisa-plan|lisa-implement|lisa-intake|lisa-debrief) return 0 ;;
     *) return 1 ;;
   esac
 }

package/plugins/src/base/hooks/enforce-verification-gate.sh

@@ -13,12 +13,12 @@
 #
 # Intentionally Claude-specific (like enforce-team-first.sh). Other harnesses
 # may not fire a Stop hook; they fall back to the prose completion gate in
-# skills/implement/SKILL.md.
+# skills/lisa-implement/SKILL.md.
 #
 # Triggered on four hook events:
 #   - UserPromptSubmit : arm enforcement when the prompt starts with
 #                        /lisa:implement (or /implement)
-#   - PreToolUse       : arm enforcement when the Skill tool loads lisa:implement
+#   - PreToolUse       : arm enforcement when the Skill tool loads lisa-implement
 #                        (covers nested/programmatic invocation, e.g. intake)
 #   - SubagentStart    : mark teammate sessions exempt — teammates inherit the
 #                        lead's flow and must not be gated on their own stop
@@ -105,7 +105,7 @@ case "$HOOK_EVENT" in
     if [ "$TOOL_NAME" = "Skill" ]; then
       SKILL_NAME=$(printf '%s' "$INPUT" | jq -r '.tool_input.skill // empty' 2>/dev/null || true)
       case "$SKILL_NAME" in
-        lisa:implement|implement)
+        lisa-implement|implement)
           arm_once
           ;;
       esac
@@ -198,7 +198,7 @@ fi
     echo "No verification verdict found at .lisa/verification-status.json."
     echo "The Verify flow must run the verification-specialist (run the actual"
     echo "system, observe results) and write a machine-readable verdict — schema"
-    echo "in skills/implement/SKILL.md — with status \"pass\" and every"
+    echo "in skills/lisa-implement/SKILL.md — with status \"pass\" and every"
     echo "acceptance criterion proven."
     echo
     echo "If you are stopping deliberately because of a blocker (readiness gate"

package/plugins/src/base/rules/eager/observability-audit.md

@@ -1,15 +1,15 @@
 # Observability Audit (load-bearing)
 
-The **audit + file** arm of `lisa:monitor`. On top of its existing live-signal sweep, `monitor` audits how well the **current repo** is instrumented and files build-ready tickets for what it finds. `monitor` is **manual** (no cron) and **files only** — it never fixes; the `intake` / `tracker-build-intake` cron implements what it files.
+The **audit + file** arm of `lisa-monitor`. On top of its existing live-signal sweep, `monitor` audits how well the **current repo** is instrumented and files build-ready tickets for what it finds. `monitor` is **manual** (no cron) and **files only** — it never fixes; the `intake` / `tracker-build-intake` cron implements what it files.
 
 ## Invariants
 
 - **Repo-scoped two ways.** Audit only the rubric dimensions in scope for the repo's detected profile (`frontend` / `backend` / `infra` — a frontend repo never evaluates backend tracing), and stamp every filed ticket `repo:<CURRENT_REPO>` as a single-repo leaf (resolve the repo via the `config-resolution` ladder; cannot resolve → report, do not file).
-- **Two finding types → build-ready leaves.** A live signal over the conservative bar → a `Bug` leaf; an in-scope MISSING instrumentation dimension (gap, e.g. "no DB/query analytics") → a `Task`/`Improvement` leaf. Always via `lisa:tracker-write` with `build_ready: true` (never a vendor write skill directly); never an Epic/container (gate S15).
+- **Two finding types → build-ready leaves.** A live signal over the conservative bar → a `Bug` leaf; an in-scope MISSING instrumentation dimension (gap, e.g. "no DB/query analytics") → a `Task`/`Improvement` leaf. Always via `lisa-tracker-write` with `build_ready: true` (never a vendor write skill directly); never an Epic/container (gate S15).
 - **Conservative by default.** Only high-signal anomalies (over the documented thresholds) and `core` missing dimensions are filed. `--all-gaps` widens gap filing to `recommended` tiers; nothing lowers the anomaly bar.
-- **Idempotent.** Every ticket carries a `<!-- lisa-monitor-finding: <fingerprint> -->` sentinel; search-before-create (including closed tickets) means a re-run never duplicates a live or just-resolved finding.
+- **Idempotent.** Every ticket carries a `<!-- lisa:monitor-finding: <fingerprint> -->` sentinel; search-before-create (including closed tickets) means a re-run never duplicates a live or just-resolved finding.
 - **Capped.** At most `monitor.maxCandidates` tickets per run (default 20), highest-severity first; report filed-vs-dropped (and list the dropped) — never silently truncate.
 - **Gate-passing.** Each ticket is a real authored artifact: three-audience description, Gherkin AC, single-repo, Target Backend Environment, and a Validation Journey with a unique kebab-case `[EVIDENCE: <name>]` marker — so `tracker-validate` (S1–S15) accepts it. A finding that cannot be made into a credible ticket is reported, not filed.
-- **Verify guard.** When `monitor` is the post-deploy step of `lisa:verify` it runs **report-only** — Verify invokes it as `lisa:monitor <env> --report-only`, so it never files there. Filing is a standalone-only action.
+- **Verify guard.** When `monitor` is the post-deploy step of `lisa-verify` it runs **report-only** — Verify invokes it as `lisa-monitor <env> --report-only`, so it never files there. Filing is a standalone-only action.
 
 Full reference (profile detection, the rubric table, anomaly thresholds, ticket templates, idempotency contract, the cap, dry-run/report-only semantics): [reference/observability-audit.md](../reference/observability-audit.md).

package/plugins/src/base/rules/eager/upstream-to-lisa.md

@@ -5,7 +5,7 @@ When working in a project that has Lisa installed, you will sometimes find that
 When that happens, you have **two obligations — do both**:
 
 1. **Fix it locally so you are not blocked.** Apply the stopgap in this project so you can keep working. Treat it as temporary: it will be clobbered when the upstream fix ships and Lisa re-applies. Do not wait on the upstream fix.
-2. **File an upstream issue in the Lisa repository.** Use the `github-write-issue` skill (`lisa:github-write-issue`) to create an issue **in Lisa's source repo `CodySwannGT/lisa`** (pass it as the target repo, e.g. `gh ... --repo CodySwannGT/lisa`) — **not** in this project's own repo. Capture: the root cause, the symptom you hit here, and the proposed durable fix in Lisa's templates/rules/skills.
+2. **File an upstream issue in the Lisa repository.** Use the `github-write-issue` skill (`lisa-github-write-issue`) to create an issue **in Lisa's source repo `CodySwannGT/lisa`** (pass it as the target repo, e.g. `gh ... --repo CodySwannGT/lisa`) — **not** in this project's own repo. Capture: the root cause, the symptom you hit here, and the proposed durable fix in Lisa's templates/rules/skills.
 
 ## Do not
 

package/plugins/src/base/rules/reference/config-resolution.md

@@ -390,7 +390,7 @@ PRD lifecycle completion is **derived** from the PRD's generated top-level work,
 
 ### Repair intake config (`intake.repair`)
 
-`lisa:repair-intake` (the recovery counterpart to `lisa:intake`) reads two optional tuning keys
+`lisa-repair-intake` (the recovery counterpart to `lisa-intake`) reads two optional tuning keys
 from the top-level `intake.repair` block. Both are **optional** — a missing block inherits the
 documented defaults, so existing projects need no config change.
 
@@ -401,7 +401,7 @@ documented defaults, so existing projects need no config change.
 
 ### Monitor audit config (`monitor`)
 
-`lisa:monitor`'s audit-and-file arm reads an optional top-level `monitor` block. Every key is
+`lisa-monitor`'s audit-and-file arm reads an optional top-level `monitor` block. Every key is
 **optional** — a missing block inherits the documented defaults, so existing projects need no
 config change. The role SEMANTICS (what counts as an anomaly or gap, how findings become tickets)
 are fixed like every other lifecycle behavior; only these thresholds and caps are tunable. Full
@@ -461,12 +461,12 @@ If a project's terminal state is the same regardless of env, set `done` to a str
 
 ### Env → base branch (forward: the build base and PR base)
 
-`deploy.branches` is also read in the **forward** direction by the build flow (`lisa:implement`): the environment a work item targets determines the branch the work is built on and the branch the PR opens against.
+`deploy.branches` is also read in the **forward** direction by the build flow (`lisa-implement`): the environment a work item targets determines the branch the work is built on and the branch the PR opens against.
 
 1. **Resolve the work item's target environment** — its `## Target Backend Environment` field.
 2. **If no environment is named**, use the **remote default branch** (`gh repo view --json defaultBranchRef`, or `origin/HEAD`) and record that default-branch assumption.
 3. **If a reported environment exists**, map env → base branch via `deploy.branches` (e.g. `staging → staging`, `production → main`). A reported env absent from `deploy.branches`, or a mapped branch missing from the remote, must stop and report the exact missing environment-to-branch mapping; never guess and never silently fall back.
-4. **Before any code is written**, `lisa:implement` fetches and **rebases the working branch onto `origin/<base>`, resolving conflicts**, so implementation builds on the latest target-environment code. **The PR then opens against that same base branch** (`target_branch=<base>` to `lisa:git-submit-pr`).
+4. **Before any code is written**, `lisa-implement` fetches and **rebases the working branch onto `origin/<base>`, resolving conflicts**, so implementation builds on the latest target-environment code. **The PR then opens against that same base branch** (`target_branch=<base>` to `lisa-git-submit-pr`).
 
 This is the exact inverse of the env-keyed `done` "Branch inference" above: `done` derives the env *from* the PR base branch (reverse); the build flow derives the base branch *from* the env (forward). Both use the one `deploy.branches` map, so the branch a PR targets and the `done` status it earns always agree.
 
@@ -627,8 +627,8 @@ reconciling any automation state.
 1. **Resolve the automation queues from merged config**
    - Resolve the PRD automation queue from merged `source`.
    - Resolve the build automation queue from merged `tracker`.
-   - Resolve repair-intake from the same queue-detection contract `lisa:intake` /
-     `lisa:repair-intake` already use; doctor should not invent a second queue schema.
+   - Resolve repair-intake from the same queue-detection contract `lisa-intake` /
+     `lisa-repair-intake` already use; doctor should not invent a second queue schema.
    - If an automation's queue cannot be resolved because `source`, `tracker`, or the selected
      vendor's required keys are still missing after merge, that automation is a doctor `FAIL`.
      Unattended runs would be ambiguous before the scheduler is even involved.
@@ -656,16 +656,16 @@ The shim → vendor mapping is fixed:
 
 | Shim | jira tracker | github tracker | linear tracker |
 |------|--------------|----------------|----------------|
-| `lisa:tracker-write` | `lisa:jira-write-ticket` | `lisa:github-write-issue` | `lisa:linear-write-issue` |
-| `lisa:tracker-validate` | `lisa:jira-validate-ticket` | `lisa:github-validate-issue` | `lisa:linear-validate-issue` |
-| `lisa:tracker-verify` | `lisa:jira-verify` | `lisa:github-verify` | `lisa:linear-verify` |
-| `lisa:tracker-read` | `lisa:jira-read-ticket` | `lisa:github-read-issue` | `lisa:linear-read-issue` |
-| `lisa:tracker-evidence` | `lisa:jira-evidence` | `lisa:github-evidence` | `lisa:linear-evidence` |
-| `lisa:tracker-sync` | `lisa:jira-sync` | `lisa:github-sync` | `lisa:linear-sync` |
-| `lisa:tracker-add-journey` | `lisa:jira-add-journey` | `lisa:github-add-journey` | `lisa:linear-add-journey` |
-| `lisa:tracker-journey` | `lisa:jira-journey` | `lisa:github-journey` | `lisa:linear-journey` |
-| `lisa:tracker-create` | `lisa:jira-create` | `lisa:github-create` | `lisa:linear-create` |
-| `lisa:tracker-build-intake` | `lisa:jira-build-intake` | `lisa:github-build-intake` | `lisa:linear-build-intake` |
+| `lisa-tracker-write` | `lisa-jira-write-ticket` | `lisa-github-write-issue` | `lisa-linear-write-issue` |
+| `lisa-tracker-validate` | `lisa-jira-validate-ticket` | `lisa-github-validate-issue` | `lisa-linear-validate-issue` |
+| `lisa-tracker-verify` | `lisa-jira-verify` | `lisa-github-verify` | `lisa-linear-verify` |
+| `lisa-tracker-read` | `lisa-jira-read-ticket` | `lisa-github-read-issue` | `lisa-linear-read-issue` |
+| `lisa-tracker-evidence` | `lisa-jira-evidence` | `lisa-github-evidence` | `lisa-linear-evidence` |
+| `lisa-tracker-sync` | `lisa-jira-sync` | `lisa-github-sync` | `lisa-linear-sync` |
+| `lisa-tracker-add-journey` | `lisa-jira-add-journey` | `lisa-github-add-journey` | `lisa-linear-add-journey` |
+| `lisa-tracker-journey` | `lisa-jira-journey` | `lisa-github-journey` | `lisa-linear-journey` |
+| `lisa-tracker-create` | `lisa-jira-create` | `lisa-github-create` | `lisa-linear-create` |
+| `lisa-tracker-build-intake` | `lisa-jira-build-intake` | `lisa-github-build-intake` | `lisa-linear-build-intake` |
 
 The `tracker-source-artifacts` skill (formerly `tracker-source-artifacts`) is read-only and vendor-neutral — it has no shim and is invoked directly by every `*-to-tracker` skill and every destination write skill (`jira-write-ticket`, `github-write-issue`, `linear-write-issue`).
 

package/plugins/src/base/rules/reference/integration-access-layer.md

@@ -19,13 +19,13 @@ available.
 
 | Vendor | Access skill | Headless env var | REST/token substrate |
 |---|---|---|---|
-| Atlassian | `lisa:atlassian-access` | `ATLASSIAN_API_TOKEN` | Atlassian Cloud REST |
-| Notion | `lisa:notion-access` | `NOTION_API_TOKEN` | Notion REST |
-| Linear | `lisa:linear-access` | `LINEAR_API_KEY` | Linear GraphQL |
-| Jam | `lisa:jam-access` | `JAM_PAT` | Jam CLI |
-| SonarCloud | `lisa:sonarcloud-access` | `SONAR_TOKEN` | SonarCloud Web API |
-| Sentry | `lisa:sentry-access` | `SENTRY_AUTH_TOKEN` | Sentry REST API |
-| PostHog | `lisa:posthog-access` | `POSTHOG_PERSONAL_API_KEY` | PostHog REST API |
+| Atlassian | `lisa-atlassian-access` | `ATLASSIAN_API_TOKEN` | Atlassian Cloud REST |
+| Notion | `lisa-notion-access` | `NOTION_API_TOKEN` | Notion REST |
+| Linear | `lisa-linear-access` | `LINEAR_API_KEY` | Linear GraphQL |
+| Jam | `lisa-jam-access` | `JAM_PAT` | Jam CLI |
+| SonarCloud | `lisa-sonarcloud-access` | `SONAR_TOKEN` | SonarCloud Web API |
+| Sentry | `lisa-sentry-access` | `SENTRY_AUTH_TOKEN` | Sentry REST API |
+| PostHog | `lisa-posthog-access` | `POSTHOG_PERSONAL_API_KEY` | PostHog REST API |
 | Google Play | `lisa-expo:play-store-access` | `GOOGLE_PLAY_SERVICE_ACCOUNT_JSON` or `GOOGLE_PLAY_SERVICE_ACCOUNT_KEY_BASE64` | Google Play Developer API |
 
 ## Current Coupling Matrix

package/plugins/src/base/rules/reference/intent-routing.md

@@ -23,7 +23,7 @@ This protocol runs **once per session**, on the first user message. After that,
 
 ## Orchestration Selection Protocol
 
-Orchestration is owned by the **lifecycle skill** for the chosen flow, not by this rule. Each top-level lifecycle skill (`lisa:research`, `lisa:plan`, `lisa:implement`, `lisa:verify`, `lisa:monitor`, `lisa:intake`) contains its own cascade-safe orchestration preamble — that's where the team is created (or skipped, if already inside one).
+Orchestration is owned by the **lifecycle skill** for the chosen flow, not by this rule. Each top-level lifecycle skill (`lisa-research`, `lisa-plan`, `lisa-implement`, `lisa-verify`, `lisa-monitor`, `lisa-intake`) contains its own cascade-safe orchestration preamble — that's where the team is created (or skipped, if already inside one).
 
 What this rule still enforces:
 
@@ -69,11 +69,11 @@ Sequence:
 4. `architecture-specialist` -- assess technical feasibility, identify constraints, map existing system boundaries
 5. Synthesize findings into a PRD containing: problem statement, user stories, acceptance criteria, technical constraints, open questions, and proposed scope
 6. **Plan Phase Tooling** -- review all available skills and agents (project-defined, plugin-provided, and built-in) and determine which ones the Plan phase will need. For each recommended skill or agent, state why it is needed. If no skills or agents beyond the defaults are identified, explicitly justify why the standard set is sufficient. Include this as a "Recommended Tooling for Plan Phase" section in the PRD.
-7. **Create the PRD in the configured source** -- invoke `lisa:prd-source-write` with the synthesized PRD (`title`, `body`, `initial_role` resolved from the caller's `prd_ready` flag — `draft` by default, `ready` when `prd_ready=true`, plus any `dedupe_key`/`marker`/`source_ref` the caller passed). The PRD **lives in the source** (Notion page / Confluence page / GitHub issue / Linear project per `.lisa.config.json` `source`); there is no separate document artifact. A `source` must be configured — if it is not, stop and report it. `prd-source-write` dedupes by marker, so re-running against the same idea references the existing PRD instead of creating a duplicate.
-8. **Record Research usage on the PRD artifact** -- invoke `lisa:usage-accounting` against the created PRD/source artifact so it gains a direct `research` usage entry in the canonical `## Lisa Usage` section at creation time. If the runtime cannot provide trustworthy usage, still write the row with `source: unavailable` and nullable token/cost fields; missing usage is never treated as zero or silently omitted.
+7. **Create the PRD in the configured source** -- invoke `lisa-prd-source-write` with the synthesized PRD (`title`, `body`, `initial_role` resolved from the caller's `prd_ready` flag — `draft` by default, `ready` when `prd_ready=true`, plus any `dedupe_key`/`marker`/`source_ref` the caller passed). The PRD **lives in the source** (Notion page / Confluence page / GitHub issue / Linear project per `.lisa.config.json` `source`); there is no separate document artifact. A `source` must be configured — if it is not, stop and report it. `prd-source-write` dedupes by marker, so re-running against the same idea references the existing PRD instead of creating a duplicate.
+8. **Record Research usage on the PRD artifact** -- invoke `lisa-usage-accounting` against the created PRD/source artifact so it gains a direct `research` usage entry in the canonical `## Lisa Usage` section at creation time. If the runtime cannot provide trustworthy usage, still write the row with `source: unavailable` and nullable token/cost fields; missing usage is never treated as zero or silently omitted.
 9. `learner` -- capture discoveries for future sessions
 
-Output: A PRD created in the configured source, carrying a "Recommended Tooling for Plan Phase" section, in the `draft` role by default (or `ready` when `prd_ready=true`, so `lisa:intake` auto-claims it). If there is not enough context to produce a complete PRD, stop and report what is missing rather than creating an incomplete one. If no `source` is configured, stop and report it rather than emitting a loose document.
+Output: A PRD created in the configured source, carrying a "Recommended Tooling for Plan Phase" section, in the `draft` role by default (or `ready` when `prd_ready=true`, so `lisa-intake` auto-claims it). If there is not enough context to produce a complete PRD, stop and report what is missing rather than creating an incomplete one. If no `source` is configured, stop and report it rather than emitting a loose document.
 
 ### Plan
 
@@ -98,9 +98,9 @@ Sequence:
    - Dependencies
    - Skills and agents required (from step 5)
 7. Create work items in the tracker (JIRA, Linear, GitHub) with acceptance criteria, dependencies, and recommended skills/agents
-8. **Record Plan usage on the PRD and created work items** -- route all direct usage writes through `lisa:usage-accounting`: attach a `plan` entry to the source PRD/spec artifact and to each created work item. If runtime usage is unavailable, still write an explicit `source: unavailable` row with nullable token/cost fields instead of omitting the entry.
-9. **PRD back-link** -- update the source PRD with a `## Tickets` section listing every created work item (key, title, type, link), so the PRD becomes the canonical anchor for downstream flows (notably **Debrief**). Invoke `lisa:prd-backlink` with the PRD source and the created ticket list. The section is regenerated on each run, not appended, so re-planning never produces stale links.
-10. **Refresh the PRD usage rollup** -- re-invoke `lisa:usage-accounting` on the source PRD after `lisa:prd-backlink` regenerates child refs so the PRD `## Lisa Usage` rollup reflects the created ticket set.
+8. **Record Plan usage on the PRD and created work items** -- route all direct usage writes through `lisa-usage-accounting`: attach a `plan` entry to the source PRD/spec artifact and to each created work item. If runtime usage is unavailable, still write an explicit `source: unavailable` row with nullable token/cost fields instead of omitting the entry.
+9. **PRD back-link** -- update the source PRD with a `## Tickets` section listing every created work item (key, title, type, link), so the PRD becomes the canonical anchor for downstream flows (notably **Debrief**). Invoke `lisa-prd-backlink` with the PRD source and the created ticket list. The section is regenerated on each run, not appended, so re-planning never produces stale links.
+10. **Refresh the PRD usage rollup** -- re-invoke `lisa-usage-accounting` on the source PRD after `lisa-prd-backlink` regenerates child refs so the PRD `## Lisa Usage` rollup reflects the created ticket set.
 11. `learner` -- capture discoveries for future sessions
 
 Output: Work items in a tracker with acceptance criteria and recommended skills/agents, ordered by dependency. The source PRD carries a `## Tickets` section linking back to every created item. If the specification cannot be decomposed without further clarification, stop and report what is missing.
@@ -127,7 +127,7 @@ Determine the work type and execute the matching variant:
 6. Run quality gates: lint, typecheck, tests (these are prerequisites, NOT verification)
 7. `verification-specialist` -- verify locally (run the software, observe behavior)
 8. `verification-specialist` -- invoke `codify-verification` skill per passing verification (Playwright for UI, integration test for API/DB/auth, etc.); commit each test in the same PR
-9. **Record Implement usage on the work artifact** -- invoke `lisa:usage-accounting` against the originating work item or implementation artifact so it gains a direct `implement` usage entry in the canonical `## Lisa Usage` section. If the hierarchy / parent refs are already known, prefer `record_and_rollup` so ancestor totals refresh in the same write; otherwise record the direct entry and leave rollup for the next caller that has the child refs. If runtime usage is unavailable, still write `source: unavailable` with nullable token/cost fields instead of omitting the row.
+9. **Record Implement usage on the work artifact** -- invoke `lisa-usage-accounting` against the originating work item or implementation artifact so it gains a direct `implement` usage entry in the canonical `## Lisa Usage` section. If the hierarchy / parent refs are already known, prefer `record_and_rollup` so ancestor totals refresh in the same write; otherwise record the direct entry and leave rollup for the next caller that has the child refs. If runtime usage is unavailable, still write `source: unavailable` with nullable token/cost fields instead of omitting the row.
 10. **Review sub-flow**
 11. `learner` -- capture discoveries
 
@@ -142,7 +142,7 @@ Determine the work type and execute the matching variant:
 7. Run quality gates: lint, typecheck, tests (these are prerequisites, NOT verification)
 8. `verification-specialist` -- verify locally (prove the bug is fixed)
 9. `verification-specialist` -- invoke `codify-verification` skill to encode the fix as a regression test (mandatory for bug fixes — the test must fail against the pre-fix commit and pass against the fix); commit in the same PR
-10. **Record Implement usage on the work artifact** -- invoke `lisa:usage-accounting` against the originating work item or implementation artifact so it gains a direct `implement` usage entry in the canonical `## Lisa Usage` section. If the hierarchy / parent refs are already known, prefer `record_and_rollup` so ancestor totals refresh in the same write; otherwise record the direct entry and leave rollup for the next caller that has the child refs. If runtime usage is unavailable, still write `source: unavailable` with nullable token/cost fields instead of omitting the row.
+10. **Record Implement usage on the work artifact** -- invoke `lisa-usage-accounting` against the originating work item or implementation artifact so it gains a direct `implement` usage entry in the canonical `## Lisa Usage` section. If the hierarchy / parent refs are already known, prefer `record_and_rollup` so ancestor totals refresh in the same write; otherwise record the direct entry and leave rollup for the next caller that has the child refs. If runtime usage is unavailable, still write `source: unavailable` with nullable token/cost fields instead of omitting the row.
 11. **Review sub-flow**
 12. `learner` -- capture discoveries
 
@@ -155,7 +155,7 @@ Determine the work type and execute the matching variant:
 5. Run quality gates: lint, typecheck, tests (these are prerequisites, NOT verification)
 6. `verification-specialist` -- measure again, prove improvement over baseline
 7. `verification-specialist` -- invoke `codify-verification` skill (typically a benchmark asserting against baseline for performance work, or a regression test for behavioral refactors); commit in the same PR
-8. **Record Implement usage on the work artifact** -- invoke `lisa:usage-accounting` against the originating work item or implementation artifact so it gains a direct `implement` usage entry in the canonical `## Lisa Usage` section. If the hierarchy / parent refs are already known, prefer `record_and_rollup` so ancestor totals refresh in the same write; otherwise record the direct entry and leave rollup for the next caller that has the child refs. If runtime usage is unavailable, still write `source: unavailable` with nullable token/cost fields instead of omitting the row.
+8. **Record Implement usage on the work artifact** -- invoke `lisa-usage-accounting` against the originating work item or implementation artifact so it gains a direct `implement` usage entry in the canonical `## Lisa Usage` section. If the hierarchy / parent refs are already known, prefer `record_and_rollup` so ancestor totals refresh in the same write; otherwise record the direct entry and leave rollup for the next caller that has the child refs. If runtime usage is unavailable, still write `source: unavailable` with nullable token/cost fields instead of omitting the row.
 9. **Review sub-flow**
 10. `learner` -- capture discoveries
 
@@ -196,8 +196,8 @@ Sequence:
    - `verification-specialist` -- verify in target environment (same checks as local verification, but on remote)
    - `ops-specialist` -- post-deploy health check, smoke test, monitor for errors in first minutes
    - If remote verification fails -- fix, open new PR, return to step 3
-7. **Record Verify usage on the evidence artifact** -- invoke `lisa:usage-accounting` against the generated evidence artifact (comment body, PR evidence section, or markdown proof) so it gains a direct `verify` usage entry in the canonical `## Lisa Usage` section. If the originating work item or PRD parentage is known, prefer `record_and_rollup` so ancestor totals refresh in the same pass. If runtime usage is unavailable, still write `source: unavailable` with nullable token/cost fields instead of omitting the row.
-8. **Post evidence via the tracker surface** -- invoke `lisa:tracker-evidence` after the usage write so the same canonical evidence artifact is uploaded / posted without hand-editing a second format.
+7. **Record Verify usage on the evidence artifact** -- invoke `lisa-usage-accounting` against the generated evidence artifact (comment body, PR evidence section, or markdown proof) so it gains a direct `verify` usage entry in the canonical `## Lisa Usage` section. If the originating work item or PRD parentage is known, prefer `record_and_rollup` so ancestor totals refresh in the same pass. If runtime usage is unavailable, still write `source: unavailable` with nullable token/cost fields instead of omitting the row.
+8. **Post evidence via the tracker surface** -- invoke `lisa-tracker-evidence` after the usage write so the same canonical evidence artifact is uploaded / posted without hand-editing a second format.
 
 Output: Merged PR, successful deploy, remote verification passing.
 
@@ -223,7 +223,7 @@ Sequence:
    - **Tooling gap** — missing skill, wrong agent assignment, broken hook, missing automation
    - **Convention drift** — an unwritten rule revealed by review comments that should be codified
 4. **Produce the human-triage document** — a markdown file with one row per candidate learning showing: category, summary, evidence (links to the source ticket comment / PR comment / commit), recommended persistence destination, and a checkbox-style disposition field the human will mark (Accept / Reject / Defer). Surface step-1 anomalies (work items missing PRs, etc.) in a separate section. The document is exhaustive — it lists every candidate, even ones the synthesizer rates low confidence — because the human, not the agent, decides what is worth keeping.
-5. **Record Debrief usage on the triage document** — invoke `lisa:usage-accounting` against the generated markdown artifact so the document carries its own direct `debrief` usage entry in the canonical `## Lisa Usage` section. If runtime usage is unavailable, write the entry with `source: unavailable` and nullable token/cost fields rather than skipping it.
+5. **Record Debrief usage on the triage document** — invoke `lisa-usage-accounting` against the generated markdown artifact so the document carries its own direct `debrief` usage entry in the canonical `## Lisa Usage` section. If runtime usage is unavailable, write the entry with `source: unavailable` and nullable token/cost fields rather than skipping it.
 6. **Stop and hand the document to the human.** Debrief does NOT persist accepted learnings itself. The human triages, marks dispositions, and runs the **`/lisa:debrief:apply`** command (skill: `debrief-apply`) to route the accepted items to their destinations.
 
 Output: A triage-ready learnings document covering every work item and PR in the initiative, with structured evidence and disposition fields. Persistence is deferred to `debrief-apply`, which the human invokes after triage.
@@ -321,7 +321,7 @@ Sequence:
 2. **Collect live signals** -- `ops-specialist` (Expo/Rails) or inline base probing (Sentry CLI/REST, CloudWatch, X-Ray, Playwright MCP) for health, logs, errors, performance. An observation is a fileable **anomaly** only when it clears the conservative thresholds in `observability-audit`.
 3. **Audit completeness** -- score the repo against the `observability-audit` rubric for its profile; each in-scope MISSING dimension is a **gap** finding (`core` always; `recommended` only with `--all-gaps`).
 4. **Report** -- health/anomaly summary + audit table. Always produced.
-5. **File (standalone only; SKIP under `--report-only`/`--dry-run` and when invoked from Verify)** -- for each anomaly and gap, dedupe by fingerprint (sentinel + search-before-create incl. closed tickets), then file a single-repo build-ready leaf via `tracker-write` (`build_ready: true`) — a `Bug` for an anomaly, a `Task`/`Improvement` for a gap — stamped `repo:<current>`, capped at `max_candidates` (default 20, `core`/high-severity first; list any dropped). Default files; `--dry-run` previews without filing. `lisa:verify` invokes monitor as `lisa:monitor <env> --report-only`, so the post-deploy check never files. Escalate anything not made into a ticket.
+5. **File (standalone only; SKIP under `--report-only`/`--dry-run` and when invoked from Verify)** -- for each anomaly and gap, dedupe by fingerprint (sentinel + search-before-create incl. closed tickets), then file a single-repo build-ready leaf via `tracker-write` (`build_ready: true`) — a `Bug` for an anomaly, a `Task`/`Improvement` for a gap — stamped `repo:<current>`, capped at `max_candidates` (default 20, `core`/high-severity first; list any dropped). Default files; `--dry-run` previews without filing. `lisa-verify` invokes monitor as `lisa-monitor <env> --report-only`, so the post-deploy check never files. Escalate anything not made into a ticket.
 
 The `observability-audit` rule owns the profile detection, rubric, anomaly thresholds, ticket templates (gate-passing), fingerprint/idempotency contract, the cap, and the Verify report-only guard. Monitor **files only** — the `intake` / `tracker-build-intake` cron implements what it files.