@codyswann/lisa 2.201.0 → 2.203.0

package/plugins/lisa-copilot/skills/lisa-jira-validate-ticket/SKILL.md

@@ -93,6 +93,7 @@ Each gate is tagged with a fixed `category` and a `product_relevant` boolean. Ca
 | F2 Epic parent exists and is an Epic | `structural` | false |
 | F3 Linked tickets exist | `structural` | false |
 | F4 Required custom fields populated | `structural` | false |
+| F5 Required external access provable | `technical` | true |
 
 Category values are drawn from this fixed set:
 
@@ -246,6 +247,31 @@ For each entry in `links`, invoke `lisa-atlassian-access` `operation: read-ticke
 
 Use the same project-issue-type-metadata lookup from F1 (via `lisa-atlassian-access`) to learn required custom fields for the issue type. Any required custom field not provided in the spec: FAIL.
 
+#### F5 — Required external access provable
+
+The factory-gate rule: an input must not enter the pipeline unless the current runtime can actually
+reach every external surface the work requires. Enumerate the surfaces this item depends on:
+
+- artifact links in the body (documents, designs, dashboards, spreadsheets, recordings),
+- systems named by the description, acceptance criteria, or Validation Journey ("read the CloudWatch
+  alarms", "pull the copy from the Google Doc", "check the Sentry issues"),
+- tooling the work plainly implies (a deploy target, a database, a third-party API).
+
+For each surface, prove **read** access from the current runtime with the cheapest read-only probe
+through the sanctioned access layer: the matching MCP tool or `lisa-*-access` skill, CLI auth
+(`aws sts get-caller-identity`, `gh auth status`, vendor equivalents), or an authenticated fetch of
+the linked artifact. Attempt to resolve a gap before failing — an alternate substrate, a configured
+access layer, a keychain credential — mirroring the intake agent's discover-first duty.
+
+- `PASS` — every required surface is provably readable.
+- `N/A` — the item needs nothing beyond the repository and the tracker itself.
+- `FAIL` — a required surface is unreachable after the resolution attempt. Name the exact surface
+  and what was probed. Intake callers must route this to `blocked` + human escalation with the
+  missing access spelled out — an input the factory cannot execute never enters the factory.
+
+Probes are read-only and bounded (seconds, not minutes, per surface); never mutate the external
+system, and never invent or ask for credentials inline.
+
 ## Execution
 
 1. Parse `$ARGUMENTS`. If it's a ticket key, fetch the ticket via `lisa-atlassian-access` `operation: read-ticket` and derive the spec from the fetched fields — including `build_ready` (label set contains `status:ready`) and `child_refs` (sub-tasks plus `is blocked by` parentage, resolved as in `lisa-jira-read-ticket`) so S15 can classify the ticket. When the fetched description is ADF, walk the document tree and extract section headings from ADF `heading` nodes, then collect the text between heading nodes for section-specific gates. If the fetched description is a single paragraph containing literal Markdown/wiki heading markers, treat that as a formatting failure rather than accepting substring matches. Otherwise parse the YAML spec.
@@ -283,6 +309,7 @@ Output is a single fenced text block. Callers parse it; do not add free-form pro
 - [PASS|FAIL|N/A] F2 Epic parent exists and is an Epic — <one-line reason>
 - [PASS|FAIL|N/A] F3 Linked tickets exist — <one-line reason>
 - [PASS|FAIL|N/A] F4 Required custom fields populated — <one-line reason>
+- [PASS|FAIL|N/A] F5 Required external access provable — <one-line reason>
 
 ### Verdict: PASS | FAIL
 ### Failures: <count>
@@ -301,7 +328,7 @@ The verdict is `PASS` if and only if every applicable gate is `PASS`. Any `FAIL`
 
 ### Failure-detail fields
 
-- **gate**: the gate ID (`S1`–`S15`, `F1`–`F4`).
+- **gate**: the gate ID (`S1`–`S15`, `F1`–`F5`).
 - **category**: the gate's fixed category from the table above. Callers use this to label or filter comments — `product-clarity`, `acceptance-criteria`, `design-ux`, `scope`, `dependency`, `data`, `technical`, or `structural`.
 - **product_relevant**: matches the gate's table entry. `false` means the failure is an internal data-quality problem (e.g., the agent built a malformed spec, an issue type is invalid in the project) and the caller should fix it without bothering the product team. `true` means the PRD needs product input to resolve.
 - **what**: plain-language description of the issue. No gate IDs, no JIRA jargon, no engineering shorthand. A product owner reading this on a Notion comment should understand what is unclear and why.

package/plugins/lisa-copilot/skills/lisa-linear-validate-issue/SKILL.md

@@ -94,6 +94,7 @@ Each gate is tagged with a fixed `category` and a `product_relevant` boolean. Ca
 | F2 Project parent exists and is in same team | `structural` | false |
 | F3 Linked items exist | `structural` | false |
 | F4 Required labels exist (or can be created) | `structural` | false |
+| F5 Required external access provable | `technical` | true |
 
 Category values are the same fixed set as `lisa-jira-validate-ticket`:
 
@@ -253,6 +254,31 @@ For each entry in `relations`, call `lisa-linear-access operation: get-issue` to
 
 For each label referenced (`status:*`, `component:<name>`, `prd-*`), confirm via `lisa-linear-access operation: list-issue-labels` (or `lisa-linear-access operation: list-project-labels` for Project labels) that it exists OR is creatable. Linear labels are team-scoped or workspace-scoped; flag if the requested scope is wrong.
 
+#### F5 — Required external access provable
+
+The factory-gate rule: an input must not enter the pipeline unless the current runtime can actually
+reach every external surface the work requires. Enumerate the surfaces this item depends on:
+
+- artifact links in the body (documents, designs, dashboards, spreadsheets, recordings),
+- systems named by the description, acceptance criteria, or Validation Journey ("read the CloudWatch
+  alarms", "pull the copy from the Google Doc", "check the Sentry issues"),
+- tooling the work plainly implies (a deploy target, a database, a third-party API).
+
+For each surface, prove **read** access from the current runtime with the cheapest read-only probe
+through the sanctioned access layer: the matching MCP tool or `lisa-*-access` skill, CLI auth
+(`aws sts get-caller-identity`, `gh auth status`, vendor equivalents), or an authenticated fetch of
+the linked artifact. Attempt to resolve a gap before failing — an alternate substrate, a configured
+access layer, a keychain credential — mirroring the intake agent's discover-first duty.
+
+- `PASS` — every required surface is provably readable.
+- `N/A` — the item needs nothing beyond the repository and the tracker itself.
+- `FAIL` — a required surface is unreachable after the resolution attempt. Name the exact surface
+  and what was probed. Intake callers must route this to `blocked` + human escalation with the
+  missing access spelled out — an input the factory cannot execute never enters the factory.
+
+Probes are read-only and bounded (seconds, not minutes, per surface); never mutate the external
+system, and never invent or ask for credentials inline.
+
 ## Execution
 
 1. Parse `$ARGUMENTS`. If it's an identifier, fetch the item and derive the spec from the fetched fields — including `build_ready` (label set contains `status:ready`) and `child_refs` (sub-issues, project-member issues, plus `blocked_by` parentage, resolved as in `lisa-linear-read-issue`) so S15 can classify the item. Otherwise parse the YAML spec.
@@ -290,6 +316,7 @@ Output is a single fenced text block. Callers parse it; do not add free-form pro
 - [PASS|FAIL|N/A] F2 Project parent exists and is in same team — <one-line reason>
 - [PASS|FAIL|N/A] F3 Linked items exist — <one-line reason>
 - [PASS|FAIL|N/A] F4 Required labels exist (or can be created) — <one-line reason>
+- [PASS|FAIL|N/A] F5 Required external access provable — <one-line reason>
 
 ### Verdict: PASS | FAIL
 ### Failures: <count>

package/plugins/lisa-copilot/skills/lisa-setup-automations/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: lisa-setup-automations
-description: "Set up the recurring Lisa automations on the local workstation using the CURRENT runtime's native scheduler — Codex automations (the native automations / automation_update mechanism) or, on Claude, /schedule. This skill is a declarative specification: it states WHICH automations to create, how often, and with which parameters; it does not template schedule files or run scheduling code itself — the runtime's native automation mechanism does the creating. Creates five automations: intake-repair (every 60 min), intake PRD (every 60 min), intake tickets (every 10 min), exploratory-bugs (once a day), exploratory-prds (once a day). Two flags — auto-start-prds and auto-start-tickets — control whether the ideated PRDs / filed bug tickets are created auto-pickup-ready (prd_ready / ready) or left for human review (default false). Tear down with /tear-down-automations."
+description: "Set up the recurring Lisa automations on the local workstation using the CURRENT runtime's native scheduler — Codex automations (the native automations / automation_update mechanism) or, on Claude, /schedule. This skill is a declarative specification: it states WHICH automations to create, how often, and with which parameters; it does not template schedule files or run scheduling code itself — the runtime's native automation mechanism does the creating. Creates six automations: intake-repair (every 60 min), intake PRD (every 60 min), intake tickets (every 10 min), exploratory-bugs (once a day), exploratory-prds (once a day), monitor (once a day). Two flags — auto-start-prds and auto-start-tickets — control whether the ideated PRDs / filed bug tickets are created auto-pickup-ready (prd_ready / ready, default true) or left for human review. Tear down with /tear-down-automations."
 allowed-tools: ["Skill", "Bash", "Read"]
 ---
 
@@ -28,18 +28,20 @@ create them; invoke the runtime's automation tool with the spec below.
 
 ## Parameters
 
-- `auto-start-prds` (default **false**) — passed as `prd_ready` to the **exploratory-prds**
+- `auto-start-prds` (default **true**) — passed as `prd_ready` to the **exploratory-prds**
   automation. `true` → ideated PRDs are created `prd-ready` (auto-picked-up by PRD intake); `false` →
   created as drafts for human review. When `true`, `/lisa:project-ideation` still checks the configured
   PRD queue before writing: existing `prd-ready`, `prd-in-review`, `prd-blocked`, unresolved
   `prd-ticketed`, or unresolved source-reader pressure can intentionally turn the automation cycle into
   a blocked/idle outcome instead of creating another ready PRD.
-- `auto-start-tickets` (default **false**) — passed as `ready` to the **exploratory-bugs**
+- `auto-start-tickets` (default **true**) — passed as `ready` to the **exploratory-bugs**
   automation. `true` → filed bug/usability tickets are created build-ready (auto-picked-up by ticket
   intake); `false` → created in the backlog for human triage.
 
-Defaults match the underlying skills — nothing auto-starts unless explicitly opted in. The two flags
-affect **only** the two exploratory automations.
+The defaults are autonomous by design — the factory model wants inputs flowing through the gates
+without a human between the loops and the pipeline. Pass `false` explicitly to opt a project into
+human triage. The two flags affect **only** the two exploratory automations; the intake gates'
+adversarial validation remains the quality control either way.
 
 ## The automations to create
 
@@ -62,6 +64,7 @@ report the exact conflicting path(s).
 | **intake-tickets** | `/lisa:intake <build queue>` (e.g. `github intake_mode=build`) | every **10 minutes** |
 | **exploratory-bugs** | `/lisa-<stack>:exploratory-qa ready=<auto-start-tickets>` | **once a day** |
 | **exploratory-prds** | `/lisa:project-ideation prd_ready=<auto-start-prds>` | **once a day** |
+| **monitor** | `/lisa:monitor` | **once a day** |
 
 For a Codex `rrule`: every 60 min → `FREQ=HOURLY;INTERVAL=1`; every 10 min →
 `FREQ=MINUTELY;INTERVAL=10`; once a day → `FREQ=DAILY;INTERVAL=1`.
@@ -92,6 +95,11 @@ place (same names) rather than creating duplicates.
 - **exploratory-bugs** is created only when the project ships an `exploratory-qa` command (the
   `expo` / `rails` / `harper-fabric` stacks). If the project has no `lisa-exploratory-qa` skill/command, skip that
   automation and note it — do not invent a command that doesn't exist.
+- **monitor** is created unconditionally: `/lisa:monitor` resolves the connected observability
+  providers itself and reports gaps (per its `monitor.gapTiers` config) rather than failing when a
+  provider is absent, so an unconnected project gets gap findings instead of a broken automation.
+  Its findings become tracker tickets, feeding the pipeline at the build gate like every other
+  input.
 - If the runtime has no native scheduler, or the intake queues can't be resolved from config, stop
   and report what's missing rather than guessing.
 - For Codex, if the durable checkout cannot be created, fetched, or verified as a non-bare Git work

package/plugins/lisa-copilot/skills/lisa-tear-down-automations/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: lisa-tear-down-automations
-description: "Remove every recurring Lisa automation that /setup-automations created for this project (the lisa-auto-<project>-* set: intake-repair, intake-prd, intake-tickets, exploratory-bugs, exploratory-prds) using the CURRENT runtime's native scheduler — Codex automations or, on Claude, /schedule. This skill is a declarative specification: it identifies WHICH automations to remove; it does not run teardown scripts. Removes only this project's Lisa automations — never other projects' automations or non-Lisa ones. The inverse of /setup-automations."
+description: "Remove every recurring Lisa automation that /setup-automations created for this project (the lisa-auto-<project>-* set: intake-repair, intake-prd, intake-tickets, exploratory-bugs, exploratory-prds, monitor) using the CURRENT runtime's native scheduler — Codex automations or, on Claude, /schedule. This skill is a declarative specification: it identifies WHICH automations to remove; it does not run teardown scripts. Removes only this project's Lisa automations — never other projects' automations or non-Lisa ones. The inverse of /setup-automations."
 allowed-tools: ["Skill", "Bash", "Read"]
 ---
 
@@ -21,9 +21,9 @@ removes them with its **native** scheduling mechanism.
 
 ## Scope (remove only what setup created)
 
-- Remove the five automations `/setup-automations` creates for the current project, matched by the
+- Remove the six automations `/setup-automations` creates for the current project, matched by the
   stable `lisa-auto-<project>-` name prefix: `intake-repair`, `intake-prd`, `intake-tickets`,
-  `exploratory-bugs`, `exploratory-prds`.
+  `exploratory-bugs`, `exploratory-prds`, `monitor`.
 - **Never** remove automations for a different project, or any non-Lisa automation (e.g. unrelated
   crawlers/ingestors). Match strictly on the `lisa-auto-<project>-` prefix for THIS project; when in
   doubt about an automation's ownership, leave it and report it rather than deleting it.

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa",
-  "version": "2.201.0",
+  "version": "2.203.0",
   "description": "Universal governance — agents, skills, commands, hooks, and rules for all projects",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-cursor/commands/lisa/agent-ready.md

@@ -0,0 +1,6 @@
+---
+description: "Make a brownfield project agent-ready: build the initial knowledge wiki from everything the agent can reach, write wiki/gaps.md with the questions only a human can answer, and converge over re-runs (humans answer, agents absorb) until zero gaps remain. Run before letting the automation fleet operate a brownfield project unattended."
+argument-hint: "[path]"
+---
+
+Use the /lisa-agent-ready skill to build the initial knowledge wiki from every reachable source, write the human-answerable gaps to wiki/gaps.md, absorb any answered gaps from a prior run, and report whether the project is agent-ready or how many gaps remain. $ARGUMENTS

package/plugins/lisa-cursor/rules/factory-model-reference.mdc

@@ -0,0 +1,112 @@
+---
+description: "The Factory Model"
+alwaysApply: false
+---
+
+# The Factory Model
+
+Lisa's purpose is to run **software factories** in the host project: agent-operated production
+lines that research, plan, implement, and verify software with as few humans as possible. This
+reference maps the model onto the concrete Lisa surfaces so agents act on it rather than around it.
+
+## Who this is for
+
+The goal of the factory setup is to let **non-technical people create scalable, enterprise-grade
+software** by describing outcomes; the factories supply the engineering discipline. This lowers the
+floor without capping the ceiling — engineers get leverage from the same machinery — and it is why
+the validation gates carry product-readable failure text (`product_relevant`, plain-language
+`what`/`recommendation` fields): the person standing at the gate does not read stack traces. Every
+outward-facing artifact an agent produces (blocked reasons, clarifying questions, tickets,
+verification reports, console copy) is written for that operator.
+
+## The four factories
+
+| Factory | Creates | Lisa surface | Gate (input signal) |
+|---|---|---|---|
+| **Research** | PRDs | `/lisa:research`, `/lisa:project-ideation` | Prompts and ideation are the main entry points |
+| **Plan** | Work units (epics, stories, tickets, tasks) | `/lisa:plan` → the `*-to-tracker` pipeline | PRD flipped to `prd-ready`, claimed by PRD intake |
+| **Implement** | Quality software (tests, code, UI, APIs, infrastructure) | `/lisa:implement` → build flows | Work unit flipped to `status:ready`, claimed by build intake |
+| **Verify** | A go/no-go decision | `/lisa:verify-prd` (PRD level), `/lisa:verify` (change level) | Shipped PRD rolled up by intake |
+
+Verify's no-go path is deliberate: failures re-open the PRD as `ticketed` with **build-ready** fix
+tickets that flow straight back into Implement — never `blocked`. The loop is self-healing.
+
+## The gates
+
+Handoff happens **outside** the factories. Agents, humans, and automations submit inputs; the
+intake agent (`/lisa:intake`, the `*-prd-intake` / `*-build-intake` agents) adversarially evaluates
+each one:
+
+- **Quality**: the validation gates (three-audience description, Gherkin acceptance criteria,
+  Validation Journey, structure, scope).
+- **Executability**: the factory must have the tooling *and provable read access to that tooling*
+  for everything the input requires — linked documents, dashboards, cloud resources, third-party
+  APIs (validator gate **F5 — Required external access provable**). An input the factory cannot
+  execute never enters the factory.
+- **Discover-first duty**: intake tries to resolve gaps itself (alternate substrates, configured
+  access layers, searching for the missing context). What it genuinely cannot resolve it rejects —
+  `blocked` plus a human-needed marker, with clarifying questions or the exact missing access named.
+
+## The loops
+
+Three schedules feed the pipeline continuously, created by `/lisa:setup-automations` on the
+runtime's native scheduler (Claude Routines, Codex Automations):
+
+| Loop | Automation | Feeds | Cadence |
+|---|---|---|---|
+| QA | `exploratory-bugs` (`/lisa:exploratory-qa`) | Implement gate (bug tickets) | daily |
+| Product Planning | `exploratory-prds` (`/lisa:project-ideation`) | Research/Plan gate (PRDs) | daily |
+| Monitoring | `monitor` (`/lisa:monitor`) | Implement gate (regression tickets) | daily |
+
+Plus the pipeline movers: `intake-prd` (hourly), `intake-tickets` (every 10 minutes),
+`intake-repair` (hourly). **Autonomy is the default**: `auto-start-prds` and `auto-start-tickets`
+default to `true`, so loop outputs enter the gates pickup-ready and the adversarial intake is the
+quality control. Projects opt into human triage by passing `false`.
+
+## Where humans stand
+
+Humans act only at explicit exterior gates:
+
+- flipping a draft they chose to hold back to `prd-ready` / `status:ready`,
+- approving protected deployments (`github.environments.require_approval`),
+- reviewing low-confidence learning PRs (auto-merge off),
+- answering what intake rejected and raised.
+
+Inside a flow, never pause to ask a human whether to proceed — the invocation was the authorization.
+Headless discipline follows: no interactive prompts, idempotent re-runs, clean exits on empty
+queues, and loud, specific failures when something is genuinely blocking.
+
+## The brownfield on-ramp
+
+Greenfield projects are agent-ready by construction. A brownfield project must earn readiness in
+two ordered steps before the automation fleet runs unattended:
+
+1. **Knowledge convergence** (`/lisa:agent-ready`): build the initial knowledge wiki from every
+   reachable source — repository, git history, tracker, connected systems — under the operating
+   premise *"starting tomorrow, you maintain this project without human input; today is your only
+   chance to ask questions."* Everything derivable is derived and written into the wiki; what only
+   a human can answer becomes a product-readable entry in `wiki/gaps.md`. Humans answer inline, a
+   **fresh session** re-runs the skill, verified answers are absorbed into wiki pages, and the loop
+   repeats until a run reports zero open gaps.
+2. **Standards adoption**: apply Lisa's full lint rules, guardrails, and thresholds — the project
+   goes red by design — then refactor to conformance **without changing business logic or
+   functionality**, via the improve/fix flows, with behavior preservation proven by tests and
+   empirical verification.
+
+Knowledge before standards: an agent refactoring a codebase it does not yet understand is exactly
+the unattended guessing the gates exist to prevent.
+
+## Quality and parity
+
+Everything else Lisa installs — skills, hooks, quality checks, guardrails, CI gates, rulesets —
+exists to enforce enterprise-grade quality and verification standards that keep the software
+maintainable. Never weaken a gate to get work through it; fix the work, or raise the
+risk-acceptance decision to a human.
+
+Every supported coding agent is a first-class factory operator: Claude Code, Codex, Cursor,
+OpenCode, Antigravity (agy), Copilot. Behavior stays in parity across them, and anything persisted
+for agents (rules, learnings, configuration) must be visible to all of them from a single source of
+truth.
+
+End state: end users have zero direct contact with coding agents. They interact with the tracker,
+the PRD source, and the shipped software — the factories do the rest.

package/plugins/lisa-cursor/rules/factory-model.mdc

@@ -0,0 +1,45 @@
+---
+description: "The Factory Model (load-bearing)"
+alwaysApply: true
+---
+
+# The Factory Model (load-bearing)
+
+This project runs as a set of **software factories** — agent-operated production lines with as few
+humans as possible. You are factory machinery, not a chat assistant. Four factories: **Research**
+(creates PRDs) → **Plan** (PRDs → work units) → **Implement** (work units → quality software) →
+**Verify** (go/no-go by using the software like a human; failures become build-ready tickets that
+flow straight back into Implement).
+
+The rules that follow from this:
+
+1. **Humans are not inside the factories.** Never pause mid-flow to ask a human whether to proceed.
+   All handoff happens at the **gates** — the ready-role flips (`prd-ready`, `status:ready`) plus
+   intake's adversarial validation.
+2. **The gate is adversarial.** An input enters a factory only when it is high-quality,
+   unambiguous, and the factory has the tooling *and provable access to that tooling* to execute it
+   (validator gate F5). Try to discover the answers to gaps first; what you genuinely cannot
+   resolve, reject to `blocked` and raise to a human with the exact missing thing named.
+3. **Everything runs on schedule.** The intake, QA, Product Planning, and Monitoring loops run as
+   native automations (Claude Routines / Codex Automations). Every flow must therefore work
+   headless: no interactive prompts, idempotent re-runs, clean exits on empty queues.
+4. **Quality is enforced, not requested.** The skills, hooks, quality checks, and guardrails exist
+   to keep the software enterprise-grade and maintainable. Never weaken a gate to get work through
+   it — fix the work.
+5. **Write outward for a non-technical operator.** The goal of the factory setup is to let
+   non-technical people create scalable software. Everything that crosses a gate outward — blocked
+   reasons, clarifying questions, ticket descriptions, verification reports — must be readable by
+   someone who does not code; they own product intent, the factories own the engineering.
+6. **Every supported coding agent is a first-class operator.** Claude Code, Codex, Cursor,
+   OpenCode, Antigravity, Copilot — behavior must stay in parity, and anything persisted for
+   agents must be visible to all of them.
+
+Brownfield on-ramp: an existing codebase becomes agent-ready **before** the fleet runs unattended
+— `/lisa:agent-ready` converges human knowledge into the wiki (gaps loop until none remain), then
+standards adoption refactors to conformance without behavior change.
+
+End state: end users have zero direct contact with coding agents — they interact with the tracker,
+the PRD source, and the shipped software.
+
+Full reference (factory ↔ Lisa surface mapping, loop details, human exterior gates):
+[reference/factory-model.md](factory-model-reference.mdc).

package/plugins/lisa-cursor/skills/lisa-agent-ready/SKILL.md

@@ -0,0 +1,123 @@
+---
+name: lisa-agent-ready
+description: "Make a brownfield project agent-ready: build the initial knowledge wiki from everything the agent can reach (repository, git history, connected trackers, docs, observability), then write wiki/gaps.md — the questions only a human can answer before agents can operate the project autonomously. Iterative convergence: humans answer the gaps inline, a fresh session re-runs the skill, verified answers are absorbed into wiki pages, and the loop repeats until a run reports zero open gaps and declares the project agent-ready. This is the knowledge half of brownfield onboarding; standards adoption (applying Lisa's lint rules, guardrails, and thresholds, then refactoring to conform without changing behavior) follows it."
+allowed-tools: ["Skill", "Bash", "Read", "Write", "Edit", "Glob", "Grep", "WebFetch"]
+---
+
+# Agent-Ready Onboarding: $ARGUMENTS
+
+Run this skill as if the following is literally true — it is the operating premise, not a
+role-play flourish:
+
+> **Starting tomorrow, you — the agent — maintain this project without any human input. Today is
+> your only chance to ask questions.** Use the existing connections, the git history, the tracker,
+> the docs, and anything else you have access to, to build the initial knowledge wiki. Critically:
+> write down every gap a human must fill in **today** for you to be able to operate autonomously —
+> the questions you would otherwise have to guess at tomorrow.
+
+Greenfield projects start agent-ready by construction. Brownfield projects carry years of tacit
+knowledge in heads, not files — this skill converges that knowledge into the wiki before the
+factories are allowed to run unattended.
+
+## What counts as a gap (the judgment rule)
+
+A **gap** is something that is (a) not derivable from any source you can reach, and (b) dangerous
+to guess — guessing would risk business logic, product intent, money, data, security, or an
+irreversible external effect. Examples: "why does the billing cutoff run at 02:00 and what breaks
+if it moves", "which of these two payment flows is the live one", "who are the users of the admin
+panel and what must never change for them".
+
+**Not a gap**: anything you can derive by reading harder — architecture, conventions, test
+behavior, deploy topology, dead code. Derive it and write it into the wiki instead. A lazy gap
+that a later reader could have answered from the repository is a defect of this skill's output.
+
+## Phases
+
+### Phase 0 — Preflight
+
+1. Ensure the knowledge wiki exists. If the project has no `wiki/`, install it first (delegate to
+   the wiki install/setup surface — `/lisa:wiki:install` / `lisa-wiki-setup`); do not hand-roll a
+   wiki layout.
+2. Inventory every reachable source: the repository and its full git history, the configured
+   `tracker` and `source`, connected MCP servers and access layers (observability, docs,
+   analytics), CI history, deployed environments named in config. Record the inventory in the wiki
+   so later runs and later agents know what was consulted.
+3. Detect a prior run: if `wiki/gaps.md` exists, this is an **absorption run** — go to Phase 3
+   first, then re-audit.
+
+### Phase 1 — Ingest
+
+Delegate to the wiki's ingestion surface (`lisa-wiki-ingest` and its connectors) across the
+repository, the git history, and each connected source from the Phase 0 inventory. Bounded and
+resumable — prefer several focused ingests over one unbounded crawl.
+
+### Phase 2 — Deep-read for autonomy
+
+Beyond raw ingestion, author the pages an unattended operator needs, deriving everything derivable:
+architecture and domain glossary, environment/deploy topology, who the users are (personas, if
+discoverable), business rules encoded in code and tests, operational runbooks (how to see logs,
+how to roll back), and the project's danger zones (migrations, money paths, irreversible jobs).
+Update `wiki/index.md` and record the run in `wiki/log.md` per wiki conventions.
+
+### Phase 3 — Absorb answered gaps (re-runs only)
+
+For each gap in `wiki/gaps.md` a human has answered inline:
+
+1. Verify the answer against reachable sources where possible; ask-back in the gap entry (keep it
+   `open` with a follow-up question) only when the answer is contradictory or incomplete.
+2. Absorb the verified answer into the proper wiki page(s) — the wiki is the durable home, the
+   gaps file is a queue, not a knowledge store.
+3. Mark the entry `absorbed` with a pointer to the page(s) it landed in, and move it to the
+   resolved section of the file.
+
+Never treat your own inference as a human answer, and never resolve an open gap by guessing.
+
+### Phase 4 — Gaps audit
+
+Regenerate the open section of `wiki/gaps.md` (create it on the first run). Every entry is written
+for a **non-technical operator** — plain language, no stack traces, no repo jargon — because the
+person answering may not code:
+
+```markdown
+## Open gaps (answer inline under each question, then re-run /lisa:agent-ready in a new session)
+
+### <stable-slug>
+- **Question**: <one plain-language question>
+- **Why it blocks autonomy**: <what an unattended agent cannot safely do without this>
+- **What was searched**: <the sources consulted before declaring this a gap>
+- **How to answer**: <where the answer likely lives / what format is useful>
+- **Answer**: _(human fills in)_
+- **Status**: open
+```
+
+Order entries by autonomy impact (what would cause the worst unattended decision first). Keep the
+file short — a gaps file with fifty entries means Phase 2 stopped too early.
+
+### Phase 5 — Converge and report
+
+- **Open gaps remain** → report the count and the top items, and instruct: a human answers inline
+  in `wiki/gaps.md`, then re-runs `/lisa:agent-ready` in a **new session** (a fresh session avoids
+  anchoring on this run's assumptions). Commit the wiki changes through the normal wiki PR flow.
+- **Zero open gaps** → declare the project **agent-ready for knowledge**: record the verdict and
+  date in the gaps file header and the wiki log, and point at the next step — standards adoption.
+
+## After convergence: standards adoption
+
+Knowledge first, standards second. Once the loop reports no gaps, apply Lisa's full standards
+(lint rules, guardrails, thresholds) and expect the project to go red — that is the point. Agents
+then refactor the codebase to conform **without changing business logic or functionality**, via
+the existing improve/fix flows, proving behavior is preserved with the test suite and empirical
+verification. Only then should the automation fleet run unattended on a brownfield project.
+
+## Rules
+
+- Never invent an answer to an open gap; the entire value of the file is that its answers came
+  from humans.
+- Gap entries are product-readable (factory-model rule: write outward for a non-technical
+  operator).
+- Idempotent: re-runs regenerate the open section in place and never lose or reword a human's
+  inline answers.
+- The wiki is the durable store; `wiki/gaps.md` is a queue. Every absorbed answer must land in a
+  real wiki page with the gaps entry pointing at it.
+- Follow the wiki's own conventions for commits, `wiki/index.md`, and `wiki/log.md` — this skill
+  adds no parallel bookkeeping.

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

@@ -23,6 +23,7 @@ Inspect only the Lisa automation fleet for the current project:
 - `intake-tickets`
 - `exploratory-bugs` when the current stack supports `exploratory-qa`
 - `exploratory-prds`
+- `monitor`
 
 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.
 

package/plugins/lisa-cursor/skills/lisa-github-validate-issue/SKILL.md

@@ -96,6 +96,7 @@ Each gate is tagged with a fixed `category` and a `product_relevant` boolean. Ca
 | F2 Parent sub-issue exists and is the right type | `structural` | false |
 | F3 Linked issues exist | `structural` | false |
 | F4 Required labels populated | `structural` | false |
+| F5 Required external access provable | `technical` | true |
 
 Category values are the same fixed set as `lisa-jira-validate-ticket`:
 
@@ -257,6 +258,31 @@ For each entry in `links`, run `gh issue view <number> --repo <link-org>/<link-r
 
 Per `Phase 5` of `lisa-github-write-issue`, every issue MUST carry: `type:<issue_type>`, `status:<status>`, `priority:<priority>`. If any are missing from the spec / live issue, FAIL with the missing label name.
 
