npm - @codyswann/lisa - Versions diffs - 2.54.0 → 2.56.0 - Mend

@codyswann/lisa 2.54.0 → 2.56.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (27) hide show

package/package.json CHANGED Viewed

@@ -82,7 +82,7 @@
     "lodash": ">=4.18.1"
   },
   "name": "@codyswann/lisa",
-  "version": "2.54.0",
+  "version": "2.56.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 CHANGED Viewed

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

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

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

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

@@ -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 (sibling tickets) runs spec-conformance + empirical verification and transitions the PRD shipped → verified | blocked."
+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)."
 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
+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

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

@@ -44,7 +44,11 @@ Never propose ideas before you understand what exists. Inspect the host project
 - **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.
+Use Lisa's existing methodology rather than inventing a parallel flow. Route each evidence source through the matching established practice before any idea is promoted to **Practical Ideas**:
+- **Host-code inspection** uses `/lisa:codebase-research` concepts: trace data flow from entry point to output, identify modification points, map dependencies, and find reusable code or patterns.
+- **Public, no-login comparison** uses web/browser research when those tools are available: inspect the public surface, preserve source URLs, and separate observed behavior from inference.
+- **UI-facing recommendations** use `/lisa:product-walkthrough` methodology first: inspect the current product surface, note existing-component reuse candidates, capture coverage smells or behavioral surprises, and only then list a UI idea as build-ready.
 ## Step 2 — Optional external / public-source inspection

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

@@ -1,4 +1,6 @@
-display_name: "Project Ideation"
-short_description: "Generate practical, verifiable product or workflow ideas for the current host project"
+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."
+  - 'Use $project-ideation: Generate practical feature ideas for this project.'
+  - 'Use $project-ideation: Looking at an external public product, what should we add here?'
+  - 'Use $project-ideation: Suggest practical improvements we can verify ourselves.'

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

@@ -1,6 +1,6 @@
 ---
 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."
+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 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. When the guard passes, it runs the PASS path: spec-conformance against the original PRD requirements (via the spec-conformance skill) plus empirical verification appropriate to the shipped surface (via verification-lifecycle), and on a CONFORMS verdict with all empirical checks passing transitions the PRD shipped → verified and posts verification evidence. 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"]
 ---
@@ -18,19 +18,21 @@ Do **not** re-prompt once invoked. Like the `*-prd-intake` skills, the caller ha
 ## Scope of this skill
