@codyswann/lisa 4.74.9 → 4.75.1

package/plugins/lisa-devin/skills/lisa-atlassian-access/scripts/markdown-to-adf.mjs

@@ -0,0 +1,236 @@
+#!/usr/bin/env node
+/**
+ * Convert the Markdown subset Lisa writes for JIRA descriptions into ADF.
+ *
+ * This intentionally supports the description shapes produced by Lisa skills:
+ * headings, paragraphs, fenced code blocks, bullet lists, numbered lists,
+ * inline code, and bold text. Unsupported Markdown stays as paragraph text
+ * instead of being dropped.
+ */
+
+const ADF_VERSION = 1;
+
+/**
+ * Convert a Markdown string into an Atlassian Document Format document.
+ * @param {string} markdown Markdown or wiki-heading text.
+ * @returns {{version: 1, type: "doc", content: Array<Record<string, unknown>>}}
+ */
+export function markdownToAdf(markdown) {
+  const lines = String(markdown ?? "")
+    .replace(/\r\n?/g, "\n")
+    .split("\n");
+  const content = [];
+  let paragraph = [];
+  let list = null;
+  let fence = null;
+
+  const flushParagraph = () => {
+    if (paragraph.length === 0) {
+      return;
+    }
+    content.push(paragraphNode(paragraph.join(" ")));
+    paragraph = [];
+  };
+
+  const flushList = () => {
+    if (!list) {
+      return;
+    }
+    content.push({
+      type: list.ordered ? "orderedList" : "bulletList",
+      content: list.items.map(item => ({
+        type: "listItem",
+        content: [paragraphNode(item)],
+      })),
+    });
+    list = null;
+  };
+
+  const flushFence = () => {
+    if (!fence) {
+      return;
+    }
+    const attrs = fence.language ? { language: fence.language } : {};
+    content.push({
+      type: "codeBlock",
+      attrs,
+      content: [{ type: "text", text: fence.lines.join("\n") }],
+    });
+    fence = null;
+  };
+
+  for (const line of lines) {
+    const fenceMatch = line.match(/^```([A-Za-z0-9_-]+)?\s*$/);
+    if (fenceMatch) {
+      if (fence) {
+        flushFence();
+      } else {
+        flushParagraph();
+        flushList();
+        fence = { language: fenceMatch[1] ?? "", lines: [] };
+      }
+      continue;
+    }
+
+    if (fence) {
+      fence.lines.push(line);
+      continue;
+    }
+
+    const heading = parseHeading(line);
+    if (heading) {
+      flushParagraph();
+      flushList();
+      content.push({
+        type: "heading",
+        attrs: { level: heading.level },
+        content: parseInline(heading.text),
+      });
+      continue;
+    }
+
+    const unordered = line.match(/^\s*[-*]\s+(.+)$/);
+    if (unordered) {
+      flushParagraph();
+      if (!list || list.ordered) {
+        flushList();
+        list = { ordered: false, items: [] };
+      }
+      list.items.push(unordered[1]);
+      continue;
+    }
+
+    const ordered = line.match(/^\s*\d+[.)]\s+(.+)$/);
+    if (ordered) {
+      flushParagraph();
+      if (!list || !list.ordered) {
+        flushList();
+        list = { ordered: true, items: [] };
+      }
+      list.items.push(ordered[1]);
+      continue;
+    }
+
+    if (line.trim() === "") {
+      flushParagraph();
+      flushList();
+      continue;
+    }
+
+    flushList();
+    paragraph.push(line.trim());
+  }
+
+  flushFence();
+  flushParagraph();
+  flushList();
+
+  return {
+    version: ADF_VERSION,
+    type: "doc",
+    content,
+  };
+}
+
+/**
+ * Parse Markdown and common JIRA wiki-style headings.
+ * @param {string} line A single input line.
+ * @returns {{level: number, text: string} | null}
+ */
+function parseHeading(line) {
+  const markdown = line.match(/^(#{1,6})\s+(.+)$/);
+  if (markdown) {
+    return { level: markdown[1].length, text: markdown[2].trim() };
+  }
+
+  const wiki = line.match(/^h([1-6])\.\s+(.+)$/i);
+  if (wiki) {
+    return { level: Number(wiki[1]), text: wiki[2].trim() };
+  }
+
+  return null;
+}
+
+/**
+ * Create an ADF paragraph node.
+ * @param {string} text Text content.
+ * @returns {{type: "paragraph", content: Array<Record<string, unknown>>}}
+ */
+function paragraphNode(text) {
+  return {
+    type: "paragraph",
+    content: parseInline(text),
+  };
+}
+
+/**
+ * Parse Lisa's inline formatting subset.
+ * @param {string} text Text with optional `code` and **strong** spans.
+ * @returns {Array<Record<string, unknown>>}
+ */
+function parseInline(text) {
+  const nodes = [];
+  const pattern = /(`([^`]+)`|\*\*([^*]+)\*\*)/g;
+  let lastIndex = 0;
+  let match;
+
+  while ((match = pattern.exec(text)) !== null) {
+    if (match.index > lastIndex) {
+      nodes.push({ type: "text", text: text.slice(lastIndex, match.index) });
+    }
+
+    if (match[2]) {
+      nodes.push({
+        type: "text",
+        text: match[2],
+        marks: [{ type: "code" }],
+      });
+    } else {
+      nodes.push({
+        type: "text",
+        text: match[3],
+        marks: [{ type: "strong" }],
+      });
+    }
+    lastIndex = pattern.lastIndex;
+  }
+
+  if (lastIndex < text.length) {
+    nodes.push({ type: "text", text: text.slice(lastIndex) });
+  }
+
+  return nodes.length > 0 ? nodes : [{ type: "text", text: "" }];
+}
+
+/**
+ * Whether this module is the one node was asked to run.
+ *
+ * Both sides are realpath'd: a raw URL comparison answers "no" through a
+ * symlinked checkout, a git worktree, or a /tmp path on macOS, so the module
+ * loads, runs nothing and exits 0 — a silent no-op that reads as success.
+ *
+ * A local copy rather than an import: plugin payload scripts ship standalone,
+ * with no `lib/` sibling to import from once installed.
+ * @param {string} moduleUrl - The caller's own `import.meta.url`.
+ * @param {string | undefined} [argv1] - Entry path; defaults to `process.argv[1]`.
+ * @returns {boolean} Whether the caller should run its CLI body.
+ */
+function invokedAsScript(moduleUrl, argv1 = process.argv[1]) {
+  if (!argv1) return false;
+  try {
+    return realpathSync(argv1) === realpathSync(fileURLToPath(moduleUrl));
+  } catch {
+    return false;
+  }
+}
+
+if (invokedAsScript(import.meta.url)) {
+  let input = "";
+  process.stdin.setEncoding("utf8");
+  process.stdin.on("data", chunk => {
+    input += chunk;
+  });
+  process.stdin.on("end", () => {
+    process.stdout.write(`${JSON.stringify(markdownToAdf(input), null, 2)}\n`);
+  });
+}

package/plugins/lisa-devin/skills/lisa-attribute-failure/SKILL.md

@@ -0,0 +1,142 @@
+---
+name: lisa-attribute-failure
+description: "Event-triggered root-cause attribution for an arbitrary failure: decide, with cited evidence, whether the defect is Lisa's fault or the project's. Accepts a failure event (defect description, implicated files, rule/skill/hook in play) and returns a verdict of lisa | project | ambiguous plus the evidence relied on. Read-only — it never files, writes, or remediates; callers (lisa-doctor findings, the learning judgment gate, rework triage) consume the verdict. Extracted from lisa-doctor's upstream Lisa change-history diagnosis (#1494) so the same attribution procedure can run on ANY failure event, not only doctor config-audit findings."
+allowed-tools: ["Skill", "Bash", "Read", "Glob", "Grep"]
+---
+
+# Attribute Failure
+
+Attribute ONE failure event to Lisa or the project, with cited evidence. Failure event: $ARGUMENTS
+
+Before a Lisa-caused failure can be routed upstream, something has to say — with evidence — "this was Lisa's fault, not the project's." A failure has two possible causes: the project drifted, or **Lisa itself changed or shipped the defect**. This skill must distinguish them instead of blaming the project by default, and equally must never blame Lisa without conclusive evidence. Wrong attribution in either direction is the failure mode; **inconclusive evidence is always `ambiguous`, and ambiguous stays local and low-confidence — never upstream.**
+
+## Input — the failure event
+
+Accept the event as JSON or `key=value` fields. This procedure is **event-triggered, not version-window-keyed**: any failure can be attributed, not only a doctor config-audit finding.
+
+- `defect` — what went wrong, in plain language (required)
+- `implicated_files` — the file paths where the defect lives or manifests (required when known)
+- `surface_in_play` — the Lisa rule / skill / hook / template / workflow involved, if any
+- `installed_version` / `latest_version` — the Lisa version window, when the caller knows it; otherwise resolve it as signal 3 describes
+- `failure_class` — a short slug naming the class of failure (used by downstream filing for the root-cause key)
+
+## Output — the verdict
+
+Return exactly one verdict — `lisa` | `project` | `ambiguous` — plus the evidence it relied on:
+
+```text
+## Attribution: [lisa | project | ambiguous]
+
+**Signal:** [managed-surface | shipped-artifact-behavior | upstream-history | none-conclusive]
+**Lisa surface at fault:** [path or rule/skill/hook name | n/a]
+**Cited evidence:**
+- [each item names the signal it came from and the concrete citation: file path + ownership proof, shipped artifact text, or commit sha/subject/version]
+**Confidence note:** [why the evidence is conclusive, or exactly what was inconclusive]
+```
+
+Verdict rules:
+
+- **`lisa`** — at least one signal conclusively pins the defect on a Lisa-shipped surface or upstream change, and the evidence names that surface. Never emit `lisa` from degraded, truncated, or unverified history.
+- **`project`** — the implicated files are project-owned, no shipped Lisa artifact drove the behavior, and the upstream-history window shows no relevant Lisa change. Cite the absence explicitly (which paths were checked, which window showed no relevant change).
+- **`ambiguous`** — anything else: unresolvable version window, unreachable history, partial ownership, conflicting signals. Ambiguous is treated as local and low-confidence; nothing is escalated upstream from it.
+
+## The three signals (evaluate in order)
+
+### Signal 1 — the defect lives in a Lisa-managed surface
+
+Resolve ownership of each implicated file the way doctor's config audit does:
+
+- **Copy-overwrite / managed**: the path is populated by `lisa apply` from a stack template (`typescript/`, `expo/`, `nestjs/`, `cdk/`, `harper-fabric/`, `rails/` copy-overwrite trees), is a plugin-distributed rule/skill/hook/agent/command surface, carries Lisa governance markers or a Lisa version stamp, or is governed by `package.lisa.json` `force` keys. A defect in the shipped content of such a surface is **Lisa's fault** — any local edit would be overwritten on the next `lisa apply`.
+- **Create-only**: the local copy is project-owned after scaffolding, but if the defect is faithful to the template as shipped, the template is still Lisa's fault (every newly scaffolded repo inherits it). Cite the template origin, and note the local copy will not be overwritten.
+- **Project-owned**: not from a Lisa template and not Lisa-managed — signal 1 is negative; continue.
+
+If the project locally modified a managed surface and the defect lives in the local modification, that is project drift, not a Lisa defect — signal 1 is negative for `lisa` and positive evidence for `project`.
+
+### Signal 2 — a shipped Lisa rule/skill/hook drove the wrong behavior
+
+Read the shipped artifact named in `surface_in_play` (the plugin-distributed rule, skill, hook, agent, or CI workflow as Lisa ships it — not a local fork). If following its instructions or configuration as shipped produces the observed defect, the verdict is `lisa`: cite the artifact path and the specific shipped text or configuration that drove the behavior. If the artifact is shipped correct and was misapplied locally, that is evidence for `project`.
+
+### Signal 3 — the upstream-history window shows Lisa changed the relevant contract
+
+This is the #1494 doctor procedure, unchanged in behavior — here it is the third signal, not the trigger. Whenever signals 1-2 are not conclusive on their own — and always before a definitive `project` verdict — pull Lisa's own git history for the version window and read what actually changed:
+
+1. **Resolve the version window.** Use the caller-supplied `installed_version`/`latest_version` when present; otherwise determine the project's installed Lisa version (the `@codyswann/lisa` entry in `package.json`/lockfile, or the plugin version stamp on the active runtime) and the latest published version (`npm view @codyswann/lisa version`, or the update check's cached result). An unresolvable window makes this signal inconclusive — it can support `ambiguous`, never `lisa`.
+2. **Pull the upstream history for that window** (read-only; no clone required when `gh` is available):
+
+   ```bash
+   gh api "repos/CodySwannGT/lisa/compare/v<installed>...v<latest>" \
+     --paginate --slurp |
+     jq '{total_commits: .[0].total_commits, files: [.[0].files[]?.filename], commits: [.[].commits[]? | {sha, subject: (.commit.message | split("\n")[0]), api_url: .url, html_url, parents: [.parents[]?.sha]}]}'
+   ```
+
+   `--paginate` fetches every page of commits, and `--slurp` gathers those pages into a single
+   array before the external `jq` projection runs. GitHub CLI does not permit its built-in `--jq`
+   flag together with `--slurp`, so keep the pipe as shown; without `--slurp`, paginated responses
+   are not one merged input. `total_commits` and `files` only need the first page
+   (files are capped at 300 and not repeated on later pages); `commits` flattens across all pages
+   while retaining each commit SHA and URLs needed for accurate follow-up.
+
+   After path-scoping identifies a candidate commit, fetch its targeted file-level diff context by
+   the retained SHA rather than attributing from the subject alone:
+
+   ```bash
+   gh api "repos/CodySwannGT/lisa/commits/<sha>" \
+     --jq '{sha, files: [.files[]? | select(.filename == "<relevant-path>" or (.filename | startswith("<relevant-prefix>/"))) | {filename, status, additions, deletions, changes, patch}]}'
+   ```
+
+   Preserve the returned filename, status, counts, and available patch with the SHA in the
+   upstream-history projection. A missing or truncated `patch` is not proof of no relevant change;
+   use the compare diff fallback below or downgrade the attribution to `ambiguous` when
+   commit-level context cannot be established.
+
+   The compare endpoint paginates commits (250 without `--paginate`) and only lists changed files
+   on the first page, capped at 300 total — a large version window can silently drop commits or
+   files. If `total_commits` or the file count looks truncated, re-run with the
+   `application/vnd.github.diff` accept header (`gh api ... -H "Accept: application/vnd.github.diff"`)
+   to pull the full patch text, or fall back to the bounded-fetch `git log` below. When completeness
+   still can't be established, say so in the evidence and return `ambiguous` rather than attributing
+   with unverified confidence.
+
+   Fallbacks, in order: `gh api repos/CodySwannGT/lisa/commits?path=<template-path>` for a
+   path-scoped view — note this endpoint has no way to bound results to the `v<installed>..v<latest>`
+   window, so treat its output as best-effort context only, not authoritative attribution; a
+   finite-depth, explicit-tag fetch, which is bounded to the two version refs and should be preferred
+   for definitive attribution; or the local marketplace/plugin cache checkout when the runtime has
+   one. For the fetch fallback, use a temporary directory and a fixed history ceiling:
+
+   ```bash
+   lisa_history_dir="$(mktemp -d)"
+   git init "$lisa_history_dir"
+   git -C "$lisa_history_dir" remote add origin https://github.com/CodySwannGT/lisa.git
+   git -C "$lisa_history_dir" fetch --no-tags --filter=blob:none --depth=256 origin \
+     refs/tags/v<installed>:refs/tags/v<installed> \
+     refs/tags/v<latest>:refs/tags/v<latest>
+   git -C "$lisa_history_dir" merge-base --is-ancestor v<installed> v<latest>
+   git -C "$lisa_history_dir" log --format='%H%x09%s' v<installed>..v<latest> -- <paths>
+   git -C "$lisa_history_dir" show --format=fuller --stat --patch <relevant-sha> -- <paths>
+   ```
+
+   The explicit tag refspecs, `--no-tags`, and finite `--depth=256` make this fetch bounded. Do not
+   silently deepen beyond that ceiling. If `merge-base --is-ancestor` fails, the shallow window is
+   incomplete (or the tags are not on one ancestry line): do not make definitive attribution from
+   it. If none of the bounded sources are reachable, or only the unbounded path-scoped fallback is
+   reachable, report the gap in the evidence and return `ambiguous` — never fail the caller's flow
+   because history was unavailable or incomplete, and never let a degraded history produce `lisa`.
+3. **Scope the reading to what the failure touches.** Filter the commit list to the paths that
+   generate the failing surface: the detected stacks' template dirs (`typescript/`, `expo/`, …),
+   `plugins/src/base/` for skills/hooks/rules, `scripts/` for governance scripts, and the shipped
+   config factories (`src/configs/`). A failure about a lint rule reads the lint-config commits,
+   not the whole log.
+4. **Attribute.** When the upstream history shows Lisa changed the relevant contract (a tightened
+   lint rule, a renamed check context, a new required config key), the verdict is `lisa` — cite the
+   commit subject/version. When history shows no relevant upstream change and signals 1-2 are also
+   negative, the project drifted — the verdict is `project`, citing the absence of a relevant
+   upstream change as the evidence.
+
+## Rules
+
+- **Read-only.** This skill reads the project and Lisa's repository; it never writes to either, never files issues, and never remediates. Filing the upstream ticket on a `lisa` verdict is the caller's flow (`lisa-persist-learning`, `handoff-upstream` disposition); doctor maps verdicts into its findings; remediation stays with whoever called.
+- **Never block.** Attribution failure, missing tooling (`gh` unavailable), or degraded history degrades to `ambiguous` with the gap named in the evidence — it never raises an error that stops the caller's build or audit.
+- **Every verdict cites its evidence.** An attribution without a named signal and concrete citation is invalid — return `ambiguous` instead. Evidence destined for upstream surfaces quotes ONLY Lisa-owned surface text (never host env values, tokens/credentials, PII, or proprietary host code — link the host issue instead of quoting it); the binding redaction procedure lives in `lisa-persist-learning`'s `handoff-upstream` step.
+- **Ambiguous never escalates.** `ambiguous` is a terminal local verdict: low-confidence, no upstream filing, no durable local rule derived from it.
+- **Headless-safe and idempotent**: no prompts, no side effects, same event in → same verdict out.

package/plugins/lisa-devin/skills/lisa-automation-status/SKILL.md

@@ -0,0 +1,149 @@
+---
+name: lisa-automation-status
+description: "Read-only operator surface for the current project's Lisa automation fleet. Resolves the expected recurring jobs from the same setup-automations contract Lisa uses to create them, inspects the active runtime scheduler (Codex automations or Claude /schedule), compares live command/cadence/queue arguments against the expected contract, and reports grouped fleet health such as healthy, missing, unsupported, drifted, stale, or failing with remediation guidance."
+allowed-tools: ["Skill", "Bash", "Read"]
+---
+
+# Automation Status: $ARGUMENTS
+
+`/lisa:automation-status` is the operator-facing inspection surface for Lisa's unattended job fleet. It answers, for the **current repo only**, whether the recurring Lisa automations that should exist actually exist, still match Lisa's setup contract, and appear healthy based on the runtime metadata available.
+
+This command is **read-only** in v1. It does not create, update, resume, rerun, pause, or delete automations. It complements `/lisa:setup-automations`, `/lisa:tear-down-automations`, `/lisa:intake`, `/lisa:repair-intake`, `doctor`, and `monitor`; it does not replace them.
+
+## Confirmation policy
+
+Do **not** ask for confirmation once invoked. This skill inspects scheduler state and reports what it finds. There are no write-side effects in the v1 surface.
+
+## Scope
+
+Inspect only the Lisa automation fleet for the current project. Derive that fleet from
+`scripts/automation-status-expected-fleet.mjs` (`resolveExpectedAutomationFleet`), which resolves
+exactly what `setup-automations` registers for this repo — including the stack-guarded
+`exploratory-bugs` and the opt-in `learnings-audit` gardener. **Membership is registration, not a
+roster** (`automation-runbook-contract`): carry no fixed list of loop names here, so a loop added to
+or removed from the registration set flows through without editing this skill.
+
+The gardener is opted into at registration time and has no config key, so **infer it from the
+scheduler**: list the project's automations first, then call
+`inferLearningsAuditRegistration({ automationPrefix, observedAutomationIds })` and pass the result
+as `learningsAudit` when resolving the fleet. A `lisa-auto-<project>-learnings-audit` entry on the
+scheduler means the project opted in, so the gardener is compared like any other loop; no such entry
+means it is reported `UNSUPPORTED` (opted out), never `MISSING`. This skill stays read-only — it
+infers, it never writes the flag anywhere.
+
+Resolve the expected project identifier, fleet naming prefix, queue arguments, cadence, and stack-support rules from the same contract used by `setup-automations` and `tear-down-automations`. Do **not** invent a second source of truth for fleet naming or queue resolution.
+
+## Runtime inspection
+
+Branch on the active runtime and prefer the runtime's native automation listing surface:
+
+- **Codex**: inspect Codex automations metadata first. Use backing-store files only as a fallback or to enrich timestamps when the runtime surface cannot provide enough status detail directly.
+- **Claude**: inspect the `/schedule` listing surface and any exposed recency or failure metadata available there.
+- **Other runtimes**: if no native recurring-task inspection exists, report that automation-status is unsupported in this runtime rather than guessing.
+
+The report must stay repo-scoped: inspect only automations whose names belong to the current repo's Lisa fleet prefix, and do not absorb unrelated automations into the result.
+
+### GitHub Actions loops: check the clock itself
+
+Loops declared with `scheduler: "github-actions"` in `.lisa.config.json` are **not** visible to any runtime-native listing. Inspect them separately, and report a **stopped clock** as a finding in its own right — not merely the absence of recent work.
+
+Three distinct states, all of which look identical from the work side:
+
+| Observation | State | Remediation |
+| --- | --- | --- |
+| Workflow file exists, no `schedule:` trigger | **registered-disabled** | Expected until the production path is proven once. Prove it with a manual dispatch, then set `enabled: true` and regenerate. |
+| `schedule:` present, but no run in well over the declared cadence | **clock stopped** | GitHub **auto-disables scheduled workflows after 60 days of repository inactivity.** Re-enable it in the Actions UI, or push any commit. |
+| Runs firing, none dispatching | **idle** | Healthy. The queue is empty. |
+
+The middle row is the one worth building for. A quiet repository silently stops running its loops and *nothing announces it*, so an unattended factory can be dead for weeks while every individual signal still looks fine. Do not infer health from "no failures"; a clock that never fires produces no failures at all.
+
+```sh
+gh run list --workflow "lisa-<loop>.yml" --limit 5 \
+  --json createdAt,conclusion,event
+```
+
+Compare the newest `schedule`-event run against the declared cron. Absent or far older than the cadence means the clock is the problem, and no amount of inspecting the queue will reveal it.
+
+Also note that GitHub's scheduled triggers are **best-effort**: they are delayed under load, sometimes considerably. Judge against a generous multiple of the cadence rather than flagging a single late tick.
+
+## What to report
+
+For each expected automation, report:
+
+1. Whether it exists.
+2. Whether it is expected or intentionally unsupported.
+3. The configured command and cadence Lisa expects.
+4. Any detected drift in name, cadence, command shape, or queue arguments.
+5. Any available recent-run health signal such as stale last-run timing or repeated failure status.
+6. A concise remediation hint when attention is needed.
+7. Where the loop's checked-in runbook lives (`automation-runbook-contract`), or `not scaffolded — run /lisa:setup-automations` when it is absent.
+8. How the last recorded run ended — its outcome, one-line summary, and timestamp — or `no recorded runs yet` when the loop has never recorded one.
+9. A bounded run history: the five most recent outcomes newest first, plus a count of how many older records exist when the file holds more.
+
+The last-run and history facts come from the durable run-outcome substrate recorded by each loop (the RBC-3 records under `.lisa/automations/runs/<loop-id>.jsonl`, read through `readAutomationRunRecords`). That directory is local scheduler state, not project knowledge — read it, never write it.
+
+Emit an overall grouped fleet verdict such as `HEALTHY`, `ATTENTION_NEEDED`, or `PARTIAL_SUPPORT`, plus the runtime surface inspected. **Repeated recovery is a fleet-health signal the scheduler cannot see**: when a loop's last three or more consecutive recorded runs are all `recovery-required`, report that loop `FAILING` — and therefore the overall verdict `ATTENTION_NEEDED` — even when its scheduler entry itself looks healthy, and point the remediation at the recorded run summaries.
+
+## Operator usage
+
+Typical entrypoint:
+
+```text
+/lisa:automation-status
+```
+
+Use this command when an operator needs to answer one of these questions for the current repo:
+
+- "Did Lisa set up every automation this project expects?"
+- "Is the scheduler still pointing at the right cadence and queue arguments?"
+- "Is the queue idle because there is no work, or because the automation is stale or failing?"
+
+The report should be terminal-first and immediately actionable: observable scheduler facts first, then the smallest useful remediation step.
+
+## Runtime differences
+
+- **Codex**: prefer native automation metadata and use backing-store files only to fill gaps such as timestamps or failure recency. When Codex exposes health/memory signals, include them as observed facts rather than assumptions.
+- **Claude**: use the `/schedule` listing as the primary runtime surface. Compare the live schedule name, cadence, and command shape against the Lisa contract, but degrade gracefully when `/schedule` does not expose equivalent recency or failure fields.
+- **Other runtimes**: report automation-status as unsupported for that runtime instead of guessing from unrelated files or naming patterns.
+
+## Verdicts and remediation
+
+- `HEALTHY`: every expected automation exists and the inspected runtime metadata shows no actionable drift, staleness, or failure.
+- `PARTIAL_SUPPORT`: the fleet is otherwise healthy, but at least one exploratory job is intentionally unsupported for this stack or runtime.
+- `ATTENTION_NEEDED`: at least one automation is missing, drifted, stale, or failing.
+
+Status-specific remediation guidance:
+
+- `MISSING`: tell the operator which job is absent and recommend rerunning `/lisa:setup-automations` or recreating the missing job with the expected cadence and command.
+- `DRIFTED`: show the expected versus observed cadence/command mismatch and recommend aligning the scheduler entry with Lisa's current setup contract, usually by rerunning `/lisa:setup-automations`.
+- `STALE`: explain that the job exists but has not run recently enough for its cadence. Recommend inspecting the runtime's recent-run history or failure logs before changing queue state.
+- `FAILING`: surface the failure signal directly and recommend checking the latest runtime error plus the affected queue command (`/lisa:intake`, `/lisa:repair-intake`, or exploratory job) after the scheduler issue is resolved. A loop also reports `FAILING` when its last three or more consecutive recorded runs are all `recovery-required` — even with a healthy scheduler entry — in which case cite the recorded run summaries and point the operator at the loop's runbook.
+- `UNSUPPORTED`: explain why the job is intentionally absent and say that no remediation is required unless the project stack or runtime support changed.
+
+Render the report in grouped sections using the shared `scripts/automation-status-report.mjs` contract:
+
+```text
+Overall verdict: <VERDICT>
+Counts: <n HEALTHY>, <n MISSING>, <n UNSUPPORTED>, <n DRIFTED>, <n STALE>, <n FAILING>
+Runtime inspected: <runtime surface>
+Generated at: <ISO timestamp>
+
+1. <group title>
+- <STATUS> <automation-id>: <summary>
+  Expected: <cadence> -> <command>
+  Observed: <what the runtime exposed>
+  Runbook: <.lisa/automations/<loop-id>.runbook.md, or "not scaffolded — run /lisa:setup-automations">
+  Last run: <outcome> — <summary> (<ts>), or "no recorded runs yet"
+  History: <outcome>, <outcome>, … (newest first); … and <N> older records
+  Remediation: <next step when attention is needed>
+```
+
+The Runbook, Last run, and History lines are observable facts and sit between Observed and Remediation. Keep observable runtime facts separate from remediation guidance so operators can distinguish drift, unsupported jobs, and actual failures quickly.
+
+## Rules
+
+- Stay **read-only**. Never create, update, delete, enable, disable, or rerun automations from this skill.
+- Reuse `setup-automations` contract logic for expected fleet resolution, cadence, queue arguments, naming, and stack-specific support checks.
+- Distinguish **unsupported** from **missing**. An exploratory job omitted because the current stack lacks `exploratory-qa` is not a failure.
+- If the runtime cannot expose a field such as last-run timestamp or failure state, say that explicitly instead of implying health.
+- Keep the output operational and repo-scoped so operators can tell whether Lisa's unattended surfaces are present, current, and healthy right now.

package/plugins/lisa-devin/skills/lisa-bug-triage/SKILL.md

@@ -0,0 +1,23 @@
+---
+name: lisa-bug-triage
+description: "8-step bug triage and implementation workflow. Ensures bugs are reproducible, root-caused, and fixable before implementation begins."
+---
+
+# Bug Triage
+
+Follow this 8-step triage process before implementing any bug fix. Do not skip triage.
+
+## Triage Steps
+
+1. Verify you have all information needed to reproduce the bug (authentication requirements, environment information, etc.). Do not make assumptions. If anything is missing, stop and ask before proceeding.
+2. Reproduce the bug on the path the user actually hits. Prerequisites the real path needs — seeded data, auth state, flags — are part of the reproduction; scaffolding that substitutes real behaviour is not, and a failure that survives only with it in place is a lead rather than a reproduction. Say which you have. Without a real-path reproduction you may not claim a root cause at all. If you cannot reproduce it, stop and report what you tried and what you observed.
+3. Once reproduced, name a candidate cause and the observation that would disprove it, and go get that observation. Surviving the disproof is not proof — it leaves the candidate standing, not confirmed — so before implementing, execute something whose output the candidate predicts and a different cause would not produce. If you cannot get that confirmation, record the verdict as inconclusive and say so rather than proceeding as if certain; add logging, trace the path, or bisect until you can.
+4. Verify you have access to the tools, environments, and permissions needed to deploy and verify this fix (e.g. CI/CD pipelines, deployment targets, logging/monitoring systems, API access, database access). If any are missing or inaccessible, stop and raise them before starting implementation.
+5. Define the tests you will write to confirm the fix and prevent a regression.
+6. Define the documentation you will create or update to explain this bug so another developer understands the "how" and "what" behind it.
+7. If you can verify your fix before deploying to the target environment (e.g. start the app, invoke the API, open a browser, run the process, check logs), do so before deploying.
+8. Define how you will verify the fix beyond a shadow of a doubt (e.g. deploy to the target environment, invoke the API, open a browser, run the process, check logs).
+
+## Implementation
+
+Use the output of the triage steps above as your guide. Do not skip triage.

package/plugins/lisa-devin/skills/lisa-capability-drift/SKILL.md

@@ -0,0 +1,71 @@
+---
+name: lisa-capability-drift
+description: "Detect the fleet getting worse when nobody changed anything — sample the evaluation suite against a recorded baseline on a cadence, decide whether a decline is real given run-to-run variance, and attribute it to a vendor-side change, accumulated local change, or a broken harness."
+allowed-tools: ["Read", "Grep", "Glob", "Bash"]
+---
+
+# Capability Drift
+
+Qualification fires when you change something. This exists because capability also moves when you change nothing.
+
+## What moves underneath you
+
+- A vendor reroutes what a pinned name resolves to, or alters the served model behind it.
+- Instruction surfaces accumulate — a rule here, a skill there — until they contradict each other and the model spends its budget reconciling them instead of working.
+- Tool behaviour shifts under the same interface.
+- The work itself changes shape, so yesterday's competence is aimed at a problem that has moved.
+
+None of these produce an event you can subscribe to. They produce a slow decline that looks like ordinary bad luck, one task at a time, until somebody finally compares against a year ago and cannot explain the gap.
+
+## Record a baseline worth comparing to
+
+A baseline is the recorded distribution of suite outcomes for a stated configuration at a stated time — not a single score. Store the configuration completely enough to reproduce it: model, reasoning or effort level, tool set, context assembly, and the suite's own review date.
+
+Re-baseline deliberately, after a qualified change, and never silently. A baseline quietly overwritten each run cannot detect anything, because the thing you are comparing against has been moving with you the whole time.
+
+## Sample on a cadence
+
+Declare an interval and hold it. Sampling only when something feels wrong means you find out about decline through the incident it caused, which is exactly the situation this is meant to prevent.
+
+Each sample runs the suite against the deployed configuration and compares to the baseline distribution — not to the previous sample, which turns a trend into a series of individually unremarkable steps.
+
+## Deciding whether a decline is real
+
+Run-to-run variance is large enough that a lower number usually means nothing. Treat a decline as a finding only when the sampled distribution is distinguishable from the baseline by the spread statistic the suite declares — the same bar a qualification has to clear.
+
+A borderline reading is not a finding and not an all-clear. It is a reason to take more samples, and saying so is the honest report.
+
+## Attribute it before acting
+
+A confirmed decline has three candidate causes, and the remedy differs completely:
+
+| Candidate | How to separate it |
+| --- | --- |
+| **Vendor-side change** | Re-run the baseline configuration explicitly pinned. If it now scores like the sample rather than like the baseline, what the pin resolves to has changed underneath you |
+| **Accumulated local change** | Diff the instruction surfaces, tool set and context assembly against the baseline's recorded configuration. Look for additions nobody qualified, and for rules that now contradict |
+| **Broken harness** | Check whether failures are the work being wrong or the run being unable to proceed — missing install, absent credential, changed path. A harness failure reads as incapability and is not one |
+
+Do not skip this. "The model got worse" is the most expensive conclusion available, and it is wrong most of the time.
+
+## Report and route
+
+A confirmed decline enters intake as build-ready work like any other finding, carrying the attribution. An unattributed decline is still worth filing — with the attribution work named as the first task, so nobody re-runs the analysis from scratch.
+
+## Output
+
+```text
+## Capability Drift
+
+**Baseline:** date · configuration (model · effort · tools · context) · suite review date
+**Sample:** date · same fields, with every difference from the baseline marked
+**Cadence:** declared interval, and whether this sample was on schedule
+
+### Comparison
+| Task class | Baseline distribution | Sampled distribution | Distinguishable? |
+|---|---|---|---|
+
+**Verdict:** stable | declined | inconclusive — take n more samples
+**Attribution (declines only):** vendor-side | accumulated local | broken harness — with the
+  evidence that separated it from the other two
+**Filed:** work item, or the reason nothing was filed
+```