+#### F5 — Required external access provable
+
+The factory-gate rule: an input must not enter the pipeline unless the current runtime can actually
+reach every external surface the work requires. Enumerate the surfaces this issue depends on:
+
+- artifact links in the body (documents, designs, dashboards, spreadsheets, recordings),
+- systems named by the description, acceptance criteria, or Validation Journey ("read the CloudWatch
+  alarms", "pull the copy from the Google Doc", "check the Sentry issues"),
+- tooling the work plainly implies (a deploy target, a database, a third-party API).
+
+For each surface, prove **read** access from the current runtime with the cheapest read-only probe
+through the sanctioned access layer: the matching MCP tool or `lisa-*-access` skill, CLI auth
+(`aws sts get-caller-identity`, `gh auth status`, vendor equivalents), or an authenticated fetch of
+the linked artifact. Attempt to resolve a gap before failing — an alternate substrate, a configured
+access layer, a keychain credential — mirroring the intake agent's discover-first duty.
+
+- `PASS` — every required surface is provably readable.
+- `N/A` — the issue needs nothing beyond the repository and the tracker itself.
+- `FAIL` — a required surface is unreachable after the resolution attempt. Name the exact surface
+  and what was probed. Intake callers must route this to `blocked` + human escalation with the
+  missing access spelled out — an input the factory cannot execute never enters the factory.
+
+Probes are read-only and bounded (seconds, not minutes, per surface); never mutate the external
+system, and never invent or ask for credentials inline.
+
 ## Execution
 
 1. Parse `$ARGUMENTS`. If it's an issue ref, fetch via `gh issue view --json` and derive the spec fields — including `build_ready` (label set contains `status:ready`) and `child_refs` (native sub-issues plus body task-list / `Blocked by #<n>` parentage, resolved as in `lisa-github-read-issue`) so S15 can classify the issue. Otherwise parse the YAML spec.
@@ -294,6 +320,7 @@ Output is a single fenced text block. Callers parse it; do not add free-form pro
 - [PASS|FAIL|N/A] F2 Parent sub-issue exists and is the right type — <one-line reason>
 - [PASS|FAIL|N/A] F3 Linked issues exist — <one-line reason>
 - [PASS|FAIL|N/A] F4 Required labels populated — <one-line reason>
+- [PASS|FAIL|N/A] F5 Required external access provable — <one-line reason>
 
 ### Verdict: PASS | FAIL
 ### Failures: <count>
@@ -313,7 +340,7 @@ The verdict is `PASS` if every applicable gate is `PASS`. Any `FAIL` makes the v
 
 Same shape and meaning as `lisa-jira-validate-ticket` so downstream PRD-intake skills (Notion, Confluence, Linear, GitHub) can format comments uniformly:
 
-- **gate**: the gate ID (`S1`–`S15`, `F1`–`F4`).
+- **gate**: the gate ID (`S1`–`S15`, `F1`–`F5`).
 - **category**: the gate's fixed category from the table.
 - **product_relevant**: matches the gate's table entry. `false` means the failure is an internal data-quality problem the caller should fix without bothering product.
 - **what**: plain-language, product-readable.

package/plugins/lisa-cursor/skills/lisa-jira-validate-ticket/SKILL.md

@@ -93,6 +93,7 @@ Each gate is tagged with a fixed `category` and a `product_relevant` boolean. Ca
 | F2 Epic parent exists and is an Epic | `structural` | false |
 | F3 Linked tickets exist | `structural` | false |
 | F4 Required custom fields populated | `structural` | false |
+| F5 Required external access provable | `technical` | true |
 
 Category values are drawn from this fixed set:
 
@@ -246,6 +247,31 @@ For each entry in `links`, invoke `lisa-atlassian-access` `operation: read-ticke
 
 Use the same project-issue-type-metadata lookup from F1 (via `lisa-atlassian-access`) to learn required custom fields for the issue type. Any required custom field not provided in the spec: FAIL.
 
+#### F5 — Required external access provable
+
+The factory-gate rule: an input must not enter the pipeline unless the current runtime can actually
+reach every external surface the work requires. Enumerate the surfaces this item depends on:
+
+- artifact links in the body (documents, designs, dashboards, spreadsheets, recordings),
+- systems named by the description, acceptance criteria, or Validation Journey ("read the CloudWatch
+  alarms", "pull the copy from the Google Doc", "check the Sentry issues"),
+- tooling the work plainly implies (a deploy target, a database, a third-party API).
+
+For each surface, prove **read** access from the current runtime with the cheapest read-only probe
+through the sanctioned access layer: the matching MCP tool or `lisa-*-access` skill, CLI auth
+(`aws sts get-caller-identity`, `gh auth status`, vendor equivalents), or an authenticated fetch of
+the linked artifact. Attempt to resolve a gap before failing — an alternate substrate, a configured
+access layer, a keychain credential — mirroring the intake agent's discover-first duty.
+
+- `PASS` — every required surface is provably readable.
+- `N/A` — the item needs nothing beyond the repository and the tracker itself.
+- `FAIL` — a required surface is unreachable after the resolution attempt. Name the exact surface
+  and what was probed. Intake callers must route this to `blocked` + human escalation with the
+  missing access spelled out — an input the factory cannot execute never enters the factory.
+
+Probes are read-only and bounded (seconds, not minutes, per surface); never mutate the external
+system, and never invent or ask for credentials inline.
+
 ## Execution
 
 1. Parse `$ARGUMENTS`. If it's a ticket key, fetch the ticket via `lisa-atlassian-access` `operation: read-ticket` and derive the spec from the fetched fields — including `build_ready` (label set contains `status:ready`) and `child_refs` (sub-tasks plus `is blocked by` parentage, resolved as in `lisa-jira-read-ticket`) so S15 can classify the ticket. When the fetched description is ADF, walk the document tree and extract section headings from ADF `heading` nodes, then collect the text between heading nodes for section-specific gates. If the fetched description is a single paragraph containing literal Markdown/wiki heading markers, treat that as a formatting failure rather than accepting substring matches. Otherwise parse the YAML spec.
@@ -283,6 +309,7 @@ Output is a single fenced text block. Callers parse it; do not add free-form pro
 - [PASS|FAIL|N/A] F2 Epic parent exists and is an Epic — <one-line reason>
 - [PASS|FAIL|N/A] F3 Linked tickets exist — <one-line reason>
 - [PASS|FAIL|N/A] F4 Required custom fields populated — <one-line reason>
+- [PASS|FAIL|N/A] F5 Required external access provable — <one-line reason>
 
 ### Verdict: PASS | FAIL
 ### Failures: <count>
@@ -301,7 +328,7 @@ The verdict is `PASS` if and only if every applicable gate is `PASS`. Any `FAIL`
 
 ### Failure-detail fields
 
-- **gate**: the gate ID (`S1`–`S15`, `F1`–`F4`).
+- **gate**: the gate ID (`S1`–`S15`, `F1`–`F5`).
 - **category**: the gate's fixed category from the table above. Callers use this to label or filter comments — `product-clarity`, `acceptance-criteria`, `design-ux`, `scope`, `dependency`, `data`, `technical`, or `structural`.
 - **product_relevant**: matches the gate's table entry. `false` means the failure is an internal data-quality problem (e.g., the agent built a malformed spec, an issue type is invalid in the project) and the caller should fix it without bothering the product team. `true` means the PRD needs product input to resolve.
 - **what**: plain-language description of the issue. No gate IDs, no JIRA jargon, no engineering shorthand. A product owner reading this on a Notion comment should understand what is unclear and why.