-This skill is the **read/guard front-half** of PRD-level verification:
+This skill covers the **read/guard front-half** plus the **PASS path** 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.
+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 verification, do not transition the PRD.
+4. **Spec conformance** — when the guard passes, invoke the `spec-conformance` skill with the PRD as the spec source to build a section-by-section coverage matrix against the shipped product (never reimplementing the matrix).
+5. **Empirical verification** — invoke `verification-lifecycle` to run empirical checks appropriate to the PRD's surface (browser/computer-use, API, CLI, DB, screenshots, logs), honoring the `verification` rule. Quality gates (test/typecheck/lint) are **not** verification.
+6. **PASS transition + evidence** — when spec conformance is `CONFORMS` **and** every applicable empirical check passes, transition the PRD lifecycle from the resolved `shipped` role to the resolved `verified` role (vendor-neutral via `config-resolution`) and post verification evidence (the coverage matrix + empirical proof artifacts) back on 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):
+The remaining phases of PRD-level verification are **out of scope** here and are delivered by sibling work:
-- **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.
+- **FAIL path** — on verification failure (spec conformance not `CONFORMS`, or any empirical check failing), 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`.
+This skill implements only the **PASS** branch of Phase 6. When verification does not pass it stops at the verdict and **leaves the PRD at `shipped`** (it does not transition to `blocked`, does not open fix issues) — that is the FAIL sibling's job. Re-running before the idempotency sibling lands may re-post evidence or re-apply the (idempotent-by-label) transition; full no-duplicate guarantees are the idempotency sibling's job.
 ## Phase 1 — Resolve the PRD ref and detect the source vendor
@@ -84,7 +86,122 @@ The **required** set is the top-level children minus the terminal-but-dropped on
 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.
+**All required top-level children are terminal** (at least one required child exists): the guard passes. Proceed to **Phase 4 — Spec conformance** and the rest of the PASS path below. The guard is the precondition for verification; only once the work graph is complete is it meaningful to check the shipped product against the PRD.
+## Phase 4 — Spec conformance against the PRD
+The guard proves the work graph is *complete*; spec conformance proves the shipped product matches *what the PRD asked for*, section by section. This is the "accountant lens" — did the initiative ship exactly the PRD's requirements, nothing silently dropped, nothing scope-crept?
+**Do NOT reimplement the coverage matrix.** Invoke the existing `spec-conformance` skill with the PRD as the spec source:
+```text
+/spec-conformance <PRD ref/URL>
+```
+Pass the same `$ARGUMENTS` PRD reference resolved in Phase 1. `spec-conformance` Phase 1 already accepts a GitHub issue URL / Linear identifier / JIRA key / Notion / Confluence PRD as its spec source and loads the full PRD body (via `tracker-read` or the vendor surface), so the PRD is the spec here — not a plan file or a leaf ticket. It then:
+- extracts every PRD requirement into a structured list (acceptance criteria, Out of Scope, technical commitments, Validation Journey assertions, deliverables);
+- inspects the shipped product (the merged work across the generated top-level children) for evidence of each;
+- builds a **section-by-section coverage matrix** mapping each requirement to evidence;
+- flags scope creep (Out-of-Scope violations) and untraceable changes separately from misses;
+- returns a verdict: **`CONFORMS`**, **`PARTIAL`**, or **`DIVERGES`**.
+Capture the coverage matrix and verdict verbatim — both feed the evidence comment in Phase 6 and gate the PASS branch.
+Spec conformance at the PRD level differs from the leaf-ticket conformance run during a single item's Build/Fix/Improve flow: the spec is the **PRD itself** (the whole initiative's requirements), and the shipped work is the **union** of all generated top-level children, not one branch's diff. The `spec-conformance` skill handles both because its spec source is parameterized; this skill simply hands it the PRD.
+**Branch on the verdict:**
+- **`CONFORMS`** — continue to Phase 5 (empirical verification).
+- **`PARTIAL` or `DIVERGES`** — verification has **not** passed. Stop the PASS path: record the verdict and the matrix in the output, **leave the PRD at `shipped`**, and do not transition or post a verified-evidence comment. Handing the `shipped → blocked` transition, the product-readable failure report, and the linked fix issues to the FAIL sibling is out of scope here (see [Scope of this skill](#scope-of-this-skill)).
+## Phase 5 — Empirical verification of the shipped surface
+Spec conformance reads the diff and the requirements; empirical verification **runs the actual shipped system and observes results**. Quality gates (tests, typecheck, lint) are prerequisites, **not** verification — a green test suite never substitutes for exercising the shipped product (see the `verification` rule).
+**The verification surface is PRD-dependent.** A PRD that shipped a UI flow is verified through the browser; one that shipped an API through request/response captures; a CLI through command runs; a schema change through database queries; a background job through logs and queue inspection. Do not assume a fixed surface — classify it from what the PRD actually delivered.
+**Do NOT reinvent the verification machinery.** Invoke the `verification-lifecycle` skill and follow its mandatory sequence (confirm quality gates → classify empirical types → check tooling → fail-fast → plan → execute → codify → loop) against the *shipped initiative*:
+```text
+/verification-lifecycle
+```
+1. **Classify** the empirical verification types that apply to the PRD's shipped surface, per the Verification Types table in the `verification` rule.
+2. **Discover tooling** for each type (browser/computer-use MCP, HTTP client, DB client, CLI, log/metrics access) via the lifecycle's Tool Discovery Process. For a UI surface, reuse the `product-walkthrough` skill to drive the live product through a real browser and ground verification (and the eventual evidence comment) in what actually renders.
+3. **Plan** each check: the exact tool/command, the expected pass outcome, and any prerequisites (running service, seeded data, auth). A plan that lists only `test`/`typecheck`/`lint` is not a verification plan.
+4. **Execute** each check and collect **proof artifacts** (screenshots, request/response captures, query outputs, log excerpts with correlation IDs) per the lifecycle's Proof Artifacts Requirements.
+5. **Codify** — for each passing empirical verification, the lifecycle invokes `codify-verification` to encode it as a regression test (Playwright for UI, integration test for API/DB, benchmark for performance) so the PRD's behavior cannot silently regress. Honor that step; it is mandatory for every empirical type except the inherently non-behavioral set the lifecycle exempts.
+If a required surface or its tooling is unavailable, follow the lifecycle's Escalation Protocol — declare the verification level (PARTIALLY VERIFIED / UNVERIFIED) and surface the gap rather than declaring a false PASS.
+**Branch on the result:**
+- **Every applicable empirical check passes** (and is codified where the lifecycle requires) — continue to Phase 6.
+- **Any applicable empirical check fails, or a required surface is unavailable** — verification has **not** passed. Stop the PASS path: record what failed/was-blocked in the output, **leave the PRD at `shipped`**, and do not transition or post verified evidence. The `shipped → blocked` hop + fix issues are the FAIL sibling's job (out of scope here).
+> **Single-environment note.** In a single-environment project (`main`/production only, no dev/staging), the shipped surface is whatever production exposes. A project with no deployed application, sign-in, or end-to-end environment variables (Lisa itself) verifies on its CLI/dry-run surface — running the documentation/skill build and drift check — which is the empirical surface the PRD's Validation Journey declares. The surface is always PRD-dependent: read the PRD's Empirical Verification Plan and verify what it says ships.
+## Phase 6 — PASS: transition `shipped → verified` and post evidence
+Reach this phase **only** when **both** are true:
+- Phase 4 spec conformance returned **`CONFORMS`**, and
+- Phase 5 every applicable empirical check **passed** (and was codified where required).
+If either is false, do not enter this phase — stop at the verdict and leave the PRD at `shipped` (the FAIL sibling owns the `blocked` path).
+### 6.1 — Resolve the `verified` and `shipped` roles
+Resolve the PRD-lifecycle roles from `.lisa.config.json` (then `.lisa.config.local.json` override) per the `config-resolution` rule — the same role-resolution the `*-prd-intake` skills use. **Cite `config-resolution` for the role vocabulary; do not hardcode label strings except as the documented defaults.** Resolution per vendor:
+| Vendor | `shipped` role | `verified` role | Default `verified` |
+|---|---|---|---|
+| **GitHub** | `github.labels.prd.shipped` | `github.labels.prd.verified` | `prd-verified` (label) |
+| **Linear** | `linear.labels.prd.shipped` | `linear.labels.prd.verified` | `prd-verified` (project/issue label) |
+| **Notion** | `notion.values.shipped` | `notion.values.verified` | `Verified` (status value) |
+| **Confluence** | `confluence.parents.shipped` | `confluence.parents.verified` | the `Verified` parent page id |
+| **JIRA** | the configured shipped status | the configured verified status | per `config-resolution` |
+For GitHub, resolve with the same helper `github-prd-intake` uses:
+```bash
+read_role() {  # role default → resolved value (local override wins)
+  local role="$1" default="$2" local_v global_v
+  local_v=$(jq -r ".github.labels.prd.${role} // empty" .lisa.config.local.json 2>/dev/null)
+  global_v=$(jq -r ".github.labels.prd.${role} // empty" .lisa.config.json 2>/dev/null)
+  echo "${local_v:-${global_v:-$default}}"
+}
+SHIPPED=$(read_role shipped  prd-shipped)
+VERIFIED=$(read_role verified prd-verified)
+```
+### 6.2 — Transition the PRD `shipped → verified`
+Apply the vendor-appropriate transition. This is the `shipped → verified` PASS hop the `prd-lifecycle-rollup` rule defines (cite it by slug; this skill is its PASS-path implementation, not a second source of truth):
+- **GitHub / Linear** — remove the `shipped` label and add the `verified` label. For GitHub:
+  ```bash
+  gh issue edit <prd-num> --repo <org>/<repo> --remove-label "$SHIPPED" --add-label "$VERIFIED"
+  ```
+  Verify exactly **one** PRD-lifecycle label remains afterward (the single-label invariant `github-prd-intake` enforces). For Linear, set the project/issue label equivalently.
+- **Notion** — set the PRD page's `notion.statusProperty` (default `Status`) to the resolved `verified` value (default `Verified`).
+- **Confluence** — move the PRD page's `parentId` to `confluence.parents.verified` (the parent-page-based lifecycle; Atlassian scoped tokens cannot write labels — see `config-resolution`).
+- **JIRA** — transition the PRD issue to the configured `verified` status.
+`verified` is the terminal, product-owned PRD state; this skill is the **only** automated writer of it (intake/rollup never set it). Do **not** close or archive the PRD here — closure is governed separately by `prd.rollup.closeOnShipped` at the `shipped` hop, not the verify hop.
+### 6.3 — Post verification evidence on the PRD
+Post a verification-evidence comment back on the PRD, in the spirit of `tracker-evidence` (the vendor-neutral evidence poster). Because the evidence lands on the **PRD source** — which may be Notion or Confluence, not a tracker ticket — post via the vendor surface that owns the PRD: `gh issue comment` for GitHub, the Linear comment API, the Notion/Confluence page comment surface, or a JIRA comment. Where the PRD lives in the configured `tracker`, you may dispatch through `tracker-evidence`; for Notion/Confluence/cross-vendor PRDs, comment on the PRD page directly. The evidence comment MUST include:
+1. **AI disclosure** — lead with "PRD-level verification by Claude (AI agent, not a human)."
+2. **Verdict line** — `shipped → verified — PASS`.
+3. **Spec-conformance coverage matrix** — the section-by-section matrix from Phase 4 verbatim, with the `CONFORMS` verdict.
+4. **Empirical proof artifacts** — the Phase 5 artifacts per surface: screenshots (upload via `gh release upload pr-assets <files> --clobber` and reference as plain URLs, per the `tracker-evidence` UI Evidence Checklist), request/response captures, query outputs, log excerpts, and the codified regression test(s) added.
+5. **What was verified** — which PRD acceptance criteria each artifact covers, and the verification surface used.
+Then emit the PASS output block (below).
 ## Output
@@ -94,7 +211,7 @@ Emit a single fenced text block so callers can parse it.
 ## verify-prd: <PRD title>
 PRD: <ref/URL>  (vendor: <github|linear|notion|confluence|jira>)
-PRD lifecycle state: shipped
+PRD lifecycle state: <shipped | verified>
 Generated top-level children read: <n>  (source: native | documented | both)
 ### Terminal-child guard
@@ -103,22 +220,48 @@ Generated top-level children read: <n>  (source: native | documented | both)
 Required top-level children: <n>   Terminal: <n>   Incomplete: <n>
-### Verdict: GUARD_PASSED | GUARD_BLOCKED | NO_CHILDREN
+### Spec conformance      (only when guard passed)
+Verdict: <CONFORMS | PARTIAL | DIVERGES>
+<coverage matrix summary: requirements covered / missed / scope-crept>
+### Empirical verification  (only when conformance CONFORMS)
+Surface: <browser | api | cli | db | logs | ...>  (PRD-dependent)
+<each check — tool/command → PASS/FAIL → artifact ref; codified test(s)>
+### Lifecycle transition   (only on PASS)
+shipped → verified   (role: <resolved verified role>)   evidence posted: <link>
+### Verdict: VERIFIED_PASS | CONFORMANCE_FAILED | EMPIRICAL_FAILED | 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.
+- `CONFORMANCE_FAILED` — guard passed but spec conformance returned `PARTIAL`/`DIVERGES`; empirical verification did not run; the PRD was left at `shipped` (the `shipped → blocked` transition + fix issues are the FAIL sibling's job).
+- `EMPIRICAL_FAILED` — guard passed and conformance `CONFORMS`, but an applicable empirical check failed or a required surface was unavailable; the PRD was left at `shipped` (FAIL sibling owns the `blocked` path).
+- `VERIFIED_PASS` — guard passed, conformance `CONFORMS`, every applicable empirical check passed and was codified; the PRD was transitioned `shipped → verified` and verification evidence was posted.
 ## 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).
+- **The only lifecycle write is the PASS hop `shipped → verified`.** The front-half (resolve → read child set → guard) is read-only and never transitions the PRD. The only write this skill performs is the Phase 6 PASS hop — and **only** when spec conformance is `CONFORMS` and every applicable empirical check passes. The guard-blocked, no-children, conformance-failed, and empirical-failed paths all leave the PRD at `shipped` untouched. The `shipped → blocked` FAIL hop, fix issues, and re-run idempotency are sibling work (out of scope).
 - **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.
+- **Never reimplement spec conformance or verification.** Phase 4 invokes the `spec-conformance` skill (the single source of truth for the coverage matrix and the `CONFORMS`/`PARTIAL`/`DIVERGES` verdict); Phase 5 invokes `verification-lifecycle` (which in turn invokes `codify-verification` and, for UI, `product-walkthrough`). This skill orchestrates those skills against the PRD; it does not duplicate their logic.
+- **Quality gates are not verification.** Tests, typecheck, and lint are prerequisites enforced by hooks/CI. Phase 5 requires running the actual shipped system and observing results on a surface chosen from what the PRD delivered — never substituting a green test suite for empirical proof (`verification` rule).
+- **The verification surface is PRD-dependent.** Classify the empirical surface (browser/API/CLI/DB/logs/…) from what the PRD shipped; do not assume a fixed surface. A single-environment project with no deployed app verifies on its CLI/dry-run surface per the PRD's Empirical Verification Plan.
+- **`verified` is product-owned and terminal.** This skill is the only automated writer of the `verified` role; intake/rollup never set it. The PASS hop does not close or archive the PRD (closure is governed by `prd.rollup.closeOnShipped` at the `shipped` hop).
 - **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.
+- **Cite, don't restate.** The generated-top-level-work boundary, the per-vendor terminal predicate, the env-keyed `done` resolution, the dedupe-by-child-ref idempotency key, and the `shipped → verified` PASS hop all come from the `prd-lifecycle-rollup` rule; the `verified`/`shipped` role vocabulary comes from `config-resolution`. This skill is a consumer of those contracts, not a second source of truth.
+## Related skills
+- `spec-conformance` — Phase 4 invokes it with the PRD as the spec source; it owns the section-by-section coverage matrix and the `CONFORMS`/`PARTIAL`/`DIVERGES` verdict. This skill never reimplements that matrix.
+- `verification-lifecycle` — Phase 5 invokes it to run empirical verification of the shipped surface (classify → check tooling → plan → execute → codify → loop). It in turn invokes `codify-verification` and, for UI surfaces, `product-walkthrough`.
+- `codify-verification` — turns each passing empirical verification into a regression test so the PRD's verified behavior cannot silently regress; invoked transitively via `verification-lifecycle`.
+- `product-walkthrough` — drives the live product through a real browser to ground UI-surface verification and the evidence comment in what actually renders.
+- `tracker-evidence` — the vendor-neutral evidence poster whose UI Evidence Checklist and `pr-assets` upload mechanics Phase 6.3 follows when posting the verification evidence comment on the PRD.
 ## 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.
+- `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 — including the `shipped → verified` PASS hop it implements — citing the rule by slug rather than restating its taxonomy.
+- `verification` — defines what counts as empirical verification (the Verification Types table) and that quality gates (test/typecheck/lint) are prerequisites, not verification. Phase 5 honors it when classifying and running the surface-appropriate checks.
 - `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.
+- `config-resolution` — the PRD-lifecycle role vocabulary (`shipped`, `verified`, `blocked`), the per-vendor `verified` role maps (`prd-verified` label for GitHub/Linear, `Verified` status for Notion, `confluence.parents.verified` parent page) Phase 6.1 resolves, and the env-keyed `done` map the terminal predicate resolves against.

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

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

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

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

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

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

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.54.0",
+  "version": "2.56.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 CHANGED Viewed

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

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

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

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

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

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

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

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.54.0",
+  "version": "2.56.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 CHANGED Viewed

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.54.0",
+  "version": "2.56.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 CHANGED Viewed

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.54.0",
+  "version": "2.56.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 CHANGED Viewed

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.54.0",
+  "version": "2.56.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 CHANGED Viewed

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.54.0",
+  "version": "2.56.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 CHANGED Viewed

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.54.0",
+  "version": "2.56.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 CHANGED Viewed

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.54.0",
+  "version": "2.56.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 CHANGED Viewed

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.54.0",
+  "version": "2.56.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/verify-prd.md CHANGED Viewed

@@ -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 (sibling tickets) runs spec-conformance + empirical verification and transitions the PRD shipped → verified | blocked."
+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)."
 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
+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

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

@@ -44,7 +44,11 @@ Never propose ideas before you understand what exists. Inspect the host project
 - **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.
+Use Lisa's existing methodology rather than inventing a parallel flow. Route each evidence source through the matching established practice before any idea is promoted to **Practical Ideas**:
+- **Host-code inspection** uses `/lisa:codebase-research` concepts: trace data flow from entry point to output, identify modification points, map dependencies, and find reusable code or patterns.
+- **Public, no-login comparison** uses web/browser research when those tools are available: inspect the public surface, preserve source URLs, and separate observed behavior from inference.
+- **UI-facing recommendations** use `/lisa:product-walkthrough` methodology first: inspect the current product surface, note existing-component reuse candidates, capture coverage smells or behavioral surprises, and only then list a UI idea as build-ready.
 ## Step 2 — Optional external / public-source inspection

package/plugins/src/base/skills/project-ideation/agents/openai.yaml ADDED Viewed

@@ -0,0 +1,6 @@
+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 feature ideas for this project.'
+  - 'Use $project-ideation: Looking at an external public product, what should we add here?'
+  - 'Use $project-ideation: Suggest practical improvements we can verify ourselves.'

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

@@ -1,6 +1,6 @@
 ---
 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."
+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 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. When the guard passes, it runs the PASS path: spec-conformance against the original PRD requirements (via the spec-conformance skill) plus empirical verification appropriate to the shipped surface (via verification-lifecycle), and on a CONFORMS verdict with all empirical checks passing transitions the PRD shipped → verified and posts verification evidence. 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"]
 ---
@@ -18,19 +18,21 @@ Do **not** re-prompt once invoked. Like the `*-prd-intake` skills, the caller ha
 ## Scope of this skill
-This skill is the **read/guard front-half** of PRD-level verification:
+This skill covers the **read/guard front-half** plus the **PASS path** 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.
+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 verification, do not transition the PRD.
+4. **Spec conformance** — when the guard passes, invoke the `spec-conformance` skill with the PRD as the spec source to build a section-by-section coverage matrix against the shipped product (never reimplementing the matrix).
+5. **Empirical verification** — invoke `verification-lifecycle` to run empirical checks appropriate to the PRD's surface (browser/computer-use, API, CLI, DB, screenshots, logs), honoring the `verification` rule. Quality gates (test/typecheck/lint) are **not** verification.
+6. **PASS transition + evidence** — when spec conformance is `CONFORMS` **and** every applicable empirical check passes, transition the PRD lifecycle from the resolved `shipped` role to the resolved `verified` role (vendor-neutral via `config-resolution`) and post verification evidence (the coverage matrix + empirical proof artifacts) back on 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):
+The remaining phases of PRD-level verification are **out of scope** here and are delivered by sibling work:
-- **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.
+- **FAIL path** — on verification failure (spec conformance not `CONFORMS`, or any empirical check failing), 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`.
+This skill implements only the **PASS** branch of Phase 6. When verification does not pass it stops at the verdict and **leaves the PRD at `shipped`** (it does not transition to `blocked`, does not open fix issues) — that is the FAIL sibling's job. Re-running before the idempotency sibling lands may re-post evidence or re-apply the (idempotent-by-label) transition; full no-duplicate guarantees are the idempotency sibling's job.
 ## Phase 1 — Resolve the PRD ref and detect the source vendor
