@codyswann/lisa 2.61.1 → 2.62.0

package/plugins/lisa-openclaw/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.61.1",
+  "version": "2.62.0",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, across Claude and Codex.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.61.1",
+  "version": "2.62.0",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-rails/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.61.1",
+  "version": "2.62.0",
   "description": "Ruby on Rails-specific skills and hooks for RuboCop and ast-grep scanning on edit.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-rails/commands/exploratory-qa.md

@@ -1,7 +1,7 @@
 ---
-description: "Run a Playwright-backed exploratory QA pass: audit the app like a human, find user-noticeable bugs and gaps in automated test coverage, and produce a QA gaps report."
+description: "Run a Playwright-backed exploratory QA pass: audit the app like a human, find user-noticeable bugs, usability issues, and gaps in automated test coverage, and file each finding as a tracked work item via lisa:tracker-write. The optional ready flag marks bug/suggestion tickets build-ready (auto-picked-up by lisa:intake) or leaves them in the backlog for human triage (default); missing-test tickets are always build-ready."
 allowed-tools: ["Skill"]
-argument-hint: "[target-url | env] [report-path]"
+argument-hint: "[target-url | env] [ready=true|false]"
 ---
 
-Use the /lisa-rails:exploratory-qa skill to run a human-style exploratory QA pass informed by the existing Playwright suite, then produce an actionable coverage-gaps report. $ARGUMENTS
+Use the /lisa-rails:exploratory-qa skill to run a human-style exploratory QA pass informed by the existing Playwright suite, then file every finding (bugs, usability issues, missing Playwright tests) as a tracked work item via lisa:tracker-write — bug/suggestion tickets build-ready or in triage per the ready flag (default: triage), missing-test tickets always build-ready. $ARGUMENTS

package/plugins/lisa-rails/skills/exploratory-qa/SKILL.md

@@ -1,19 +1,30 @@
 ---
 name: exploratory-qa
-description: Playwright-backed exploratory QA workflow for web apps. Use when asked to audit an app or project with Playwright/e2e tests, find human-noticeable bugs, identify gaps in automated test coverage, test responsive breakpoints, observe slow or unclear load states, exercise mutable workflows with cleanup, or produce a QA gaps report.
+description: Playwright-backed exploratory QA workflow for web apps that FEEDS THE LIFECYCLE. Use when asked to audit an app with Playwright/e2e tests, find human-noticeable bugs and usability issues, identify gaps in automated test coverage, test responsive breakpoints, observe slow or unclear load states, or exercise mutable workflows with cleanup. Instead of writing a report file, it files every finding as a tracked work item via lisa:tracker-write (bugs, usability suggestions, and missing Playwright tests). A `ready` parameter controls whether bug and suggestion tickets are created build-ready (auto-picked-up by lisa:intake) or in the backlog for human triage (default); missing-test tickets are always created build-ready.
 ---
 
 # Exploratory QA
 
 ## Overview
 
-Run a human-style exploratory QA pass informed by the existing Playwright suite. The goal is to find issues users notice and machines often miss, then translate those observations into actionable Playwright coverage gaps.
+Run a human-style exploratory QA pass informed by the existing Playwright suite, then **file every finding as a tracked work item** in the project's configured tracker so it enters the Lisa lifecycle. The goal is to find issues users notice and machines often miss — bugs, usability friction, and coverage gaps — and turn each into actionable, automatable work, not a static report.
+
+## Parameters
+
+- **`target-url | env`** (first positional) — what to audit.
+- **`ready=true|false`** — the build-ready state for the **bug** and **usability/suggestion** tickets this pass creates.
+  - `ready=true` → created build-ready, so `lisa:intake` / the build-intake scanner auto-picks them up.
+  - `ready=false` (**default**) → created in the backlog (not build-ready) for a human to review and promote into the queue.
+  - **Missing Playwright test tickets are ALWAYS created build-ready, regardless of this flag** — adding missing coverage is always safe to queue.
+
+`ready` maps directly to the `build_ready` write-control input on `lisa:tracker-write`.
 
 ## Core Workflow
 
 ### 1. Establish Scope
 
-- Identify the target environment, account type, browser requirement, and requested report path.
+- Identify the target environment, account type, browser requirement, and the `ready` flag value (default `false`).
+- **Confirm the tracker is configured.** Findings are filed as tickets, so read `tracker` from `.lisa.config.json` (local overrides global). If it is unset, stop and report that the tracker must be configured (via `/lisa:setup:jira` / `:github` / `:linear`) before exploratory QA can file findings — do not silently fall back to a report file.
 - If credentials, tenant, seed data, or mutation boundaries are missing and cannot be discovered safely, ask a concise clarifying question.
 - Treat production-like environments conservatively. Do not mutate production data unless the user explicitly approves it.
 - Prefer a test user, dev/staging environment, or isolated seeded account for mutation testing.
@@ -57,7 +68,7 @@ Exploratory QA should exercise mutable workflows when the environment is safe.
 - Prefer high-value user workflows: create/edit/delete records, lists, boards, tags, notes, comments, scenarios, uploads, messages, settings, invitations, or assignments.
 - Use unique names with a clear prefix such as `qa-`, `pw-`, or `codex-`.
 - Before mutating, identify the cleanup path. After mutating, make a best effort to clean up through the UI, then verify cleanup.
-- If UI cleanup is unavailable, record that as a product/test gap. Use documented API cleanup only if appropriate for the project and account.
+- If UI cleanup is unavailable, file that as a product/test gap (a finding — see below). Use documented API cleanup only if appropriate for the project and account.
 - Record all mutations performed, cleanup attempts, and residue left behind.
 - Avoid destructive bulk actions unless the user explicitly asks or the test account is clearly disposable.
 
