@codyswann/lisa 2.2.0 → 2.4.0

package/plugins/lisa/skills/prd-ticket-coverage/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: prd-ticket-coverage
-description: "Verifies that every requirement in a Notion PRD is covered by at least one created JIRA ticket — no silent drops. Parses the PRD into atomic items (goals, user stories, functional/non-functional requirements, acceptance criteria, important notes), maps each to the created tickets, and produces a coverage matrix and verdict (COMPLETE / COMPLETE_WITH_SCOPE_CREEP / GAPS_FOUND / NO_TICKETS_FOUND). Used by notion-prd-intake post-write to gate the Status=Ticketed transition; can also be invoked standalone for after-the-fact audits."
-allowed-tools: ["Skill", "mcp__claude_ai_Notion__notion-fetch", "mcp__claude_ai_Notion__notion-get-comments", "mcp__atlassian__getJiraIssue", "mcp__atlassian__searchJiraIssuesUsingJql", "mcp__atlassian__getAccessibleAtlassianResources"]
+description: "Verifies that every requirement in a PRD (Notion or Confluence) is covered by at least one created JIRA ticket — no silent drops. Parses the PRD into atomic items (goals, user stories, functional/non-functional requirements, acceptance criteria, important notes), maps each to the created tickets, and produces a coverage matrix and verdict (COMPLETE / COMPLETE_WITH_SCOPE_CREEP / GAPS_FOUND / NO_TICKETS_FOUND). Used by notion-prd-intake / confluence-prd-intake post-write to gate the Ticketed transition; can also be invoked standalone for after-the-fact audits."
+allowed-tools: ["Skill", "mcp__claude_ai_Notion__notion-fetch", "mcp__claude_ai_Notion__notion-get-comments", "mcp__atlassian__getConfluencePage", "mcp__atlassian__getConfluencePageDescendants", "mcp__atlassian__getConfluencePageFooterComments", "mcp__atlassian__getConfluencePageInlineComments", "mcp__atlassian__getConfluenceCommentChildren", "mcp__atlassian__getJiraIssue", "mcp__atlassian__searchJiraIssuesUsingJql", "mcp__atlassian__getAccessibleAtlassianResources"]
 ---
 
 # PRD Ticket Coverage Audit: $ARGUMENTS
