@codyswann/lisa 1.95.0 → 2.0.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/{plan-fix-linter-error → fix-linter-error}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: plan-fix-linter-error
+name: fix-linter-error
 description: This skill should be used when fixing all violations of one or more RuboCop cops across the codebase. It runs RuboCop, groups violations by cop and file, generates a brief with fix strategies, and creates a plan with tasks to implement the fixes.
 allowed-tools: ["Read", "Bash", "Glob", "Grep"]
 
@@ -42,4 +42,4 @@ Fix strategies: extract methods, reduce complexity, apply auto-correct where saf
 Verification: `bundle exec rubocop --format simple 2>&1 | grep -E "($ARGUMENTS)" | wc -l` -> Expected: 0
 ```
 
-Invoke `/plan-execute` with this brief to create the implementation plan.
+Invoke `/implement` with this brief to create the implementation plan.

package/plugins/src/rails/skills/{plan-lower-code-complexity → improve-code-complexity}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: plan-lower-code-complexity
+name: improve-code-complexity
 description: This skill should be used when reducing the code complexity threshold of the codebase. It lowers the CyclomaticComplexity threshold by 2, identifies methods that exceed the new limit, generates a brief with refactoring strategies, and creates a plan with tasks to fix all violations.
 allowed-tools: ["Read", "Bash", "Glob", "Grep"]
 ---
@@ -45,4 +45,4 @@ Refactoring strategies: extract methods, early returns, extract conditions, use
 Verification: `bundle exec rubocop --only Metrics/CyclomaticComplexity --format simple 2>&1 | grep "offense" | wc -l` -> Expected: 0
 ```
 
-Invoke `/plan-execute` with this brief to create the implementation plan.
+Invoke `/implement` with this brief to create the implementation plan.

package/plugins/{lisa-rails/skills/plan-reduce-max-lines → src/rails/skills/improve-max-lines}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: plan-reduce-max-lines
+name: improve-max-lines
 description: This skill should be used when reducing the maximum class/module lines threshold and fixing all violations. It updates the RuboCop configuration, identifies classes and modules exceeding the new limit, generates a brief with refactoring strategies, and creates a plan with tasks to split oversized files.
 allowed-tools: ["Read", "Bash", "Glob", "Grep"]
 
@@ -43,4 +43,4 @@ Refactoring strategies: extract concerns, extract service objects, remove duplic
 Verification: `bundle exec rubocop --only Metrics/ClassLength,Metrics/ModuleLength --format simple 2>&1 | grep "offense" | wc -l` -> Expected: 0
 ```
 
-Invoke `/plan-execute` with this brief to create the implementation plan.
+Invoke `/implement` with this brief to create the implementation plan.

package/plugins/{lisa-rails/skills/plan-reduce-max-lines-per-function → src/rails/skills/improve-max-lines-per-function}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: plan-reduce-max-lines-per-function
+name: improve-max-lines-per-function
 description: This skill should be used when reducing the maximum lines per method threshold and fixing all violations. It updates the RuboCop configuration, identifies methods exceeding the new limit, generates a brief with refactoring strategies, and creates a plan with tasks to split oversized methods.
 allowed-tools: ["Read", "Bash", "Glob", "Grep"]
 
@@ -43,4 +43,4 @@ Refactoring strategies: extract methods, early returns, extract conditions, use
 Verification: `bundle exec rubocop --only Metrics/MethodLength --format simple 2>&1 | grep "offense" | wc -l` -> Expected: 0
 ```
 
-Invoke `/plan-execute` with this brief to create the implementation plan.
+Invoke `/implement` with this brief to create the implementation plan.

package/plugins/src/rails/skills/{plan-add-test-coverage → improve-test-coverage}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: plan-add-test-coverage
+name: improve-test-coverage
 description: This skill should be used when increasing test coverage to a specified threshold percentage. It runs the test suite with SimpleCov, identifies files with the lowest coverage, generates a brief with coverage gaps, and creates a plan with tasks to add the missing tests.
 allowed-tools: ["Read", "Bash", "Glob", "Grep"]
 