@@ -83,26 +94,45 @@ Measure perceived latency, not just eventual success.
 - Treat long waits without clear progress, error, retry, or cancellation as bugs or test gaps.
 - Do not overfit exact milliseconds unless the project has defined budgets. Use practical labels such as noticeable, slow, or unacceptable and include observed durations when available.
 
-## Report Structure
+## Filing findings as tracked work
+
+This skill does **not** write a report file. Every finding becomes a **leaf work item** created via `lisa:tracker-write` (the vendor-neutral writer — it dispatches to the configured tracker and runs the validation gate; never call a vendor `*-write-*` skill directly). Map each finding to a type and a build-ready state:
+
+| Finding | `issue_type` | `build_ready` |
+|---------|--------------|---------------|
+| User-visible **bug** | `Bug` | the `ready` flag (default `false`) |
+| **Usability / UX issue** (suggestion) | `Improvement` | the `ready` flag (default `false`) |
+| **Missing Playwright test** (coverage gap) | `Task` | **`true` (always)** |
+
+Each finding is a flat leaf (no children), so `build_ready` applies directly. Pass it explicitly on every create — `build_ready: <ready flag>` for bugs and suggestions, `build_ready: true` for missing tests.
+
+Each ticket MUST be a complete spec (`lisa:tracker-write` runs the validator and rejects thin tickets):
+
+- **Three-audience description** (context / business value, technical approach, stakeholder impact).
+- **For a bug:** exact reproduction steps, observed-vs-expected, the env / account / breakpoint it occurred at, and console/network evidence.
+- **For a usability issue:** the observed friction, who it affects, and the proposed improvement.
+- **For a missing test:** the user behavior the test must assert and the stable selector/flow to use — concrete and automatable.
+- **Gherkin acceptance criteria** describing the fixed (bug / usability) or added (test) behavior.
+
+### Idempotency — don't spam duplicates
+
+Re-running a QA pass must not refile the same finding. Before creating a ticket, search the tracker for an **open** ticket carrying a stable marker `[lisa-exploratory-qa] <finding-key>` in its body (the `<finding-key>` is a stable slug of surface + symptom, e.g. `settings-modal/horizontal-overflow@tablet`). If one exists, reference/update it instead of creating a duplicate; only create when none exists. **Match by the marker, never by title** (titles get edited). A *closed* prior ticket does not suppress a new one — a recurrence after a fix is a genuine regression.
 
-Write the report to the user's requested path. If none is specified, use a clear local name such as `PLAYWRIGHT_GAPS.md` or `EXPLORATORY_QA_REPORT.md`.
+## Output
 
-Include:
+No report file. Emit a concise in-session summary:
 
-- Scope: target URL/env, browser/tool, account type, build/version if visible, date.
-- Existing Playwright coverage: strengths, thin areas, skipped tests, viewport/browser matrix, mutation coverage.
-- Exploratory findings: steps, observed behavior, impact, why existing tests miss it, recommended test.
-- Breakpoint findings: exact viewports tested and boundary behavior.
-- Load-state findings: observed delays, blank/spinner/connecting states, suggested budgets/tests.
-- Mutation findings: data created, behavior observed, cleanup attempt, cleanup result, residue.
-- Missing Playwright tests to add: prioritized, concrete, and automatable.
-- Maintenance notes: selector scoping, fixture cleanup, flaky/stale-state risks.
+- **Scope:** target URL/env, browser/tool, account type, build/version if visible, date.
+- **Existing Playwright coverage:** strengths and thin areas observed during research.
+- **Findings filed**, bucketed by type — bugs, usability suggestions, missing tests — each with its **created or referenced ticket ref** and its **build-ready state** (`ready` vs `triage/backlog`).
+- **Observed but not filed:** anything noticed but intentionally not ticketed, with why.
 
 ## Quality Bar
 
 - Be honest about what was and was not tested.
-- Distinguish user-visible bugs from missing automated coverage.
-- Prefer concrete examples over vague recommendations.
+- Distinguish user-visible bugs from missing automated coverage — they map to different issue types (`Bug` vs `Task`).
+- Prefer concrete, reproducible findings. Every ticket must stand alone for an implementer who was not in the session.
 - Do not claim cleanup succeeded unless verified.
 - Do not let broad locators pass against hidden/inactive content.
-- Preserve unrelated repo changes and keep report edits scoped.
+- File missing-test tickets build-ready; file bug and usability tickets per the `ready` flag (default: backlog for human triage).
+- Preserve unrelated repo changes.

package/plugins/lisa-rails/skills/exploratory-qa/agents/openai.yaml

@@ -1,4 +1,4 @@
 display_name: "Exploratory QA"
-short_description: "Playwright-backed exploratory QA workflow for web apps"
+short_description: "Playwright-backed exploratory QA workflow for web apps that FEEDS THE LIFECYCLE"
 default_prompt:
-  - "Use $exploratory-qa: Playwright-backed exploratory QA workflow for web apps."
+  - "Use $exploratory-qa: Playwright-backed exploratory QA workflow for web apps that FEEDS THE LIFECYCLE."

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.61.1",
+  "version": "2.62.0",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-typescript/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.61.1",
+  "version": "2.62.0",
   "description": "TypeScript-specific hooks for formatting, linting, and ast-grep scanning on edit.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.61.1",
+  "version": "2.62.0",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-wiki/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.61.1",
+  "version": "2.62.0",
   "description": "Distributable LLM Wiki kernel — ingest, query, lint, and maintain a git-native markdown knowledge base across Claude and Codex.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-wiki/skills/lisa-wiki-ingest/SKILL.md

@@ -19,6 +19,24 @@ performs the shared, ordered pipeline.
   run includes explicit external-write intent**.
 - **Dry run:** `/ingest --dry-run` — list the sources a full ingest would run; perform no writes.
 