@@ -9,9 +9,16 @@ allowed-tools: ["Skill", "mcp__claude_ai_Notion__notion-fetch", "mcp__claude_ai_
 `$ARGUMENTS` is one of:
 
 1. A PRD URL alone — auto-discover created tickets via the PRD's epic remote link.
-2. A PRD URL plus an explicit list of ticket keys — `<PRD URL> tickets=[KEY-1,KEY-2,...]`. Use this when called from `lisa:notion-prd-intake` (which knows the keys it just created).
+2. A PRD URL plus an explicit list of ticket keys — `<PRD URL> tickets=[KEY-1,KEY-2,...]`. Use this when called from `lisa:notion-prd-intake` or `lisa:confluence-prd-intake` (which know the keys they just created).
 
-Verify that every atomic item in the PRD is covered by at least one of the listed/discovered JIRA tickets. The output gates whether the PRD's `Status` should remain `Ticketed` or revert to `Blocked`.
+The PRD URL can be a **Notion page URL** or a **Confluence page URL**. Detect the vendor from the host:
+
+- `notion.so` / `notion.site` → Notion. Fetch with `mcp__claude_ai_Notion__notion-fetch` (`include_discussions: true`) and `mcp__claude_ai_Notion__notion-get-comments`.
+- Atlassian Confluence host (e.g. `*.atlassian.net/wiki/...`) → Confluence. Fetch with `mcp__atlassian__getConfluencePage`, `mcp__atlassian__getConfluencePageDescendants` (for child epic pages), `mcp__atlassian__getConfluencePageFooterComments`, `mcp__atlassian__getConfluencePageInlineComments`, and `mcp__atlassian__getConfluenceCommentChildren` for nested replies.
+
+Both vendors produce the same downstream artifact-extraction and coverage-matrix logic — only the fetch surface differs. The rest of this skill is vendor-agnostic.
+
+Verify that every atomic item in the PRD is covered by at least one of the listed/discovered JIRA tickets. The output gates whether the PRD's lifecycle should remain at `Ticketed` (Notion `Status = Ticketed`, Confluence `prd-ticketed` label) or revert to `Blocked`.
 
 ## Why this exists
 
@@ -22,12 +29,17 @@ Per-ticket gates (`lisa:jira-validate-ticket`) prove each created ticket is well
 ### Phase 1 — Resolve inputs
 
 1. Parse `$ARGUMENTS`:
-   - PRD URL → extract page ID.
+   - PRD URL → detect vendor from host, extract page ID.
    - Optional `tickets=[...]` → list of explicit ticket keys.
-2. Fetch the PRD via `notion-fetch` with `include_discussions: true`. Capture: title, body, child Epic pages, all comment threads.
-3. If the PRD has child Epic sub-pages (a multi-epic PRD like Home revamp), fetch each in parallel with `include_discussions: true`. The audit walks the full PRD tree.
+2. Fetch the PRD using the vendor-appropriate tool surface:
+   - **Notion**: `notion-fetch` with `include_discussions: true`. Capture: title, body, child Epic pages, all comment threads.
+   - **Confluence**: `getConfluencePage` (capture title, body, labels), `getConfluencePageFooterComments` + `getConfluencePageInlineComments` (capture all comments; walk replies via `getConfluenceCommentChildren` for any thread with children).
+3. If the PRD has child Epic sub-pages (a multi-epic PRD), fetch each in parallel:
+   - **Notion**: `notion-fetch` per child page with `include_discussions: true`.
+   - **Confluence**: enumerate descendants via `getConfluencePageDescendants`, then `getConfluencePage` per child plus its comment streams.
+   The audit walks the full PRD tree.
 4. If `tickets=[...]` not provided, locate the JIRA epic by:
-   - Looking for a JIRA URL in the PRD body, comments, or the PRD's most recent "Ticketed by Claude" comment posted by `lisa:notion-prd-intake`.
+   - Looking for a JIRA URL in the PRD body, comments, or the PRD's most recent "Ticketed by Claude" comment posted by `lisa:notion-prd-intake` / `lisa:confluence-prd-intake`.
    - Searching JIRA via `searchJiraIssuesUsingJql` for an epic whose summary or description references the PRD title or page ID.
    - If no epic found, return verdict `NO_TICKETS_FOUND` with a clear remediation — coverage cannot be assessed without the ticket set.
 5. Once the epic is known, fetch all child stories and sub-tasks via JQL: `"Epic Link" = <EPIC-KEY>` and recursively for sub-tasks.
@@ -115,9 +127,13 @@ Atomic PRD items extracted: <n>
 | ... | ... |
 
 ### Gaps  (PRD items with zero ticket coverage — blocks Ticketed status)
-- <item-id> (<type>) — <text>
-  - *Source:* <PRD section reference>
-  - *Suggested fix:* <add a ticket scoped to X / extend ticket Y to cover this / clarify whether this is in scope>
+- item: <item-id> (<type>)
+  text: <text>
+  prd_section: "<heading text from the PRD>"
+  prd_anchor: "<first ~10 chars>...<last ~10 chars>"   # for selection_with_ellipsis; null if no specific section
+  category: <product-clarity|acceptance-criteria|design-ux|scope|dependency|data|technical|structural>
+  what: <plain-language description of the gap, no JIRA jargon — written for the product team>
+  recommendation: <1–3 candidate resolutions: add a ticket scoped to X / extend ticket Y to cover this / mark out-of-scope explicitly. Never "clarify this".>
 
 ### Scope creep  (tickets without PRD trace — informational, does not block)
 - <ticket-key> — <summary>
@@ -128,6 +144,10 @@ Atomic PRD items extracted: <n>
 ### Scope-creep count: <n>
 ```
 
+`prd_anchor` and `prd_section` are built the same way as in `lisa:notion-to-jira` / `lisa:confluence-to-jira`. For Notion, `prd_anchor` is the `selection_with_ellipsis` start/end snippet; for Confluence, it's the inline-comment selection text accepted by `createConfluenceInlineComment`. The downstream caller knows which vendor it's writing to and uses the right API; this skill just emits the anchor that vendor expects. Set both to `null` only when the gap is not anchored to any specific section (rare).
+
+`category` is drawn from the same fixed taxonomy used by `lisa:jira-validate-ticket` so downstream callers can apply one consistent comment-formatting policy. Most coverage gaps map to `scope` (item not represented in any ticket) or `product-clarity` (item too vague to map). Use `acceptance-criteria` for missing pass/fail conditions and `design-ux` for missing visuals.
+
 ## Rules
 
 - Read-only — never write to JIRA, never write to Notion (callers do that based on the verdict).

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

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

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

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

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

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

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.2.0",
+  "version": "2.4.0",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting 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.2.0",
+  "version": "2.4.0",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -0,0 +1,63 @@
+---
+name: confluence-prd-intake
+description: PRD intake agent for Confluence-hosted PRDs. Runs one intake cycle against a Confluence space or parent page — claims `prd-ready` PRDs (relabels to `prd-in-review`), validates each through the dry-run pipeline, and routes to `prd-blocked` (with clarifying comments) or `prd-ticketed` (with JIRA tickets created). Confluence counterpart of `notion-prd-intake`. Designed to be invoked manually via /confluence-prd-intake or autonomously via a scheduled cron.
+skills:
+  - confluence-prd-intake
+  - confluence-to-jira
+  - jira-validate-ticket
+  - jira-source-artifacts
+  - product-walkthrough
+  - jira-write-ticket
+  - prd-ticket-coverage
+---
+
+# PRD Intake Agent (Confluence)
+
+You are a PRD intake agent. Your single job is to run one intake cycle against the Confluence scope (a space or a parent page) given to you, then report what happened.
+
+This agent is the Confluence counterpart of `notion-prd-intake`. The behavior is identical apart from the source-of-truth tool surface; if you have a Notion database, use the Notion agent instead.
+
+## Confirmation policy
+
+Once you have a space or parent-page URL, RUN. Do not ask the caller whether to proceed, do not preview projected scope, do not offer "proceed / skip / dry-run" choices. The caller has already authorized the run by invoking you; re-prompting defeats the purpose of a background batch. `prd-blocked` is a valid terminal state of the lifecycle, not a failure mode — large PRDs and PRDs full of open questions are exactly what this skill is for. The `confluence-prd-intake` skill defines the only legitimate early-exit conditions (missing scope, unreachable space/parent, empty Ready set); ask only when one of those applies.
+
+## Workflow
+
+### 1. Receive the scope URL or key
+
+The invoking caller (a slash command, a scheduled cron, or a parent agent) hands you a Confluence space URL/key or a parent page URL/ID. You do not pick the scope yourself.
+
+If no scope is provided, stop and ask. Never run intake against a default or guessed scope — the side effects (label changes, JIRA tickets created) are too high to act without an explicit target.
+
+### 2. Run the intake skill
+
+Invoke the `confluence-prd-intake` skill with the scope as `$ARGUMENTS`. The skill owns the cycle logic — claim, dry-run, branch, write or comment, label transitions, summary. Do not duplicate that logic here.
+
+Treat the skill's output as the source of truth. If it reports `prd-ticketed: 3 / prd-blocked: 1 / Errors: 0`, that's what you report.
+
+### 3. Surface the summary
+
+Pass the skill's summary block through to the caller verbatim — do not paraphrase or condense. The caller (often a human running `/confluence-prd-intake` ad-hoc, or a scheduled cron) needs the structured record:
+
+- Total processed
+- Per-PRD outcomes (`prd-ticketed` → which tickets created; `prd-blocked` → how many gate failures; Errors → reason)
+- JIRA ticket count
+
+If the cycle errored before processing any PRDs (e.g. space unreachable, missing config, label convention not yet adopted), surface the failure cause in plain language and stop.
+
+### 4. Suggest next actions when warranted
+
+After a successful cycle, if any PRDs ended in `prd-blocked`, mention to the caller that those PRDs need product attention before they can be re-ticketed. Do not auto-notify product — Confluence comments on the PRDs are the channel; the caller decides whether to ping anyone.
+
+When reporting `prd-blocked` outcomes, distinguish the cause: **pre-write gate failure** (per-ticket validator caught a problem before any tickets were created) vs **post-write coverage gap** (tickets were created and remain in JIRA, but the PRD has uncovered requirements that the next intake cycle will address). Both result in `prd-blocked`, but the implication for product is different — coverage gaps mean some tickets are already real and product should not re-author the PRD from scratch.
+
+If all PRDs ended in `prd-ticketed` with coverage `COMPLETE`, mention that the next step is for product to monitor the created tickets and apply the `prd-shipped` label after delivery. If any are `COMPLETE_WITH_SCOPE_CREEP`, point that out so product can review the flagged tickets.
+
+## Rules
+
+- **Never run a cycle without an explicit scope.** Side effects are too high to default.
+- **Never modify the lifecycle**: only `prd-ready → prd-in-review → prd-blocked|prd-ticketed`. Never touch `prd-draft` or `prd-shipped`. Never invent new labels.
+- **Never write JIRA tickets directly.** All writes go through the skill chain (intake → confluence-to-jira → jira-write-ticket).
+- **Never edit a PRD's body.** Communication with product happens only via Confluence comments on the PRD.
+- **Never start a second cycle while one is in flight against the same scope.** Serial execution; the scheduling layer is responsible for not double-firing.
+- **Stop and surface failures rather than retry-loop.** If `confluence-to-jira` returns an error, the skill records it under `Errors` in the summary; pass that through.

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

@@ -1,6 +1,6 @@
 ---
-description: "Vendor-agnostic batch scanner for Status=Ready queues. Notion PRD database URL → finds Ready PRDs and runs lisa:plan per item. JIRA project key or JQL → finds Ready tickets and runs lisa:implement per item. Designed as the cron target for /schedule."
-argument-hint: "<Notion-PRD-database-URL | JIRA-project-key | JQL-filter>"
+description: "Vendor-agnostic batch scanner for Ready queues. Notion PRD database URL → finds Status=Ready PRDs and runs lisa:plan per item. Confluence space or parent-page URL → finds prd-ready PRDs and runs lisa:plan per item. JIRA project key or JQL → finds Ready tickets and runs lisa:implement per item. Designed as the cron target for /schedule."
+argument-hint: "<Notion-PRD-database-URL | Confluence-space-URL | Confluence-parent-page-URL | JIRA-project-key | JQL-filter>"
 ---
 
-Use the /lisa:intake skill to scan the queue for Status=Ready items and dispatch each one through the appropriate single-item lifecycle skill. $ARGUMENTS
+Use the /lisa:intake skill to scan the queue for Ready items and dispatch each one through the appropriate single-item lifecycle skill. $ARGUMENTS

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

@@ -0,0 +1,259 @@
+---
+name: confluence-prd-intake
+description: "Scans a Confluence space (or a parent page) for PRD pages labelled `prd-ready` and runs each one through the dry-run validation pipeline. PRDs that pass every gate get tickets written and the label flipped to `prd-ticketed`; PRDs that fail get clarifying-question comments and the label flipped to `prd-blocked`. Confluence counterpart of `lisa:notion-prd-intake` — the workflow is identical; only the source-of-truth tools differ. Composes existing skills (confluence-to-jira, jira-validate-ticket, jira-source-artifacts, product-walkthrough)."
+allowed-tools: ["Skill", "Bash", "mcp__atlassian__getConfluencePage", "mcp__atlassian__getConfluenceSpaces", "mcp__atlassian__getPagesInConfluenceSpace", "mcp__atlassian__getConfluencePageDescendants", "mcp__atlassian__searchConfluenceUsingCql", "mcp__atlassian__updateConfluencePage", "mcp__atlassian__createConfluenceFooterComment", "mcp__atlassian__createConfluenceInlineComment", "mcp__atlassian__getConfluencePageFooterComments", "mcp__atlassian__getConfluencePageInlineComments", "mcp__atlassian__getAccessibleAtlassianResources"]
+---
+
+# Confluence PRD Intake: $ARGUMENTS
+
+`$ARGUMENTS` is one of:
+
+- A Confluence **space** URL or space key — scans every page in the space whose labels include `prd-ready`. Example: `https://mycompany.atlassian.net/wiki/spaces/PRD` or `PRD`.
+- A Confluence **parent page** URL or page ID — scans every descendant of the parent whose labels include `prd-ready`. Example: `https://mycompany.atlassian.net/wiki/spaces/PRD/pages/123456789/PRDs`.
+
+Run one intake cycle against that scope. Each PRD with the `prd-ready` label is claimed, validated, and routed to either `prd-blocked` (with clarifying comments) or `prd-ticketed` (with JIRA tickets created).
+
+This skill is the Confluence counterpart of `lisa:notion-prd-intake`. The phases, gates, comment templates, and rules are identical — the only differences are (1) the lifecycle is encoded as **page labels** instead of a Status property, and (2) the fetch / comment / update tools are Confluence MCP instead of Notion MCP. Keep the two skills behaviorally aligned: when changing intake logic, change BOTH skills together.
+
+## Confirmation policy
+
+Do NOT ask the caller whether to proceed. Once invoked with a space or parent-page URL, run the cycle to completion — claim, validate, branch to `prd-blocked` or `prd-ticketed`, write the summary. The caller (a human or a cron) has already authorized the run by invoking the skill; re-prompting defeats the purpose of a background batch.
+
+Specifically forbidden:
+
+- Previewing projected scope (epic count, story count, write count) and asking whether to continue.
+- Offering A/B/C-style choices like "proceed / skip / dry-run only" — the documented behavior IS the default.
+- Pausing because a PRD looks large, has many open questions, or is likely to end in `prd-blocked`. `prd-blocked` is a valid terminal state of this lifecycle, not a failure mode — routing a PRD to `prd-blocked` with gate-failure comments is exactly how this skill communicates "the PRD needs more work before it can be ticketed." That outcome is success.
+- Pausing because the dry-run validation looks expensive. The cost of one cycle is bounded; the cost of stalling a scheduled cron waiting on a human is unbounded.
+
+The only legitimate reasons to stop early:
+
+- Missing space/parent argument or required configuration (`JIRA_PROJECT`, `JIRA_SERVER`, `E2E_BASE_URL`, etc.). Surface the missing value and exit.
+- Space/parent unreachable, or the labelling convention not yet adopted (no PRDs carry any of `prd-ready` / `prd-in-review` / `prd-blocked` / `prd-ticketed`). Surface and exit.
+- Empty `prd-ready` set. Exit cleanly with `"No PRDs labelled prd-ready. Nothing to do."`
+
+## Lifecycle assumed
+
+The Confluence PRD lifecycle is encoded as **page labels** (Confluence has no native status field). Exactly one of these labels is expected on a PRD page at any time:
+
+```text
+prd-draft → prd-ready → prd-in-review → prd-blocked | prd-ticketed → prd-shipped
+            (product)    (us)            (us)                          (product)
+```
+
+This skill ONLY transitions:
+
+- `prd-ready` → `prd-in-review` (claim)
+- `prd-in-review` → `prd-blocked` (gate failures or coverage gaps)
+- `prd-in-review` → `prd-ticketed` (success)
+
+It never adds, removes, or touches `prd-draft` or `prd-shipped`. Those labels are owned by product.
+
+A "transition" means: remove the old lifecycle label and add the new one in a single `updateConfluencePage` call. The skill MUST verify that exactly one lifecycle label exists on the page after the update — having two simultaneously breaks idempotency.
+
+If the project does not yet use `prd-*` labels, this skill cannot run. Adopting the convention is a one-time setup the project owner does (see "Adoption" at the bottom of this file).
+
+## Phases
+
+### Phase 1 — Resolve the scope
+
+1. Parse `$ARGUMENTS`:
+   - Space URL → extract space key from `/wiki/spaces/<KEY>`.
+   - Bare space key → use as-is.
+   - Parent page URL → extract numeric page ID from `/pages/<ID>/...`.
+   - Bare page ID → use as-is.
+2. Resolve Atlassian cloud ID via `mcp__atlassian__getAccessibleAtlassianResources` (downstream tools need it).
+3. Verify the scope is reachable:
+   - For a space: call `mcp__atlassian__getConfluenceSpaces` and confirm the key resolves.
+   - For a parent page: call `mcp__atlassian__getConfluencePage` on the ID and confirm it loads.
+
+### Phase 2 — Find Ready PRDs
+
+Build a CQL query and call `mcp__atlassian__searchConfluenceUsingCql`:
+
+- For a space: `space = "<KEY>" AND label = "prd-ready" AND type = page`
+- For a parent: `ancestor = <PARENT-ID> AND label = "prd-ready" AND type = page`
+
+The query returns the list of candidate pages with IDs and titles. For each candidate, confirm the label set on the page (CQL hits should be authoritative, but a follow-up `getConfluencePage` with labels included guards against eventual-consistency lag) and ensure exactly one lifecycle label is present.
+
+If the result set is empty, run a secondary CQL to distinguish between a genuinely empty queue and a project that has not yet adopted the label convention:
+
+- Secondary query (space scope): `space = "<KEY>" AND (label = "prd-ready" OR label = "prd-in-review" OR label = "prd-blocked" OR label = "prd-ticketed") AND type = page`
+- Secondary query (parent scope): `ancestor = <PARENT-ID> AND (label = "prd-ready" OR label = "prd-in-review" OR label = "prd-blocked" OR label = "prd-ticketed") AND type = page`
+
+If the secondary query also returns nothing → the `prd-*` label convention has not been adopted. Surface a misconfiguration message: `"No pages in this scope carry prd-* labels. If this is a new project, apply the prd-ready label to PRDs that are ready for ticketing (see Adoption section)."` Exit with an error — this is a setup issue, not a normal idle cycle.
+
+If the secondary query returns results → the queue is genuinely empty (all PRDs are already in-review, blocked, ticketed, or shipped). Exit cleanly with `"No PRDs labelled prd-ready. Nothing to do."`
+
+### Phase 3 — Process each Ready PRD
+
+For each PRD page (process serially to keep label transitions auditable):
+
+#### 3a. Claim
+
+Transition labels via `mcp__atlassian__updateConfluencePage`: remove `prd-ready`, add `prd-in-review`. This is the idempotency lock — a re-entrant cycle running concurrently won't see this PRD because its CQL query filters on `label = "prd-ready"`.
+
+If the update fails (permission error, version conflict / 409 race), log it and skip this PRD. Do not proceed to validation on a PRD you didn't successfully claim.
+
+The `updateConfluencePage` call must preserve the page body; only the labels change. (If the MCP tool requires a full body in the update payload, fetch the current body via `getConfluencePage` immediately before the update and pass it back unchanged — preserving body content is non-negotiable, this skill never edits PRD content.)
+
+#### 3b. Dry-run validation
+
+Invoke the `lisa:confluence-to-jira` skill with `dry_run: true` and the PRD's URL. The skill returns a structured report containing:
+- The planned ticket hierarchy
+- Per-ticket validation verdicts and remediation
+- An overall PASS / FAIL verdict
+- A failure count
+
+This call also indirectly invokes `lisa:jira-source-artifacts` (artifact extraction + classification) and `lisa:product-walkthrough` (when the PRD touches existing user-facing surfaces). All gate logic lives in `lisa:jira-validate-ticket`, which `lisa:confluence-to-jira` calls per ticket.
+
+#### 3c. Branch on the verdict
+
+**If `PASS`** (every planned ticket passed every applicable gate):
+
+1. Re-invoke `lisa:confluence-to-jira` with `dry_run: false` to actually write the tickets. This re-runs Phases 1-5 and runs the preservation gate (Phase 5.5).
+2. Capture the created ticket keys from the skill's output.
+3. Post a Confluence **footer comment** on the PRD via `mcp__atlassian__createConfluenceFooterComment` listing the created tickets (epic, stories, sub-tasks) with their JIRA URLs. Lead with: `"Ticketed by Claude. Created N JIRA issues — see below. Add the prd-shipped label after the work is delivered."`
+4. Transition labels: remove `prd-in-review`, add `prd-ticketed` via `updateConfluencePage`.
+5. **Run Phase 3e (coverage audit)** before considering this PRD done.
+
+**If `FAIL`** (one or more planned tickets failed one or more gates):
+
+The audience for these comments is the **product team**, not engineers. They are not familiar with JIRA gate IDs, validator vocabulary, or skill internals. Follow the rules below strictly — the goal is for a non-engineer product owner to read a comment, understand what is unclear, and know what to do next.
+
+##### 3c.1 Partition failures
+
+1. Drop every failure where `product_relevant = false`. Those are internal data-quality problems — the agent should fix its own spec rather than ask product to clarify a missing core field. Record the dropped failures under `Errors` in the cycle summary so engineers can see them; never surface them on the PRD.
+2. Group the remaining product-relevant failures by `prd_anchor` (the inline-comment anchor from `confluence-to-jira`'s dry-run report). Failures that share an anchor become one comment thread on that block. Failures with `prd_anchor: null` are batched into one footer comment, since they have no source section to attach to.
+
+##### 3c.2 Render each comment
+
+For each anchored group, post via `mcp__atlassian__createConfluenceInlineComment` with:
+- `page_id`: the PRD page ID
+- `inline_text` (or whatever the MCP tool calls the selection-anchor parameter): the `prd_anchor` value
+- `body`: the comment body, formatted using the template below
+
+For the unanchored group, post a single footer comment via `mcp__atlassian__createConfluenceFooterComment` using the same template, prefixed with `Issues without a specific section anchor:` and one block per failure.
+
+If `createConfluenceInlineComment` returns "anchor not found" (the page text changed between fetch and post), fall back to a footer comment for that group. Do not silently drop the failure.
+
+##### 3c.3 Comment template
+
+Each comment body MUST contain these four parts, in this order, no exceptions:
+
+```text
+[<Category badge>] <prd_section heading text>
+
+**What's unclear:** <validator's `what` field, verbatim — already product-readable>
+
+**Recommendation:** <validator's `recommendation` field, verbatim — must contain 1–3 concrete options, never a generic "please clarify">
+
+**Action:** Update this section in the PRD, then replace the `prd-blocked` label with `prd-ready` and Claude will re-run intake.
+```
+
+If multiple failures share an anchor, render each as its own `**What's unclear:** ... **Recommendation:** ...` block within the same comment, separated by horizontal lines (`---`). Keep the single `[Category badge]` heading at the top using the most-severe / most-blocking category from the group.
+
+##### 3c.4 Category badges
+
+Use these exact badge labels — they are the validator's category values translated for product readers:
+
+| Validator category | Badge label |
+|---------------------|-------------|
+| `product-clarity` | `[Product clarity]` |
+| `acceptance-criteria` | `[Acceptance criteria]` |
+| `design-ux` | `[Design / UX]` |
+| `scope` | `[Scope]` |
+| `dependency` | `[Dependency]` |
+| `data` | `[Data]` |
+| `technical` | `[Technical]` |
+
+`structural` failures must never reach this step (filtered in 3c.1). If you see one here, treat it as an Error and surface internally.
+
+##### 3c.5 Forbidden in product comments
+
+- Gate IDs (`S4`, `F2`, etc.). Never appear in a comment body.
+- JIRA terminology that has no product meaning (e.g. "Gherkin", "epic parent", "issue link", "validation journey", "sub-task hierarchy"). Paraphrase before posting.
+- Internal skill names (`lisa:jira-validate-ticket`, `confluence-to-jira`).
+- Engineering shorthand (`AC`, `OOS`, `repo`, `env var`).
+- "Clarify this" / "Please specify" without candidate resolutions. The validator is required to provide candidates; if `recommendation` is empty or vague, treat the failure as an Error and surface internally rather than posting a useless comment.
+
+##### 3c.6 Label transition
+
+After all comments are posted (anchored groups + the optional footer summary), transition labels: remove `prd-in-review`, add `prd-blocked` via `updateConfluencePage`. Do NOT write any JIRA tickets.
+
+#### 3d. Continue
+
+Move to the next Ready PRD. One PRD failing does not affect others.
+
+#### 3e. Coverage audit (mandatory after prd-ticketed)
+
+Per-ticket gates prove each ticket is well-formed; they do NOT prove the *set* of created tickets covers the *whole* PRD. Silent drops happen — invoke the `lisa:prd-ticket-coverage` skill to catch them.
+
+1. Invoke `lisa:prd-ticket-coverage` with `<PRD URL> tickets=[<created ticket keys from 3c step 2>]`. The coverage skill auto-detects the PRD vendor from the URL.
+2. Read the verdict:
+
+   | Verdict | Action |
+   |---------|--------|
+   | `COMPLETE` | Done. Leave label as `prd-ticketed`. Move to next PRD. |
+   | `COMPLETE_WITH_SCOPE_CREEP` | Post an advisory footer comment naming the scope-creep tickets (so product can decide whether to close them as out-of-scope). Leave label as `prd-ticketed`. |
+   | `GAPS_FOUND` | The created ticket set is incomplete. (a) For each gap, post a comment using the same product-facing template as Phase 3c.3 — inline-anchored when `prd_anchor` is non-null, footer otherwise; category badge from the gap's `category` field; `What's unclear` and `Recommendation` from the audit report's `what` and `recommendation` fields. Apply the same forbidden-language rules from Phase 3c.5. (b) Post one footer summary comment listing the tickets that *were* successfully created (so product knows what to keep vs. what to extend). (c) Transition labels from `prd-ticketed` back to `prd-blocked` via `updateConfluencePage`. |
+   | `NO_TICKETS_FOUND` | Should not happen if step 2 succeeded. If it does, log it as an Error in the cycle summary and leave label as `prd-ticketed` with a comment flagging the audit failure for human review. |
+
+3. The created tickets remain in JIRA regardless of the verdict — they are valid in their own right. The audit only tells us whether *more* are needed.
+
+### Phase 4 — Summary report
+
+After processing every Ready PRD, emit a summary:
+
+```text
+## confluence-prd-intake summary
+
+Scope: <space-key | parent-page-title> (<URL>)
+Cycle started: <ISO timestamp>
+Cycle completed: <ISO timestamp>
+
+PRDs processed: <n>
+- prd-ticketed: <n>
+  - <PRD title> → <epic-key> + <story-count> stories + <subtask-count> sub-tasks (coverage: COMPLETE | COMPLETE_WITH_SCOPE_CREEP)
+- prd-blocked: <n>
+  - <PRD title> → <gate-failure-count> gate failures (pre-write) OR <gap-count> coverage gaps (post-write)
+- Errors (claim failed, etc): <n>
+  - <PRD title> — <reason>
+
+Total JIRA tickets created: <n>
+Coverage audit summary: <n> COMPLETE / <n> COMPLETE_WITH_SCOPE_CREEP / <n> GAPS_FOUND
+```
+
+Print to the agent's output. Do not write this summary to Confluence or JIRA — it's an operational record for the human.
+
+## Idempotency & safety
+
+- **Single-cycle scope**: this skill processes the `prd-ready` set as it exists at the start of Phase 2. New `prd-ready` PRDs added mid-cycle are picked up next run.
+- **No writes outside the lifecycle**: this skill only ever writes to JIRA via `lisa:confluence-to-jira` (which delegates to `lisa:jira-write-ticket`), and only ever changes Confluence labels among `prd-in-review`, `prd-blocked`, `prd-ticketed`. It never edits PRD body content, never touches `prd-draft` or `prd-shipped`, never deletes pages.
+- **Claim-first ordering**: the label flip to `prd-in-review` happens BEFORE validation runs, so a re-entrant call won't double-process.
+- **Failure isolation**: an exception processing one PRD must not stop the cycle. Catch, record under "Errors" in the summary, continue to the next PRD. The PRD that errored is left labelled `prd-in-review` — the human investigates from there.
+- **Single-label invariant**: after every transition, verify exactly one lifecycle label is present on the page. If two are present (rare race), surface as an Error and skip — do NOT auto-resolve, the human decides.
+
+## Configuration
+
+Same env vars as `lisa:confluence-to-jira` — `JIRA_PROJECT`, `JIRA_SERVER`, `CONFLUENCE_HOST`, `E2E_BASE_URL`, `E2E_TEST_PHONE`, `E2E_TEST_OTP`, `E2E_TEST_ORG`, `E2E_GRAPHQL_URL`. If any required value is missing, surface the missing key(s) and exit this cycle — never invent values.
+
+## Rules
+
+- Never write to JIRA outside of `lisa:confluence-to-jira` → `lisa:jira-write-ticket`. The validator's verdict gates progress; bypassing it produces broken tickets.
+- Never add or remove a label this skill doesn't own (`prd-in-review`, `prd-blocked`, `prd-ticketed`). Product owns `prd-draft`, `prd-ready`, `prd-shipped`.
+- Never edit the PRD's body. Communication with product happens only through Confluence comments. If `updateConfluencePage` requires a body in the payload, refetch and pass it back unchanged.
+- Never post a single page-level dump of all gate failures. One inline comment per `prd_anchor` group (or one footer summary for unanchored failures only). Comments must be inline-anchored where possible, categorized, plain-language, and contain a concrete recommendation.
+- Never include a gate ID, internal skill name, or engineering shorthand in a comment body.
+- Never run more than one intake cycle concurrently against the same scope. This skill assumes serial execution.
+- If `lisa:confluence-to-jira` returns errors, treat them as gate failures: comment + `prd-blocked`. Don't silently fail.
+
+## Adoption (one-time per project)
+
+Before this skill can run against a project, the project must adopt the `prd-*` label convention:
+
+1. Apply `prd-ready` to PRDs that are ready for ticketing (replaces the Notion `Status = Ready` flip).
+2. Reserve `prd-in-review`, `prd-blocked`, `prd-ticketed` for this skill — humans should not set them manually except to recover from an error.
+3. (Optional but recommended) Add `prd-draft` for in-progress PRDs and `prd-shipped` for delivered work, so the full lifecycle is visible at a glance.
+
+If the project hasn't adopted these labels, the first run exits with a label-convention error (not the idle empty-set message) — this distinguishes a setup issue from a genuinely empty queue so operators know to apply the convention rather than assuming the queue is drained. See Phase 2 for how the skill detects this case.