@@ -84,7 +86,122 @@ The **required** set is the top-level children minus the terminal-but-dropped on
 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.
+**All required top-level children are terminal** (at least one required child exists): the guard passes. Proceed to **Phase 4 — Spec conformance** and the rest of the PASS path below. The guard is the precondition for verification; only once the work graph is complete is it meaningful to check the shipped product against the PRD.
+## Phase 4 — Spec conformance against the PRD
+The guard proves the work graph is *complete*; spec conformance proves the shipped product matches *what the PRD asked for*, section by section. This is the "accountant lens" — did the initiative ship exactly the PRD's requirements, nothing silently dropped, nothing scope-crept?
+**Do NOT reimplement the coverage matrix.** Invoke the existing `spec-conformance` skill with the PRD as the spec source:
+```text
+/spec-conformance <PRD ref/URL>
+```
+Pass the same `$ARGUMENTS` PRD reference resolved in Phase 1. `spec-conformance` Phase 1 already accepts a GitHub issue URL / Linear identifier / JIRA key / Notion / Confluence PRD as its spec source and loads the full PRD body (via `tracker-read` or the vendor surface), so the PRD is the spec here — not a plan file or a leaf ticket. It then:
+- extracts every PRD requirement into a structured list (acceptance criteria, Out of Scope, technical commitments, Validation Journey assertions, deliverables);
+- inspects the shipped product (the merged work across the generated top-level children) for evidence of each;
+- builds a **section-by-section coverage matrix** mapping each requirement to evidence;
+- flags scope creep (Out-of-Scope violations) and untraceable changes separately from misses;
+- returns a verdict: **`CONFORMS`**, **`PARTIAL`**, or **`DIVERGES`**.
+Capture the coverage matrix and verdict verbatim — both feed the evidence comment in Phase 6 and gate the PASS branch.
+Spec conformance at the PRD level differs from the leaf-ticket conformance run during a single item's Build/Fix/Improve flow: the spec is the **PRD itself** (the whole initiative's requirements), and the shipped work is the **union** of all generated top-level children, not one branch's diff. The `spec-conformance` skill handles both because its spec source is parameterized; this skill simply hands it the PRD.
+**Branch on the verdict:**
+- **`CONFORMS`** — continue to Phase 5 (empirical verification).
+- **`PARTIAL` or `DIVERGES`** — verification has **not** passed. Stop the PASS path: record the verdict and the matrix in the output, **leave the PRD at `shipped`**, and do not transition or post a verified-evidence comment. Handing the `shipped → blocked` transition, the product-readable failure report, and the linked fix issues to the FAIL sibling is out of scope here (see [Scope of this skill](#scope-of-this-skill)).
+## Phase 5 — Empirical verification of the shipped surface
+Spec conformance reads the diff and the requirements; empirical verification **runs the actual shipped system and observes results**. Quality gates (tests, typecheck, lint) are prerequisites, **not** verification — a green test suite never substitutes for exercising the shipped product (see the `verification` rule).
+**The verification surface is PRD-dependent.** A PRD that shipped a UI flow is verified through the browser; one that shipped an API through request/response captures; a CLI through command runs; a schema change through database queries; a background job through logs and queue inspection. Do not assume a fixed surface — classify it from what the PRD actually delivered.
+**Do NOT reinvent the verification machinery.** Invoke the `verification-lifecycle` skill and follow its mandatory sequence (confirm quality gates → classify empirical types → check tooling → fail-fast → plan → execute → codify → loop) against the *shipped initiative*:
+```text
+/verification-lifecycle
+```
+1. **Classify** the empirical verification types that apply to the PRD's shipped surface, per the Verification Types table in the `verification` rule.
+2. **Discover tooling** for each type (browser/computer-use MCP, HTTP client, DB client, CLI, log/metrics access) via the lifecycle's Tool Discovery Process. For a UI surface, reuse the `product-walkthrough` skill to drive the live product through a real browser and ground verification (and the eventual evidence comment) in what actually renders.
+3. **Plan** each check: the exact tool/command, the expected pass outcome, and any prerequisites (running service, seeded data, auth). A plan that lists only `test`/`typecheck`/`lint` is not a verification plan.
+4. **Execute** each check and collect **proof artifacts** (screenshots, request/response captures, query outputs, log excerpts with correlation IDs) per the lifecycle's Proof Artifacts Requirements.
+5. **Codify** — for each passing empirical verification, the lifecycle invokes `codify-verification` to encode it as a regression test (Playwright for UI, integration test for API/DB, benchmark for performance) so the PRD's behavior cannot silently regress. Honor that step; it is mandatory for every empirical type except the inherently non-behavioral set the lifecycle exempts.
+If a required surface or its tooling is unavailable, follow the lifecycle's Escalation Protocol — declare the verification level (PARTIALLY VERIFIED / UNVERIFIED) and surface the gap rather than declaring a false PASS.
+**Branch on the result:**
+- **Every applicable empirical check passes** (and is codified where the lifecycle requires) — continue to Phase 6.
+- **Any applicable empirical check fails, or a required surface is unavailable** — verification has **not** passed. Stop the PASS path: record what failed/was-blocked in the output, **leave the PRD at `shipped`**, and do not transition or post verified evidence. The `shipped → blocked` hop + fix issues are the FAIL sibling's job (out of scope here).
+> **Single-environment note.** In a single-environment project (`main`/production only, no dev/staging), the shipped surface is whatever production exposes. A project with no deployed application, sign-in, or end-to-end environment variables (Lisa itself) verifies on its CLI/dry-run surface — running the documentation/skill build and drift check — which is the empirical surface the PRD's Validation Journey declares. The surface is always PRD-dependent: read the PRD's Empirical Verification Plan and verify what it says ships.
+## Phase 6 — PASS: transition `shipped → verified` and post evidence
+Reach this phase **only** when **both** are true:
+- Phase 4 spec conformance returned **`CONFORMS`**, and
+- Phase 5 every applicable empirical check **passed** (and was codified where required).
+If either is false, do not enter this phase — stop at the verdict and leave the PRD at `shipped` (the FAIL sibling owns the `blocked` path).
+### 6.1 — Resolve the `verified` and `shipped` roles
+Resolve the PRD-lifecycle roles from `.lisa.config.json` (then `.lisa.config.local.json` override) per the `config-resolution` rule — the same role-resolution the `*-prd-intake` skills use. **Cite `config-resolution` for the role vocabulary; do not hardcode label strings except as the documented defaults.** Resolution per vendor:
+| Vendor | `shipped` role | `verified` role | Default `verified` |
+|---|---|---|---|
+| **GitHub** | `github.labels.prd.shipped` | `github.labels.prd.verified` | `prd-verified` (label) |
+| **Linear** | `linear.labels.prd.shipped` | `linear.labels.prd.verified` | `prd-verified` (project/issue label) |
+| **Notion** | `notion.values.shipped` | `notion.values.verified` | `Verified` (status value) |
+| **Confluence** | `confluence.parents.shipped` | `confluence.parents.verified` | the `Verified` parent page id |
+| **JIRA** | the configured shipped status | the configured verified status | per `config-resolution` |
+For GitHub, resolve with the same helper `github-prd-intake` uses:
+```bash
+read_role() {  # role default → resolved value (local override wins)
+  local role="$1" default="$2" local_v global_v
+  local_v=$(jq -r ".github.labels.prd.${role} // empty" .lisa.config.local.json 2>/dev/null)
+  global_v=$(jq -r ".github.labels.prd.${role} // empty" .lisa.config.json 2>/dev/null)
+  echo "${local_v:-${global_v:-$default}}"
+}
+SHIPPED=$(read_role shipped  prd-shipped)
+VERIFIED=$(read_role verified prd-verified)
+```
+### 6.2 — Transition the PRD `shipped → verified`
+Apply the vendor-appropriate transition. This is the `shipped → verified` PASS hop the `prd-lifecycle-rollup` rule defines (cite it by slug; this skill is its PASS-path implementation, not a second source of truth):
+- **GitHub / Linear** — remove the `shipped` label and add the `verified` label. For GitHub:
+  ```bash
+  gh issue edit <prd-num> --repo <org>/<repo> --remove-label "$SHIPPED" --add-label "$VERIFIED"
+  ```
+  Verify exactly **one** PRD-lifecycle label remains afterward (the single-label invariant `github-prd-intake` enforces). For Linear, set the project/issue label equivalently.
+- **Notion** — set the PRD page's `notion.statusProperty` (default `Status`) to the resolved `verified` value (default `Verified`).
+- **Confluence** — move the PRD page's `parentId` to `confluence.parents.verified` (the parent-page-based lifecycle; Atlassian scoped tokens cannot write labels — see `config-resolution`).
+- **JIRA** — transition the PRD issue to the configured `verified` status.
+`verified` is the terminal, product-owned PRD state; this skill is the **only** automated writer of it (intake/rollup never set it). Do **not** close or archive the PRD here — closure is governed separately by `prd.rollup.closeOnShipped` at the `shipped` hop, not the verify hop.
+### 6.3 — Post verification evidence on the PRD
+Post a verification-evidence comment back on the PRD, in the spirit of `tracker-evidence` (the vendor-neutral evidence poster). Because the evidence lands on the **PRD source** — which may be Notion or Confluence, not a tracker ticket — post via the vendor surface that owns the PRD: `gh issue comment` for GitHub, the Linear comment API, the Notion/Confluence page comment surface, or a JIRA comment. Where the PRD lives in the configured `tracker`, you may dispatch through `tracker-evidence`; for Notion/Confluence/cross-vendor PRDs, comment on the PRD page directly. The evidence comment MUST include:
+1. **AI disclosure** — lead with "PRD-level verification by Claude (AI agent, not a human)."
+2. **Verdict line** — `shipped → verified — PASS`.
+3. **Spec-conformance coverage matrix** — the section-by-section matrix from Phase 4 verbatim, with the `CONFORMS` verdict.
+4. **Empirical proof artifacts** — the Phase 5 artifacts per surface: screenshots (upload via `gh release upload pr-assets <files> --clobber` and reference as plain URLs, per the `tracker-evidence` UI Evidence Checklist), request/response captures, query outputs, log excerpts, and the codified regression test(s) added.
+5. **What was verified** — which PRD acceptance criteria each artifact covers, and the verification surface used.
+Then emit the PASS output block (below).
 ## Output
@@ -94,7 +211,7 @@ Emit a single fenced text block so callers can parse it.
 ## verify-prd: <PRD title>
 PRD: <ref/URL>  (vendor: <github|linear|notion|confluence|jira>)
-PRD lifecycle state: shipped
+PRD lifecycle state: <shipped | verified>
 Generated top-level children read: <n>  (source: native | documented | both)
 ### Terminal-child guard
@@ -103,22 +220,48 @@ Generated top-level children read: <n>  (source: native | documented | both)
 Required top-level children: <n>   Terminal: <n>   Incomplete: <n>
-### Verdict: GUARD_PASSED | GUARD_BLOCKED | NO_CHILDREN
+### Spec conformance      (only when guard passed)
+Verdict: <CONFORMS | PARTIAL | DIVERGES>
+<coverage matrix summary: requirements covered / missed / scope-crept>
+### Empirical verification  (only when conformance CONFORMS)
+Surface: <browser | api | cli | db | logs | ...>  (PRD-dependent)
+<each check — tool/command → PASS/FAIL → artifact ref; codified test(s)>
+### Lifecycle transition   (only on PASS)
+shipped → verified   (role: <resolved verified role>)   evidence posted: <link>
+### Verdict: VERIFIED_PASS | CONFORMANCE_FAILED | EMPIRICAL_FAILED | 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.
+- `CONFORMANCE_FAILED` — guard passed but spec conformance returned `PARTIAL`/`DIVERGES`; empirical verification did not run; the PRD was left at `shipped` (the `shipped → blocked` transition + fix issues are the FAIL sibling's job).
+- `EMPIRICAL_FAILED` — guard passed and conformance `CONFORMS`, but an applicable empirical check failed or a required surface was unavailable; the PRD was left at `shipped` (FAIL sibling owns the `blocked` path).
+- `VERIFIED_PASS` — guard passed, conformance `CONFORMS`, every applicable empirical check passed and was codified; the PRD was transitioned `shipped → verified` and verification evidence was posted.
 ## 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).
+- **The only lifecycle write is the PASS hop `shipped → verified`.** The front-half (resolve → read child set → guard) is read-only and never transitions the PRD. The only write this skill performs is the Phase 6 PASS hop — and **only** when spec conformance is `CONFORMS` and every applicable empirical check passes. The guard-blocked, no-children, conformance-failed, and empirical-failed paths all leave the PRD at `shipped` untouched. The `shipped → blocked` FAIL hop, fix issues, and re-run idempotency are sibling work (out of scope).
 - **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.
+- **Never reimplement spec conformance or verification.** Phase 4 invokes the `spec-conformance` skill (the single source of truth for the coverage matrix and the `CONFORMS`/`PARTIAL`/`DIVERGES` verdict); Phase 5 invokes `verification-lifecycle` (which in turn invokes `codify-verification` and, for UI, `product-walkthrough`). This skill orchestrates those skills against the PRD; it does not duplicate their logic.
+- **Quality gates are not verification.** Tests, typecheck, and lint are prerequisites enforced by hooks/CI. Phase 5 requires running the actual shipped system and observing results on a surface chosen from what the PRD delivered — never substituting a green test suite for empirical proof (`verification` rule).
+- **The verification surface is PRD-dependent.** Classify the empirical surface (browser/API/CLI/DB/logs/…) from what the PRD shipped; do not assume a fixed surface. A single-environment project with no deployed app verifies on its CLI/dry-run surface per the PRD's Empirical Verification Plan.
+- **`verified` is product-owned and terminal.** This skill is the only automated writer of the `verified` role; intake/rollup never set it. The PASS hop does not close or archive the PRD (closure is governed by `prd.rollup.closeOnShipped` at the `shipped` hop).
 - **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.
+- **Cite, don't restate.** The generated-top-level-work boundary, the per-vendor terminal predicate, the env-keyed `done` resolution, the dedupe-by-child-ref idempotency key, and the `shipped → verified` PASS hop all come from the `prd-lifecycle-rollup` rule; the `verified`/`shipped` role vocabulary comes from `config-resolution`. This skill is a consumer of those contracts, not a second source of truth.
+## Related skills
+- `spec-conformance` — Phase 4 invokes it with the PRD as the spec source; it owns the section-by-section coverage matrix and the `CONFORMS`/`PARTIAL`/`DIVERGES` verdict. This skill never reimplements that matrix.
+- `verification-lifecycle` — Phase 5 invokes it to run empirical verification of the shipped surface (classify → check tooling → plan → execute → codify → loop). It in turn invokes `codify-verification` and, for UI surfaces, `product-walkthrough`.
+- `codify-verification` — turns each passing empirical verification into a regression test so the PRD's verified behavior cannot silently regress; invoked transitively via `verification-lifecycle`.
+- `product-walkthrough` — drives the live product through a real browser to ground UI-surface verification and the evidence comment in what actually renders.
+- `tracker-evidence` — the vendor-neutral evidence poster whose UI Evidence Checklist and `pr-assets` upload mechanics Phase 6.3 follows when posting the verification evidence comment on the PRD.
 ## 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.
+- `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 — including the `shipped → verified` PASS hop it implements — citing the rule by slug rather than restating its taxonomy.
+- `verification` — defines what counts as empirical verification (the Verification Types table) and that quality gates (test/typecheck/lint) are prerequisites, not verification. Phase 5 honors it when classifying and running the surface-appropriate checks.
 - `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.
+- `config-resolution` — the PRD-lifecycle role vocabulary (`shipped`, `verified`, `blocked`), the per-vendor `verified` role maps (`prd-verified` label for GitHub/Linear, `Verified` status for Notion, `confluence.parents.verified` parent page) Phase 6.1 resolves, and the env-keyed `done` map the terminal predicate resolves against.