+## Before ingesting — sync the branch (once per run)
+
+Run this **once per ingest invocation, before any source is processed** (skip for `--dry-run`, which
+writes nothing). The point is to ingest on top of fresh state, never stale state.
+
+1. **Resolve the default remote branch** — `gh repo view --json defaultBranchRef -q .defaultBranchRef.name`,
+   or `git remote show origin | sed -n 's/.*HEAD branch: //p'`, or the `origin/HEAD` symbolic ref. If
+   the repo has no remote, note "no remote — skipping branch sync" and proceed.
+2. **Fetch** — `git fetch <remote>` to update remote-tracking refs.
+3. **Bring the working branch up to date with the default remote branch** so the ingest lands on
+   current state:
+   - On the default branch → fast-forward to `<remote>/<default>` (`git pull --ff-only`).
+   - On a non-default branch → merge or rebase `<remote>/<default>` in (per the project's convention)
+     so the branch is not behind the default.
+4. If the sync cannot complete cleanly (merge conflict, diverged history, or a dirty tree that would
+   conflict), **stop and surface it** rather than ingesting on top of stale or conflicted state — the
+   human resolves and re-runs. **Never discard unrelated working-tree changes** to force a sync.
+
 ## The ordered pipeline (per source) — never reorder
 1. **Connector** validates (tenant guard + auth), reads its state cursor (first-run vs incremental),
    fetches read-only, and writes a sanitized **source note** under `wiki/sources/<system>/` plus run
@@ -29,9 +47,20 @@ performs the shared, ordered pipeline.
 4. **Log**: append a `wiki/log.md` entry (fixed operation vocabulary).
 5. **Verify**: `git diff --check`, secret/tenant/contamination scans, touched-file guard.
 6. **State**: advance the connector's `wiki/state/<system>/*.json` cursor — only now, after 1–5 pass.
-7. **Commit/PR**: per `config.git` policy. `external-write` runs and sensitive content never auto-merge.
+7. **Commit/PR**: commit only the ingestion changes per `config.git` policy. If the ingest started on
+   the default branch, create a dedicated ingestion branch first — never commit ingestion straight to
+   the default. Push the branch and **open a PR targeting the default remote branch** (via the host's
+   PR mechanism — e.g. `gh pr create --base <default>`), then **enable auto-merge when possible**
+   (`gh pr merge --auto`, or the host's equivalent). `external-write` runs and sensitive content are
+   the exception — open the PR **without** auto-merge so a human reviews them before it lands. If
+   auto-merge cannot be enabled (the host doesn't support it, or branch protection forbids it), leave
+   the PR open and note that a human must merge.
 
 ## Rules
+- **Bookend every ingest with git hygiene:** sync the branch with the default remote branch *before*
+  writing (see "Before ingesting"), and *after* a successful ingest open a PR to the default remote
+  branch with auto-merge enabled when possible — never auto-merging `external-write`/sensitive runs.
+  `--dry-run` does neither (it writes nothing).
 - Source-note-before-synthesis; state advanced **only** after verification.
 - Project-scoped only; memory ingestion never touches global/Codex-global stores.
 - Respect `sourceRetention` and `sensitivity`; do not invent facts.

package/plugins/src/base/agents/confluence-prd-intake.md

@@ -53,7 +53,7 @@ After a successful cycle, if any PRDs ended in the `blocked` label, mention to t
 
 When reporting `blocked` outcomes, distinguish the cause: **pre-write gate failure** (per-ticket validator caught a problem before any tickets were created) vs **post-write coverage gap** (tickets were created and remain in the destination tracker, but the PRD has uncovered requirements that the next intake cycle will address). Both result in the `blocked` label, but the implication for product is different — coverage gaps mean some tickets are already real and product should not re-author the PRD from scratch.
 
-If all PRDs ended in the `ticketed` label with coverage `COMPLETE`, mention that the next step is for product to monitor the created tickets and apply the configured `shipped` label after delivery, then run `/lisa:verify-prd` to empirically verify the shipped product against the PRD and move it to `verified` (or back to `blocked` with linked fix issues on failure). If any are `COMPLETE_WITH_SCOPE_CREEP`, point that out so product can review the flagged tickets.
+If all PRDs ended in the `ticketed` label with coverage `COMPLETE`, mention that the next step is for product to monitor the created tickets and apply the configured `shipped` label after delivery, then run `/lisa:verify-prd` to empirically verify the shipped product against the PRD and move it to `verified` (or, on failure, re-open it to `ticketed` with build-ready fix tickets that auto-build and re-verify — never `blocked`). If any are `COMPLETE_WITH_SCOPE_CREEP`, point that out so product can review the flagged tickets.
 
 ## Rules
 

package/plugins/src/base/agents/github-prd-intake.md

@@ -53,7 +53,7 @@ After a successful cycle, if any PRDs ended in the `blocked` label, mention to t
 
 When reporting `blocked` outcomes, distinguish the cause: **pre-write gate failure** (per-ticket validator caught a problem before any tickets were created) vs **post-write coverage gap** (tickets were created and remain in the destination tracker, but the PRD has uncovered requirements that the next intake cycle will address). Both result in the `blocked` label, but the implication for product is different — coverage gaps mean some tickets are already real and product should not re-author the PRD from scratch.
 
-If all PRDs ended in the `ticketed` label with coverage `COMPLETE`, mention that the next step is for product to monitor the created tickets and apply the configured `shipped` label after delivery, then run `/lisa:verify-prd` to empirically verify the shipped product against the PRD and move it to `verified` (or back to `blocked` with linked fix issues on failure). If any are `COMPLETE_WITH_SCOPE_CREEP`, point that out so product can review the flagged tickets.
+If all PRDs ended in the `ticketed` label with coverage `COMPLETE`, mention that the next step is for product to monitor the created tickets and apply the configured `shipped` label after delivery, then run `/lisa:verify-prd` to empirically verify the shipped product against the PRD and move it to `verified` (or, on failure, re-open it to `ticketed` with build-ready fix tickets that auto-build and re-verify — never `blocked`). If any are `COMPLETE_WITH_SCOPE_CREEP`, point that out so product can review the flagged tickets.
 
 ## Rules
 

package/plugins/src/base/agents/linear-prd-intake.md

@@ -53,7 +53,7 @@ After a successful cycle, if any PRDs ended in the `blocked` label, mention to t
 
 When reporting `blocked` outcomes, distinguish the cause: **pre-write gate failure** (per-ticket validator caught a problem before any tickets were created) vs **post-write coverage gap** (tickets were created and remain in the destination tracker, but the PRD has uncovered requirements that the next intake cycle will address). Both result in the `blocked` label, but the implication for product is different — coverage gaps mean some tickets are already real and product should not re-author the PRD from scratch.
 
-If all PRDs ended in the `ticketed` label with coverage `COMPLETE`, mention that the next step is for product to monitor the created tickets and apply the configured `shipped` label after delivery, then run `/lisa:verify-prd` to empirically verify the shipped product against the PRD and move it to `verified` (or back to `blocked` with linked fix issues on failure). If any are `COMPLETE_WITH_SCOPE_CREEP`, point that out so product can review the flagged tickets.
+If all PRDs ended in the `ticketed` label with coverage `COMPLETE`, mention that the next step is for product to monitor the created tickets and apply the configured `shipped` label after delivery, then run `/lisa:verify-prd` to empirically verify the shipped product against the PRD and move it to `verified` (or, on failure, re-open it to `ticketed` with build-ready fix tickets that auto-build and re-verify — never `blocked`). If any are `COMPLETE_WITH_SCOPE_CREEP`, point that out so product can review the flagged tickets.
 
 ## Rules
 

package/plugins/src/base/agents/notion-prd-intake.md

@@ -51,7 +51,7 @@ After a successful cycle, if any PRDs ended in the `blocked` status, mention to
 
 When reporting `blocked` outcomes, distinguish the cause: **pre-write gate failure** (per-ticket validator caught a problem before any tickets were created) vs **post-write coverage gap** (tickets were created and remain in the destination tracker, but the PRD has uncovered requirements that the next intake cycle will address). Both result in the `blocked` status, but the implication for product is different — coverage gaps mean some tickets are already real and product should not re-author the PRD from scratch.
 
-If all PRDs ended in the `ticketed` status with coverage `COMPLETE`, mention that the next step is for product to monitor the created tickets and flip the PRDs to the configured `shipped` status after delivery, then run `/lisa:verify-prd` to empirically verify the shipped product against the PRD and move it to `verified` (or back to `blocked` with linked fix issues on failure). If any are `COMPLETE_WITH_SCOPE_CREEP`, point that out so product can review the flagged tickets.
+If all PRDs ended in the `ticketed` status with coverage `COMPLETE`, mention that the next step is for product to monitor the created tickets and flip the PRDs to the configured `shipped` status after delivery, then run `/lisa:verify-prd` to empirically verify the shipped product against the PRD and move it to `verified` (or, on failure, re-open it to `ticketed` with build-ready fix tickets that auto-build and re-verify — never `blocked`). If any are `COMPLETE_WITH_SCOPE_CREEP`, point that out so product can review the flagged tickets.
 
 ## Rules
 

package/plugins/src/base/commands/intake.md

@@ -3,4 +3,4 @@ description: "Vendor-agnostic batch scanner for Ready queues. Notion PRD databas
 argument-hint: "<Notion-PRD-database-URL | Confluence-space-URL | Confluence-parent-page-URL | Linear-workspace-URL | Linear-team-URL | GitHub-repo-URL | org/repo | JIRA-project-key | JQL-filter>"
 ---
 
-Use the /lisa:intake skill to scan the queue for Ready items and dispatch each one through the appropriate single-item lifecycle skill. $ARGUMENTS
+Use the /lisa:intake skill to scan the queue for Ready items and dispatch one eligible Ready item per invocation through the appropriate single-item lifecycle skill — and, on the PRD side, close the loop by dispatching /lisa:verify-prd for one shipped PRD per cycle (shipped → verified on pass, or re-opened to ticketed with build-ready fix tickets that auto-build and re-verify on fail — never blocked). $ARGUMENTS

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

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

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

@@ -0,0 +1,6 @@
+---
+description: "Repair counterpart to /lisa:intake. Vendor-agnostic batch scanner that finds stuck work — items left in `blocked` or stalled in an in-progress role (build `claimed`, PRD `in_review`) — across the same queues /lisa:intake serves (Notion / Confluence / Linear / GitHub PRDs; JIRA / GitHub / Linear build issues), and attempts to repair the first materially actionable one per cycle: resumes stalled in-progress work in place, re-validates blocked PRDs, and re-dispatches blocked build items whose blockers have cleared. One actionable repair per invocation; cron-safe. Designed as a /schedule target alongside /lisa:intake."
+argument-hint: "<Notion-PRD-database-URL | Confluence-space-URL | Confluence-parent-page-URL | Linear-workspace-URL | Linear-team-URL | GitHub-repo-URL | org/repo | JIRA-project-key | JQL-filter> [intake_mode=prd|build|both] [stale_after=24h] [max_candidates=100] [force=true]"
+---
+
+Use the /lisa:repair-intake skill to scan the queue for stuck items (blocked, or stalled in an in-progress role) and repair the first materially actionable one. $ARGUMENTS

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

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

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

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

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

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

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

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

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

@@ -120,6 +120,13 @@ fi
       "staging":    "staging",
       "production": "main"
     }
+  },
+
+  "intake": {
+    "repair": {
+      "staleAfterHours": 24,
+      "maxCandidates": 100
+    }
   }
 }
 ```
@@ -226,6 +233,22 @@ The `rollup` object lives in each PRD-source vendor section (`github.labels.prd.
 
 Like every other vocabulary key, `prd.rollup` is **optional** — a missing block inherits `closeOnShipped: false`. The `shipped` transition itself is unconditional on the all-terminal condition; only the close/archive step is gated by this flag.
 