@@ -42,4 +42,4 @@ Configuration: .simplecov, update minimum_coverage to $ARGUMENTS%
 Verification: `bundle exec rspec` -> Expected: SimpleCov reports >= $ARGUMENTS% coverage
 ```
 
-Invoke `/plan-execute` with this brief to create the implementation plan.
+Invoke `/implement` with this brief to create the implementation plan.

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.

package/plugins/lisa/commands/build.md

@@ -1,12 +0,0 @@
----
-description: "Build a feature. Defines acceptance criteria, researches codebase, implements via TDD, verifies locally, and reviews."
-argument-hint: "<description-or-ticket-id-or-url>"
----
-
-Apply the `intent-routing` rule (loaded via the lisa plugin) and execute the **Implement** flow with the **Build** work type.
-
-**Orchestration: agent team.** Build runs a long multi-specialist sequence with parallel review. After echoing the flow and orchestration mode, your FIRST tool call MUST be `TeamCreate`. Do not call `TaskCreate`, `Agent`, or implementation tools before the team exists.
-
-If the argument is a JIRA ticket ID or URL, hand off to the `jira-agent` which will read the ticket, extract context, and delegate back to the Implement flow.
-
-$ARGUMENTS

package/plugins/lisa/commands/fix.md

@@ -1,12 +0,0 @@
----
-description: "Fix a bug. Reproduces, analyzes git history, finds root cause, implements fix via TDD, verifies locally, and reviews."
-argument-hint: "<description-or-ticket-id-or-url>"
----
-
-Apply the `intent-routing` rule (loaded via the lisa plugin) and execute the **Implement** flow with the **Fix** work type.
-
-**Orchestration: agent team.** Fix runs a long multi-specialist sequence with parallel review. After echoing the flow and orchestration mode, your FIRST tool call MUST be `TeamCreate`. Do not call `TaskCreate`, `Agent`, or implementation tools before the team exists.
-
-If the argument is a JIRA ticket ID or URL, hand off to the `jira-agent` which will read the ticket, extract context, and delegate back to the Implement flow.
-
-$ARGUMENTS

package/plugins/lisa/commands/improve.md

@@ -1,18 +0,0 @@
----
-description: "Improve existing code. Measures baseline, implements improvements via TDD, measures again, and reviews."
-argument-hint: "<target-description>"
----
-
-Apply the `intent-routing` rule (loaded via the lisa plugin) and execute the **Implement** flow with the **Improve** work type.
-
-**Orchestration: agent team.** Improve runs a multi-specialist sequence with parallel review. After echoing the flow and orchestration mode, your FIRST tool call MUST be `TeamCreate`. Do not call `TaskCreate`, `Agent`, or implementation tools before the team exists.
-
-For specific improvement types, you can also use:
-- `/lisa:plan:add-test-coverage` -- increase test coverage
-- `/lisa:plan:fix-linter-error` -- fix lint rule violations
-- `/lisa:plan:lower-code-complexity` -- reduce cognitive complexity
-- `/lisa:plan:reduce-max-lines` -- reduce file length
-- `/lisa:plan:reduce-max-lines-per-function` -- reduce function length
-- `/lisa:plan:improve-tests` -- improve test quality
-
-$ARGUMENTS

package/plugins/lisa/commands/investigate.md

@@ -1,10 +0,0 @@
----
-description: "Investigate an issue. Analyzes git history, reproduces, traces execution, checks logs, and reports findings with evidence."
-argument-hint: "<description-or-ticket-id-or-url>"
----
-
-Apply the `intent-routing` rule (loaded via the lisa plugin) and execute the **Implement** flow with the **Investigate Only** work type (spike).
-
-If the argument is a JIRA ticket ID or URL, hand off to the `jira-agent` which will read the ticket and extract context.
-
-$ARGUMENTS

package/plugins/lisa/commands/jira/add-journey.md

@@ -1,7 +0,0 @@
----
-description: "Add Validation Journey section to existing ticket"
-allowed-tools: ["Skill"]
-argument-hint: "<TICKET_ID>"
----
-
-Use the /lisa:jira-add-journey skill to add a Validation Journey section to the ticket. $ARGUMENTS

package/plugins/lisa/commands/jira/create.md

@@ -1,7 +0,0 @@
----
-description: "Create JIRA epics/stories/tasks from code files with comprehensive quality requirements"
-allowed-tools: ["Skill"]
-argument-hint: "<file-or-directory-path> [project-key]"
----
-
-Use the /lisa:jira-create skill to create JIRA issues from the provided input. $ARGUMENTS

package/plugins/lisa/commands/jira/evidence.md

@@ -1,7 +0,0 @@
----
-description: "Post captured evidence to JIRA and GitHub PR"
-allowed-tools: ["Skill"]
-argument-hint: "<TICKET_ID> <EVIDENCE_DIR> <PR_NUMBER>"
----
-
-Use the /lisa:jira-evidence skill to post captured evidence to JIRA and the GitHub PR. $ARGUMENTS

package/plugins/lisa/commands/jira/journey.md

@@ -1,7 +0,0 @@
----
-description: "Execute Validation Journey and capture evidence"
-allowed-tools: ["Skill"]
-argument-hint: "<TICKET_ID> [PR_NUMBER]"
----
-
-Use the /lisa:jira-journey skill to execute the Validation Journey and capture evidence. $ARGUMENTS

package/plugins/lisa/commands/jira/read-ticket.md

@@ -1,7 +0,0 @@
----
-description: "Read a JIRA ticket with full scope — metadata, comments, remote PRs, linked tickets, epic siblings, subtasks"
-allowed-tools: ["Skill"]
-argument-hint: "<TICKET-ID>"
----
-
-Use the /lisa:jira-read-ticket skill to fetch the full scope of the JIRA ticket and its related graph. $ARGUMENTS

package/plugins/lisa/commands/jira/sync.md

@@ -1,7 +0,0 @@
----
-description: "Sync plan progress to a linked JIRA ticket"
-allowed-tools: ["Skill"]
-argument-hint: "<ticket-id>"
----
-
-Use the /lisa:jira-sync skill to sync plan progress to the linked JIRA ticket. $ARGUMENTS

package/plugins/lisa/commands/jira/triage.md

@@ -1,7 +0,0 @@
----
-description: "Analytical triage of a JIRA ticket -- ambiguity detection, edge case analysis, verification methodology"
-allowed-tools: ["Skill"]
-argument-hint: "<TICKET-ID>"
----
-
-Use the /lisa:ticket-triage skill to run analytical triage on the JIRA ticket. $ARGUMENTS

package/plugins/lisa/commands/jira/verify.md

@@ -1,7 +0,0 @@
----
-description: "Verify JIRA ticket meets standards for epic relationships and description quality"
-allowed-tools: ["Skill"]
-argument-hint: "<TICKET-ID>"
----
-
-Use the /lisa:jira-verify skill to verify the JIRA ticket meets organizational standards. $ARGUMENTS

package/plugins/lisa/commands/jira/write-ticket.md

@@ -1,7 +0,0 @@
----
-description: "Create or update a JIRA ticket with enforced relationships, Gherkin criteria, and metadata quality gates"
-allowed-tools: ["Skill"]
-argument-hint: "[TICKET-ID | <create-intent-description>]"
----
-
-Use the /lisa:jira-write-ticket skill to create or update the JIRA ticket with full relationship discovery and quality enforcement. $ARGUMENTS

package/plugins/lisa/commands/plan/create.md

@@ -1,8 +0,0 @@
----
-description: "Creates an implementation plan from a ticket URL, file path, or text description"
-argument-hint: "<ticket-url | @file-path | description>"
----
-
-Apply the `intent-routing` rule (loaded via the lisa plugin) and execute the **Plan** flow on $ARGUMENTS.
-
-If requirements are ambiguous or no specification exists, suggest running the **Research** flow first.

package/plugins/lisa/commands/plan/execute.md

@@ -1,6 +0,0 @@
----
-description: "Deploys an agent team to research, implement, review and deploy a plan"
-argument-hint: "<ticket-url | @file-path | description>"
----
-
-Pass through to `/build` with $ARGUMENTS. The Build command applies the `intent-routing` rule (loaded via the lisa plugin) and runs the full Implement → Review → Verify chain, which is what this command historically did.

package/plugins/lisa/commands/review/implementation.md

@@ -1,7 +0,0 @@
----
-description: "Compare project's Lisa-managed files against Lisa source templates and offer to upstream changes"
-allowed-tools: ["Skill"]
-argument-hint: "[lisa-dir]"
----
-
-Use the /lisa:lisa-review-implementation skill to compare project files against Lisa templates. $ARGUMENTS

package/plugins/lisa/commands/review.md

@@ -1,10 +0,0 @@
----
-description: "Review code changes. Runs quality, security, performance, product, and test reviews in parallel, then consolidates findings."
-argument-hint: "[pr-link-or-branch]"
----
-
-Apply the `intent-routing` rule (loaded via the lisa plugin) and execute the **Review** sub-flow.
-
-This sub-flow is also invoked automatically by the Implement flow. It runs `quality-specialist`, `security-specialist`, and `performance-specialist` in parallel, followed by `product-specialist` and `test-specialist`. Consolidates all findings ranked by severity.
-
-$ARGUMENTS