@codyswann/lisa 1.95.0 → 1.96.0

package/plugins/lisa-expo/skills/jira-create/SKILL.md

@@ -1,23 +1,27 @@
 ---
 name: jira-create
 description: This skill should be used when creating JIRA epics, stories, and tasks from code files or descriptions. It analyzes the provided input, determines the appropriate issue hierarchy, and creates issues with comprehensive quality requirements including test-first development and documentation.
-allowed-tools: ["Read", "Glob", "LS", "mcp__atlassian__createJiraIssue", "mcp__atlassian__getVisibleJiraProjects", "mcp__atlassian__getJiraProjectIssueTypesMetadata", "mcp__atlassian__getAccessibleAtlassianResources"]
+allowed-tools: ["Read", "Glob", "LS", "Skill", "mcp__atlassian__getVisibleJiraProjects", "mcp__atlassian__getJiraProjectIssueTypesMetadata", "mcp__atlassian__getAccessibleAtlassianResources"]
 ---
 
 # Create JIRA Issues from $ARGUMENTS
 
-Analyze the provided file(s) and create a comprehensive JIRA hierarchy with all mandatory quality gates.
+Analyze the provided file(s) and plan a JIRA hierarchy. **This skill plans structure only — every individual ticket write is delegated to `jira-write-ticket`.** Do not call `mcp__atlassian__createJiraIssue` from this skill; the necessary write tools are intentionally not in `allowed-tools`.
 
 ## Process
 
-1. **Analyze**: Read $ARGUMENTS to understand scope
-2. **Determine Structure**:
+1. **Analyze**: Read $ARGUMENTS to understand scope.
+2. **Extract source artifacts**: invoke the `jira-source-artifacts` skill, then enumerate every external URL, embed, attachment, or example payload and classify each by domain per its rules. Build the `artifacts` map. See "Source Artifacts" below.
+3. **Walk the live product** (when applicable): if the work touches existing user-facing surfaces, invoke the `product-walkthrough` skill to capture current behavior, design-vs-product divergence, and reuse candidates. Especially load-bearing for Expo/React Native — a UI ticket without a current-product walkthrough is missing context the implementer needs. Skip only when the work is purely backend or affects a screen that does not yet exist. See "Live Product Walkthrough" below.
+4. **Determine structure**:
    - Epic needed if: multiple features, major changes, >3 related files
    - Direct tasks if: bug fix, single file, minor change
-3. **Create Issues** with hierarchy:
-   ```
+5. **Plan hierarchy**:
+   ```text
    Epic → User Story → Tasks (test, implement, document, cleanup)
    ```
+6. **Delegate every write to `jira-write-ticket`** in dependency order (epic first, then stories with the epic as parent, then sub-tasks with their story as parent). Pass the artifacts (filtered by domain per `jira-source-artifacts` inheritance rules), the walkthrough findings (under `## Current Product`), and — for UI tickets — the Validation Journey draft with `[SCREENSHOT: ...]` markers. See "Delegation to jira-write-ticket" below.
+7. **Run the artifact preservation gate** (`jira-source-artifacts` §8): after all writes complete, build the preservation matrix and verify every extracted artifact is reachable from the created tickets. Fail loudly if anything was dropped.
 
 ## Mandatory for Every Code Issue
 
@@ -87,33 +91,19 @@ h3. Assertions
 6. **Prerequisites include feature flags** — If the feature is behind a PostHog flag, name it explicitly
 7. **Auth steps included when needed** — If the journey requires login, include the test credentials in Prerequisites
 
-## Source Artifact Preservation
-
-If $ARGUMENTS includes a PRD, design doc, Figma URL, Lovable prototype, or similar external artifact — or if a referenced file links out to one — those references MUST be preserved as remote links on the created tickets. Dropping source artifacts during ticket creation is the single most common quality failure in this pipeline, because developers picking up a ticket then lose the design/UX source of truth.
+## Source Artifacts
 
-Rules:
+If $ARGUMENTS includes (or references) any external artifact — PRD, design doc, Figma URL, Lovable prototype, Loom walkthrough, screenshot, example payload — those references MUST be preserved as remote links on the created tickets. Silent artifact loss is the single most common quality failure in this pipeline.
 
