@codyswann/lisa 1.96.0 → 2.1.0

package/plugins/src/expo/skills/jira-add-journey/SKILL.md

@@ -121,6 +121,6 @@ The parser should now return the steps, viewports, and assertions from the newly
 ## When to Use This Skill
 
 - Ticket was created before the Validation Journey convention was established
-- Ticket was created manually without following `jira-create` guidelines
+- Ticket was created manually without following `lisa:jira-create` guidelines
 - Ticket needs a journey added or updated based on implementation progress
 - During sprint planning, to ensure all frontend tickets have journeys before work starts

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

@@ -6,13 +6,13 @@ allowed-tools: ["Read", "Glob", "LS", "Skill", "mcp__atlassian__getVisibleJiraPr
 
 # Create JIRA Issues from $ARGUMENTS
 
-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`.
+Analyze the provided file(s) and plan a JIRA hierarchy. **This skill plans structure only — every individual ticket write is delegated to `lisa: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. **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.
+2. **Extract source artifacts**: invoke the `lisa: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 `lisa: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
@@ -20,8 +20,8 @@ Analyze the provided file(s) and plan a JIRA hierarchy. **This skill plans struc
    ```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.
+6. **Delegate every write to `lisa: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 `lisa: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** (`lisa: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
 
@@ -34,7 +34,7 @@ Analyze the provided file(s) and plan a JIRA hierarchy. **This skill plans struc
 
 ## Validation Journey (Frontend Tickets)
 
-Every ticket that changes, adds, or fixes UI must include a `Validation Journey` section in the description. This section is consumed by the `jira-journey` skill to automate visual verification via Playwright.
+Every ticket that changes, adds, or fixes UI must include a `Validation Journey` section in the description. This section is consumed by the `lisa:jira-journey` skill to automate visual verification via Playwright.
 
 ### When to Include
 
@@ -95,15 +95,15 @@ h3. Assertions
 
 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.
 
-**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.
+**Invoke the `lisa: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.
 
 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.
 
-When delegating writes to `jira-write-ticket`, pass the extracted artifact list so its Phase 4c step can attach them.
+When delegating writes to `lisa:jira-write-ticket`, pass the extracted artifact list so its Phase 4c step can attach them.
 
 ## Live Product Walkthrough
 
-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.
+When the work touches existing user-facing surfaces, invoke the `lisa: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
 
@@ -118,9 +118,9 @@ Exclude unless requested: migration plans, performance tests
 
 ## 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.
+**Mandatory.** Every ticket created by this skill MUST go through `lisa: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:
+`lisa: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)
@@ -134,9 +134,9 @@ Exclude unless requested: migration plans, performance tests
 
 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.
+1. Invoke `lisa:jira-write-ticket` for the epic. Capture the returned key.
+2. For each story, invoke `lisa:jira-write-ticket` with the epic key as the epic parent. Capture each story key.
+3. For each sub-task, invoke `lisa:jira-write-ticket` with the parent story key.
 
 ### What to pass to each invocation
 
@@ -145,8 +145,8 @@ For every delegated write, pass:
 - 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.
+- The artifact list extracted in "Source Artifacts", filtered by domain per the inheritance rules — `lisa: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 `lisa:jira-add-journey` after create.
 
 ### What this skill is responsible for
 
@@ -158,4 +158,4 @@ This skill owns:
 - 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.
+It does not own the actual JIRA write — that's `lisa:jira-write-ticket`'s job.

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

@@ -6,22 +6,22 @@ allowed-tools: ["Skill", "mcp__atlassian__getJiraIssue", "mcp__atlassian__getAcc
 
 # Verify JIRA Ticket: $ARGUMENTS
 
-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.
+Verify that the existing JIRA ticket `$ARGUMENTS` meets organizational standards. This skill is a thin post-write wrapper around `lisa:jira-validate-ticket`: it fetches the live ticket and asks `lisa:jira-validate-ticket` to run the gates against the fetched state.
 
-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.
+This indirection exists so the gate definitions live in exactly one place (`lisa:jira-validate-ticket`). When the bar changes, change it there — `lisa:jira-verify`, `lisa:jira-write-ticket` (Phase 5.5 pre-write), and `lisa:notion-to-jira` (PRD dry-run) all pick it up.
 
 ## Process
 
 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.
+3. Invoke `lisa: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.
 
 ## Output
 
-Pass through `jira-validate-ticket`'s structured output unchanged. Downstream callers parse the gate lines.
+Pass through `lisa:jira-validate-ticket`'s structured output unchanged. Downstream callers parse the gate lines.
 
 ## Notes
 
 - 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.
+- For UI tickets that fail the Validation Journey gate, the validator's remediation will recommend `/lisa:jira-add-journey` — the Expo flavor of `lisa:jira-add-journey` produces the `[SCREENSHOT: ...]` + viewport block that the Playwright-based journey runner consumes.

package/plugins/{lisa-rails/commands/plan/fix-linter-error.md → src/rails/commands/fix/linter-error.md}

@@ -4,4 +4,4 @@ allowed-tools: ["Skill"]
 argument-hint: "<rule-1> [rule-2] [rule-3] ..."
 ---
 
-Use the /lisa-rails:plan-fix-linter-error skill to fix linter errors. $ARGUMENTS
+Use the /lisa-rails:fix-linter-error skill to fix linter errors. $ARGUMENTS

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

@@ -3,4 +3,4 @@ description: "Reduce the cognitive complexity threshold by 2 and fix all violati
 allowed-tools: ["Skill"]
 ---
 
-Use the /lisa-rails:plan-lower-code-complexity skill to lower code complexity.
+Use the /lisa-rails:improve-code-complexity skill to lower code complexity.

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