+### Repair intake config (`intake.repair`)
+
+`lisa:repair-intake` (the recovery counterpart to `lisa:intake`) reads two optional tuning keys
+from the top-level `intake.repair` block. Both are **optional** — a missing block inherits the
+documented defaults, so existing projects need no config change.
+
+| Key | Required | Default | Notes |
+|-----|----------|---------|-------|
+| `intake.repair.staleAfterHours` | no | `24` | How long an in-progress item (build `claimed`, PRD `in_review`) may show no observable activity before repair-intake treats it as stalled and resumes it. `blocked` items are judged on blocker/answer state, not this threshold. Overridable per-run via `stale_after=<dur>` in `$ARGUMENTS` (which always wins). The same value is the default backoff window for loop-prevention notes. |
+| `intake.repair.maxCandidates` | no | `100` | Upper bound on how many stuck items repair-intake enumerates while searching for the first actionable one. Bounds scan cost. Overridable per-run via `max_candidates=<n>`. |
+
+Resolution order matches every other key: `$ARGUMENTS` override → `.lisa.config.local.json` →
+`.lisa.config.json` → built-in default. The role SEMANTICS repair-intake operates on (which
+roles count as "stuck", what each repair does) are fixed like every other lifecycle transition;
+only these thresholds are tunable.
+
 ### Env-keyed `done`
 
 The `done` role is special: the terminal status/label depends on which environment a PR was merged into. A hotfix to staging ends at `On Stg`; a production hotfix ends at `Done`. So `done` is a **map** keyed by env name (`dev`, `staging`, `production`).
