@codyswann/lisa 2.189.7 → 2.189.9

package/plugins/lisa-copilot/skills/lisa-tracker-validate/SKILL.md

@@ -0,0 +1,36 @@
+---
+name: lisa-tracker-validate
+description: "Vendor-neutral wrapper for the pre-write quality gate. Reads `tracker` from .lisa.config.json (default: jira) and dispatches to lisa-jira-validate-ticket, lisa-github-validate-issue, or lisa-linear-validate-issue. Read-only — never writes to any tracker. Used by tracker-write Phase 5.5 (pre-write gate), tracker-verify (post-write checks), and the *-to-tracker dry-run paths. Output is structured PASS/FAIL per gate so callers can parse it."
+allowed-tools: ["Skill", "Bash", "Read"]
+---
+
+# Tracker Validate: $ARGUMENTS
+
+Thin dispatcher. Resolves the configured destination tracker and delegates to the matching vendor validator.
+
+See the `config-resolution` rule for the full configuration schema and skill-mapping table.
+
+## Workflow
+
+1. **Resolve tracker config** (same logic as `lisa-tracker-write` Step 1):
+
+   ```bash
+   local_tracker=$(jq -r '.tracker // empty' .lisa.config.local.json 2>/dev/null)
+   global_tracker=$(jq -r '.tracker // empty' .lisa.config.json 2>/dev/null)
+   tracker="${local_tracker:-${global_tracker:-jira}}"
+   ```
+
+2. **Dispatch**
+
+   - `jira` → invoke `lisa-jira-validate-ticket` with `$ARGUMENTS` verbatim.
+   - `github` → invoke `lisa-github-validate-issue` with `$ARGUMENTS` verbatim.
+   - `linear` → invoke `lisa-linear-validate-issue` with `$ARGUMENTS` verbatim.
+   - Anything else → stop and report `"Unknown tracker '<value>' in .lisa.config.json. Expected 'jira', 'github', or 'linear'."`
+
+3. **Pass through the validator's structured report unchanged.** Callers (e.g. `lisa-jira-write-ticket` Phase 5.5) parse the gate lines; do not paraphrase.
+
+## Rules
+
+- Read-only — never write to any tracker.
+- Never re-implement gate logic here. The gate definitions are the vendor validator's responsibility.
+- Never silently transform the input — pass `$ARGUMENTS` through verbatim.

package/plugins/lisa-copilot/skills/lisa-tracker-verify/SKILL.md

@@ -0,0 +1,28 @@
+---
+name: lisa-tracker-verify
+description: "Vendor-neutral wrapper for the post-write verification gate. Reads `tracker` from .lisa.config.json (default: jira) and dispatches to lisa-jira-verify, lisa-github-verify, or lisa-linear-verify. Fetches the live ticket/issue and runs the validator gates against the stored state — catches anything dropped or reformatted on write. Read-only."
+allowed-tools: ["Skill", "Bash", "Read"]
+---
+
+# Tracker Verify: $ARGUMENTS
+
+Thin dispatcher. Resolves the configured destination tracker and delegates to the matching vendor post-write verifier.
+
+See the `config-resolution` rule for configuration and dispatch table.
+
+## Workflow
+
+1. Resolve tracker config (same logic as `lisa-tracker-write`).
+2. Dispatch:
+   - `jira` → invoke `lisa-jira-verify` with `$ARGUMENTS` verbatim.
+   - `github` → invoke `lisa-github-verify` with `$ARGUMENTS` verbatim.
+   - `linear` → invoke `lisa-linear-verify` with `$ARGUMENTS` verbatim.
+   - Anything else → stop and report `"Unknown tracker '<value>' in .lisa.config.json. Expected 'jira', 'github', or 'linear'."`
+3. Pass through the verifier's structured report unchanged.
+
+## Rules
+
+- Read-only.
+- The same gates run pre-write and post-write — this shim simply chooses the vendor implementation.
+- If the vendor verify reports `FAIL`, callers must NOT auto-fix from this layer. Surface the failures to the caller and let the higher-level skill decide.
+- Duplicate closeout is not a verifier shortcut. A build-intake ticket may be auto-closed as duplicate only when downstream triage returns `DUPLICATE_ALREADY_FIXED` with a canonical ticket reference and empirical evidence that the canonical fix is present on the relevant base branch; ordinary verifier `FAIL`/`PASS` output never implies duplicate resolution.

package/plugins/lisa-copilot/skills/lisa-tracker-write/SKILL.md