@@ -4,4 +4,4 @@ allowed-tools: ["Skill"]
 argument-hint: "<max-lines-per-function-value>"
 ---
 
-Use the /lisa-rails:plan-reduce-max-lines-per-function skill to reduce max function lines. $ARGUMENTS
+Use the /lisa-rails:improve-max-lines-per-function skill to reduce max function lines. $ARGUMENTS

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

@@ -4,4 +4,4 @@ allowed-tools: ["Skill"]
 argument-hint: "<max-lines-value>"
 ---
 
-Use the /lisa-rails:plan-reduce-max-lines skill to reduce max lines. $ARGUMENTS
+Use the /lisa-rails:improve-max-lines skill to reduce max lines. $ARGUMENTS

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

@@ -4,4 +4,4 @@ allowed-tools: ["Skill"]
 argument-hint: "<threshold-percentage>"
 ---
 
-Use the /lisa-rails:plan-add-test-coverage skill to increase test coverage. $ARGUMENTS
+Use the /lisa-rails:improve-test-coverage skill to increase test coverage. $ARGUMENTS

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

@@ -6,13 +6,13 @@ allowed-tools: ["Read", "Glob", "LS", "Skill", "mcp__atlassian__getVisibleJiraPr
 
 # Create JIRA Issues from $ARGUMENTS
 
-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`.
+Analyze the provided file(s) and plan a JIRA hierarchy. **This skill plans structure only — every individual ticket write is delegated to `lisa: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. **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.
+2. **Extract source artifacts**: invoke the `lisa: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 `lisa: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
@@ -20,8 +20,8 @@ Analyze the provided file(s) and plan a JIRA hierarchy. **This skill plans struc
    ```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.
+6. **Delegate every write to `lisa: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 `lisa: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** (`lisa: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
 
@@ -35,15 +35,15 @@ Analyze the provided file(s) and plan a JIRA hierarchy. **This skill plans struc
 
 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.
 
-**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.
+**Invoke the `lisa: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.
 
 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.
 
-When delegating writes to `jira-write-ticket`, pass the extracted artifact list so its Phase 4c step can attach them.
+When delegating writes to `lisa:jira-write-ticket`, pass the extracted artifact list so its Phase 4c step can attach them.
 
 ## Live Product Walkthrough
 
-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.
+When the work touches existing user-facing surfaces, invoke the `lisa: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
 
@@ -58,9 +58,9 @@ Exclude unless requested: migration plans, performance tests
 
 ## 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.
+**Mandatory.** Every ticket created by this skill MUST go through `lisa: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:
+`lisa: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)
@@ -74,9 +74,9 @@ Exclude unless requested: migration plans, performance tests
 
 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.
+1. Invoke `lisa:jira-write-ticket` for the epic. Capture the returned key.
+2. For each story, invoke `lisa:jira-write-ticket` with the epic key as the epic parent. Capture each story key.
+3. For each sub-task, invoke `lisa:jira-write-ticket` with the parent story key.
 
 ### What to pass to each invocation
 
@@ -85,8 +85,8 @@ For every delegated write, pass:
 - 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
+- The artifact list extracted in "Source Artifacts", filtered by domain per the inheritance rules — `lisa: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 `lisa:jira-add-journey` after create
 
 ### What this skill is responsible for
 
@@ -97,4 +97,4 @@ This skill owns:
 - 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.
+It does not own the actual JIRA write — that's `lisa:jira-write-ticket`'s job.

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

@@ -6,20 +6,20 @@ allowed-tools: ["Skill", "mcp__atlassian__getJiraIssue", "mcp__atlassian__getAcc
 
 # Verify JIRA Ticket: $ARGUMENTS
 
-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.
+Verify that the existing JIRA ticket `$ARGUMENTS` meets organizational standards. This skill is a thin post-write wrapper around `lisa:jira-validate-ticket`: it fetches the live ticket and asks `lisa:jira-validate-ticket` to run the gates against the fetched state.
 
-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.
+This indirection exists so the gate definitions live in exactly one place (`lisa:jira-validate-ticket`). When the bar changes, change it there — `lisa:jira-verify`, `lisa:jira-write-ticket` (Phase 5.5 pre-write), and `lisa:notion-to-jira` (PRD dry-run) all pick it up.
 
 ## Process
 
 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.
+3. Invoke `lisa: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.
 
 ## Output
 
-Pass through `jira-validate-ticket`'s structured output unchanged. Downstream callers parse the gate lines.
+Pass through `lisa:jira-validate-ticket`'s structured output unchanged. Downstream callers parse the gate lines.
 
 ## Notes
 

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/build-intake.md

@@ -1,7 +0,0 @@
----
-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/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/source-artifacts.md

@@ -1,6 +0,0 @@
----
-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/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/validate-ticket.md

@@ -1,7 +0,0 @@
----
-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/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/notion-prd-intake.md

@@ -1,7 +0,0 @@
----
-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/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/prd-ticket-coverage.md

@@ -1,7 +0,0 @@
----
-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/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

package/plugins/lisa/commands/ship.md

@@ -1,8 +0,0 @@
----
-description: "Ship current changes. Alias for /verify."
-argument-hint: "[commit-message-hint]"
----
-
-Apply the `intent-routing` rule (loaded via the lisa plugin) and execute the **Verify** flow.
-
-$ARGUMENTS

package/plugins/lisa/commands/spec-conformance.md

@@ -1,7 +0,0 @@
----
-description: "Verify shipped work matches its spec — coverage matrix with scope-creep detection and verdict"
-allowed-tools: ["Skill"]
-argument-hint: "[plan-file | TICKET-KEY | issue-url]"
----
-
-Use the /lisa:spec-conformance skill to compare shipped work against its spec and produce a coverage matrix with verdict. $ARGUMENTS