@codyswann/lisa 1.95.0 → 1.96.0

package/plugins/src/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/src/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/src/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/src/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.