@@ -0,0 +1,53 @@
+---
+name: lisa-tracker-write
+description: "Vendor-neutral wrapper for ticket creation and updates. Reads `tracker` from .lisa.config.json (default: jira) and dispatches to lisa-jira-write-ticket, lisa-github-write-issue, or lisa-linear-write-issue. Callers in vendor-neutral skills (notion-to-tracker, linear-to-tracker, confluence-to-tracker, github-to-tracker, implement, verify) MUST invoke this skill instead of the vendor-specific ones — that is what makes the tracker switchable per project. The Phase-5.5 validate-pre-write gate, post-write verify, and Phase-8 announce-comment behavior live in the vendor skills; this shim is dispatch only."
+allowed-tools: ["Skill", "Bash", "Read"]
+---
+
+# Tracker Write: $ARGUMENTS
+
+Thin dispatcher. Resolves the configured destination tracker and delegates to the matching vendor
+write skill.
+
+When the incoming description/body already contains the canonical `## Lisa Usage` ledger, the vendor
+writer must preserve that managed section on update and use the `lisa-lisa-usage-accounting` contract for any
+body-vs-comment fallback. This shim only routes — it never edits tracker artifacts itself.
+
+See the `config-resolution` rule for the full configuration schema and skill-mapping table.
+
+## Workflow
+
+1. **Resolve tracker config**
+
+   Read `.lisa.config.local.json` first (if present), then `.lisa.config.json`. Local overrides global on a per-key basis. Use `jq` — never hand-parse JSON.
+
+   ```bash
+   local_tracker=$(jq -r '.tracker // empty' .lisa.config.local.json 2>/dev/null)
+   global_tracker=$(jq -r '.tracker // empty' .lisa.config.json 2>/dev/null)
+   tracker="${local_tracker:-${global_tracker:-jira}}"
+   ```
+
+2. **Validate the value**
+
+   - `jira` → confirm `atlassian.cloudId` and `jira.project` are present. If either is missing, stop and report: `"tracker=jira but atlassian.cloudId and jira.project are not set in .lisa.config.json."` Continue to Step 3a.
+   - `github` → confirm `github.org` and `github.repo` are present. If either is missing, stop and report: `"tracker=github but github.org and github.repo are not set in .lisa.config.json."` Continue to Step 3b.
+   - `linear` → confirm `linear.workspace` and `linear.teamKey` are present. If either is missing, stop and report: `"tracker=linear but linear.workspace and linear.teamKey are not set in .lisa.config.json."` Continue to Step 3c.
+   - Any other value → stop and report: `"Unknown tracker '<value>' in .lisa.config.json. Expected 'jira', 'github', or 'linear'."`
+
+3. **Dispatch**
+
+   - **3a (jira):** Invoke `lisa-jira-write-ticket` via the Skill tool, passing `$ARGUMENTS` verbatim.
+   - **3b (github):** Invoke `lisa-github-write-issue` via the Skill tool, passing `$ARGUMENTS` verbatim.
+   - **3c (linear):** Invoke `lisa-linear-write-issue` via the Skill tool, passing `$ARGUMENTS` verbatim.
+
+4. **Surface the vendor skill's output unchanged.** Do not paraphrase; downstream callers parse the structured response.
+
+## Rules
+
+- Never bypass dispatch — calling the vendor skill directly from a vendor-neutral caller defeats the per-project switch.
+- Never drop, duplicate, or hand-rewrite an existing managed `## Lisa Usage` section in this shim.
+  Writer-specific preservation logic belongs in the vendor writers and follows the
+  `lisa-lisa-usage-accounting` contract.
+- Never accept a tracker value outside `{jira, github, linear}`.
+- Never mutate `$ARGUMENTS` between layers. The vendor skills define their own input contract.
+- Never inline gate logic here. All validation rules live in the vendor skills (`lisa-jira-validate-ticket` / `lisa-github-validate-issue` / `lisa-linear-validate-issue`); this skill only routes.

package/plugins/lisa-copilot/skills/lisa-usage-accounting/SKILL.md