@@ -238,6 +261,16 @@ Skills that transition to `done` MUST resolve the env first:
 
 If a project's terminal state is the same regardless of env, set `done` to a string instead of a map (lifecycle skills accept either shape).
 
+### Env → base branch (forward: the build base and PR base)
+
+`deploy.branches` is also read in the **forward** direction by the build flow (`lisa:implement`): the environment a work item targets determines the branch the work is built on and the branch the PR opens against.
+
+1. **Resolve the work item's target environment** — its `## Target Backend Environment` field. If the item names no environment, use the **remote default branch** (`gh repo view --json defaultBranchRef`, or `origin/HEAD`).
+2. **Map env → base branch** via `deploy.branches` (e.g. `staging → staging`, `production → main`). Absent env or missing branch → stop and report; never guess.
+3. **Before any code is written**, `lisa:implement` fetches and **rebases the working branch onto `origin/<base>`, resolving conflicts**, so implementation builds on the latest target-environment code. **The PR then opens against that same base branch** (`target_branch=<base>` to `lisa:git-submit-pr`).
+
+This is the exact inverse of the env-keyed `done` "Branch inference" above: `done` derives the env *from* the PR base branch (reverse); the build flow derives the base branch *from* the env (forward). Both use the one `deploy.branches` map, so the branch a PR targets and the `done` status it earns always agree.
+
 The true terminal `done` value is also the only value that triggers provider-native closure / resolution per `leaf-only-lifecycle`:
 
 - If `done` is a string, that value is terminal.