-1. **Extract before creating**: enumerate every external URL, embed, attachment, or example payload in the input. Classify by domain (`ui-design`, `ux-flow`, `data`, `ops`, `reference`) — see `notion-to-jira` Phase 1.5 for the canonical taxonomy.
-2. **Epic gets everything**: attach all extracted artifacts as remote links on the epic, regardless of domain.
-3. **Stories inherit by domain**: frontend/Expo stories get `ui-design` + `ux-flow` + `reference`; backend gets `data` + `reference`; infra gets `ops` + `reference`. When ambiguous, err on the side of inclusion.
-4. **Sub-tasks inherit via parent**: do not re-attach on every sub-task unless a specific artifact applies only to that sub-task.
-5. **Verify before reporting**: before declaring done, confirm every extracted artifact is reachable from the tickets. If any are missing, fail loudly and surface the dropped list to the human — do not silently drop.
+**Invoke the `jira-source-artifacts` skill** for the canonical rules: domains, per-tool classification (Figma `/proto/` vs design, Lovable, Loom, screenshots), source precedence, conflict handling under `## Open Questions`, inheritance from epic → story → sub-task, and the existing-component reuse expectation. Do not restate the rules here.
 
-When delegating actual writes to `jira-write-ticket`, pass the extracted artifact list so its Phase 4c (Remote Links) step can attach them.
+Expo-specific note: the existing-component reuse rule is especially load-bearing for React Native — the project has an established component library; pixel-matching a mock instead of reusing components is the most common drift mode.
 
-**Classification disambiguation** (applied during extraction):
-- Figma URL with `/proto/` or `starting-point-node-id=` → `ux-flow`; plain design frame URL → `ui-design`.
-- Lovable output → always `ux-flow` (its code/styling/logic is NOT authoritative).
-- Loom / annotated screenshot with flow arrows → `ux-flow`; bare screenshot → `ui-design`.
+When delegating writes to `jira-write-ticket`, pass the extracted artifact list so its Phase 4c step can attach them.
 
-**Source precedence** (must be recorded on every ticket carrying design artifacts):
-- Business rules (fields, validation, permissions, constraints) come from the **description / PRD body**.
-- Visual treatment (layout, spacing, typography, color) comes from **mocks** (`ui-design`).
-- Flow and interaction (navigation, transitions, state changes, empty/error/loading states) come from **prototypes** (`ux-flow`).
-- API / data shape comes from **`data` artifacts**.
-- Cross-axis conflicts are surfaced as `## Open Questions` BLOCKERs, never silently reconciled.
+## Live Product Walkthrough
 
-**Existing-component reuse** (applies to every UI-touching ticket — especially relevant for Expo/React Native with its established component library): the story description must instruct the implementer to locate the closest existing component in the codebase and prefer reuse over pixel-matching a mock. Design-vs-code divergence is raised on the ticket, not resolved by the implementer alone.
+When the work touches existing user-facing surfaces, invoke the `product-walkthrough` skill before drafting tickets. Findings (current behavior, design-vs-product divergence, reuse candidates, behavioral surprises) become inputs to the ticket plan and surface under `## Current Product` on the resulting tickets, complementing the Validation Journey (which describes how to verify the *new* behavior, not what exists today). Skip only when the work is purely backend or affects a screen that does not yet exist.
 
 ## Issue Requirements
 
@@ -126,4 +116,46 @@ Each issue must clearly communicate to:
 Default project: from jira-cli config (override via arguments)
 Exclude unless requested: migration plans, performance tests
 