@@ -0,0 +1,170 @@
+---
+name: lisa-usage-accounting
+description: "Shared usage-ledger utility for Lisa lifecycle flows and artifact writers. Delegates all direct-entry recording and rollup refreshes through one vendor-neutral contract so PRDs, tickets, evidence comments, PRs, and markdown artifacts preserve the canonical `## Lisa Usage` section instead of inventing per-flow formats."
+allowed-tools: ["Skill", "Read", "Bash"]
+---
+
+# Usage Accounting: $ARGUMENTS
+
+Single chokepoint for Lisa usage-ledger writes. Caller skills (`research`, `plan`,
+`implement`, `verify`, `debrief`, `intake`, `prd-source-write`, `tracker-write`,
+`tracker-evidence`, later rollup/monitor flows) MUST delegate usage-entry writes and
+rollup refreshes through this skill rather than hand-editing artifact bodies or comments.
+
+This skill does not define the ledger format itself. The durable schema, token order,
+rewrite invariants, and rollup semantics live in the `usage-accounting` rule. This skill
+applies that contract to real artifacts and chooses the safest writable surface.
+
+## Invocation contract
+
+The caller passes exactly one operation plus its arguments:
+
+```text
+operation: record
+artifact_ref: github:CodySwannGT/lisa#729
+artifact_kind: github-issue
+entry: { ...LisaUsageEntry fields... }
+
+operation: rollup
+artifact_ref: github:CodySwannGT/lisa#724
+artifact_kind: github-issue
+child_refs:
+  - github:CodySwannGT/lisa#729
+  - github:CodySwannGT/lisa#730
+
+operation: record_and_rollup
+artifact_ref: github:CodySwannGT/lisa#724
+artifact_kind: github-issue
+entry: { ...LisaUsageEntry fields... }
+child_refs:
+  - github:CodySwannGT/lisa#729
+```
+
+Required arguments:
+
+- `operation`: one of `record`, `rollup`, or `record_and_rollup`.
+- `artifact_ref`: canonical artifact identifier for the target being updated.
+- `artifact_kind`: the writable host surface (`github-issue`, `github-pr-comment`, `jira-ticket`,
+  `linear-issue`, `notion-page`, `confluence-page`, `markdown-file`, or another caller-defined
+  host string with a matching read/write adapter).
+
+Operation-specific arguments:
+
+- `record` requires `entry`.
+- `rollup` requires `child_refs` (empty is allowed when the caller wants a direct-only refresh).
+- `record_and_rollup` requires `entry` and may also pass `child_refs`.
+
+Optional arguments:
+
+- `attachment_preference`: `body-first` (default) or `comment-only`.
+- `comment_ref`: existing managed comment identifier when the ledger already lives in a comment.
+- `parent_artifact_ref`: explicit parent for callers that need to anchor descendant rollups.
+- `existing_body`: caller-supplied body snapshot when it already owns a fresh read.
+
+The `entry` payload MUST satisfy the canonical usage-entry contract from the rule: stable
+`entry_id`, `flow`, `run_id`, provider/model, source semantics, token fields, pricing fields,
+and artifact refs. Callers do not get to omit the "unavailable" case; when trustworthy usage is
+missing they still pass an explicit entry with `source: unavailable` and nullable token/cost
+fields.
+
+## Return shape
+
+Return structured output so callers can persist or log what happened without reparsing prose:
+
+```yaml
+outcome: updated | comment-fallback | no-op | blocked
+artifact_ref: "github:CodySwannGT/lisa#729"
+surface:
+  kind: body | comment
+  ref: "<artifact or comment identifier>"
+entry_ids:
+  direct:
+    - "<entry-id>"
+  child:
+    - "<rolled-up-child-entry-id>"
+rollup:
+  direct_tokens: 1200
+  child_tokens: 450
+  total_tokens: 1650
+  direct_cost: 0.42
+  child_cost: 0.17
+  total_cost: 0.59
+warnings:
+  - "<warning text>"
+error:
+  code: "<stable-code>"
+  message: "<exact failure text>"
+  remediation: "<next step>"
+```
+
+- `updated` means the preferred writable surface was updated successfully.
+- `comment-fallback` means body/description edits were unsafe, so the canonical ledger landed in a
+  managed comment instead.
+- `no-op` means the requested operation produced byte-identical ledger output.
+- `blocked` means the caller asked for a write that could not be completed; preserve the exact host
+  failure text.
+
+## Workflow
+
+### Step 1 — Read the current managed surface
+
+1. Resolve the target artifact from `artifact_ref` / `artifact_kind`.
+2. Prefer a caller-supplied `existing_body` when present and trustworthy for this write.
+3. Otherwise read the current body/description from the host's native adapter.
+4. If the caller passed `comment_ref`, read that managed comment body too.
+
+Never guess the prior ledger state. Always start from the current managed body/comment so rewrite
+idempotency is preserved.
+
+### Step 2 — Choose the writable surface
+
+Default policy is **body first**:
+
+- If the host body/description is writable by the caller's normal writer path, update the body in
+  place and keep the canonical `## Lisa Usage` section there.
+- If direct body edits are unsafe, unavailable, or likely to clobber other writer-owned content,
+  fall back to a **single managed comment** containing the same canonical section.
+- If the caller explicitly passes `attachment_preference: comment-only`, skip the body attempt and
+  write the managed comment directly.
+
+The fallback is part of the contract, not an error. Writers should prefer the artifact body they
+already own, but evidence comments, immutable PR descriptions, or size-limited hosts may require
+the managed comment path.
+
+### Step 3 — Apply the requested operation
+
+All three operations use the shared utilities and rule contract; they differ only in which inputs
+they require and whether they recompute child totals:
+
+- `record`: upsert exactly one direct usage entry on the target artifact. Rewrite the entire
+  `## Lisa Usage` section in place using the canonical serializer; never append ad hoc rows.
+- `rollup`: recompute the rollup token and visible totals from the target's current direct entries
+  plus usage discovered from `child_refs`. Dedupe strictly by stable `entry_id`.
+- `record_and_rollup`: first upsert the direct entry, then refresh totals against `child_refs` in
+  the same managed write so callers do not produce split-brain ledger states.
+
+The implementation path should use the shared utility layer (`parseLisaUsageSection`,
+`mergeLisaUsageEntries`, `createLisaUsageRollup`, `upsertLisaUsageSection`) rather than duplicating
+token parsing or markdown rendering in each caller.
+
+### Step 4 — Persist and report
+
+1. If the rendered ledger body is byte-identical to the current managed surface, return `outcome:
+   no-op`.
+2. Otherwise write the body or managed comment through the host adapter.
+3. Return the exact writable surface used, direct entry ids, rolled-up child entry ids, totals, and
+   any fallback warning.
+
+If the host write fails, preserve the exact error text in `error.message`. Do not collapse write
+failures into a generic "usage update failed."
+
+## Rules
+
+- Never invent a per-flow usage format. All usage-ledger writes go through this skill and the
+  canonical `usage-accounting` rule.
+- Never append a second `## Lisa Usage` section or a second managed usage comment.
+- Never treat missing usage as zero. Callers must record explicit `source: unavailable` entries.
+- Never skip rollup dedupe. Child totals are keyed by stable `entry_id`, not by child ref count.
+- Never silently drop to comments. Return `outcome: comment-fallback` so the caller can surface the
+  writable surface that actually holds the ledger.
+- Never overwrite unrelated artifact body content. Rewrite only the managed usage section/comment.