@@ -437,6 +470,33 @@ GitHub and Linear PRD lifecycles use labels (`prd-ready` / `prd-in-review` / etc
 
 **Why curl is still needed**: acli's Confluence surface only covers `space` and `page view`. v1 page-write endpoints accept scoped tokens but return 410 Gone (deprecated); v2 endpoints require granular OAuth scopes acli doesn't request. API tokens via Basic auth bypass this with full user scope, so curl is the headless-friendly path for ops neither acli nor MCP can do.
 
+## Repo scoping (multi-repo trackers)
+
+A ticketing system can oversee **multiple repos** — e.g. one JIRA project (or Linear team) for `frontend`, `backend`, and `infrastructure`. When build-intake runs inside one repo, it must claim only the tickets that belong to **that** repo and skip the rest. Two pieces make this work; the claim-time enforcement lives in the `repo-scope-split` rule.
+
+### The `repo:<name>` label (the repo marker)
+
+A work item's target repo is recorded as a **label** `repo:<name>`, where `<name>` is the repo's short name (e.g. `repo:frontend`). The convention is uniform across trackers (JIRA / GitHub / Linear), consistent with the other namespaced labels (`status:`, `type:`, `component:`). On JIRA a **component** equal to the repo name is accepted as an alias (matches the legacy `component = "frontend"` JQL pattern). A leaf work unit carries **exactly one** `repo:<name>` (leaves are single-repo per `repo-scope-split`); a container (Epic/Story/Spike) may carry several or none.
+
+The label is not required to exist up front: build-intake **determines** the target repo from the ticket's content + code surfaces when the label is absent and **stamps** `repo:<name>` so later cycles filter cheaply (see `repo-scope-split` "claim-time repo scoping").
+
+### Current-repo resolution (which repo am I?)
+
+Resolve the name of the repo intake is running in, highest priority first:
+
+1. `.lisa.config.local.json` then `.lisa.config.json` `repo` (an explicit override, e.g. `"repo": "frontend"`).
+2. `.lisa.config.json` `github.repo` when set (the repo's own identity).
+3. The git remote basename: `basename -s .git "$(git remote get-url origin)"` (e.g. `git@github.com:acme/frontend.git` → `frontend`).
+
+```bash
+read_g() { local lv gv; lv=$(jq -r "$1 // empty" .lisa.config.local.json 2>/dev/null); gv=$(jq -r "$1 // empty" .lisa.config.json 2>/dev/null); echo "${lv:-${gv}}"; }
+CURRENT_REPO=$(read_g '.repo')
+[ -z "$CURRENT_REPO" ] && CURRENT_REPO=$(read_g '.github.repo')
+[ -z "$CURRENT_REPO" ] && CURRENT_REPO=$(basename -s .git "$(git remote get-url origin 2>/dev/null)" 2>/dev/null)
+```
+
+If the current repo cannot be resolved by any tier, build-intake stops with a clear error rather than claiming tickets it cannot scope. The match is by repo short name (`repo:<CURRENT_REPO>`), case-insensitive.
+
 ## Invariants
 
 - Project tracker selection is **persistent** within a project — always read from config, never infer from the shape of `$ARGUMENTS`. If a developer wants a different destination for one run, they edit `.lisa.config.local.json`.

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

@@ -67,11 +67,12 @@ Sequence:
 2. `product-specialist` -- define user goals, user flows (Gherkin), acceptance criteria, error states, UX concerns, and out-of-scope items
 3. **Edge Case Brainstorm sub-flow** -- run the PRD candidate through the edge-case checklist; fold accepted cases into acceptance criteria, out-of-scope, or open questions
 4. `architecture-specialist` -- assess technical feasibility, identify constraints, map existing system boundaries
-5. Synthesize findings into a PRD document containing: problem statement, user stories, acceptance criteria, technical constraints, open questions, and proposed scope
+5. Synthesize findings into a PRD containing: problem statement, user stories, acceptance criteria, technical constraints, open questions, and proposed scope
 6. **Plan Phase Tooling** -- review all available skills and agents (project-defined, plugin-provided, and built-in) and determine which ones the Plan phase will need. For each recommended skill or agent, state why it is needed. If no skills or agents beyond the defaults are identified, explicitly justify why the standard set is sufficient. Include this as a "Recommended Tooling for Plan Phase" section in the PRD.
-7. `learner` -- capture discoveries for future sessions
+7. **Create the PRD in the configured source** -- invoke `lisa:prd-source-write` with the synthesized PRD (`title`, `body`, `initial_role` resolved from the caller's `prd_ready` flag — `draft` by default, `ready` when `prd_ready=true`, plus any `dedupe_key`/`marker`/`source_ref` the caller passed). The PRD **lives in the source** (Notion page / Confluence page / GitHub issue / Linear project per `.lisa.config.json` `source`); there is no separate document artifact. A `source` must be configured — if it is not, stop and report it. `prd-source-write` dedupes by marker, so re-running against the same idea references the existing PRD instead of creating a duplicate.
+8. `learner` -- capture discoveries for future sessions
 
-Output: A PRD document that includes a "Recommended Tooling for Plan Phase" section listing the skills and agents the Plan phase should use. If there is not enough context to produce a complete PRD, stop and report what is missing rather than producing an incomplete one.
+Output: A PRD created in the configured source, carrying a "Recommended Tooling for Plan Phase" section, in the `draft` role by default (or `ready` when `prd_ready=true`, so `lisa:intake` auto-claims it). If there is not enough context to produce a complete PRD, stop and report what is missing rather than creating an incomplete one. If no `source` is configured, stop and report it rather than emitting a loose document.
 
 ### Plan
 

package/plugins/src/base/rules/prd-lifecycle-rollup.md

@@ -108,9 +108,17 @@ The PRD never advances to `shipped` on its own authority — it is **derived** f
 **`/lisa:verify` (one work item) vs `/lisa:verify-prd` (the whole initiative).** These are deliberately separate scopes:
 
 - **`/lisa:verify`** empirically verifies a **single work item** (a ticket / story / sub-task) in its target environment as part of that item's Build/Fix/Improve flow. It is what drives a build ticket to its `done` state; it operates at the *leaf/build* level (see `leaf-only-lifecycle`). It does **not** read the PRD or judge initiative-level acceptance, and it is **not** replaced by PRD verification.
-- **`/lisa:verify-prd`** is the **initiative-level acceptance gate**. It runs *after* the PRD is `shipped` (all generated top-level work terminal), reads the PRD and its generated child set, confirms the children are terminal, then runs spec-conformance against the original PRD requirements plus empirical verification of the shipped surface. On pass it transitions the PRD `shipped → verified` and posts evidence; on fail it transitions the PRD `shipped → blocked`, posts a product-readable failure report, and creates linked fix issues for the missing or incorrect behavior. Re-runs are idempotent (no duplicate evidence, fix issues, or lifecycle transitions).
+- **`/lisa:verify-prd`** is the **initiative-level acceptance gate**. It runs *after* the PRD is `shipped` (all generated top-level work terminal), reads the PRD and its generated child set, confirms the children are terminal, then runs spec-conformance against the original PRD requirements plus empirical verification of the shipped surface. On pass it transitions the PRD `shipped → verified` and posts evidence; on fail it **re-opens the PRD `shipped → ticketed`** (never `blocked`), creates **build-ready fix tickets** for the missing or incorrect behavior (registered as the PRD's generated work) and posts a product-readable failure report — the fix tickets auto-build, rollup re-ships the PRD once they are terminal, and a later cycle re-verifies (self-healing; see "Closing the loop" below). Re-runs are idempotent (no duplicate evidence, fix tickets, or lifecycle transitions).
 
-**No extra failure states.** A failed PRD verification reuses the existing `blocked` role (`shipped → blocked`) rather than introducing a `prd-verifying` or `prd-verification-failed` state — the lifecycle stays intentionally small. `verified` is terminal and product-owned (like `draft` and `shipped`); a PRD is never moved to `verified` solely because its tickets are closed, and a PRD is never closed/archived before verification has passed. The vendor maps for the `verified` role (`prd-verified` label for GitHub/Linear, `Verified` status for Notion, the verified parent page for Confluence) live in the `config-resolution` rule.
+**No extra failure states, and verification never uses `blocked`.** A failed PRD verification does **not** move the PRD to `blocked`; it re-opens the PRD `shipped → ticketed` and creates build-ready fix tickets (see "Closing the loop"), forming a self-healing loop rather than parking the PRD for a human. It introduces no `prd-verifying` or `prd-verification-failed` state — the lifecycle stays intentionally small, and `blocked` remains the *intake* (ready-stage validation) failure state, not the verification one. `verified` is terminal and product-owned (like `draft` and `shipped`); a PRD is never moved to `verified` solely because its tickets are closed, and a PRD is never closed/archived before verification has passed. The vendor maps for the `verified` role (`prd-verified` label for GitHub/Linear, `Verified` status for Notion, the verified parent page for Confluence) live in the `config-resolution` rule.
+
+### Closing the loop: PRD intake dispatches `/lisa:verify-prd` for shipped PRDs
+
+`shipped → verified` does not happen on its own — something has to run the acceptance gate. The PRD-intake scanners close that loop: in addition to the `ticketed → shipped` rollup, each PRD-intake cycle **dispatches `/lisa:verify-prd` for a shipped PRD** so a shipped PRD does not sit unverified forever. This is a **dispatch**, not a transition — the intake scanner still never *sets* the verification outcome itself; `/lisa:verify-prd` (which it invokes) performs the `shipped → verified` (pass) or, on fail, the `shipped → ticketed` re-open (it **never** uses `blocked`), with its own guard, evidence, and build-ready fix-ticket creation.
+
+**The self-healing FAIL loop.** When verify-prd fails it re-opens the PRD `shipped → ticketed` and creates **build-ready** fix tickets (registered as the PRD's generated work). Because the fix tickets are build-ready they are auto-claimed by the build queue with no human promotion; once they reach terminal, the `ticketed → shipped` rollup (Phase 3f) re-ships the PRD, and the next cycle's verify dispatch (Phase 3g) re-verifies. PASS ends at `verified`; FAIL starts another round. The loop **never auto-halts** (the failure report carries a verification-round count for human visibility) and **never** parks the PRD in `blocked`.
+
+Bounded, like the ready claim: `/lisa:verify-prd` is a heavy full flow (spec-conformance + empirical verification + fix-ticket creation), so a scanner verifies **one shipped PRD per cycle** and lets the scheduler drain the rest — the same one-item-per-cycle discipline the `ready` claim uses. After verify-prd runs, the PRD leaves `shipped` (to `verified` on pass, or `ticketed` on fail), so it is not re-picked by the shipped query that cycle; a PRD whose generated work is not actually terminal is guard-stopped by verify-prd and left `shipped` (verify-prd's gate, not the scanner's). A PRD that the project chose to close on ship (`*.rollup.closeOnShipped = true`) is out of the open verification queue — closing on ship is an explicit opt-out of the open loop. This dispatch is **behaviorally identical across all four PRD-intake skills** (the `github` / `linear` / `notion` / `confluence` `*-prd-intake` Phase 3g); only the `shipped`-role query surface differs.
 
 ## Idempotency dedupe key
 

package/plugins/src/base/rules/repo-scope-split.md

@@ -2,7 +2,7 @@
 
 Leaf work units are single-repo. A **leaf work unit** is an individually implementable ticket with no child tickets — issue types **Bug, Task, Sub-task, Improvement**. Each must name exactly one repository. **Epic, Story, Spike** are coordination containers and may span repos.
 
-This invariant is enforced at three points: gate **S10** in the `*-validate-*` skills (write time), `task-decomposition` step 1.5 (PRD-decomposition time), and the work-time split procedure below (when an agent picks up an existing ticket to implement it).
+This invariant is enforced at four points: gate **S10** in the `*-validate-*` skills (write time), `task-decomposition` step 1.5 (PRD-decomposition time), **claim-time repo scoping** in the build-intake skills (when intake decides whether to claim a ready ticket for the current repo — see below), and the work-time split procedure below (when an agent picks up an existing ticket to implement it).
 
 ## Two splitting strategies, by phase
 
@@ -32,6 +32,23 @@ Auto-split only when the split is unambiguous. Fall back to the standard BLOCK +
 - Splitting would strand stakeholder context that only the reporter can re-scope (e.g. the acceptance criteria describe a single indivisible cross-repo behavior with no clean per-repo boundary).
 - The metadata required to clone (parent, environment, credentials) is itself missing — block on the missing metadata first; do not propagate gaps into the siblings.
 
+## Claim-time repo scoping (build-intake)
+
+A ticketing system can oversee multiple repos (one JIRA project / Linear team for `frontend`, `backend`, `infrastructure`). When `lisa:*-build-intake` runs inside one repo, it claims only tickets for **that** repo — it never pulls a ready ticket meant for a sibling repo. This is the fourth enforcement point of the single-repo-leaf invariant; it runs in each vendor build-intake's claim gate (Phase 3a), **before** the leaf-only container gate and the claim.
+
+Resolve the current repo per the `config-resolution` "Repo scoping" section (config `repo` → `github.repo` → git remote basename; stop with a clear error if unresolvable). Then walk the ready candidates in priority order and apply the **repo-scope decision** to each before claiming:
+
+1. **Read the candidate's repo marker** — the `repo:<name>` label (JIRA: also a component equal to a repo name).
+   - **Labeled for another repo** → **skip** cheaply (do not claim, do not re-determine); it stays `ready` for that repo's own intake. Move to the next candidate.
+   - **Labeled for the current repo** → proceed to the leaf-only gate + claim (the cheap, common path once labels exist).
+   - **Unlabeled** → **determine** the target repo(s) from the ticket (description, acceptance criteria, technical approach) confirmed against the actual code surfaces the change requires — the same detection as step 1 of the work-time split. Then **stamp** the resolved `repo:<name>` label(s) so future cycles filter cheaply, and re-apply this decision with the now-known repo.
+2. **Multi-repo leaf → split, never claim.** If determination finds the leaf touches more than one repo, run the **work-time split procedure** below to break it into single-repo siblings — each created **build-ready** (`build_ready: true`, so the build queue auto-claims it) and stamped with its own `repo:<name>`. After the split, the current repo's sibling (if any) becomes a normal current-repo candidate; the others are separate single-repo `ready` leaves for their repos. A multi-repo leaf is never claimed as-is.
+3. **Wrong repo → skip.** A single-repo leaf whose `repo:<name>` ≠ the current repo is left `ready` (and labeled) and skipped; intake moves on until it finds a claimable current-repo leaf, then stops (one item per cycle).
+
+**Cost.** Only **unlabeled** candidates need content determination; once stamped, wrong-repo candidates are skipped by label alone. Prefer candidates already labeled `repo:<current>` first (cheap claim), falling through to unlabeled candidates (determine + stamp) only when no pre-labeled current-repo leaf is ready.
+
+A container (Epic/Story/Spike) is handled by the leaf-only gate, not here — containers may span repos and are never claimed/built directly.
+
 ## Vendor mechanics
 
 The procedure is vendor-neutral; the create + link + edit mechanics differ:

package/plugins/src/base/skills/confluence-prd-intake/SKILL.md

@@ -108,7 +108,7 @@ draft → ready → in_review → blocked | ticketed → shipped → verified
 
 (Each role corresponds to a dedicated parent page; the `verified` parent is resolved from `confluence.parents.verified`.)
 
-`verified` is the terminal state after `shipped`: it means the shipped product has been empirically checked against the PRD (set by `/lisa:verify-prd`, not by this intake skill). A failed post-ship verification re-parents back under `blocked` rather than introducing a separate `verifying` / `verification-failed` parent. Like `draft` and `shipped`, `verified` is **product-owned** — this intake skill never re-parents a PRD into or out of the `verified` parent. See the "PRD-level verification vs ticket verification" section of the `prd-lifecycle-rollup` rule.
+`verified` is the terminal state after `shipped`: it means the shipped product has been empirically checked against the PRD (set by `/lisa:verify-prd`, not by this intake skill). A failed post-ship verification does **not** use `blocked`; `/lisa:verify-prd` re-parents the PRD `shipped → ticketed` and creates build-ready fix tickets that auto-build and trigger a re-verify (the self-healing loop), introducing no `verifying` / `verification-failed` parent. Like `draft` and `shipped`, `verified` is **product-owned** — this intake skill never re-parents a PRD into or out of the `verified` parent. See the "PRD-level verification vs ticket verification" section of the `prd-lifecycle-rollup` rule.
 
 A PRD's current state is determined entirely by which lifecycle parent it sits under. Re-parenting is the transition.
 
@@ -352,6 +352,16 @@ The set of **required** children for the all-terminal check is the top-level chi
 
 This phase implements exactly one PRD-lifecycle hop — `ticketed → shipped` — and the optional config-gated archive that follows it. All terminal-state semantics, the generated-top-level-work boundary, and the dedupe-by-child-ref idempotency come from the `prd-lifecycle-rollup` rule; this skill is its Confluence implementation, not a second source of truth.
 
+#### 3g. PRD verification dispatch (close the loop on shipped PRDs)
+
+`shipped` and `verified` are distinct facts about a PRD (see the `prd-lifecycle-rollup` rule's "PRD-level verification vs ticket verification" and "Closing the loop" sections). Rollup (3f) only reaches the shipped parent; the `shipped → verified` (pass) / `shipped → ticketed` (fail) hops are owned by `/lisa:verify-prd`. This phase **closes that loop** by dispatching the initiative-level acceptance gate for shipped PRDs. It never performs the verification transition itself — the "never sets the verification outcome" invariant holds: `lisa:verify-prd`, not this skill, sets `verified` (or, on failure, re-opens the PRD to `ticketed`).
+
+Re-query the PRDs currently parented under the shipped lifecycle parent via `lisa:atlassian-access` `operation: read-page-descendants id: <confluence.parents.shipped>`. Pick the **first** one and invoke `lisa:verify-prd <page-url>`. Process **one shipped PRD per cycle** — `lisa:verify-prd` is a heavy full flow (spec-conformance + empirical verification + fix-issue creation), so it is bounded exactly like the single-ready-PRD claim in Phase 3; the scheduler drains the rest.
+
+**Per-cycle combined bound:** each scheduler cycle dispatches at most one ready PRD (the Phase 3 single-ready-PRD claim) **and** at most one shipped PRD for verification (this Phase 3g dispatch), for a maximum of two PRD operations per cycle. Ready intake runs first (Phase 3), then shipped verify (Phase 3g).
+
+`lisa:verify-prd` owns the outcome: on a CONFORMS verdict with all empirical checks passing it transitions the PRD to the verified parent and posts evidence; on a conformance miss or a failing/unavailable check it **re-parents the PRD shipped → ticketed** (never the blocked parent) and creates **build-ready** fix tickets registered as the PRD's generated work, then posts a failure report — the fix tickets auto-build, rollup (3f) re-ships the PRD once they are terminal, and a later cycle re-verifies (the self-healing loop). Either branch moves the PRD out of the shipped parent, so it is not re-picked this cycle; a PRD whose generated work is not actually terminal is guard-stopped by `lisa:verify-prd` (left under shipped) — that is verify-prd's gate, not this skill's. A PRD archived on ship (`confluence.rollup.closeOnShipped = true`) is out of the open verification queue. This phase, like 3f, is **behaviorally identical across all four intake skills** (`github-prd-intake`, `linear-prd-intake`, `notion-prd-intake`, `confluence-prd-intake`) — only the `$SHIPPED` query surface differs; keep them aligned. Record the dispatched PRD + verify-prd's verdict in the summary.
+
 ### Phase 4 — Summary report
 
 After processing the single selected PRD, emit a summary: