@codyswann/lisa 2.51.0 → 2.53.0

package/package.json

@@ -82,7 +82,7 @@
     "lodash": ">=4.18.1"
   },
   "name": "@codyswann/lisa",
-  "version": "2.51.0",
+  "version": "2.53.0",
   "description": "Claude Code governance framework that applies guardrails, guidance, and automated enforcement to projects",
   "main": "dist/index.js",
   "exports": {

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

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

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

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

package/plugins/lisa/commands/project-ideation.md

@@ -0,0 +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]"
+---
+
+Use the /lisa:project-ideation skill to generate a decision-ready idea report for the host project. $ARGUMENTS

package/plugins/lisa/commands/verify-prd.md

@@ -0,0 +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 (sibling tickets) runs spec-conformance + empirical verification and transitions the PRD shipped → verified | blocked."
+argument-hint: "<prd>"
+---
+
+Use the /lisa:verify-prd skill to read the PRD, confirm its generated top-level work is terminal, and run initiative-level acceptance verification. $ARGUMENTS

package/plugins/lisa/skills/project-ideation/SKILL.md

@@ -0,0 +1,118 @@
+---
+name: project-ideation
+description: "Generate practical, verifiable product or workflow ideas for the current host project. Inspects the host project (code, docs, scripts, data sources, current surfaces), optionally compares against external public products, and returns a prioritized idea report. Every build-ready idea must pass a practicality gate (an obtainable data/source path the project can plausibly implement) and an empirical verification gate (a user-observable outcome the agent can verify itself). Ideas that fail either gate are demoted to Discovery Spikes or Rejected / Not Practical Yet. Invoke for prompts like 'generate feature ideas for this project', 'looking at <external product>, what should we add here?', 'suggest practical improvements we can verify ourselves', or 'what should this app do next given the data we can get?'. Vendor- and stack-agnostic: works for web apps, APIs, CLIs, wiki systems, data pipelines, and internal tools. Does not create tickets or mutate the project — it produces a decision-ready report the user can later hand to a Research, Plan, or Implement flow."
+allowed-tools: ["Skill", "Bash", "Read", "Glob", "Grep", "WebFetch", "WebSearch"]
+---
+
+# Project Ideation
+
+Produce a decision-ready idea report for the host project described in `$ARGUMENTS` (or the current working directory if no target is given). The report separates ideas that are **build-ready now** from ideas that need a **discovery spike** and ideas that are **rejected / not practical yet**.
+
+The value of this skill is **filtering**, not brainstorming volume. An attractive idea you cannot ground in obtainable data and cannot verify yourself is not a recommendation — it is noise. Demote it honestly.
+
+## When to use
+
+Trigger this skill on prompts such as:
+
+- "generate feature ideas for this project"
+- "looking at <external product / website>, what should we add here?"
+- "suggest practical improvements we can verify ourselves"
+- "what should this app do next given the data we can get?"
+- "what high-value features could we add to <repo>?"
+
+Do **not** use this skill to create tickets, write a PRD, or change code. It stops at a report. The user can then ask Lisa to turn one or more ideas into a PRD (`/lisa:research`), a plan (`/lisa:plan`), or an implementation (`/lisa:implement`).
+
+## Two gates every build-ready idea must pass
+
+An idea may only appear under **Practical Ideas** if it passes BOTH gates. Otherwise demote it.
+
+1. **Practicality gate.** The project can plausibly implement the idea from sources that are actually available: existing code, an existing data model, a route/command/UI surface, a public or already-integrated API, a scrapeable public page, an existing user input, a local database, or documented integrations. You must be able to name the specific source and how the data is obtained. "We could probably get the data somehow" fails the gate.
+2. **Empirical verification gate.** You can personally confirm the resulting behavior by using the software or workflow — running the CLI, hitting the API, loading the page, querying the database, or inspecting a generated artifact — and capture a concrete evidence artifact. Saying "tests could be written later" does **not** satisfy this gate. Quality gates (tests, lint, typecheck, build) are prerequisites, never proof that an idea works.
+
+If an idea fails the practicality gate → it goes under **Rejected / Not Practical Yet** (or **Discovery Spikes** if a bounded probe could make it practical), with the missing data/source/access named explicitly.
+
+If an idea fails only the empirical verification gate → it goes under **Discovery Spikes** (define the missing proof) or stays as a strategic note, never as a build-ready recommendation.
+
+## Step 1 — Establish host-project context (always first)
+
+Never propose ideas before you understand what exists. Inspect the host project and record:
+
+- **Project type and package manager** — read the manifests (`package.json`, `pyproject.toml`, `go.mod`, `Cargo.toml`, `Gemfile`, etc.) and any `.lisa.config.json`.
+- **Docs and specs** — `README`, `docs/`, `wiki/`, architecture notes, ADRs.
+- **Current product surfaces or commands** — routes, screens, CLI subcommands, API endpoints, scheduled jobs, generated artifacts.
+- **Data model and existing user inputs** — schemas, migrations, forms, config the user already supplies.
+- **Available data sources and ingestion/scraping paths** — integrated APIs, public datasets, scrapeable public pages, local databases, event streams.
+- **Existing verification tooling and empirical paths** — how a human currently observes that the software works (a local dev server, a CLI you can run, a seedable DB, a dry-run mode).
+
+Use Lisa's existing methodology rather than inventing a parallel flow. Read the host code through the same lens as `/lisa:codebase-research` (trace data flow, find reusable code, identify modification points). When the request references an external product, use web/browser research; when the ideas would touch a live UI, use `/lisa:product-walkthrough` to ground the analysis in what exists today.
+
+## Step 2 — Optional external / public-source inspection
+
+Only when the user references an external product, website, public dataset, competitor, or example:
+
+- Inspect **public, no-login** surfaces only. Do not assume sign-in, credentials, or paid access.
+- Preserve every **source URL** you used so each informed idea can cite it.
+- If the runtime has no browser or web capability, mark that research source as **unavailable** and proceed with host-project-only ideas (document the fallback rather than fabricating findings).
+
+The external source is **inspiration, not a domain you bake in**. Keep the workflow reusable across any Lisa-managed repository.
+
+## Step 3 — Generate ideas, then filter through the gates
+
+Brainstorm broadly, then run every idea through both gates from the top of this skill. For each surviving idea, build a **feasibility card** containing at least:
+
+- **User/persona value** — why the host project's user would care.
+- **Existing fit** — the current route / API / CLI / model / doc / surface it builds on.
+- **Data/source required** — the specific data the idea consumes.
+- **How the data can be obtained or scraped** — the concrete accessible path (endpoint, query, public page, existing input).
+- **Known source limitations or terms constraints** — rate limits, robots/ToS, staleness, missing fields.
+- **Smallest practical implementation slice** — the minimal useful version.
+- **Empirical verification steps** — what you (the agent) will do against the running app / API / CLI / DB / artifact to confirm it works.
+- **Evidence artifact** — the screenshot, curl output, CLI output, DB row, or generated file the verifier captures.
+- **Confidence** — high | medium | low, with the reason.
+
+## Step 4 — Rank and assemble the report
+
+Rank build-ready ideas by **user value, feasibility, verification clarity, and project fit**. Emit the report in this shape:
+
+```markdown
+## What Already Exists
+- <current surfaces, data, commands, or workflows discovered — so duplicates are not re-proposed>
+
+## Practical Ideas
+### 1. <Idea name>
+- User value: <why the host project's user would care>
+- Existing fit: <current route/API/CLI/model/doc/surface it builds on>
+- Data/source path: <specific accessible source or scrape/API path>
+- Practical slice: <smallest useful version>
+- Empirical verification: <steps the agent can perform against the running software>
+- Evidence: <screenshot, curl output, CLI output, DB row, generated file, etc.>
+- Confidence: high|medium|low with reason
+
+## Discovery Spikes
+- <ideas that need proof of data, access, or verification before they can be build-ready — name the missing proof>
+
+## Rejected / Not Practical Yet
+- <attractive ideas rejected because data, access, legality, or verification is not available — name what is missing>
+```
+
+Always include the **What Already Exists** section so the user can tell genuinely new ideas from duplicates, and so the report records existing capabilities. Always include both the **Discovery Spikes** and **Rejected / Not Practical Yet** sections (even if empty) so the user can see what was deliberately filtered out and why.
+
+## Out of scope (hard rules)
+
+- **No sign-in-only ideas** unless the host project already supports sign-in *and* credentials are available.
+- **No private-data assumptions** — do not premise an idea on data the project cannot legitimately obtain.
+- **No manual-data-only requirements** unless the user explicitly accepts manual curation.
+- **No paid-API or non-scrapeable-source ideas** in the build-ready list — demote them with the blocker named.
+- **Tests, lint, typecheck, and build are not the empirical verification plan.** They are prerequisites; the verification plan must observe user-facing behavior.
+- **Do not auto-create tracker tickets or mutate the host project.** Produce the report only; planning and implementation are separate, user-invoked flows.
+- **Do not add a new verification or browser-automation framework** when the host project already has one — reuse it.
+- **Do not overfit to a source example.** Keep the workflow project-agnostic and reusable.
+
+## Handing off
+
+When the user wants to act on an idea, preserve its feasibility and verification card as the source artifact so downstream flows inherit the evidence:
+
+- Turn an idea into a PRD → `/lisa:research`
+- Turn a PRD into tickets → `/lisa:plan`
+- Build a ticket end-to-end → `/lisa:implement`
+- Lock in the verification so it never regresses → `/lisa:codify-verification`

package/plugins/lisa/skills/project-ideation/agents/openai.yaml

@@ -0,0 +1,4 @@
+display_name: "Project Ideation"
+short_description: "Generate practical, verifiable product or workflow ideas for the current host project"
+default_prompt:
+  - "Use $project-ideation: Generate practical, verifiable product or workflow ideas for the current host project."

package/plugins/lisa/skills/verify-prd/SKILL.md

@@ -0,0 +1,124 @@
+---
+name: verify-prd
+description: "Initiative-level PRD acceptance gate. Given a PRD ref/URL (GitHub Issue, Linear project/issue, Notion page, Confluence page, or JIRA issue), resolves the source vendor, reads the PRD body and its generated top-level child work set via the prd-lifecycle-rollup contract (native hierarchy first, machine-readable generated-work section fallback — never reimplementing child enumeration), and confirms every required generated top-level work item is terminal before any empirical verification runs. If any required top-level child is non-terminal, it reports the incomplete child set and STOPS without verifying or transitioning the PRD. The entry point of the PRD-level verification flow; the PASS path (spec-conformance + empirical verification + shipped → verified), the FAIL path (shipped → blocked + fix issues), and idempotency are handled by sibling work."
+allowed-tools: ["Skill", "Bash", "Read", "mcp__claude_ai_Notion__notion-fetch", "mcp__claude_ai_Notion__notion-get-comments", "mcp__atlassian__getConfluencePage", "mcp__atlassian__getConfluencePageDescendants", "mcp__atlassian__getJiraIssue", "mcp__atlassian__searchJiraIssuesUsingJql", "mcp__atlassian__getAccessibleAtlassianResources", "mcp__linear-server__get_project", "mcp__linear-server__list_issues", "mcp__linear-server__get_issue", "mcp__linear-server__list_documents", "mcp__linear-server__get_document"]
+---
+
+# PRD-level Verification: $ARGUMENTS
+
+`/lisa:verify-prd <prd>` is the **initiative-level acceptance gate**. It runs *after* a PRD is `shipped` (all generated top-level work terminal, per `prd-lifecycle-rollup`'s rollup phase) and proves the shipped product actually matches the PRD — not merely that every ticket is closed. `shipped` is **necessary but not sufficient** for `verified`: a PRD can have every child ticket closed while still missing a requirement, diverging from its acceptance criteria, or failing a real user workflow.
+
+This is distinct from `/lisa:verify`, which 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. `/lisa:verify` drives a build ticket to `done` at the leaf/build level; it does not read the PRD or judge initiative-level acceptance. `/lisa:verify-prd` operates one level up, over the whole initiative. See the `prd-lifecycle-rollup` rule's "PRD-level verification vs ticket verification" section for the full distinction.
+
+`$ARGUMENTS` is a single PRD reference: a **GitHub issue URL** (or `<org>/<repo>#<n>`), a **Linear project/issue URL**, a **Notion page URL**, a **Confluence page URL**, or a **JIRA issue key/URL**.
+
+## Confirmation policy
+
+Do **not** re-prompt once invoked. Like the `*-prd-intake` skills, the caller has already authorized the run by invoking the skill; asking the user to confirm before reading or before applying the guard defeats the purpose of a batchable acceptance gate. Run the front-half (resolve → read child set → guard) to completion and report.
+
+## Scope of this skill
+
+This skill is the **read/guard front-half** of PRD-level verification:
+
+1. Resolve the PRD ref and detect its source vendor.
+2. Read the PRD body and its **generated top-level child work set** via the `prd-lifecycle-rollup` contract.
+3. Apply the per-vendor terminal predicate to the generated top-level work and run the **terminal-child guard**: if any required top-level child is non-terminal, report the incomplete set and STOP — do not run empirical verification, do not transition the PRD.
+
+The remaining phases of PRD-level verification are **out of scope** here and are delivered by sibling work (this skill is their entry point):
+
+- **PASS path** — spec-conformance against the PRD's requirements + empirical verification of the shipped surface, then the `shipped → verified` transition with evidence.
+- **FAIL path** — on verification failure, the `shipped → blocked` transition, a product-readable failure report, and linked fix issues for the missing/incorrect behavior.
+- **Idempotency** — re-runs producing no duplicate evidence, fix issues, or lifecycle transitions.
+
+When the terminal-child guard passes (all required generated top-level work is terminal), this front-half hands off to the PASS/FAIL phases. Until those phases land, a passing guard means "ready for verification"; this skill does not itself transition the PRD to `verified` or `blocked`.
+
+## Phase 1 — Resolve the PRD ref and detect the source vendor
+
+Detect the vendor from `$ARGUMENTS` the same way `prd-ticket-coverage` / `prd-backlink` do — from the host (or key shape for JIRA), never by guessing:
+
+| Input shape | Vendor | Read surface |
+|---|---|---|
+| `github.com/<org>/<repo>/issues/<n>` or `<org>/<repo>#<n>` | **GitHub Issues** | `gh` CLI (Lisa uses the CLI exclusively for GitHub — no GitHub MCP) |
+| `linear.app/...` | **Linear** | `mcp__linear-server__get_project` / `get_issue` |
+| `notion.so` / `notion.site` | **Notion** | `mcp__claude_ai_Notion__notion-fetch` (`include_discussions: true`) |
+| `*.atlassian.net/wiki/...` | **Confluence** | `mcp__atlassian__getConfluencePage` (+ descendants) |
+| JIRA issue key (e.g. `PROJ-123`) or `*.atlassian.net/browse/...` | **JIRA** | `mcp__atlassian__getJiraIssue` |
+
+Read the PRD body via the vendor-appropriate surface. The vendor that owns the PRD source is what Phase 2 reads the child set from; it is independent of which tracker hosts the generated tickets (a Notion PRD can own JIRA tickets — the cross-vendor case is handled by the documented generated-work section in Phase 2).
+
+Where the PRD lives in the same vendor as the configured `tracker` (`.lisa.config.json`), prefer reading the PRD ticket through `lisa:tracker-read` so this skill stays agnostic of which tracker hosts the work — `tracker-read` dispatches to `lisa:github-read-issue` / `lisa:jira-read-ticket` / `lisa:linear-read-issue` per config and returns the consolidated context bundle (PRD body, native children, links). For PRD sources with no tracker counterpart (Notion / Confluence / cross-vendor), read the PRD body directly via the vendor surface above.
+
+## Phase 2 — Read the generated top-level child work set
+
+**Do NOT reimplement child enumeration.** Consume the PRD→generated-top-level-work relationship recorded by the merged child-linking work (`prd-backlink` native linking + its always-written machine-readable generated-work section), exactly as `github-prd-intake`'s rollup phase consumes it. Read the **generated top-level work** only — the PRD's created Epics and any top-level Story created directly under it — and **exclude** leaf Sub-tasks and any Story nested under a generated Epic, per the `prd-lifecycle-rollup` rule's generated-top-level-work contract.
+
+Use two sources, **native first**, deduped by child-ref identity:
+
+1. **Native hierarchy (primary).** Read the PRD's direct native children — these are its top-level children:
+   - **GitHub** — the PRD issue's direct `subIssues` nodes (the GraphQL `subIssues` query `lisa:github-read-issue` Phase 3 uses; capture `number title state url stateReason labels`).
+   - **Linear** — for a PRD Project, its member Issues (`list_issues({project})`); for a PRD Issue, its sub-Issues (`get_issue` children). Capture each child's `state` (workflow state + category).
+   - **JIRA** — the PRD's children via the epic-link/parent JQL `lisa:jira-read-ticket` Phase 5 uses (`"Epic Link" = <PRD-KEY>` or `parent = <PRD-KEY>`). Capture each child's `statusCategory`.
+   - **Notion / Confluence** — no native issue hierarchy; use the documented section below.
+
+2. **Documented generated-work section (fallback / cross-vendor).** When native hierarchy is unavailable (older host, cross-vendor PRD→tracker, or the relationship was only recorded in the PRD body), parse the machine-readable generated-work section `prd-backlink` writes to the PRD body (`## Tickets`, alias `## Generated Work`). Enumerate the `<!-- lisa:gw ref=… url=… type=… parent=… -->` tokens; the **generated top-level child set is every token whose `parent` is empty** (top-level), exactly as `prd-backlink` documents. Tokens with a non-empty `parent` are descendants — skip them. For GitHub, this is the same `awk` extraction `github-prd-intake` Phase 3f.2 uses.
+
+**Dedupe by child-ref identity** (`owner/repo#number` for GitHub, the issue/project identifier for Linear, the issue key for JIRA, the recorded ref for Notion/Confluence — the `prd-lifecycle-rollup` idempotency dedupe key) so a child appearing in both the native graph and the documented section is counted once. **Match by stable ref, never by title.**
+
+If neither source yields any generated top-level child (the PRD generated nothing, or the relationship was never recorded), report `no generated top-level children — cannot verify an empty PRD` and STOP. Do not transition the PRD.
+
+## Phase 3 — Terminal-child guard
+
+Apply the **per-vendor terminal-state predicate from the `prd-lifecycle-rollup` rule** to every generated **top-level** work item (cite the rule by slug — do not restate its predicate table here). In summary, a top-level child is:
+
+- **Terminal** — it has reached its source/tracker's done/shipped state (GitHub: closed + the resolved build `done` role label where used; Linear: a `done`-category completed state; JIRA: `statusCategory.key == "done"`; Notion/Confluence: the documented generated-work entry marked done). A generated Epic is terminal only when *it* has rolled up to its own terminal state per `leaf-only-lifecycle` — read the child's own resolved state; do not re-derive it from its leaves.
+- **Terminal-but-dropped** — closed-as-not-planned (GitHub `stateReason == "not_planned"`) / canceled (Linear) / won't-do. It does **not** hold the PRD open and is excluded from the required set.
+- **Incomplete / blocked** — anything else (still open, or closed without the `done` role). It holds the PRD open.
+
+The **required** set is the top-level children minus the terminal-but-dropped ones. Branch:
+
+**Any required top-level child is non-terminal** (the "Given a PRD has generated child work that is not terminal" scenario):
+
+1. **STOP.** Do **not** run empirical verification or spec-conformance.
+2. **Leave the PRD lifecycle untouched** — it stays at `shipped`. Do not transition it to `verified` or `blocked`; do not close or archive it.
+3. **Report the incomplete child set** — list each non-terminal required top-level child as `- <ref> "<title>" — <state>`, so product can see exactly what is blocking PRD-level verification.
+
+This guard exists because PRD-level acceptance is only meaningful once the work graph is actually complete. `shipped` is the precondition; verifying a PRD whose generated work is still in flight would produce a false PASS or FAIL against an incomplete product.
+
+**All required top-level children are terminal** (at least one required child exists): the guard passes. Hand off to the PASS/FAIL verification phases (sibling work, out of scope here — see [Scope of this skill](#scope-of-this-skill)). Until those phases land, report `terminal-child guard PASSED — <n> required top-level children terminal; ready for PRD-level verification` and stop.
+
+## Output
+
+Emit a single fenced text block so callers can parse it.
+
+```text
+## verify-prd: <PRD title>
+
+PRD: <ref/URL>  (vendor: <github|linear|notion|confluence|jira>)
+PRD lifecycle state: shipped
+Generated top-level children read: <n>  (source: native | documented | both)
+
+### Terminal-child guard
+- <ref> "<title>" — <terminal|terminal-but-dropped|incomplete>: <state>
+- ...
+
+Required top-level children: <n>   Terminal: <n>   Incomplete: <n>
+
+### Verdict: GUARD_PASSED | GUARD_BLOCKED | NO_CHILDREN
+```
+
+- `GUARD_BLOCKED` — one or more required top-level children are non-terminal; verification did not run; the PRD was left at `shipped`.
+- `GUARD_PASSED` — all required top-level children are terminal; ready to hand off to PRD-level verification (PASS/FAIL phases — sibling work).
+- `NO_CHILDREN` — no generated top-level children found; cannot verify; the PRD was left untouched.
+
+## Rules
+
+- **Read-only in this front-half.** This skill resolves the PRD, reads the child set, and applies the guard. It never transitions the PRD lifecycle — neither the guard-blocked path (leave at `shipped`) nor the guard-passed path (hand off; the `shipped → verified | blocked` hops are owned by the PASS/FAIL sibling work, not by this scaffold).
+- **Never reimplement child enumeration.** Consume the recorded PRD→child relationship (`prd-lifecycle-rollup` native linking + machine-readable generated-work section). The two-source read here mirrors `github-prd-intake` Phase 3f.2 — same sources, same dedupe-by-child-ref, same top-level-only boundary.
+- **Top-level only.** Exclude leaf Sub-tasks and Stories nested under a generated Epic. The PRD owns its top-level work; those top-level units own their descendants (`prd-lifecycle-rollup` generated-top-level-work contract).
+- **Cite, don't restate.** The generated-top-level-work boundary, the per-vendor terminal predicate, the env-keyed `done` resolution, and the dedupe-by-child-ref idempotency key all come from the `prd-lifecycle-rollup` rule. This skill is a consumer of that contract, not a second source of truth.
+
+## Related rules
+
+- `prd-lifecycle-rollup` — the vendor-neutral source of truth for PRD→generated-top-level-work ownership, the per-vendor terminal predicate, the `shipped` rollup, the `shipped → verified | blocked` PRD-level verification hops, and the child-ref idempotency dedupe key. This skill consumes that contract; it cites the rule by slug rather than restating its taxonomy.
+- `leaf-only-lifecycle` — governs the build lifecycle of leaf work units and how a generated Epic rolls up from its own children; this skill trusts that bottom-up rollup when reading a top-level child's resolved state.
+- `config-resolution` — the PRD-lifecycle role vocabulary (`shipped`, `verified`, `blocked`) and the env-keyed `done` map the terminal predicate resolves against.

package/plugins/lisa/skills/verify-prd/agents/openai.yaml

@@ -0,0 +1,4 @@
+display_name: "Verify PRD"
+short_description: "Initiative-level PRD acceptance gate"
+default_prompt:
+  - "Use $verify-prd: Initiative-level PRD acceptance gate."

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.51.0",
+  "version": "2.53.0",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.51.0",
+  "version": "2.53.0",
   "description": "AWS CDK-specific Lisa plugin.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.51.0",
+  "version": "2.53.0",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.51.0",
+  "version": "2.53.0",
   "description": "Expo and React Native-specific skills, agents, rules, and MCP servers.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-harper-fabric/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.51.0",
+  "version": "2.53.0",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-harper-fabric/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.51.0",
+  "version": "2.53.0",
   "description": "Harper/Fabric-specific Lisa rules for TypeScript component apps.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.51.0",
+  "version": "2.53.0",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.51.0",
+  "version": "2.53.0",
   "description": "NestJS-specific skills and migration write-protection hooks.",
   "author": {
     "name": "Cody Swann"

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

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

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.51.0",
+  "version": "2.53.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.51.0",
+  "version": "2.53.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.51.0",
+  "version": "2.53.0",
   "description": "Ruby on Rails-specific skills and hooks for RuboCop and ast-grep scanning on edit.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.51.0",
+  "version": "2.53.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.51.0",
+  "version": "2.53.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.51.0",
+  "version": "2.53.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.51.0",
+  "version": "2.53.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/src/base/commands/project-ideation.md

@@ -0,0 +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]"
+---
+
+Use the /lisa:project-ideation skill to generate a decision-ready idea report for the host project. $ARGUMENTS

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

@@ -0,0 +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 (sibling tickets) runs spec-conformance + empirical verification and transitions the PRD shipped → verified | blocked."
+argument-hint: "<prd>"
+---
+
+Use the /lisa:verify-prd skill to read the PRD, confirm its generated top-level work is terminal, and run initiative-level acceptance verification. $ARGUMENTS

package/plugins/src/base/skills/project-ideation/SKILL.md

@@ -0,0 +1,118 @@
+---
+name: project-ideation
+description: "Generate practical, verifiable product or workflow ideas for the current host project. Inspects the host project (code, docs, scripts, data sources, current surfaces), optionally compares against external public products, and returns a prioritized idea report. Every build-ready idea must pass a practicality gate (an obtainable data/source path the project can plausibly implement) and an empirical verification gate (a user-observable outcome the agent can verify itself). Ideas that fail either gate are demoted to Discovery Spikes or Rejected / Not Practical Yet. Invoke for prompts like 'generate feature ideas for this project', 'looking at <external product>, what should we add here?', 'suggest practical improvements we can verify ourselves', or 'what should this app do next given the data we can get?'. Vendor- and stack-agnostic: works for web apps, APIs, CLIs, wiki systems, data pipelines, and internal tools. Does not create tickets or mutate the project — it produces a decision-ready report the user can later hand to a Research, Plan, or Implement flow."
+allowed-tools: ["Skill", "Bash", "Read", "Glob", "Grep", "WebFetch", "WebSearch"]
+---
+
+# Project Ideation
+
+Produce a decision-ready idea report for the host project described in `$ARGUMENTS` (or the current working directory if no target is given). The report separates ideas that are **build-ready now** from ideas that need a **discovery spike** and ideas that are **rejected / not practical yet**.
+
+The value of this skill is **filtering**, not brainstorming volume. An attractive idea you cannot ground in obtainable data and cannot verify yourself is not a recommendation — it is noise. Demote it honestly.
+
+## When to use
+
+Trigger this skill on prompts such as:
+
+- "generate feature ideas for this project"
+- "looking at <external product / website>, what should we add here?"
+- "suggest practical improvements we can verify ourselves"
+- "what should this app do next given the data we can get?"
+- "what high-value features could we add to <repo>?"
+
+Do **not** use this skill to create tickets, write a PRD, or change code. It stops at a report. The user can then ask Lisa to turn one or more ideas into a PRD (`/lisa:research`), a plan (`/lisa:plan`), or an implementation (`/lisa:implement`).
+
+## Two gates every build-ready idea must pass
+
+An idea may only appear under **Practical Ideas** if it passes BOTH gates. Otherwise demote it.
+
+1. **Practicality gate.** The project can plausibly implement the idea from sources that are actually available: existing code, an existing data model, a route/command/UI surface, a public or already-integrated API, a scrapeable public page, an existing user input, a local database, or documented integrations. You must be able to name the specific source and how the data is obtained. "We could probably get the data somehow" fails the gate.
+2. **Empirical verification gate.** You can personally confirm the resulting behavior by using the software or workflow — running the CLI, hitting the API, loading the page, querying the database, or inspecting a generated artifact — and capture a concrete evidence artifact. Saying "tests could be written later" does **not** satisfy this gate. Quality gates (tests, lint, typecheck, build) are prerequisites, never proof that an idea works.
+
+If an idea fails the practicality gate → it goes under **Rejected / Not Practical Yet** (or **Discovery Spikes** if a bounded probe could make it practical), with the missing data/source/access named explicitly.
+
+If an idea fails only the empirical verification gate → it goes under **Discovery Spikes** (define the missing proof) or stays as a strategic note, never as a build-ready recommendation.
+
+## Step 1 — Establish host-project context (always first)
+
+Never propose ideas before you understand what exists. Inspect the host project and record:
+
+- **Project type and package manager** — read the manifests (`package.json`, `pyproject.toml`, `go.mod`, `Cargo.toml`, `Gemfile`, etc.) and any `.lisa.config.json`.
+- **Docs and specs** — `README`, `docs/`, `wiki/`, architecture notes, ADRs.
+- **Current product surfaces or commands** — routes, screens, CLI subcommands, API endpoints, scheduled jobs, generated artifacts.
+- **Data model and existing user inputs** — schemas, migrations, forms, config the user already supplies.
+- **Available data sources and ingestion/scraping paths** — integrated APIs, public datasets, scrapeable public pages, local databases, event streams.
+- **Existing verification tooling and empirical paths** — how a human currently observes that the software works (a local dev server, a CLI you can run, a seedable DB, a dry-run mode).
+
+Use Lisa's existing methodology rather than inventing a parallel flow. Read the host code through the same lens as `/lisa:codebase-research` (trace data flow, find reusable code, identify modification points). When the request references an external product, use web/browser research; when the ideas would touch a live UI, use `/lisa:product-walkthrough` to ground the analysis in what exists today.
+
+## Step 2 — Optional external / public-source inspection
+
+Only when the user references an external product, website, public dataset, competitor, or example:
+
+- Inspect **public, no-login** surfaces only. Do not assume sign-in, credentials, or paid access.
+- Preserve every **source URL** you used so each informed idea can cite it.
+- If the runtime has no browser or web capability, mark that research source as **unavailable** and proceed with host-project-only ideas (document the fallback rather than fabricating findings).
+
+The external source is **inspiration, not a domain you bake in**. Keep the workflow reusable across any Lisa-managed repository.
+
+## Step 3 — Generate ideas, then filter through the gates
+
+Brainstorm broadly, then run every idea through both gates from the top of this skill. For each surviving idea, build a **feasibility card** containing at least:
+
+- **User/persona value** — why the host project's user would care.
+- **Existing fit** — the current route / API / CLI / model / doc / surface it builds on.
+- **Data/source required** — the specific data the idea consumes.
+- **How the data can be obtained or scraped** — the concrete accessible path (endpoint, query, public page, existing input).
+- **Known source limitations or terms constraints** — rate limits, robots/ToS, staleness, missing fields.
+- **Smallest practical implementation slice** — the minimal useful version.
+- **Empirical verification steps** — what you (the agent) will do against the running app / API / CLI / DB / artifact to confirm it works.
+- **Evidence artifact** — the screenshot, curl output, CLI output, DB row, or generated file the verifier captures.
+- **Confidence** — high | medium | low, with the reason.
+
+## Step 4 — Rank and assemble the report
+
+Rank build-ready ideas by **user value, feasibility, verification clarity, and project fit**. Emit the report in this shape:
+
+```markdown
+## What Already Exists
+- <current surfaces, data, commands, or workflows discovered — so duplicates are not re-proposed>
+
+## Practical Ideas
+### 1. <Idea name>
+- User value: <why the host project's user would care>
+- Existing fit: <current route/API/CLI/model/doc/surface it builds on>
+- Data/source path: <specific accessible source or scrape/API path>
+- Practical slice: <smallest useful version>
+- Empirical verification: <steps the agent can perform against the running software>
+- Evidence: <screenshot, curl output, CLI output, DB row, generated file, etc.>
+- Confidence: high|medium|low with reason
+
+## Discovery Spikes
+- <ideas that need proof of data, access, or verification before they can be build-ready — name the missing proof>
+
+## Rejected / Not Practical Yet
+- <attractive ideas rejected because data, access, legality, or verification is not available — name what is missing>
+```
+
+Always include the **What Already Exists** section so the user can tell genuinely new ideas from duplicates, and so the report records existing capabilities. Always include both the **Discovery Spikes** and **Rejected / Not Practical Yet** sections (even if empty) so the user can see what was deliberately filtered out and why.
+
+## Out of scope (hard rules)
+
+- **No sign-in-only ideas** unless the host project already supports sign-in *and* credentials are available.
+- **No private-data assumptions** — do not premise an idea on data the project cannot legitimately obtain.
+- **No manual-data-only requirements** unless the user explicitly accepts manual curation.
+- **No paid-API or non-scrapeable-source ideas** in the build-ready list — demote them with the blocker named.
+- **Tests, lint, typecheck, and build are not the empirical verification plan.** They are prerequisites; the verification plan must observe user-facing behavior.
+- **Do not auto-create tracker tickets or mutate the host project.** Produce the report only; planning and implementation are separate, user-invoked flows.
+- **Do not add a new verification or browser-automation framework** when the host project already has one — reuse it.
+- **Do not overfit to a source example.** Keep the workflow project-agnostic and reusable.
+
+## Handing off
+
+When the user wants to act on an idea, preserve its feasibility and verification card as the source artifact so downstream flows inherit the evidence:
+
+- Turn an idea into a PRD → `/lisa:research`
+- Turn a PRD into tickets → `/lisa:plan`
+- Build a ticket end-to-end → `/lisa:implement`
+- Lock in the verification so it never regresses → `/lisa:codify-verification`

package/plugins/src/base/skills/verify-prd/SKILL.md

@@ -0,0 +1,124 @@
+---
+name: verify-prd
+description: "Initiative-level PRD acceptance gate. Given a PRD ref/URL (GitHub Issue, Linear project/issue, Notion page, Confluence page, or JIRA issue), resolves the source vendor, reads the PRD body and its generated top-level child work set via the prd-lifecycle-rollup contract (native hierarchy first, machine-readable generated-work section fallback — never reimplementing child enumeration), and confirms every required generated top-level work item is terminal before any empirical verification runs. If any required top-level child is non-terminal, it reports the incomplete child set and STOPS without verifying or transitioning the PRD. The entry point of the PRD-level verification flow; the PASS path (spec-conformance + empirical verification + shipped → verified), the FAIL path (shipped → blocked + fix issues), and idempotency are handled by sibling work."
+allowed-tools: ["Skill", "Bash", "Read", "mcp__claude_ai_Notion__notion-fetch", "mcp__claude_ai_Notion__notion-get-comments", "mcp__atlassian__getConfluencePage", "mcp__atlassian__getConfluencePageDescendants", "mcp__atlassian__getJiraIssue", "mcp__atlassian__searchJiraIssuesUsingJql", "mcp__atlassian__getAccessibleAtlassianResources", "mcp__linear-server__get_project", "mcp__linear-server__list_issues", "mcp__linear-server__get_issue", "mcp__linear-server__list_documents", "mcp__linear-server__get_document"]
+---
+
+# PRD-level Verification: $ARGUMENTS
+
+`/lisa:verify-prd <prd>` is the **initiative-level acceptance gate**. It runs *after* a PRD is `shipped` (all generated top-level work terminal, per `prd-lifecycle-rollup`'s rollup phase) and proves the shipped product actually matches the PRD — not merely that every ticket is closed. `shipped` is **necessary but not sufficient** for `verified`: a PRD can have every child ticket closed while still missing a requirement, diverging from its acceptance criteria, or failing a real user workflow.
+
+This is distinct from `/lisa:verify`, which 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. `/lisa:verify` drives a build ticket to `done` at the leaf/build level; it does not read the PRD or judge initiative-level acceptance. `/lisa:verify-prd` operates one level up, over the whole initiative. See the `prd-lifecycle-rollup` rule's "PRD-level verification vs ticket verification" section for the full distinction.
+
+`$ARGUMENTS` is a single PRD reference: a **GitHub issue URL** (or `<org>/<repo>#<n>`), a **Linear project/issue URL**, a **Notion page URL**, a **Confluence page URL**, or a **JIRA issue key/URL**.
+
+## Confirmation policy
+
+Do **not** re-prompt once invoked. Like the `*-prd-intake` skills, the caller has already authorized the run by invoking the skill; asking the user to confirm before reading or before applying the guard defeats the purpose of a batchable acceptance gate. Run the front-half (resolve → read child set → guard) to completion and report.
+
+## Scope of this skill
+
+This skill is the **read/guard front-half** of PRD-level verification:
+
+1. Resolve the PRD ref and detect its source vendor.
+2. Read the PRD body and its **generated top-level child work set** via the `prd-lifecycle-rollup` contract.
+3. Apply the per-vendor terminal predicate to the generated top-level work and run the **terminal-child guard**: if any required top-level child is non-terminal, report the incomplete set and STOP — do not run empirical verification, do not transition the PRD.
+
+The remaining phases of PRD-level verification are **out of scope** here and are delivered by sibling work (this skill is their entry point):
+
+- **PASS path** — spec-conformance against the PRD's requirements + empirical verification of the shipped surface, then the `shipped → verified` transition with evidence.
+- **FAIL path** — on verification failure, the `shipped → blocked` transition, a product-readable failure report, and linked fix issues for the missing/incorrect behavior.
+- **Idempotency** — re-runs producing no duplicate evidence, fix issues, or lifecycle transitions.
+
+When the terminal-child guard passes (all required generated top-level work is terminal), this front-half hands off to the PASS/FAIL phases. Until those phases land, a passing guard means "ready for verification"; this skill does not itself transition the PRD to `verified` or `blocked`.
+
+## Phase 1 — Resolve the PRD ref and detect the source vendor
+
+Detect the vendor from `$ARGUMENTS` the same way `prd-ticket-coverage` / `prd-backlink` do — from the host (or key shape for JIRA), never by guessing:
+
+| Input shape | Vendor | Read surface |
+|---|---|---|
+| `github.com/<org>/<repo>/issues/<n>` or `<org>/<repo>#<n>` | **GitHub Issues** | `gh` CLI (Lisa uses the CLI exclusively for GitHub — no GitHub MCP) |
+| `linear.app/...` | **Linear** | `mcp__linear-server__get_project` / `get_issue` |
+| `notion.so` / `notion.site` | **Notion** | `mcp__claude_ai_Notion__notion-fetch` (`include_discussions: true`) |
+| `*.atlassian.net/wiki/...` | **Confluence** | `mcp__atlassian__getConfluencePage` (+ descendants) |
+| JIRA issue key (e.g. `PROJ-123`) or `*.atlassian.net/browse/...` | **JIRA** | `mcp__atlassian__getJiraIssue` |
+
+Read the PRD body via the vendor-appropriate surface. The vendor that owns the PRD source is what Phase 2 reads the child set from; it is independent of which tracker hosts the generated tickets (a Notion PRD can own JIRA tickets — the cross-vendor case is handled by the documented generated-work section in Phase 2).
+
+Where the PRD lives in the same vendor as the configured `tracker` (`.lisa.config.json`), prefer reading the PRD ticket through `lisa:tracker-read` so this skill stays agnostic of which tracker hosts the work — `tracker-read` dispatches to `lisa:github-read-issue` / `lisa:jira-read-ticket` / `lisa:linear-read-issue` per config and returns the consolidated context bundle (PRD body, native children, links). For PRD sources with no tracker counterpart (Notion / Confluence / cross-vendor), read the PRD body directly via the vendor surface above.
+
+## Phase 2 — Read the generated top-level child work set
+
+**Do NOT reimplement child enumeration.** Consume the PRD→generated-top-level-work relationship recorded by the merged child-linking work (`prd-backlink` native linking + its always-written machine-readable generated-work section), exactly as `github-prd-intake`'s rollup phase consumes it. Read the **generated top-level work** only — the PRD's created Epics and any top-level Story created directly under it — and **exclude** leaf Sub-tasks and any Story nested under a generated Epic, per the `prd-lifecycle-rollup` rule's generated-top-level-work contract.
+
+Use two sources, **native first**, deduped by child-ref identity:
+
+1. **Native hierarchy (primary).** Read the PRD's direct native children — these are its top-level children:
+   - **GitHub** — the PRD issue's direct `subIssues` nodes (the GraphQL `subIssues` query `lisa:github-read-issue` Phase 3 uses; capture `number title state url stateReason labels`).
+   - **Linear** — for a PRD Project, its member Issues (`list_issues({project})`); for a PRD Issue, its sub-Issues (`get_issue` children). Capture each child's `state` (workflow state + category).
+   - **JIRA** — the PRD's children via the epic-link/parent JQL `lisa:jira-read-ticket` Phase 5 uses (`"Epic Link" = <PRD-KEY>` or `parent = <PRD-KEY>`). Capture each child's `statusCategory`.
+   - **Notion / Confluence** — no native issue hierarchy; use the documented section below.
+
+2. **Documented generated-work section (fallback / cross-vendor).** When native hierarchy is unavailable (older host, cross-vendor PRD→tracker, or the relationship was only recorded in the PRD body), parse the machine-readable generated-work section `prd-backlink` writes to the PRD body (`## Tickets`, alias `## Generated Work`). Enumerate the `<!-- lisa:gw ref=… url=… type=… parent=… -->` tokens; the **generated top-level child set is every token whose `parent` is empty** (top-level), exactly as `prd-backlink` documents. Tokens with a non-empty `parent` are descendants — skip them. For GitHub, this is the same `awk` extraction `github-prd-intake` Phase 3f.2 uses.
+
+**Dedupe by child-ref identity** (`owner/repo#number` for GitHub, the issue/project identifier for Linear, the issue key for JIRA, the recorded ref for Notion/Confluence — the `prd-lifecycle-rollup` idempotency dedupe key) so a child appearing in both the native graph and the documented section is counted once. **Match by stable ref, never by title.**
+
+If neither source yields any generated top-level child (the PRD generated nothing, or the relationship was never recorded), report `no generated top-level children — cannot verify an empty PRD` and STOP. Do not transition the PRD.
+
+## Phase 3 — Terminal-child guard
+
+Apply the **per-vendor terminal-state predicate from the `prd-lifecycle-rollup` rule** to every generated **top-level** work item (cite the rule by slug — do not restate its predicate table here). In summary, a top-level child is:
+
+- **Terminal** — it has reached its source/tracker's done/shipped state (GitHub: closed + the resolved build `done` role label where used; Linear: a `done`-category completed state; JIRA: `statusCategory.key == "done"`; Notion/Confluence: the documented generated-work entry marked done). A generated Epic is terminal only when *it* has rolled up to its own terminal state per `leaf-only-lifecycle` — read the child's own resolved state; do not re-derive it from its leaves.
+- **Terminal-but-dropped** — closed-as-not-planned (GitHub `stateReason == "not_planned"`) / canceled (Linear) / won't-do. It does **not** hold the PRD open and is excluded from the required set.
+- **Incomplete / blocked** — anything else (still open, or closed without the `done` role). It holds the PRD open.
+
+The **required** set is the top-level children minus the terminal-but-dropped ones. Branch:
+
+**Any required top-level child is non-terminal** (the "Given a PRD has generated child work that is not terminal" scenario):
+
+1. **STOP.** Do **not** run empirical verification or spec-conformance.
+2. **Leave the PRD lifecycle untouched** — it stays at `shipped`. Do not transition it to `verified` or `blocked`; do not close or archive it.
+3. **Report the incomplete child set** — list each non-terminal required top-level child as `- <ref> "<title>" — <state>`, so product can see exactly what is blocking PRD-level verification.
+
+This guard exists because PRD-level acceptance is only meaningful once the work graph is actually complete. `shipped` is the precondition; verifying a PRD whose generated work is still in flight would produce a false PASS or FAIL against an incomplete product.
+
+**All required top-level children are terminal** (at least one required child exists): the guard passes. Hand off to the PASS/FAIL verification phases (sibling work, out of scope here — see [Scope of this skill](#scope-of-this-skill)). Until those phases land, report `terminal-child guard PASSED — <n> required top-level children terminal; ready for PRD-level verification` and stop.
+
+## Output
+
+Emit a single fenced text block so callers can parse it.
+
+```text
+## verify-prd: <PRD title>
+
+PRD: <ref/URL>  (vendor: <github|linear|notion|confluence|jira>)
+PRD lifecycle state: shipped
+Generated top-level children read: <n>  (source: native | documented | both)
+
+### Terminal-child guard
+- <ref> "<title>" — <terminal|terminal-but-dropped|incomplete>: <state>
+- ...
+
+Required top-level children: <n>   Terminal: <n>   Incomplete: <n>
+
+### Verdict: GUARD_PASSED | GUARD_BLOCKED | NO_CHILDREN
+```
+
+- `GUARD_BLOCKED` — one or more required top-level children are non-terminal; verification did not run; the PRD was left at `shipped`.
+- `GUARD_PASSED` — all required top-level children are terminal; ready to hand off to PRD-level verification (PASS/FAIL phases — sibling work).
+- `NO_CHILDREN` — no generated top-level children found; cannot verify; the PRD was left untouched.
+
+## Rules
+
+- **Read-only in this front-half.** This skill resolves the PRD, reads the child set, and applies the guard. It never transitions the PRD lifecycle — neither the guard-blocked path (leave at `shipped`) nor the guard-passed path (hand off; the `shipped → verified | blocked` hops are owned by the PASS/FAIL sibling work, not by this scaffold).
+- **Never reimplement child enumeration.** Consume the recorded PRD→child relationship (`prd-lifecycle-rollup` native linking + machine-readable generated-work section). The two-source read here mirrors `github-prd-intake` Phase 3f.2 — same sources, same dedupe-by-child-ref, same top-level-only boundary.
+- **Top-level only.** Exclude leaf Sub-tasks and Stories nested under a generated Epic. The PRD owns its top-level work; those top-level units own their descendants (`prd-lifecycle-rollup` generated-top-level-work contract).
+- **Cite, don't restate.** The generated-top-level-work boundary, the per-vendor terminal predicate, the env-keyed `done` resolution, and the dedupe-by-child-ref idempotency key all come from the `prd-lifecycle-rollup` rule. This skill is a consumer of that contract, not a second source of truth.
+
+## Related rules
+
+- `prd-lifecycle-rollup` — the vendor-neutral source of truth for PRD→generated-top-level-work ownership, the per-vendor terminal predicate, the `shipped` rollup, the `shipped → verified | blocked` PRD-level verification hops, and the child-ref idempotency dedupe key. This skill consumes that contract; it cites the rule by slug rather than restating its taxonomy.
+- `leaf-only-lifecycle` — governs the build lifecycle of leaf work units and how a generated Epic rolls up from its own children; this skill trusts that bottom-up rollup when reading a top-level child's resolved state.
+- `config-resolution` — the PRD-lifecycle role vocabulary (`shipped`, `verified`, `blocked`) and the env-keyed `done` map the terminal predicate resolves against.