@codyswann/lisa 2.100.2 → 2.101.1

package/package.json

@@ -82,7 +82,7 @@
     "lodash": ">=4.18.1"
   },
   "name": "@codyswann/lisa",
-  "version": "2.100.2",
+  "version": "2.101.1",
   "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.100.2",
+  "version": "2.101.1",
   "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.100.2",
+  "version": "2.101.1",
   "description": "Universal governance: agents, skills, commands, hooks, and rules for all projects.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa/scripts/doctor-report.mjs

@@ -39,7 +39,7 @@ export const DOCTOR_VERDICTS = ["READY", "READY_WITH_WARNINGS", "NOT_READY"];
  * @returns {DoctorVerdict}
  */
 export function computeDoctorVerdict(groups) {
-  const checks = groups.flatMap(group => group.checks);
+  const checks = groups.flatMap(group => group.checks.map(normalizeCheck));
   if (checks.some(check => check.status === "FAIL")) {
     return "NOT_READY";
   }
@@ -55,7 +55,7 @@ export function computeDoctorVerdict(groups) {
  */
 export function countDoctorStatuses(groups) {
   return groups
-    .flatMap(group => group.checks)
+    .flatMap(group => group.checks.map(normalizeCheck))
     .reduce(
       (counts, check) => ({
         ...counts,
@@ -111,9 +111,20 @@ export function renderDoctorReport(input) {
  * @returns {DoctorGroup}
  */
 function normalizeGroup(group) {
+  const checks =
+    group.checks.length === 0
+      ? [
+          {
+            id: "empty-group",
+            status: "SKIP",
+            summary: "no checks registered yet",
+          },
+        ]
+      : group.checks.map(normalizeCheck);
+
   return {
     ...group,
-    checks: group.checks.map(normalizeCheck),
+    checks,
   };
 }
 

package/plugins/lisa/scripts/queue-status-build-readers.mjs

@@ -19,6 +19,7 @@ export const BUILD_LIFECYCLE_ORDER = [
 ];
 
 const ACTIONABLE_ROLE_ORDER = ["blocked", "ready", "claimed", "review"];
+const RAW_BUILD_READER_TRACKERS = new Set(["github"]);
 
 const HIGHLIGHT_COPY = {
   blocked: {
@@ -89,6 +90,8 @@ export function readGithubBuildQueueSnapshot(input = {}) {
  * }} input
  */
 export function createBuildQueueSnapshot(input = {}) {
+  const tracker = normalizeTracker(input.tracker);
+  const unsupportedReaderError = resolveUnsupportedReaderError(input, tracker);
   const roles = normalizeRoles(input.roles);
   const items = normalizeItems(input.items);
   const counts = buildLifecycleCounts(items);
@@ -99,9 +102,14 @@ export function createBuildQueueSnapshot(input = {}) {
     input.queueArgument
   );
   const queueResolved =
-    input.queueResolved ?? typeof input.resolutionError !== "string";
+    input.queueResolved ??
+    (unsupportedReaderError
+      ? false
+      : typeof input.resolutionError !== "string");
   const namespaceAdopted =
     input.namespaceAdopted ?? inferNamespaceAdopted(items, roles);
+  const resolutionError =
+    unsupportedReaderError ?? input.resolutionError ?? null;
 
   const health = classifyQueueHealth({
     queueResolved,
@@ -110,11 +118,11 @@ export function createBuildQueueSnapshot(input = {}) {
     activeCount: counts.claimed + counts.review,
     blockedCount: counts.blocked,
     stalledCount: repairSignals.stalled.length,
-    resolutionError: input.resolutionError ?? null,
+    resolutionError,
   });
 
   return {
-    tracker: input.tracker ?? "unknown",
+    tracker,
     queueResolved,
     namespaceAdopted,
     roles,
@@ -122,7 +130,7 @@ export function createBuildQueueSnapshot(input = {}) {
     highlights,
     repairSignals,
     health,
-    resolutionError: input.resolutionError ?? null,
+    resolutionError,
   };
 }
 
@@ -218,6 +226,33 @@ function normalizeRoles(roles) {
   };
 }
 
+/**
+ * @param {string | undefined} tracker
+ * @returns {string}
+ */
+function normalizeTracker(tracker) {
+  return typeof tracker === "string" && tracker.trim().length > 0
+    ? tracker.trim().toLowerCase()
+    : "unknown";
+}
+
+/**
+ * @param {Record<string, any>} input
+ * @param {string} tracker
+ * @returns {string | null}
+ */
+function resolveUnsupportedReaderError(input, tracker) {
+  if (
+    tracker === "unknown" ||
+    RAW_BUILD_READER_TRACKERS.has(tracker) ||
+    Object.hasOwn(input, "items")
+  ) {
+    return null;
+  }
+
+  return `vendor reader not implemented for build tracker '${tracker}'`;
+}
+
 /**
  * @param {Record<string, any> | undefined} done
  * @returns {Record<string, string>}

package/plugins/lisa/scripts/queue-status-prd-readers.mjs

@@ -27,6 +27,7 @@ const ACTIONABLE_ROLE_ORDER = [
   "ready",
   "ticketed",
 ];
+const RAW_PRD_READER_SOURCES = new Set(["github"]);
 
 const HIGHLIGHT_COPY = {
   blocked: {
@@ -96,15 +97,22 @@ export function readGithubPrdQueueSnapshot(input = {}) {
  * }} input
  */
 export function createPrdQueueSnapshot(input = {}) {
+  const source = normalizeSource(input.source);
+  const unsupportedReaderError = resolveUnsupportedReaderError(input, source);
   const rawRoles = input.roles ?? {};
   const roles = normalizeRoles(rawRoles);
   const items = normalizeItems(input.items);
   const counts = buildLifecycleCounts(items);
   const highlights = buildActionableHighlights(items, input.queueArgument);
   const queueResolved =
-    input.queueResolved ?? typeof input.resolutionError !== "string";
+    input.queueResolved ??
+    (unsupportedReaderError
+      ? false
+      : typeof input.resolutionError !== "string");
   const namespaceAdopted =
     input.namespaceAdopted ?? inferNamespaceAdopted(items, rawRoles);
+  const resolutionError =
+    unsupportedReaderError ?? input.resolutionError ?? null;
 
   const health = classifyQueueHealth({
     queueResolved,
@@ -113,18 +121,18 @@ export function createPrdQueueSnapshot(input = {}) {
     activeCount: counts.in_review + counts.ticketed,
     blockedCount: counts.blocked,
     stalledCount: counts.shipped,
-    resolutionError: input.resolutionError ?? null,
+    resolutionError,
   });
 
   return {
-    source: input.source ?? "unknown",
+    source,
     queueResolved,
     namespaceAdopted,
     roles,
     counts,
     highlights,
     health,
-    resolutionError: input.resolutionError ?? null,
+    resolutionError,
   };
 }
 
@@ -203,6 +211,33 @@ function normalizeRoles(roles) {
   return normalized;
 }
 
+/**
+ * @param {string | undefined} source
+ * @returns {string}
+ */
+function normalizeSource(source) {
+  return typeof source === "string" && source.trim().length > 0
+    ? source.trim().toLowerCase()
+    : "unknown";
+}
+
+/**
+ * @param {Record<string, any>} input
+ * @param {string} source
+ * @returns {string | null}
+ */
+function resolveUnsupportedReaderError(input, source) {
+  if (
+    source === "unknown" ||
+    RAW_PRD_READER_SOURCES.has(source) ||
+    Object.hasOwn(input, "items")
+  ) {
+    return null;
+  }
+
+  return `vendor reader not implemented for PRD source '${source}'`;
+}
+
 /**
  * @param {readonly Record<string, any>[] | undefined} items
  * @returns {readonly Record<string, any>[]}

package/plugins/lisa/skills/intake-explain/SKILL.md

@@ -143,6 +143,33 @@ The explanation must stay aligned with existing Lisa rules:
 - If a claimed, in-review, or blocked item is not yet repairable, explain the relevant staleness or backoff condition at a human-readable level.
 - If the source lane, tracker lane, repo/project scope, or lifecycle namespace is unresolved, report `MISCONFIGURED` instead of pretending the item is idle or actionable.
 
+## PRD item role and repair diagnosis
+
+For PRD lifecycle items, run the same read-side checks that PRD intake and repair-intake use before they would claim, validate, roll up, or retry a PRD. This is still a read-only explanation: if execution intake would transition `ready -> in_review`, route a `ticketed` PRD through rollup, move a `blocked` PRD after new answers, or suppress repair because a `[lisa-repair-intake]` marker is still inside its backoff window, intake-explain reports that decision and does not mutate the PRD, comments, labels, parent page, project labels, or generated work.
+
+Resolve the source lane from `.lisa.config.json` `source` and the PRD lifecycle roles from the same vendor-specific config keys PRD intake and repair-intake use (`github.labels.prd.*`, `linear.labels.prd.*`, `notion.values.*`, or `confluence.parents.*`) with the usual defaults (`draft`, `ready`, `in_review`, `blocked`, `ticketed`, `shipped`, and `verified` equivalents). If the current item carries conflicting PRD lifecycle roles, lacks an adopted PRD namespace, or cannot be tied to the configured source lane, return `MISCONFIGURED` rather than guessing.
+
+For GitHub-backed PRDs, collect these reader signals before choosing a verdict:
+
+- current PRD lifecycle role label and any conflicting `prd-*` labels
+- source-lane role ownership: `draft`, `shipped`, and `verified` are product-owned or verification-owned; `ready`, `in_review`, `blocked`, and `ticketed` are Lisa-owned for intake, repair, or rollup purposes
+- provider-native timestamps (`updatedAt`) plus latest PRD comments, with special attention to comments after the most recent blocked or in-review marker
+- `[lisa-repair-intake]` marker comments, including state fingerprint, repair verdict, retry count, and backoff window when present
+- generated top-level work from native sub-issues first, then the `## Tickets` / `## Generated Work` section used by `prd-lifecycle-rollup`
+- generated child terminal status so `ticketed` PRDs can explain whether rollup is waiting on downstream work or ready for `/lisa:repair-intake`
+- clarifying-answer signals on `blocked` PRDs: new product comments, changed body text, changed blocker refs, or cleared dependencies compared with the last blocked/repair fingerprint
+
+Apply PRD verdicts in the same order as PRD intake and repair-intake:
+
+1. **Product-owned or verification-owned roles.** A PRD in `draft` returns `PRODUCT_OWNED_STATE`; the next action is manual product clarification or promotion to the configured `ready` role. A PRD in `shipped` returns `PRODUCT_OWNED_STATE` with `/lisa:verify-prd <item-ref>` as the next Lisa workflow because shipped-to-verified acceptance is outside PRD intake. A PRD in `verified` returns `PRODUCT_OWNED_STATE` or a terminal no-op explanation; normal intake and repair must not mutate it.
+2. **Ready PRD.** A PRD in the configured `ready` role returns `ELIGIBLE_FOR_INTAKE` when the source lane and lifecycle namespace resolve cleanly. The `Why:` line should say PRD intake would claim it into the configured `in_review` role and run the source-to-tracker dry-run validate-to-route pipeline.
+3. **In-review PRD.** A PRD in `in_review` is already Lisa-owned. Compare the newest activity signal against the resolved repair `stale_after` threshold (`$ARGUMENTS` override if present, `.lisa.config.json` `intake.repair.staleAfterHours`, then the 24h default). If provider activity, a progress comment, or a source edit is newer than `now - stale_after`, return `WAITING_ON_STALENESS` and name the activity timestamp. If no reliable timestamp exists, return `WAITING_ON_STALENESS` unless the caller explicitly uses the repair flow with `stale_after=0`; intake-explain should not imply automatic recovery from unknown freshness. If the item is stale and no repair-backoff marker suppresses retry, return `ELIGIBLE_FOR_REPAIR`.
+4. **Blocked PRD.** A PRD in `blocked` is Lisa-owned but repairable only when the next validate-to-route pass can materially differ. Treat new human answers after the blocking comment, body edits after the blocking marker, cleared blockers, changed blocker refs, or changed validator fingerprint as repair-enabling signals. If none are present, return `HELD_BY_BLOCKERS` or `WAITING_ON_STALENESS` depending on whether the decisive fact is an active blocker/unchanged clarification need or a still-fresh blocked marker. If the blocker/answer state changed and repair backoff is clear, return `ELIGIBLE_FOR_REPAIR`.
+5. **Ticketed PRD.** A PRD in `ticketed` is not ready for first intake. Read generated top-level work using the same `prd-lifecycle-rollup` boundary as PRD intake: top-level Epics and top-level Stories count; nested Stories and Sub-tasks do not. If any generated top-level child is non-terminal, return `PRODUCT_OWNED_STATE` or a waiting explanation that downstream build work is still in progress. If all generated top-level work is terminal but the PRD has not rolled up to `shipped`, return `ELIGIBLE_FOR_REPAIR` and recommend `/lisa:repair-intake <queue>` to reconcile rollup drift.
+6. **Repair backoff suppression.** Before returning `ELIGIBLE_FOR_REPAIR` for `in_review`, `blocked`, or `ticketed` PRDs, inspect `[lisa-repair-intake]` markers. If the latest marker's state fingerprint matches the current reader signals and its backoff window has not expired, return `WAITING_ON_STALENESS` with a `Why:` line that says repair-intake would suppress an unchanged retry to avoid a loop. If the fingerprint changed, the backoff expired, or a human uses repair-intake `force=true`, the item may be repair-eligible.
+
+Relevant `Signals:` should include the decisive context, not every field: for example `prd-blocked; new product comment after blocker`, `prd-in-review; last activity 2h ago; stale_after=24h`, `prd-ticketed; generated top-level work #12/#13 terminal`, or `[lisa-repair-intake] fingerprint unchanged; backoff until 2026-05-27T12:00:00Z`.
+
 ## Build item gate diagnosis
 
 For build lifecycle items, run the same read-side checks that build intake runs before it would claim an issue. This is still a read-only explanation: if execution intake would stamp repo labels, split a cross-repo leaf, move a stale container from `ready` to `claimed`, or post a dependency-hold comment, intake-explain reports what intake would do but does not stamp, does not split, does not move labels, and does not comment.

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.100.2",
+  "version": "2.101.1",
   "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.100.2",
+  "version": "2.101.1",
   "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.100.2",
+  "version": "2.101.1",
   "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.100.2",
+  "version": "2.101.1",
   "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.100.2",
+  "version": "2.101.1",
   "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.100.2",
+  "version": "2.101.1",
   "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.100.2",
+  "version": "2.101.1",
   "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.100.2",
+  "version": "2.101.1",
   "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.100.2",
+  "version": "2.101.1",
   "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.100.2",
+  "version": "2.101.1",
   "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.100.2",
+  "version": "2.101.1",
   "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.100.2",
+  "version": "2.101.1",
   "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.100.2",
+  "version": "2.101.1",
   "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.100.2",
+  "version": "2.101.1",
   "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.100.2",
+  "version": "2.101.1",
   "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.100.2",
+  "version": "2.101.1",
   "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/scripts/doctor-report.mjs

@@ -39,7 +39,7 @@ export const DOCTOR_VERDICTS = ["READY", "READY_WITH_WARNINGS", "NOT_READY"];
  * @returns {DoctorVerdict}
  */
 export function computeDoctorVerdict(groups) {
-  const checks = groups.flatMap(group => group.checks);
+  const checks = groups.flatMap(group => group.checks.map(normalizeCheck));
   if (checks.some(check => check.status === "FAIL")) {
     return "NOT_READY";
   }
@@ -55,7 +55,7 @@ export function computeDoctorVerdict(groups) {
  */
 export function countDoctorStatuses(groups) {
   return groups
-    .flatMap(group => group.checks)
+    .flatMap(group => group.checks.map(normalizeCheck))
     .reduce(
       (counts, check) => ({
         ...counts,
@@ -111,9 +111,20 @@ export function renderDoctorReport(input) {
  * @returns {DoctorGroup}
  */
 function normalizeGroup(group) {
+  const checks =
+    group.checks.length === 0
+      ? [
+          {
+            id: "empty-group",
+            status: "SKIP",
+            summary: "no checks registered yet",
+          },
+        ]
+      : group.checks.map(normalizeCheck);
+
   return {
     ...group,
-    checks: group.checks.map(normalizeCheck),
+    checks,
   };
 }
 

package/plugins/src/base/scripts/queue-status-build-readers.mjs

@@ -19,6 +19,7 @@ export const BUILD_LIFECYCLE_ORDER = [
 ];
 
 const ACTIONABLE_ROLE_ORDER = ["blocked", "ready", "claimed", "review"];
+const RAW_BUILD_READER_TRACKERS = new Set(["github"]);
 
 const HIGHLIGHT_COPY = {
   blocked: {
@@ -89,6 +90,8 @@ export function readGithubBuildQueueSnapshot(input = {}) {
  * }} input
  */
 export function createBuildQueueSnapshot(input = {}) {
+  const tracker = normalizeTracker(input.tracker);
+  const unsupportedReaderError = resolveUnsupportedReaderError(input, tracker);
   const roles = normalizeRoles(input.roles);
   const items = normalizeItems(input.items);
   const counts = buildLifecycleCounts(items);
@@ -99,9 +102,14 @@ export function createBuildQueueSnapshot(input = {}) {
     input.queueArgument
   );
   const queueResolved =
-    input.queueResolved ?? typeof input.resolutionError !== "string";
+    input.queueResolved ??
+    (unsupportedReaderError
+      ? false
+      : typeof input.resolutionError !== "string");
   const namespaceAdopted =
     input.namespaceAdopted ?? inferNamespaceAdopted(items, roles);
+  const resolutionError =
+    unsupportedReaderError ?? input.resolutionError ?? null;
 
   const health = classifyQueueHealth({
     queueResolved,
@@ -110,11 +118,11 @@ export function createBuildQueueSnapshot(input = {}) {
     activeCount: counts.claimed + counts.review,
     blockedCount: counts.blocked,
     stalledCount: repairSignals.stalled.length,
-    resolutionError: input.resolutionError ?? null,
+    resolutionError,
   });
 
   return {
-    tracker: input.tracker ?? "unknown",
+    tracker,
     queueResolved,
     namespaceAdopted,
     roles,
@@ -122,7 +130,7 @@ export function createBuildQueueSnapshot(input = {}) {
     highlights,
     repairSignals,
     health,
-    resolutionError: input.resolutionError ?? null,
+    resolutionError,
   };
 }
 
@@ -218,6 +226,33 @@ function normalizeRoles(roles) {
   };
 }
 
+/**
+ * @param {string | undefined} tracker
+ * @returns {string}
+ */
+function normalizeTracker(tracker) {
+  return typeof tracker === "string" && tracker.trim().length > 0
+    ? tracker.trim().toLowerCase()
+    : "unknown";
+}
+
+/**
+ * @param {Record<string, any>} input
+ * @param {string} tracker
+ * @returns {string | null}
+ */
+function resolveUnsupportedReaderError(input, tracker) {
+  if (
+    tracker === "unknown" ||
+    RAW_BUILD_READER_TRACKERS.has(tracker) ||
+    Object.hasOwn(input, "items")
+  ) {
+    return null;
+  }
+
+  return `vendor reader not implemented for build tracker '${tracker}'`;
+}
+
 /**
  * @param {Record<string, any> | undefined} done
  * @returns {Record<string, string>}

package/plugins/src/base/scripts/queue-status-prd-readers.mjs

@@ -27,6 +27,7 @@ const ACTIONABLE_ROLE_ORDER = [
   "ready",
   "ticketed",
 ];
+const RAW_PRD_READER_SOURCES = new Set(["github"]);
 
 const HIGHLIGHT_COPY = {
   blocked: {
@@ -96,15 +97,22 @@ export function readGithubPrdQueueSnapshot(input = {}) {
  * }} input
  */
 export function createPrdQueueSnapshot(input = {}) {
+  const source = normalizeSource(input.source);
+  const unsupportedReaderError = resolveUnsupportedReaderError(input, source);
   const rawRoles = input.roles ?? {};
   const roles = normalizeRoles(rawRoles);
   const items = normalizeItems(input.items);
   const counts = buildLifecycleCounts(items);
   const highlights = buildActionableHighlights(items, input.queueArgument);
   const queueResolved =
-    input.queueResolved ?? typeof input.resolutionError !== "string";
+    input.queueResolved ??
+    (unsupportedReaderError
+      ? false
+      : typeof input.resolutionError !== "string");
   const namespaceAdopted =
     input.namespaceAdopted ?? inferNamespaceAdopted(items, rawRoles);
+  const resolutionError =
+    unsupportedReaderError ?? input.resolutionError ?? null;
 
   const health = classifyQueueHealth({
     queueResolved,
@@ -113,18 +121,18 @@ export function createPrdQueueSnapshot(input = {}) {
     activeCount: counts.in_review + counts.ticketed,
     blockedCount: counts.blocked,
     stalledCount: counts.shipped,
-    resolutionError: input.resolutionError ?? null,
+    resolutionError,
   });
 
   return {
-    source: input.source ?? "unknown",
+    source,
     queueResolved,
     namespaceAdopted,
     roles,
     counts,
     highlights,
     health,
-    resolutionError: input.resolutionError ?? null,
+    resolutionError,
   };
 }
 
@@ -203,6 +211,33 @@ function normalizeRoles(roles) {
   return normalized;
 }
 
+/**
+ * @param {string | undefined} source
+ * @returns {string}
+ */
+function normalizeSource(source) {
+  return typeof source === "string" && source.trim().length > 0
+    ? source.trim().toLowerCase()
+    : "unknown";
+}
+
+/**
+ * @param {Record<string, any>} input
+ * @param {string} source
+ * @returns {string | null}
+ */
+function resolveUnsupportedReaderError(input, source) {
+  if (
+    source === "unknown" ||
+    RAW_PRD_READER_SOURCES.has(source) ||
+    Object.hasOwn(input, "items")
+  ) {
+    return null;
+  }
+
+  return `vendor reader not implemented for PRD source '${source}'`;
+}
+
 /**
  * @param {readonly Record<string, any>[] | undefined} items
  * @returns {readonly Record<string, any>[]}

package/plugins/src/base/skills/intake-explain/SKILL.md

@@ -143,6 +143,33 @@ The explanation must stay aligned with existing Lisa rules:
 - If a claimed, in-review, or blocked item is not yet repairable, explain the relevant staleness or backoff condition at a human-readable level.
 - If the source lane, tracker lane, repo/project scope, or lifecycle namespace is unresolved, report `MISCONFIGURED` instead of pretending the item is idle or actionable.
 
+## PRD item role and repair diagnosis
+
+For PRD lifecycle items, run the same read-side checks that PRD intake and repair-intake use before they would claim, validate, roll up, or retry a PRD. This is still a read-only explanation: if execution intake would transition `ready -> in_review`, route a `ticketed` PRD through rollup, move a `blocked` PRD after new answers, or suppress repair because a `[lisa-repair-intake]` marker is still inside its backoff window, intake-explain reports that decision and does not mutate the PRD, comments, labels, parent page, project labels, or generated work.
+
+Resolve the source lane from `.lisa.config.json` `source` and the PRD lifecycle roles from the same vendor-specific config keys PRD intake and repair-intake use (`github.labels.prd.*`, `linear.labels.prd.*`, `notion.values.*`, or `confluence.parents.*`) with the usual defaults (`draft`, `ready`, `in_review`, `blocked`, `ticketed`, `shipped`, and `verified` equivalents). If the current item carries conflicting PRD lifecycle roles, lacks an adopted PRD namespace, or cannot be tied to the configured source lane, return `MISCONFIGURED` rather than guessing.
+
+For GitHub-backed PRDs, collect these reader signals before choosing a verdict:
+
+- current PRD lifecycle role label and any conflicting `prd-*` labels
+- source-lane role ownership: `draft`, `shipped`, and `verified` are product-owned or verification-owned; `ready`, `in_review`, `blocked`, and `ticketed` are Lisa-owned for intake, repair, or rollup purposes
+- provider-native timestamps (`updatedAt`) plus latest PRD comments, with special attention to comments after the most recent blocked or in-review marker
+- `[lisa-repair-intake]` marker comments, including state fingerprint, repair verdict, retry count, and backoff window when present
+- generated top-level work from native sub-issues first, then the `## Tickets` / `## Generated Work` section used by `prd-lifecycle-rollup`
+- generated child terminal status so `ticketed` PRDs can explain whether rollup is waiting on downstream work or ready for `/lisa:repair-intake`
+- clarifying-answer signals on `blocked` PRDs: new product comments, changed body text, changed blocker refs, or cleared dependencies compared with the last blocked/repair fingerprint
+
+Apply PRD verdicts in the same order as PRD intake and repair-intake:
+
+1. **Product-owned or verification-owned roles.** A PRD in `draft` returns `PRODUCT_OWNED_STATE`; the next action is manual product clarification or promotion to the configured `ready` role. A PRD in `shipped` returns `PRODUCT_OWNED_STATE` with `/lisa:verify-prd <item-ref>` as the next Lisa workflow because shipped-to-verified acceptance is outside PRD intake. A PRD in `verified` returns `PRODUCT_OWNED_STATE` or a terminal no-op explanation; normal intake and repair must not mutate it.
+2. **Ready PRD.** A PRD in the configured `ready` role returns `ELIGIBLE_FOR_INTAKE` when the source lane and lifecycle namespace resolve cleanly. The `Why:` line should say PRD intake would claim it into the configured `in_review` role and run the source-to-tracker dry-run validate-to-route pipeline.
+3. **In-review PRD.** A PRD in `in_review` is already Lisa-owned. Compare the newest activity signal against the resolved repair `stale_after` threshold (`$ARGUMENTS` override if present, `.lisa.config.json` `intake.repair.staleAfterHours`, then the 24h default). If provider activity, a progress comment, or a source edit is newer than `now - stale_after`, return `WAITING_ON_STALENESS` and name the activity timestamp. If no reliable timestamp exists, return `WAITING_ON_STALENESS` unless the caller explicitly uses the repair flow with `stale_after=0`; intake-explain should not imply automatic recovery from unknown freshness. If the item is stale and no repair-backoff marker suppresses retry, return `ELIGIBLE_FOR_REPAIR`.
+4. **Blocked PRD.** A PRD in `blocked` is Lisa-owned but repairable only when the next validate-to-route pass can materially differ. Treat new human answers after the blocking comment, body edits after the blocking marker, cleared blockers, changed blocker refs, or changed validator fingerprint as repair-enabling signals. If none are present, return `HELD_BY_BLOCKERS` or `WAITING_ON_STALENESS` depending on whether the decisive fact is an active blocker/unchanged clarification need or a still-fresh blocked marker. If the blocker/answer state changed and repair backoff is clear, return `ELIGIBLE_FOR_REPAIR`.
+5. **Ticketed PRD.** A PRD in `ticketed` is not ready for first intake. Read generated top-level work using the same `prd-lifecycle-rollup` boundary as PRD intake: top-level Epics and top-level Stories count; nested Stories and Sub-tasks do not. If any generated top-level child is non-terminal, return `PRODUCT_OWNED_STATE` or a waiting explanation that downstream build work is still in progress. If all generated top-level work is terminal but the PRD has not rolled up to `shipped`, return `ELIGIBLE_FOR_REPAIR` and recommend `/lisa:repair-intake <queue>` to reconcile rollup drift.
+6. **Repair backoff suppression.** Before returning `ELIGIBLE_FOR_REPAIR` for `in_review`, `blocked`, or `ticketed` PRDs, inspect `[lisa-repair-intake]` markers. If the latest marker's state fingerprint matches the current reader signals and its backoff window has not expired, return `WAITING_ON_STALENESS` with a `Why:` line that says repair-intake would suppress an unchanged retry to avoid a loop. If the fingerprint changed, the backoff expired, or a human uses repair-intake `force=true`, the item may be repair-eligible.
+
+Relevant `Signals:` should include the decisive context, not every field: for example `prd-blocked; new product comment after blocker`, `prd-in-review; last activity 2h ago; stale_after=24h`, `prd-ticketed; generated top-level work #12/#13 terminal`, or `[lisa-repair-intake] fingerprint unchanged; backoff until 2026-05-27T12:00:00Z`.
+
 ## Build item gate diagnosis
 
 For build lifecycle items, run the same read-side checks that build intake runs before it would claim an issue. This is still a read-only explanation: if execution intake would stamp repo labels, split a cross-repo leaf, move a stale container from `ready` to `claimed`, or post a dependency-hold comment, intake-explain reports what intake would do but does not stamp, does not split, does not move labels, and does not comment.