-Execute the analysis and create the complete JIRA structure with proper parent-child relationships.
+## Delegation to jira-write-ticket
+
+**Mandatory.** Every ticket created by this skill MUST go through `jira-write-ticket`. This skill never calls `mcp__atlassian__createJiraIssue` itself — that tool is intentionally excluded from `allowed-tools` so the gate cannot be bypassed.
+
+`jira-write-ticket` enforces things this skill does not, and which determine ticket quality:
+- 3-audience description (Context / Technical Approach / Acceptance Criteria)
+- Gherkin acceptance criteria
+- Epic parent validation (non-bug, non-epic types)
+- Explicit link discovery (`blocks` / `is blocked by` / `relates to` / `duplicates` / `clones`)
+- Remote links (PRs, Confluence, dashboards)
+- Single-repo scope check for Bug / Task / Sub-task
+- Sign-in account and target environment recorded in description
+- Post-create verification
+
+### Invocation order
+
+Tickets must be created in parent-before-child order so each child can be passed its parent key:
+
+1. Invoke `jira-write-ticket` for the epic. Capture the returned key.
+2. For each story, invoke `jira-write-ticket` with the epic key as the epic parent. Capture each story key.
+3. For each sub-task, invoke `jira-write-ticket` with the parent story key.
+
+### What to pass to each invocation
+
+For every delegated write, pass:
+- The summary, issue type, project key, and priority you decided
+- The 3-section description body you drafted (Context / Technical Approach / Acceptance Criteria)
+- Gherkin acceptance criteria
+- Parent key (epic key for stories; story key for sub-tasks)
+- The artifact list extracted in "Source Artifacts", filtered by domain per the inheritance rules — `jira-write-ticket` Phase 4c attaches them as remote links
+- For UI-touching tickets: the Validation Journey draft (with `[SCREENSHOT: ...]` markers, viewports, and feature-flag prerequisites). If the journey is missing, instruct it to call `jira-add-journey` after create.
+
+### What this skill is responsible for
+
+This skill owns:
+- Deciding the *shape* of the hierarchy (what's an epic vs. story vs. sub-task)
+- Drafting the description body and acceptance criteria from the input
+- Extracting and classifying source artifacts
+- Threading parent keys through subsequent writes
+- Drafting the Validation Journey for UI tickets (this is Expo-specific guidance the base skill doesn't have)
+- Running the artifact preservation check after all writes complete
+
+It does not own the actual JIRA write — that's `jira-write-ticket`'s job.

package/plugins/lisa-expo/skills/jira-verify/SKILL.md

@@ -1,47 +1,27 @@
 ---
 name: jira-verify
-description: This skill should be used when verifying that a JIRA ticket meets organizational standards for epic relationships and description quality. It checks epic parent relationships and validates description completeness for coding assistants, developers, and stakeholders.
-allowed-tools: ["mcp__atlassian__getJiraIssue", "mcp__atlassian__searchJiraIssuesUsingJql", "mcp__atlassian__getAccessibleAtlassianResources"]
+description: This skill should be used when verifying that a JIRA ticket meets organizational standards for epic relationships, description quality, and (for UI tickets) Validation Journey presence. It fetches the live ticket and delegates the gate checks to jira-validate-ticket so the bar matches what jira-write-ticket enforces pre-write.
+allowed-tools: ["Skill", "mcp__atlassian__getJiraIssue", "mcp__atlassian__getAccessibleAtlassianResources"]
 ---
 
 # Verify JIRA Ticket: $ARGUMENTS
 
-Fetch ticket $ARGUMENTS and verify it meets organizational standards.
+Verify that the existing JIRA ticket `$ARGUMENTS` meets organizational standards. This skill is a thin post-write wrapper around `jira-validate-ticket`: it fetches the live ticket and asks `jira-validate-ticket` to run the gates against the fetched state.
 
-## Verification Checks
+This indirection exists so the gate definitions live in exactly one place (`jira-validate-ticket`). When the bar changes, change it there — `jira-verify`, `jira-write-ticket` (Phase 5.5 pre-write), and `notion-to-jira` (PRD dry-run) all pick it up.
 
-### 1. Epic Parent Relationship
+## Process
 
-**Rule**: Non-bug, non-epic tickets MUST have an epic parent
+1. Resolve cloud ID via `mcp__atlassian__getAccessibleAtlassianResources`.
+2. Fetch the ticket via `mcp__atlassian__getJiraIssue` for `$ARGUMENTS`.
+3. Invoke `jira-validate-ticket` and pass the ticket key. The validator runs every gate (Specification + Feasibility) against the live state, including the Validation Journey check (S11) which applies to any runtime-behavior change — UI tickets in Expo always qualify.
+4. Surface the validator's report verbatim.
 
-- If missing: Search filter 10089 (Epic Backlog) and suggest appropriate epics
+## Output
 
-### 2. Description Quality
+Pass through `jira-validate-ticket`'s structured output unchanged. Downstream callers parse the gate lines.
 
-Verify description adequately addresses:
+## Notes
 
-**Coding Assistants**: Acceptance criteria, requirements, constraints, I/O
-**Developers**: Technical context, integration points, testing, edge cases
-**Stakeholders**: Business value, user impact, success metrics, summary
-
-### 3. Validation Journey (Frontend Tickets)
-
-**Rule**: Tickets that touch UI (components, labels, or description mentioning frontend, UI, modal, layout, responsive, screen, page, button, form) MUST include a Validation Journey section.
-
-Check by running:
-
-```bash
-python3 .claude/skills/jira-journey/scripts/parse-plan.py <TICKET_ID> 2>&1
-```
-
-- If the parser returns steps: PASS
-- If the parser fails with "No 'Validation Journey' section found": FAIL — recommend using `/jira-add-journey <TICKET_ID>` to add one
-
-This check is skipped for:
-- Pure backend/API tickets (no UI surface)
-- Config-only tickets (env vars, feature flags, CI/CD)
-- Epic-level tickets (journeys belong on child stories/tasks)
-
-## Execute Verification
-
-Retrieve ticket details, run all checks, and provide specific improvement recommendations for any failures.
+- This skill is read-only. It never edits the ticket, posts comments, or changes status.
+- For UI tickets that fail the Validation Journey gate, the validator's remediation will recommend `/jira-add-journey` — the Expo flavor of `jira-add-journey` produces the `[SCREENSHOT: ...]` + viewport block that the Playwright-based journey runner consumes.

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "1.95.0",
+  "version": "1.96.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": "1.95.0",
+  "version": "1.96.0",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-rails/skills/jira-create/SKILL.md

@@ -1,23 +1,27 @@
 ---
 name: jira-create
 description: This skill should be used when creating JIRA epics, stories, and tasks from code files or descriptions. It analyzes the provided input, determines the appropriate issue hierarchy, and creates issues with comprehensive quality requirements including test-first development and documentation.
-allowed-tools: ["Read", "Glob", "LS", "mcp__atlassian__createJiraIssue", "mcp__atlassian__getVisibleJiraProjects", "mcp__atlassian__getJiraProjectIssueTypesMetadata", "mcp__atlassian__getAccessibleAtlassianResources"]
+allowed-tools: ["Read", "Glob", "LS", "Skill", "mcp__atlassian__getVisibleJiraProjects", "mcp__atlassian__getJiraProjectIssueTypesMetadata", "mcp__atlassian__getAccessibleAtlassianResources"]
 ---
 
 # Create JIRA Issues from $ARGUMENTS
 
-Analyze the provided file(s) and create a comprehensive JIRA hierarchy with all mandatory quality gates.
+Analyze the provided file(s) and plan a JIRA hierarchy. **This skill plans structure only — every individual ticket write is delegated to `jira-write-ticket`.** Do not call `mcp__atlassian__createJiraIssue` from this skill; the necessary write tools are intentionally not in `allowed-tools`.
 
 ## Process
 
-1. **Analyze**: Read $ARGUMENTS to understand scope
-2. **Determine Structure**:
+1. **Analyze**: Read $ARGUMENTS to understand scope.
+2. **Extract source artifacts**: invoke the `jira-source-artifacts` skill, then enumerate every external URL, embed, attachment, or example payload and classify each by domain per its rules. Build the `artifacts` map. See "Source Artifacts" below.
+3. **Walk the live product** (when applicable): if the work touches existing user-facing surfaces, invoke the `product-walkthrough` skill to capture current behavior, design-vs-product divergence, and reuse candidates. Skip only when the work is purely backend or affects a screen that does not yet exist. See "Live Product Walkthrough" below.
+4. **Determine structure**:
    - Epic needed if: multiple features, major changes, >3 related files
    - Direct tasks if: bug fix, single file, minor change
-3. **Create Issues** with hierarchy:
-   ```
+5. **Plan hierarchy**:
+   ```text
    Epic → User Story → Tasks (test, implement, document, cleanup)
    ```
+6. **Delegate every write to `jira-write-ticket`** in dependency order (epic first, then stories with the epic as parent, then sub-tasks with their story as parent). Pass the artifacts (filtered by domain per `jira-source-artifacts` inheritance rules) and the walkthrough findings (under `## Current Product`). See "Delegation to jira-write-ticket" below.
+7. **Run the artifact preservation gate** (`jira-source-artifacts` §8): after all writes complete, build the preservation matrix and verify every extracted artifact is reachable from the created tickets. Fail loudly if anything was dropped.
 
 ## Mandatory for Every Code Issue
 
@@ -27,33 +31,19 @@ Analyze the provided file(s) and create a comprehensive JIRA hierarchy with all
 **Feature Flags**: All features behind flags with lifecycle plan
 **Cleanup**: Remove temporary code, scripts, dev configs
 
-## Source Artifact Preservation
-
-If $ARGUMENTS includes a PRD, design doc, Figma URL, Lovable prototype, or similar external artifact — or if a referenced file links out to one — those references MUST be preserved as remote links on the created tickets. Dropping source artifacts during ticket creation is the single most common quality failure in this pipeline, because developers picking up a ticket then lose the design/UX source of truth.
+## Source Artifacts
 
-Rules:
+If $ARGUMENTS includes (or references) any external artifact — PRD, design doc, Figma URL, Lovable prototype, Loom walkthrough, screenshot, example payload — those references MUST be preserved as remote links on the created tickets. Silent artifact loss is the single most common quality failure in this pipeline.
 
-1. **Extract before creating**: enumerate every external URL, embed, attachment, or example payload in the input. Classify by domain (`ui-design`, `ux-flow`, `data`, `ops`, `reference`) — see `notion-to-jira` Phase 1.5 for the canonical taxonomy.
-2. **Epic gets everything**: attach all extracted artifacts as remote links on the epic, regardless of domain.
-3. **Stories inherit by domain**: frontend/view stories get `ui-design` + `ux-flow` + `reference`; backend/model/controller stories get `data` + `reference`; infra stories get `ops` + `reference`. When ambiguous, err on the side of inclusion.
-4. **Sub-tasks inherit via parent**: do not re-attach on every sub-task unless a specific artifact applies only to that sub-task.
-5. **Verify before reporting**: before declaring done, confirm every extracted artifact is reachable from the tickets. If any are missing, fail loudly and surface the dropped list to the human — do not silently drop.
+**Invoke the `jira-source-artifacts` skill** for the canonical rules: domains, per-tool classification (Figma `/proto/` vs design, Lovable, Loom, screenshots), source precedence, conflict handling under `## Open Questions`, inheritance from epic → story → sub-task, and the existing-component reuse expectation. Do not restate the rules here.
 
-When delegating actual writes to `jira-write-ticket`, pass the extracted artifact list so its Phase 4c (Remote Links) step can attach them.
+Rails-specific note: the existing-component reuse rule applies to view partials and ViewComponents — the closest existing partial/component is usually the right answer over pixel-matching a mock from scratch.
 
-**Classification disambiguation** (applied during extraction):
-- Figma URL with `/proto/` or `starting-point-node-id=` → `ux-flow`; plain design frame URL → `ui-design`.
-- Lovable output → always `ux-flow` (its code/styling/logic is NOT authoritative).
-- Loom / annotated screenshot with flow arrows → `ux-flow`; bare screenshot → `ui-design`.
+When delegating writes to `jira-write-ticket`, pass the extracted artifact list so its Phase 4c step can attach them.
 
-**Source precedence** (must be recorded on every ticket carrying design artifacts):
-- Business rules (fields, validation, permissions, constraints) come from the **description / PRD body**.
-- Visual treatment (layout, spacing, typography, color) comes from **mocks** (`ui-design`).
-- Flow and interaction (navigation, transitions, state changes, empty/error/loading states) come from **prototypes** (`ux-flow`).
-- API / data shape comes from **`data` artifacts**.
-- Cross-axis conflicts are surfaced as `## Open Questions` BLOCKERs, never silently reconciled.
+## Live Product Walkthrough
 
-**Existing-component reuse** (applies to every view/partial-touching ticket): the story description must instruct the implementer to locate the closest existing view partial or ViewComponent in the codebase and prefer reuse over pixel-matching a mock. Design-vs-code divergence is raised on the ticket, not resolved by the implementer alone.
+When the work touches existing user-facing surfaces, invoke the `product-walkthrough` skill before drafting tickets. Findings (current behavior, design-vs-product divergence, reuse candidates, behavioral surprises) become inputs to the ticket plan and surface under `## Current Product` on the resulting tickets. Skip only when the work is purely backend or affects a screen that does not yet exist.
 
 ## Issue Requirements
 
@@ -66,4 +56,45 @@ Each issue must clearly communicate to:
 Default project: SE (override via arguments)
 Exclude unless requested: migration plans, performance tests
 
-Execute the analysis and create the complete JIRA structure with proper parent-child relationships.
+## Delegation to jira-write-ticket
+
+**Mandatory.** Every ticket created by this skill MUST go through `jira-write-ticket`. This skill never calls `mcp__atlassian__createJiraIssue` itself — that tool is intentionally excluded from `allowed-tools` so the gate cannot be bypassed.
+
+`jira-write-ticket` enforces things this skill does not, and which determine ticket quality:
+- 3-audience description (Context / Technical Approach / Acceptance Criteria)
+- Gherkin acceptance criteria
+- Epic parent validation (non-bug, non-epic types)
+- Explicit link discovery (`blocks` / `is blocked by` / `relates to` / `duplicates` / `clones`)
+- Remote links (PRs, Confluence, dashboards)
+- Single-repo scope check for Bug / Task / Sub-task
+- Sign-in account and target environment recorded in description
+- Post-create verification
+
+### Invocation order
+
+Tickets must be created in parent-before-child order so each child can be passed its parent key:
+
+1. Invoke `jira-write-ticket` for the epic. Capture the returned key.
+2. For each story, invoke `jira-write-ticket` with the epic key as the epic parent. Capture each story key.
+3. For each sub-task, invoke `jira-write-ticket` with the parent story key.
+
+### What to pass to each invocation
+
+For every delegated write, pass:
+- The summary, issue type, project key, and priority you decided
+- The 3-section description body you drafted (Context / Technical Approach / Acceptance Criteria)
+- Gherkin acceptance criteria
+- Parent key (epic key for stories; story key for sub-tasks)
+- The artifact list extracted in "Source Artifacts", filtered by domain per the inheritance rules — `jira-write-ticket` Phase 4c attaches them as remote links
+- For tickets that change runtime behavior: the Validation Journey draft, or instruct it to call `jira-add-journey` after create
+
+### What this skill is responsible for
+
+This skill owns:
+- Deciding the *shape* of the hierarchy (what's an epic vs. story vs. sub-task)
+- Drafting the description body and acceptance criteria from the input
+- Extracting and classifying source artifacts
+- Threading parent keys through subsequent writes
+- Running the artifact preservation check after all writes complete
+
+It does not own the actual JIRA write — that's `jira-write-ticket`'s job.

package/plugins/lisa-rails/skills/jira-verify/SKILL.md

@@ -1,29 +1,26 @@
 ---
 name: jira-verify
-description: This skill should be used when verifying that a JIRA ticket meets organizational standards for epic relationships and description quality. It checks epic parent relationships and validates description completeness for coding assistants, developers, and stakeholders.
-allowed-tools: ["mcp__atlassian__getJiraIssue", "mcp__atlassian__searchJiraIssuesUsingJql", "mcp__atlassian__getAccessibleAtlassianResources"]
+description: This skill should be used when verifying that a JIRA ticket meets organizational standards for epic relationships and description quality. It fetches the live ticket and delegates the gate checks to jira-validate-ticket so the bar matches what jira-write-ticket enforces pre-write.
+allowed-tools: ["Skill", "mcp__atlassian__getJiraIssue", "mcp__atlassian__getAccessibleAtlassianResources"]
 ---
 
 # Verify JIRA Ticket: $ARGUMENTS
 
-Fetch ticket $ARGUMENTS and verify it meets organizational standards.
+Verify that the existing JIRA ticket `$ARGUMENTS` meets organizational standards. This skill is a thin post-write wrapper around `jira-validate-ticket`: it fetches the live ticket and asks `jira-validate-ticket` to run the gates against the fetched state.
 
-## Verification Checks
+This indirection exists so the gate definitions live in exactly one place (`jira-validate-ticket`). When the bar changes, change it there — `jira-verify`, `jira-write-ticket` (Phase 5.5 pre-write), and `notion-to-jira` (PRD dry-run) all pick it up.
 
-### 1. Epic Parent Relationship
+## Process
 
-**Rule**: Non-bug, non-epic tickets MUST have an epic parent
+1. Resolve cloud ID via `mcp__atlassian__getAccessibleAtlassianResources`.
+2. Fetch the ticket via `mcp__atlassian__getJiraIssue` for `$ARGUMENTS`.
+3. Invoke `jira-validate-ticket` and pass the ticket key. The validator runs every gate (Specification + Feasibility) against the live state.
+4. Surface the validator's report verbatim.
 
-- If missing: Search filter 10089 (Epic Backlog) and suggest appropriate epics
+## Output
 
-### 2. Description Quality
+Pass through `jira-validate-ticket`'s structured output unchanged. Downstream callers parse the gate lines.
 
-Verify description adequately addresses:
+## Notes
 
-**Coding Assistants**: Acceptance criteria, requirements, constraints, I/O
-**Developers**: Technical context, integration points, testing, edge cases
-**Stakeholders**: Business value, user impact, success metrics, summary
-
-## Execute Verification
-
-Retrieve ticket details, run both checks, and provide specific improvement recommendations for any failures.
+- This skill is read-only. It never edits the ticket, posts comments, or changes status.

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

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

package/plugins/src/base/agents/jira-build-intake.md

@@ -0,0 +1,58 @@
+---
+name: jira-build-intake
+description: JIRA build-intake agent. Runs one build-intake cycle against a JIRA project (or JQL filter) — claims Ready tickets, dispatches each to the jira-agent build flow, transitions to On Dev on success. Symmetric counterpart to notion-prd-intake. Designed to be invoked manually via /jira-build-intake or autonomously via a scheduled cron later.
+skills:
+  - jira-build-intake
+  - jira-read-ticket
+  - jira-verify
+  - jira-validate-ticket
+  - jira-write-ticket
+  - jira-sync
+  - jira-evidence
+  - jira-add-journey
+  - ticket-triage
+---
+
+# JIRA Build Intake Agent
+
+You are a JIRA build-intake agent. Your single job is to run one cycle against a JIRA project / JQL filter — find Ready tickets, dispatch each through the build flow, transition successful builds to On Dev — then report what happened.
+
+## Workflow
+
+### 1. Receive the query
+
+The invoking caller (a slash command or a future schedule wrapper) hands you a JIRA project key (e.g. `SE`) or a full JQL filter. You do not pick the query yourself.
+
+If no query is provided, stop and ask. Never run intake against a default scope — the side effects (status transitions, PRs opened, builds running) are too high to act without an explicit target.
+
+### 2. Run the intake skill
+
+Invoke the `jira-build-intake` skill with the query as `$ARGUMENTS`. The skill owns the cycle logic — JQL execution, claim, dispatch to `jira-agent`, transition on success, summary. Do not duplicate that logic here.
+
+The skill in turn invokes `jira-agent` per ticket, which owns the per-ticket lifecycle (read full graph, verify, triage, route to flow, sync progress, post evidence). You do not call `jira-agent` directly — the intake skill does.
+
+### 3. Surface the summary
+
+Pass the skill's summary block through to the caller verbatim. The caller needs the structured record:
+
+- Total processed
+- Per-ticket outcomes (`On Dev` → which PR; `Blocked` by verify → which gate; `Held` by triage → which ambiguities; Errors → reason)
+- PR count
+
+If the cycle errored before processing any tickets (e.g. workflow misconfigured — `In Progress` or `On Dev` not valid transitions, missing `Ready` status entirely), surface the cause in plain language and stop. Do NOT attempt to invent transitions.
+
+### 4. Suggest next actions when warranted
+
+After a successful cycle, if any tickets ended in `On Dev`, mention that the next phase (QA, deploy, or downstream verification — depending on the project workflow) is owned by either humans or a future intake skill. This skill does not own anything past `On Dev`.
+
+If any tickets ended in `Blocked` (pre-flight verify failed) or `Held` (triage found ambiguities), point that out so the caller knows which tickets need human attention before they can be re-claimed. The Blocked ones were transitioned by `jira-agent`'s gate logic — that is correct and expected.
+
+## Rules
+
+- **Never run a cycle without an explicit query.** Side effects too high to default.
+- **Never modify the lifecycle**: only `Ready → In Progress → On Dev`. Never touch `TODO`, `On QA`, `Done`, or any other status. (Exception: `jira-agent` may transition to `Blocked` as part of its pre-flight gate — that's its job, not yours.)
+- **Never bypass `jira-agent` to do build work directly.** The intake skill dispatches; `jira-agent` builds. Skipping the dispatch produces broken work.
+- **Never invent transitions.** If a project's workflow uses different status names, the caller passes them as overrides in `$ARGUMENTS`. Don't guess.
+- **Never start a second cycle while one is in flight against an overlapping query.** Serial execution. Scheduling layer (when added) is responsible for not double-firing.
+- **Stop and surface failures rather than retry-loop.** If `jira-agent` returns an unexpected response or an error, the skill records it under "Errors" — pass that through. Do not auto-retry.
+- **Pre-flight failures are not your problem to fix.** If a ticket fails `jira-verify` (missing Validation Journey, sign-in, etc.), `jira-agent` transitions it to `Blocked` and reassigns to Reporter. Surface the count and move on. Do NOT try to add the missing pieces from this agent — that's product / authoring work, not build work.

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

@@ -0,0 +1,57 @@
+---
+name: notion-prd-intake
+description: PRD intake agent. Runs one intake cycle against a Notion PRD database — claims Ready PRDs, validates each through the dry-run pipeline, and routes to Blocked (with clarifying comments) or Ticketed (with JIRA tickets created). Designed to be invoked manually via /notion-prd-intake or autonomously via a scheduled cron.
+skills:
+  - notion-prd-intake
+  - notion-to-jira
+  - jira-validate-ticket
+  - jira-source-artifacts
+  - product-walkthrough
+  - jira-write-ticket
+  - prd-ticket-coverage
+---
+
+# PRD Intake Agent
+
+You are a PRD intake agent. Your single job is to run one intake cycle against the Notion PRD database whose URL is given to you, then report what happened.
+
+## Workflow
+
+### 1. Receive the database URL
+
+The invoking caller (a slash command, a scheduled cron, or a parent agent) hands you a Notion database URL or bare ID. You do not pick the database yourself.
+
+If no URL is provided, stop and ask. Never run intake against a default or guessed database — the side effects (Notion status changes, JIRA tickets created) are too high to act without an explicit target.
+
+### 2. Run the intake skill
+
+Invoke the `notion-prd-intake` skill with the database URL as `$ARGUMENTS`. The skill owns the cycle logic — claim, dry-run, branch, write or comment, status transition, summary. Do not duplicate that logic here.
+
+Treat the skill's output as the source of truth. If it reports `Ticketed: 3 / 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 `/notion-prd-intake` ad-hoc, or a future schedule wrapper) needs the structured record:
+
+- Total processed
+- Per-PRD outcomes (Ticketed → which tickets created; Blocked → how many gate failures; Errors → reason)
+- JIRA ticket count
+
+If the cycle errored before processing any PRDs (e.g. database misconfigured, missing config), surface the failure cause in plain language and stop.
+
+### 4. Suggest next actions when warranted
+
+After a successful cycle, if any PRDs ended in `Blocked`, mention to the caller that those PRDs need product attention before they can be re-ticketed. Do not auto-notify product — Notion comments on the PRDs are the channel; the caller decides whether to ping anyone.
+
+When reporting Blocked outcomes, distinguish the cause: **pre-write gate failure** (per-ticket validator caught a problem before any tickets were created) vs **post-write coverage gap** (tickets were created and remain in JIRA, but the PRD has uncovered requirements that the next intake cycle will address). Both result in `Status = 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 `Ticketed` with coverage `COMPLETE`, mention that the next step is for product to monitor the created tickets and flip the PRDs to `Shipped` 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 database URL.** Side effects are too high to default.
+- **Never modify the lifecycle**: only `Ready → In Review → Blocked|Ticketed`. Never touch `Draft` or `Shipped`. Never invent new status values.
+- **Never write JIRA tickets directly.** All writes go through the skill chain (intake → notion-to-jira → jira-write-ticket). Bypassing this skips quality gates.
+- **Never edit a PRD's body.** Communication with product happens only via Notion comments on the PRD.
+- **Never start a second cycle while one is in flight against the same database.** This agent assumes serial execution; the scheduling layer is responsible for not double-firing.
+- **Stop and surface failures rather than retry-loop.** If `notion-to-jira` returns an error, the skill records it under `Errors` in the summary; pass that through. Do not auto-retry.

package/plugins/src/base/commands/jira/build-intake.md

@@ -0,0 +1,7 @@
+---
+description: "Run one JIRA build-intake cycle. Finds tickets in Status=Ready, claims each via In Progress, runs the implementation flow via jira-agent, and transitions to On Dev on completion. Symmetric counterpart to /notion-prd-intake."
+allowed-tools: ["Skill"]
+argument-hint: "<project key> | <full JQL filter>"
+---
+
+Use the /lisa:jira-build-intake skill to scan for Ready JIRA tickets, claim them, run the build flow, and transition to On Dev. $ARGUMENTS

package/plugins/src/base/commands/jira/source-artifacts.md

@@ -0,0 +1,6 @@
+---
+description: "Load the canonical taxonomy and rules for handling source artifacts (Figma, Lovable, Loom, etc.) in JIRA tickets — domains, classification, source precedence, inheritance, and conflict handling."
+allowed-tools: ["Skill"]
+---
+
+Use the /lisa:jira-source-artifacts skill to load the canonical taxonomy and rules for source artifact handling. $ARGUMENTS

package/plugins/src/base/commands/jira/validate-ticket.md

@@ -0,0 +1,7 @@
+---
+description: "Validate a proposed JIRA ticket spec or an existing ticket against the organizational quality gates. Read-only, no writes."
+allowed-tools: ["Skill"]
+argument-hint: "<TICKET-ID> | <YAML spec block>"
+---
+
+Use the /lisa:jira-validate-ticket skill to validate the ticket spec or existing ticket against organizational quality gates and return a structured PASS/FAIL report. $ARGUMENTS

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

@@ -0,0 +1,7 @@
+---
+description: "Run one PRD intake cycle against a Notion PRD database. Finds Ready PRDs, validates each through the JIRA gate logic, then routes to Blocked (with clarifying comments) or Ticketed (with JIRA tickets created)."
+allowed-tools: ["Skill"]
+argument-hint: "<Notion database URL or ID>"
+---
+
+Use the /lisa:notion-prd-intake skill to scan the given Notion PRD database for Ready PRDs, dry-run-validate each, and route to Blocked or Ticketed. $ARGUMENTS

package/plugins/src/base/commands/prd-ticket-coverage.md

@@ -0,0 +1,7 @@
+---
+description: "Audit PRD-to-tickets coverage. Verifies every requirement in a Notion PRD is covered by at least one created JIRA ticket; flags gaps (silent drops) and scope creep. Read-only — no writes to JIRA or Notion."
+allowed-tools: ["Skill"]
+argument-hint: "<PRD URL> [tickets=KEY-1,KEY-2,...]"
+---
+
+Use the /lisa:prd-ticket-coverage skill to audit coverage of the PRD against the listed (or auto-discovered) JIRA tickets and produce a coverage matrix + verdict. $ARGUMENTS

package/plugins/src/base/commands/product-walkthrough.md

@@ -0,0 +1,7 @@
+---
+description: "Walk through the live product via a real browser (Playwright MCP) to ground PRD evaluation or ticket creation in what exists today. Captures current behavior, design-vs-product divergence, reuse candidates, and behavioral surprises."
+allowed-tools: ["Skill"]
+argument-hint: "<route or feature area to walk>"
+---
+
+Use the /lisa:product-walkthrough skill to walk through the live product, capture current state, and produce findings that ground PRD/ticket reasoning. $ARGUMENTS