@codyswann/lisa 2.195.4 → 2.195.6

package/plugins/lisa/.codex-plugin/skills/lisa-automation-status/SKILL.md

@@ -0,0 +1,111 @@
+---
+name: lisa-automation-status
+description: "Read-only operator surface for…"
+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:
+
+- `intake-repair`
+- `intake-prd`
+- `intake-tickets`
+- `exploratory-bugs` when the current stack supports `exploratory-qa`
+- `exploratory-prds`
+
+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.
+
+## 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.
+
+Emit an overall grouped fleet verdict such as `HEALTHY`, `ATTENTION_NEEDED`, or `PARTIAL_SUPPORT`, plus the runtime surface inspected.
+
+## 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.
+- `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>
+  Remediation: <next step when attention is needed>
+```
+
+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/.codex-plugin/skills/lisa-automation-status/agents/openai.yaml

@@ -0,0 +1,4 @@
+display_name: "Automation Status"
+short_description: "Read-only operator surface for…"
+default_prompt:
+  - "Use $lisa-automation-status: Read-only operator surface for…."

package/plugins/lisa/.codex-plugin/skills/lisa-bug-triage/SKILL.md

@@ -0,0 +1,23 @@
+---
+name: lisa-bug-triage
+description: "8-step bug triage and…"
+---
+
+# 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. If you cannot reproduce it, stop and report what you tried and what you observed.
+3. Once reproduced, verify you are 100% positive on how to fix it. If not, determine what you need to do to be 100% positive (e.g. add logging, trace the code path, inspect state) and do that first.
+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/.codex-plugin/skills/lisa-bug-triage/agents/openai.yaml

@@ -0,0 +1,4 @@
+display_name: "Bug Triage"
+short_description: "8-step bug triage and…"
+default_prompt:
+  - "Use $lisa-bug-triage: 8-step bug triage and…."

package/plugins/lisa/.codex-plugin/skills/lisa-codebase-research/SKILL.md

@@ -0,0 +1,87 @@
+---
+name: lisa-codebase-research
+description: "Codebase exploration and…"
+---
+
+# Codebase Research
+
+Systematically explore and analyze a codebase to understand its architecture, trace data flow, and identify how to make changes safely.
+
+## Analysis Process
+
+Follow these steps in order. Do not skip steps or propose changes to code you have not read.
+
+### 1. Read Referenced Files
+
+- Read every file that is directly relevant to the task
+- Understand the current architecture before proposing changes
+- Read imports and dependencies to understand the module graph
+- Check for configuration files that affect behavior (tsconfig, eslint, webpack, etc.)
+
+### 2. Trace Data Flow
+
+- Follow the path from entry point to output for the affected feature
+- Identify every transformation the data undergoes
+- Map inputs, intermediate states, and outputs
+- Note where data crosses boundaries (API calls, database queries, message queues)
+
+### 3. Identify Modification Points
+
+- Determine which files, functions, and interfaces need changes
+- Note the exact lines where modifications are required
+- Identify any type definitions, schemas, or contracts that must be updated
+- Check for generated code that may need regeneration
+
+### 4. Map Dependencies
+
+- Identify what depends on the code being changed (downstream consumers)
+- Identify what the code being changed depends on (upstream providers)
+- Determine the safe modification order to avoid breaking intermediate states
+- Flag any circular dependencies
+
+### 5. Check for Reusable Code
+
+- Search for existing utilities, helpers, or patterns that apply to the task
+- Check shared libraries and common modules
+- Look for similar implementations elsewhere in the codebase that can be referenced
+- Prefer reusing existing code over creating new abstractions
+
+### 6. Evaluate Design Patterns
+
+- Match the codebase's existing patterns -- do not introduce new architectural patterns without reason
+- Check naming conventions, file organization, and code style
+- Identify any patterns that are partially implemented and should be completed
+- Note anti-patterns that should not be propagated
+
+## Output Format
+
+```text
+## Architecture Analysis
+
+### Files to Create
+- `path/to/file.ts` -- purpose
+
+### Files to Modify
+- `path/to/file.ts:L42-L68` -- what changes and why
+
+### Dependency Graph
+- [file A] -> [file B] -> [file C] (modification order)
+
+### Design Decisions
+| Decision | Choice | Rationale |
+|----------|--------|-----------|
+
+### Reusable Code
+- `path/to/util.ts:functionName` -- how it applies
+
+### Risks
+- [risk description] -- [mitigation]
+```
+
+## Rules
+
+- Always read files before recommending changes to them
+- Follow existing patterns in the codebase -- do not introduce new architectural patterns unless explicitly required
+- Include file:line references for all recommendations
+- Flag breaking changes explicitly
+- Keep the modification surface area as small as possible

package/plugins/lisa/.codex-plugin/skills/lisa-codebase-research/agents/openai.yaml

@@ -0,0 +1,4 @@
+display_name: "Codebase Research"
+short_description: "Codebase exploration and…"
+default_prompt:
+  - "Use $lisa-codebase-research: Codebase exploration and…."

package/plugins/lisa/.codex-plugin/skills/lisa-codify-verification/SKILL.md

@@ -0,0 +1,162 @@
+---
+name: lisa-codify-verification
+description: "Convert empirical verification…"
+allowed-tools: ["Bash", "Read", "Edit", "Write", "Glob", "Grep", "Skill"]
+---
+
+# Codify Verification: $ARGUMENTS
+
+Take the empirical verification that just passed and encode it as an automated regression test. The manual proof becomes a repeatable check that catches future regressions.
+
+This skill is invoked from the verification lifecycle (between Execute and Spec Conformance) and from each work-type sub-flow (Build / Fix / Improve) after the local verification step.
+
+## When to invoke
+
+Invoke once per empirical verification that produced PASS evidence. If a single change had three verifications (UI flow, API endpoint, DB query), this skill runs three times — or once with the three verifications batched, but each must produce its own committed test.
+
+## When to skip
+
+Skip codification only for verification types whose proof is inherently non-behavioral:
+
+- **PR** — proof is the PR description itself
+- **Documentation** — proof is content review
+- **Deploy** — proof is deployment output and health endpoints (already covered by ops-verify-health)
+- **Investigate-Only spikes** — produce findings, not shipped code
+
+For every other verification type, codification is mandatory. If the codification is not possible (e.g., the test framework doesn't exist and can't be installed in scope), escalate via the lifecycle's Escalation Protocol — do not silently skip.
+
+## Inputs
+
+The caller must provide:
+
+- The verification type (UI, API, Database, Auth, Security, Performance, Background Jobs, Cache, Configuration, Email/Notification, Observability, Infrastructure)
+- The exact steps that were performed (URL visited, request made, query run, etc.)
+- The expected outcome (status code, UI state, row count, log entry, etc.)
+- The proof artifact captured (screenshot path, response body, query output, log excerpt)
+
+If any of these are missing, ask the caller before generating a test — a test built on guesswork will not match the verification it claims to encode.
+
+## Process
+
+### 1. Discover existing test infrastructure
+
+Before creating anything new, find what the project already has. Use the Tool Discovery Process from `verification-lifecycle`. Specifically check for:
+
+- **Browser/E2E**: `playwright.config.*`, `cypress.config.*`, `e2e/` directory, `tests/e2e/`, Playwright/Cypress in `package.json` devDependencies
+- **API/integration**: `tests/integration/`, `spec/`, `test/integration/`, supertest/fetch helpers, Vitest/Jest integration configs
+- **Database**: integration test setup with migrations, factory files, seed scripts
+- **Performance**: existing benchmark suite (`benchmarks/`, `bench/`), `vitest bench`, k6 scripts
+- **Mobile (RN/Expo)**: Detox config, Maestro flows
+- **Backend jobs**: existing job-test harness, queue integration tests
+
+Do NOT install a new framework if one already exists for the verification type. Use what's there.
+
+### 2. Map verification type → framework
+
+| Verification type | Preferred framework (use whichever the project already has) |
+|---|---|
+| UI (web) | Playwright > Cypress > Selenium |
+| UI (mobile) | Maestro > Detox > Playwright (mobile emulation) |
+| API | project's integration test runner (Vitest / Jest / RSpec / pytest) with HTTP client (supertest / fetch / faraday) |
+| Database | integration test with real DB + migrations applied |
+| Auth | API or UI test asserting role-gated access (multi-role coverage) |
+| Security | regression test that reproduces the attack and asserts safe handling |
+| Performance | benchmark in the project's bench harness, asserting against the baseline captured in the verification |
+| Background Jobs | integration test that enqueues, drains the queue, and asserts terminal state |
+| Cache | integration test asserting hit/miss/invalidation behavior |
+| Configuration | integration test that loads config and asserts effect |
+| Email/Notification | test capturing outbound message via project's mailer test mode |
+| Observability | test asserting structured log/metric/trace emission |
+| Infrastructure | test or script asserting infra state (terraform plan diff, CDK snapshot test) |
+
+If the project lacks the preferred framework AND no acceptable substitute exists, escalate.
+
+### 3. Generate the test
+
+The generated test must:
+
+- **Encode the exact verification that passed**, not a paraphrase. Same URL, same input, same assertion target.
+- **Assert the observable outcome**, not implementation details. If the verification confirmed "user sees order confirmation", the test asserts that text/element is visible — not that a particular function was called.
+- **Be deterministic.** No reliance on timing, network flakiness, real third-party services, or mutable shared state. Use the project's existing fixtures, factories, mocks, and seed data conventions.
+- **Be self-contained.** Set up its own preconditions and clean up after itself, following the project's existing test isolation patterns.
+- **Be named after the behavior, not the bug/ticket.** `displays order confirmation after checkout` not `fixes PROJ-1234`.
+- **Live in the project's existing test directory** for that type. Do not create a parallel test tree.
+
+For Playwright UI tests specifically:
+- Use the project's existing `test` fixture / `page` fixture / auth helper if one exists
+- Prefer role/text selectors (`getByRole`, `getByText`) over CSS/XPath — they survive markup churn
+- Capture a trace or screenshot only if the project's existing tests do; do not invent a new artifact convention
+- Mirror the project's existing config for base URL, retries, and test isolation
+
+**Concrete verification (UAT) contract.** Verification *is* UAT — codifying it is
+how the playthrough becomes durable. For a runtime/behavioral `feat`/`fix`: place
+the codified test where the project's e2e/Playwright tests live (`tests/e2e/**`)
+so CI re-runs it, and commit the evidence artifact to `evidence/<ticket>/`
+(`verdict.json` + state + screenshots). For a Phaser game, drive the canvas
+through the in-game verification test bridge (seed RNG, read state, inject input,
+step frames) with deterministic rendering. CI's `verification-coverage` check
+requires a verification-spec delta on every behavioral change. See the
+`reference/verification.md` "Making verification concrete (UAT)" section.
+
+### 4. Run the test in isolation
+
+Run only the new test, using whatever per-test invocation the project supports:
+
+- Playwright: `npx playwright test path/to/new.spec.ts`
+- Vitest: `npx vitest run path/to/new.spec.ts`
+- Jest: `npx jest path/to/new.test.ts`
+- RSpec: `bundle exec rspec path/to/new_spec.rb`
+
+Confirm:
+1. The test PASSES against the current code (the change being shipped)
+2. The test would have FAILED before the change (sanity check by mentally reverting, or for bug fixes, by running against the pre-fix commit if cheap)
+
+For a bug fix, step 2 is mandatory and easy: check out the failing commit, run the new test, see it fail, return to the fix branch. This proves the test actually guards the regression.
+
+### 5. Wire it into the suite
+
+Confirm the test is picked up by the project's standard test command (the one CI runs). Run that command and confirm the count went up by exactly the number of tests added.
+
+If the test is in a directory the standard test command excludes (e.g., E2E suite that runs separately in CI), confirm the appropriate CI workflow includes it.
+
+### 6. Commit
+
+Commit the test in the same PR as the change it codifies, in its own atomic commit:
+
+- Build/feature: `test: add e2e for <behavior>`
+- Bug fix: `test: add regression test for <bug behavior>`
+- Performance: `test: add benchmark asserting <metric> <baseline>`
+
+The commit message body should reference the verification it encodes (one line linking to the proof artifact or the verification report section).
+
+### 7. Record evidence
+
+Append to the verification report (or PR description):
+
+```markdown
+### Codified Verifications
+
+| # | Verification | Framework | Test file | Status |
+|---|--------------|-----------|-----------|--------|
+| 1 | <description> | Playwright | `e2e/checkout.spec.ts::displays order confirmation after checkout` | PASS |
+```
+
+This evidence shows the verification is now guarded.
+
+## Output
+
+For each empirical verification passed in:
+
+- A new test file (or extension to an existing test file) committed to the PR
+- Confirmation that the test passes against the current branch
+- The test file path + test name recorded in the verification report
+
+If codification was skipped, an explicit reason recorded in the report (one of the skip conditions above) — never silent.
+
+## Rules
+
+- Never claim a verification is codified without running the new test and observing it pass
+- Never disable, skip, or `.skip()` the new test "temporarily" to make CI green — fix the test or fix the underlying change
+- Never use `expect(true).toBe(true)` placeholders or smoke-only assertions that don't actually exercise the verified behavior
+- Never reuse the verification's manual artifact (screenshot, curl output) as a "test" — those are evidence, not regression coverage
+- If the project lacks the appropriate framework, escalate via Human Action Packet rather than installing one mid-task without approval

package/plugins/lisa/.codex-plugin/skills/lisa-codify-verification/agents/openai.yaml

@@ -0,0 +1,4 @@
+display_name: "Codify Verification"
+short_description: "Convert empirical verification…"
+default_prompt:
+  - "Use $lisa-codify-verification: Convert empirical verification…."