package/plugins/lisa-copilot/skills/lisa-use-the-product/SKILL.md

@@ -0,0 +1,86 @@
+---
+name: lisa-use-the-product
+description: Shared methodology for actually USING a project's product the way its real end user would — across product types (DOM web app, HTTP/API backend, canvas game, CLI/library, IaC/CDK). Detects the product's consumer-facing interface, drives it as that consumer, gated by a per-environment mutation policy read from .lisa.config.json (so the agent never mutates production data by accident), and lensed through the project's personas/subagents when it defines them. Invoked by exploratory-qa (files defect/UX tickets) and product-walkthrough (grounds planning in the live product); rarely run standalone.
+---
+
+# Use the Product
+
+## The one idea
+
+Every product has a **consumer-facing interface**. To evaluate a product you (1) **detect** that interface, (2) **resolve where you're allowed to drive it and how much you may change**, and (3) **drive it as the real consumer would** — through the project's personas when it has them. This skill owns steps 1–4 below; the **caller** decides what to *do* with what you find (`exploratory-qa` files tickets, `product-walkthrough` grounds planning).
+
+Driving the product means **interacting** with it. Static route scans, HTTP fetches, screenshots-alone, and reading the code are *supporting evidence only* — never a substitute for actually using it.
+
+## 1. Detect the product type & interface
+
+Infer from the repo; if genuinely ambiguous, ask one concise question.
+
+| Signals | Type | Consumer-facing interface |
+|---|---|---|
+| `vite`/`next`/`angular`/`svelte` + `index.html`, DOM UI | **DOM web app** | the rendered UI in a real browser |
+| API server (`nest`/`express`/`fastify`/serverless handlers), OpenAPI, no frontend | **HTTP / API backend** | the API endpoints |
+| `phaser`/`pixi`/canvas game | **Canvas game** | the canvas + input (keyboard/pointer), read visually |
+| `cdk.json` / Terraform / IaC | **IaC / CDK** | the resources it provisions (+ synth output) |
+| `bin/` CLI or published library, no server | **CLI / library** | the commands / public API |
+
+## 2. Resolve the environment & mutation policy — the gate
+
+Read the `exploration` block from `.lisa.config.json` (a repo-local config overrides a global one):
+
+```jsonc
+"exploration": {
+  "default": "<env-name>",              // which env to use when none is passed
+  "environments": {
+    "<name>": {
+      "url": "https://dev.example.io",  // web/API target (omit for local CLI/game)
+      "provision": true,                // IaC/ephemeral: stand up, then tear down
+      "mutation": "forbidden | read-only | full",
+      "identity": "<test-account ref>", // which login to use (env var / 1Password ref)
+      "prodMutationAck": "<one sentence>" // REQUIRED to allow `full` on a production-named env
+    }
+  }
+}
+```
+
+Resolve the target env: explicit argument → `default` → infer. Then the **mutation level governs everything**:
+
+- **`read-only`** — only non-mutating interactions: read endpoints (`GET`), view UI without submitting, `cdk synth`/`diff`, `--help`/dry-run. Never create / edit / delete.
+- **`full`** — create / edit / delete allowed, but **only as the `identity` test account** and under Mutation Discipline (§5).
+- **`forbidden`** — do not exercise this environment at all.
+
+**Safety rules — enforced regardless of config:**
+
+- **No `exploration` block, or an unconfigured env → treat as `read-only`.** Never mutate without an explicit policy.
+- **A production-named env (`prod` / `production`) defaults to `forbidden`.** It may be raised to `full` **only** when a written `prodMutationAck` justification is present (this is how a single-environment app — e.g. a local-only game whose only "env" is production and whose mutations are the user's own local save — deliberately opts in). A bare `production: { "mutation": "full" }` with **no** `prodMutationAck` is downgraded to `forbidden`, and you warn.
+- **Never sign in as a real user or an admin** — only the `identity` test account.
+- If evaluating something *requires* a mutation the policy forbids, stop at that boundary and report it — never escalate your own permissions.
+
+## 3. Discover personas & subagents — soft-detect
+
+Look for the project's personas: `wiki/personas/**` (target-player archetypes, stakeholders) and persona subagents (e.g. the `lisa-phaser` `target-player` / `player-advocate` agents).
+
+- **Present** → drive the product **through each relevant persona**: adopt the archetype's constraints (device, session length, goals, patience, genre-literacy) and evaluate as them; run each archetype for breadth.
+- **Absent** → drive as a single **generic representative end user** of the app's stated audience, and say so.
+
+## 4. Drive the product — per type
+
+Apply the interface's *read-only* actions always; the *mutate* actions only when the policy is `full`.
+
+- **DOM web app** — a real browser (Playwright MCP). Land cold on the entry page, then click / type / select / submit visible controls and attempt real tasks; sweep viewport widths. *(The caller's lens supplies the specific things to look for.)*
+- **HTTP / API backend** — the consumer is a client, not a browser. Read-only: read the OpenAPI/routes and call safe `GET`s (`curl`/`httpie`). Mutate: exercise representative `POST`/`PUT`/`DELETE` flows with test data as the `identity`; check status codes, payload shapes, and error responses.
+- **Canvas game** — a real browser, but the UI is **drawn to a canvas, not the DOM**. Boot it (e.g. `bun run dev` + Playwright), drive via **keyboard/pointer into the canvas**, and read state **visually via screenshots** (not the accessibility tree). Mutation is usually local save state. Judge readability, game-feel, and input responsiveness — not DOM breakpoints.
+- **CLI / library** — the interface is the command / public API. Read-only: `--help`, read-only commands, dry-runs. Mutate: run state-changing commands with disposable inputs.
+- **IaC / CDK** — the "user" is whoever **consumes the resources the stack provisions** (plus the operator). **Read-only (default):** `cdk synth` → read the generated template; `cdk diff` vs. the deployed env; verify the resources, IAM, and outputs express what a consumer would expect. Flag over-broad IAM, missing/opaque outputs, resources that don't serve their stated purpose, and drift. **Mutate (only when `mutation: "full"` *and* `provision: true` on an ephemeral/sandbox env):** `cdk deploy` to the sandbox → recurse into the API/web playbook against the provisioned resources → `cdk destroy`. Never deploy to a real account without explicit sandbox-provisioning config.
+
+## 5. Mutation Discipline — only when the policy is `full`
+
+A real user creates, edits, and deletes things — exercise those flows when, and only when, the policy allows and always as the `identity` account.
+
+- Use unique names with a clear prefix such as `qa-` or `codex-`.
+- Before mutating, identify the cleanup path. After mutating, make a best effort to clean up, then verify it. If cleanup is unavailable, that itself is a finding.
+- Avoid destructive bulk actions unless the account/data is clearly disposable.
+- Record every mutation performed, cleanup attempts, and any residue left behind.
+
+## What you return
+
+Structured, raw observations for the caller — **what** you did, **as whom** (which persona / generic user), **where** (env + mutation level), **what you saw**, and **what you could not reach and why** (especially policy boundaries you stopped at). You do **not** file tickets or write plans; the caller does.

package/plugins/lisa-copilot/skills/lisa-validate-tracker-mapping/SKILL.md

@@ -0,0 +1,188 @@
+---
+name: lisa-validate-tracker-mapping
+description: "Detect and repair drift between a project's configured Lisa status/label mappings and the live tracker/source workflow. Compares every lifecycle role in `.lisa.config.json` (JIRA `jira.workflow` statuses, GitHub/Linear `labels.{build,prd}`, Notion `notion.values` select options, Confluence `confluence.parents`) against the authoritative live names the access layer reports — catching renames, deletions, and case drift (e.g. config `On Stg` vs live `ON STG`). Read-only by default; `repair=true` rewrites the config to the canonical live names (config is fixed, never the tracker). Audits the current repo by default, or sweeps a set of projects via `projects=<glob>` / `workspaces=<file>`. Safe to schedule for continuous drift detection."
+allowed-tools: ["Skill", "Bash", "Read", "Write", "Edit", "AskUserQuestion"]
+---
+
+# Validate Tracker Mapping: $ARGUMENTS
+
+`/lisa:validate-tracker-mapping` answers one question: **do the status/label names this project's `.lisa.config.json` maps each lifecycle role to still exist — with the exact name — in the live tracker and PRD source?**
+
+Lisa's lifecycle is driven by configured role → name mappings (`ready` → `"Ready"`, `done.staging` → `"On Stg"`, a GitHub `ready` build label → `"status:ready"`, a Notion `ticketed` value → `"Ticketed"`, …). When someone renames or deletes a status in JIRA, a label in GitHub/Linear, or a select option in Notion, the config silently points at a name that no longer resolves. The symptom is downstream: a build finishes but the completion transition can't be found, so the item stalls — exactly the kind of half-broken state `/lisa:repair-intake` then has to clean up. This skill catches that drift at the source: the config-to-live mapping itself.
+
+It is the audit/repair counterpart to `/lisa:setup-jira` (and the other `setup-*` skills): where `setup-*` *establishes* the mapping interactively, this skill *re-validates an existing mapping* against the live workflow and, on request, repairs the config to match.
+
+## Confirmation policy
+
+- **Default mode is read-only.** Detect drift and report. Never mutate config or the tracker.
+- **`repair=true` enables writes — to the config only, never to the tracker.** Within repair mode:
+  - **Case drift** (the live workflow has the same name with different casing — the configured name resolves case-insensitively but the canonical case differs) is repaired automatically: rewrite the config value to the live canonical name. This is non-destructive and unambiguous.
+  - **Missing name** (no case-insensitive match exists in the live set — renamed beyond recognition or deleted) is **never** auto-repaired. Compute the closest live candidates and confirm via `AskUserQuestion` before writing. Default to leaving the value unchanged.
+- This skill never renames or deletes anything in the tracker/source. Repair fixes the Lisa config to match reality; correcting the tracker itself is a human/admin decision made elsewhere.
+
+## Arguments
+
+- (none) — audit the **current repo** (`./.lisa.config.json`).
+- `projects=<glob-or-path>` — batch sweep. Expands to every directory under the glob that contains a `.lisa.config.json`. Example: `projects=~/workspace/geminisportsai/projects/*`.
+- `workspaces=<file>` — batch sweep driven by a Lisa workspaces file (the `{ "<project-path>": "<branch>" }` map used by `/lisa:update-projects`). Each key is a project path to audit. Combine with `filter=<substring>` to restrict to matching paths (e.g. `filter=geminisportsai`).
+- `repair=true` — enable config repair (see confirmation policy). Default `false`.
+- `lane=build|prd|both` — which mapping family to check. Default `both`. `build` = the destination `tracker` workflow; `prd` = the PRD `source` status/label mapping.
+
+Batch mode runs the identical per-project audit on each resolved project and prints one section per project plus a roll-up summary.
+
+## Step 1 — Resolve scope
+
+```bash
+# Single-repo (default): the audit target is the current directory.
+# Batch: expand projects=<glob> to dirs containing .lisa.config.json,
+# or read workspaces=<file> keys (optionally filtered).
+```
+
+For `workspaces=<file>`, parse with `jq` (never grep/sed JSON):
+
+```bash
+jq -r 'keys[]' "$WORKSPACES_FILE" \
+  | sed "s#^~#$HOME#" \
+  | while read -r proj; do
+      [ -n "$FILTER" ] && case "$proj" in *"$FILTER"*) : ;; *) continue ;; esac
+      [ -f "$proj/.lisa.config.json" ] && echo "$proj"
+    done
+```
+
+Skip (and note) any path with no `.lisa.config.json`.
+
+## Step 2 — Load the project's mappings
+
+For each project, read `.lisa.config.json`:
+
+```bash
+tracker=$(jq -r '.tracker // "jira"' .lisa.config.json)
+source=$(jq -r '.source // empty' .lisa.config.json)
+```
+
+Resolve the **effective** role → name mapping using the same defaults `/lisa:intake` and `/lisa:setup-jira` use (config-resolution contract). Only keys present in config override the defaults; absent keys fall back to the documented default. Build the list of `(role, configured-name)` pairs to validate:
+
+- **JIRA build workflow** (`jira.workflow`): `ready`, `claimed`, optional `review`, `blocked`, and each `done.<env>` (`dev` / `staging` / `production`). Defaults: `Ready`, `In Progress`, `Code Review`, `Blocked`, `{dev: "On Dev", staging: "On Stg", production: "Done"}`.
+- **GitHub build/prd labels** (`github.labels.build`, `github.labels.prd`): each configured label string.
+- **Linear build/prd labels** (`linear.labels.build`, `linear.labels.prd`): each configured label/state string.
+- **Notion PRD values** (`notion.values`): each configured select-option value, validated against the `notion.statusProperty` property's options.
+- **Confluence PRD parents** (`confluence.parents`): each configured parent page id, validated by existence.
+
+## Step 3 — Enumerate the authoritative live name set
+
+Resolve the live, canonical names per vendor through the **same access layer the rest of Lisa uses** — never a second source of truth.
+
+### JIRA (via `/lisa:atlassian-access`)
+
+First confirm the active substrate is authenticated to **this project's** `atlassian.cloudId` / `atlassian.site`. `/lisa:atlassian-access` already enforces account identity: a substrate authed as a different Atlassian account is skipped, not used. If no substrate matches the configured account, mark the project `UNRESOLVABLE` (auth mismatch) and move on — do **not** validate against the wrong instance, and do **not** trust a case-insensitive JQL pass as proof.
+
+Enumerate the project's full workflow status set, preferring the most authoritative substrate:
+
+1. **curl** (authoritative — all statuses, including empty ones):
+   ```bash
+   # GET /rest/api/3/project/<KEY>/statuses → union of canonical status names across issue types
+   # via lisa-atlassian-access curl substrate
+   # jq: '[.[].statuses[].name] | unique'
+   ```
+2. **MCP fallback** (when curl creds aren't available): union of `to.name` from `getTransitionsForJiraIssue` (with `includeUnavailableTransitions=true`) on a sample ticket, plus changelog-observed names (`fromString`/`toString`). This can miss a status that is empty *and* unreachable from the sample, so when only this substrate is available, report the enumeration method in the output so the operator knows the set may be partial.
+
+> Note: JQL `status = "<name>"` matching is **case-insensitive**, so a JQL probe that "passes" does **not** prove the configured casing matches. Always compare against the canonical `status.name` strings from the enumeration above, case-sensitively.
+
+### GitHub (via `gh`)
+
+```bash
+gh label list --repo "$REPO" --limit 200 --json name -q '.[].name'
+```
+
+### Linear / Notion / Confluence
+
+Enumerate via the corresponding access surface (Linear MCP workflow states + labels; Notion data-source select options for `notion.statusProperty`; Confluence page-exists check per parent id). Same compare-exact-case contract as JIRA.
+
+## Step 4 — Compare (exact case)
+
+For each `(role, configured-name)` pair, classify against the live name set:
+
+- **VALID** — an exact-case match exists in the live set.
+- **CASE_DRIFT** — a case-insensitive match exists but no exact-case match (e.g. config `"On Stg"` vs live `"ON STG"`). Canonical = the live exact name.
+- **MISSING** — no case-insensitive match exists. The name was renamed beyond recognition or deleted.
+
+A project's verdict:
+
+- **VALID** — every role is VALID.
+- **DRIFTED** — at least one CASE_DRIFT or MISSING role, none of which is UNRESOLVABLE.
+- **UNRESOLVABLE** — the live set couldn't be enumerated (auth mismatch, missing tracker config, access failure). Distinguish this loudly from VALID — an unresolved audit is not a passing audit.
+
+## Step 5 — Report
+
+Per project, print a terminal-first section:
+
+```
+<project-path>  [tracker=<vendor> project/repo=<id>]  VERDICT
+  role            configured        live (canonical)    status
+  ready           Ready             Ready               VALID
+  claimed         In Progress       In Progress         VALID
+  blocked         Blocked           Blocked             VALID
+  done.dev        On Dev            On Dev              VALID
+  done.staging    On Stg            ON STG              CASE_DRIFT  → fix: "ON STG"
+  done.production Done              Done                VALID
+```
+
+End with a roll-up: counts of VALID / DRIFTED / UNRESOLVABLE projects and the exact next command (`… repair=true` when drift is auto-repairable; an admin note when a status is genuinely MISSING).
+
+## Step 6 — Repair (only when `repair=true`)
+
+For each drifted role, repair the **config** (preserve everything else; only write changed keys; always `jq … > tmp && mv`):
+
+### CASE_DRIFT — automatic
+
+Rewrite the configured value to the live canonical name. Examples:
+
+```bash
+# scalar role (ready/claimed/blocked/review)
+jq --arg v "$CANONICAL" '.jira.workflow.<role> = $v' \
+  .lisa.config.json > .lisa.config.json.tmp && mv .lisa.config.json.tmp .lisa.config.json
+
+# done.<env>
+jq --arg v "$CANONICAL" '.jira.workflow.done.<env> = $v' \
+  .lisa.config.json > .lisa.config.json.tmp && mv .lisa.config.json.tmp .lisa.config.json
+
+# github/linear label
+jq --arg v "$CANONICAL" '.github.labels.<lane>.<role> = $v' \
+  .lisa.config.json > .lisa.config.json.tmp && mv .lisa.config.json.tmp .lisa.config.json
+```
+
+### MISSING — confirm first
+
+Compute the closest live candidates (case-insensitive token/substring overlap, then edit distance). Present via `AskUserQuestion`:
+
+> Role `<role>` maps to `<configured>`, which no longer exists in `<vendor>`. Closest live names: `<c1>`, `<c2>`, `<c3>`. Pick the replacement, leave unchanged, or enter a name manually.
+
+Only write on an explicit pick. Never auto-select. If the user leaves it unchanged, keep the project `DRIFTED` and surface the admin remediation (add the status back, or fix it in the tracker).
+
+### Invalidate the verification cache
+
+After any JIRA repair, clear the `setup-jira` reachability cache so it re-verifies the new mapping:
+
+```bash
+jq 'if .jira then .jira.verified_workflow_hash = null else . end' \
+  .lisa.config.local.json > .lisa.config.local.json.tmp 2>/dev/null \
+  && mv .lisa.config.local.json.tmp .lisa.config.local.json || true
+```
+
+Re-print the project section showing the post-repair mapping and the new verdict (VALID if every role now resolves).
+
+## Idempotency & repeatability
+
+- Re-running on a clean config reports `VALID` and writes nothing.
+- Read-only mode has no side effects and is safe to schedule. Pair with `/schedule` (or run in CI) to detect drift continuously; run `repair=true` interactively when drift appears (the `MISSING` path needs a human decision and should not run unattended).
+- Repair only ever touches `.lisa.config.json` (and clears the local verification-cache key) — it preserves all unrelated config and never stages secrets or env values.
+
+## Rules
+
+- Compare status/label names **case-sensitively** against the live canonical set. A case-insensitive tracker query (e.g. JQL) that resolves is not proof the casing matches.
+- Verify the access substrate is authenticated to the **configured** account before trusting any enumeration. An audit run against the wrong instance is `UNRESOLVABLE`, not `VALID`.
+- Repair fixes the **config**, never the tracker. Do not rename or delete tracker statuses, labels, or options.
+- Never auto-repair a `MISSING` mapping; confirm the replacement via `AskUserQuestion`.
+- Use `jq` for all JSON reads/writes; write only changed keys via `jq … > tmp && mv`.
+- In batch mode, audit each project independently — one project's `UNRESOLVABLE` (e.g. an auth mismatch) must not abort the rest of the sweep.
+- Reuse the config-resolution defaults and the vendor access skills (`atlassian-access`, `gh`, Linear/Notion MCP); do not invent a parallel mapping or lifecycle vocabulary.