@codyswann/lisa 1.96.0 → 2.1.0

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

@@ -9,13 +9,13 @@ allowed-tools: ["Skill", "mcp__claude_ai_Notion__notion-fetch", "mcp__claude_ai_
 `$ARGUMENTS` is one of:
 
 1. A PRD URL alone — auto-discover created tickets via the PRD's epic remote link.
-2. A PRD URL plus an explicit list of ticket keys — `<PRD URL> tickets=[KEY-1,KEY-2,...]`. Use this when called from `notion-prd-intake` (which knows the keys it just created).
+2. A PRD URL plus an explicit list of ticket keys — `<PRD URL> tickets=[KEY-1,KEY-2,...]`. Use this when called from `lisa:notion-prd-intake` (which knows the keys it just created).
 
 Verify that every atomic item in the PRD is covered by at least one of the listed/discovered JIRA tickets. The output gates whether the PRD's `Status` should remain `Ticketed` or revert to `Blocked`.
 
 ## Why this exists
 
-Per-ticket gates (`jira-validate-ticket`) prove each created ticket is well-formed in isolation. They do NOT prove the *set* of created tickets is complete relative to the source PRD. Silent drops happen — an agent generates 8 tickets when the PRD called for 9, and nothing notices. This skill is the catch.
+Per-ticket gates (`lisa:jira-validate-ticket`) prove each created ticket is well-formed in isolation. They do NOT prove the *set* of created tickets is complete relative to the source PRD. Silent drops happen — an agent generates 8 tickets when the PRD called for 9, and nothing notices. This skill is the catch.
 
 ## Phases
 
@@ -27,7 +27,7 @@ Per-ticket gates (`jira-validate-ticket`) prove each created ticket is well-form
 2. Fetch the PRD via `notion-fetch` with `include_discussions: true`. Capture: title, body, child Epic pages, all comment threads.
 3. If the PRD has child Epic sub-pages (a multi-epic PRD like Home revamp), fetch each in parallel with `include_discussions: true`. The audit walks the full PRD tree.
 4. If `tickets=[...]` not provided, locate the JIRA epic by:
-   - Looking for a JIRA URL in the PRD body, comments, or the PRD's most recent "Ticketed by Claude" comment posted by `notion-prd-intake`.
+   - Looking for a JIRA URL in the PRD body, comments, or the PRD's most recent "Ticketed by Claude" comment posted by `lisa:notion-prd-intake`.
    - Searching JIRA via `searchJiraIssuesUsingJql` for an epic whose summary or description references the PRD title or page ID.
    - If no epic found, return verdict `NO_TICKETS_FOUND` with a clear remediation — coverage cannot be assessed without the ticket set.
 5. Once the epic is known, fetch all child stories and sub-tasks via JQL: `"Epic Link" = <EPIC-KEY>` and recursively for sub-tasks.
@@ -134,4 +134,4 @@ Atomic PRD items extracted: <n>
 - Never silently drop a PRD item from extraction. If an item is ambiguous about whether it's scope, include it in extraction with type `ambiguous` and let the matching phase resolve it. The point of the audit is to catch silent drops; the audit can't have its own.
 - Be explicit about confidence in matches — the matrix is for humans to skim; vague matches help no one. If a match is rule-3 ("scope inheritance"), say so.
 - Scope creep is INFORMATIONAL. It is normal for an agent to add infra tickets (`X.0 Setup`) the PRD doesn't explicitly enumerate. Only flag scope creep when the ticket genuinely doesn't trace to PRD content AND isn't standard scaffolding.
-- The `GAPS_FOUND` verdict is the gate. The caller (e.g. `notion-prd-intake`) uses it to decide whether to revert `Status` from `Ticketed` to `Blocked`.
+- The `GAPS_FOUND` verdict is the gate. The caller (e.g. `lisa:notion-prd-intake`) uses it to decide whether to revert `Status` from `Ticketed` to `Blocked`.

package/plugins/lisa/skills/product-walkthrough/SKILL.md

@@ -66,8 +66,8 @@ For every walkthrough, record:
 
 - **What exists today**: a short prose description of the current flow, the components in use (if you can identify them from the DOM via `browser_snapshot`), and the states observed.
 - **What the PRD changes**: explicit delta — added screens, removed screens, modified components, new states, removed states.
-- **Existing-component reuse candidates**: components in the current product that could absorb the new behavior. The PRD-vs-current-product comparison drives which existing components a developer should reuse instead of building new (see `jira-source-artifacts` §7).
-- **Design-vs-current-product divergence**: places where the mock/prototype materially diverges from what's shipped. Each divergence is a discussion item, not an automatic "rebuild from scratch" — see `jira-source-artifacts` §3 (mocks define visual intent, not implementation shortcut).
+- **Existing-component reuse candidates**: components in the current product that could absorb the new behavior. The PRD-vs-current-product comparison drives which existing components a developer should reuse instead of building new (see `lisa:jira-source-artifacts` §7).
+- **Design-vs-current-product divergence**: places where the mock/prototype materially diverges from what's shipped. Each divergence is a discussion item, not an automatic "rebuild from scratch" — see `lisa:jira-source-artifacts` §3 (mocks define visual intent, not implementation shortcut).
 - **Coverage smells**: states the PRD doesn't address that exist today (e.g., the mock shows the empty state but ignores the populated state that has 90% of users).
 - **Behavioral surprises**: anything that doesn't match the PRD's assumptions about current behavior — these are usually the most valuable findings, because they invalidate parts of the PRD.
 
@@ -85,7 +85,7 @@ Capture screenshots/snapshots in a way that the originating ticket / Notion comm
 
 ## Findings format
 
-Use this structure when emitting walkthrough findings, so consuming skills can splice them into tickets / comments unchanged. The `## Current Product` heading matches what `jira-write-ticket` Phase 4e expects to inherit — keep the heading exact.
+Use this structure when emitting walkthrough findings, so consuming skills can splice them into tickets / comments unchanged. The `## Current Product` heading matches what `lisa:jira-write-ticket` Phase 4e expects to inherit — keep the heading exact.
 
 ```text
 ## Current Product

package/plugins/lisa/skills/research/SKILL.md

@@ -0,0 +1,23 @@
+---
+name: research
+description: "Research a problem space and produce a PRD. Investigates the codebase, defines user flows, assesses technical feasibility, and outputs a specification ready to hand to the Plan flow. Vendor-agnostic — the resulting PRD lands wherever the configured destination is (Notion, Confluence, file, etc.)."
+allowed-tools: ["Skill", "Bash", "Read", "Glob", "Grep"]
+---
+
+# Research
+
+Produce a PRD for the problem in `$ARGUMENTS`.
+
+## Orchestration: agent team
+
+If you are NOT already operating inside an agent team (no prior `TeamCreate` in this session, not spawned via `Agent` with `team_name`), your FIRST tool call MUST be `TeamCreate`. Do not call `TaskCreate`, `Agent`, or implementation tools before the team exists.
+
+If you ARE already inside an agent team (e.g., a teammate invoked this skill via the Skill tool), do NOT call `TeamCreate` — the harness rejects double-creates. Continue within the existing team. The team lead created the team; teammates inherit it.
+
+## Flow
+
+Execute the **Research** flow as defined in the `intent-routing` rule (loaded via the lisa plugin). The rule contains the canonical step sequence (gates, sub-flows, deliverables). This skill does NOT restate flow steps — change them in the rule, propagate everywhere.
+
+## Output
+
+A PRD that includes (per the intent-routing rule's Research flow definition): context, problem statement, user flows, acceptance criteria, technical feasibility notes, and any open questions. The PRD lands in the configured destination (Notion database, Confluence space, local markdown file) per project config. The Plan flow consumes it next.

package/plugins/lisa/skills/{plan-local-code-review → review-local}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: plan-local-code-review
+name: review-local
 description: This skill should be used when performing a code review on local changes on the current branch compared to the main branch. It uses multiple parallel agents to check for bugs, CLAUDE.md compliance, git history context, previous PR comments, and code comment adherence, then scores and filters findings by confidence level.
 disable-model-invocation: false
 ---

package/plugins/lisa/skills/ticket-triage/SKILL.md

@@ -6,13 +6,13 @@ allowed-tools: ["Read", "Glob", "Grep", "Bash"]
 
 # Ticket Triage: $ARGUMENTS
 
-Perform analytical triage on the JIRA ticket. The caller MUST have run `jira-read-ticket` first and provided the resulting context bundle — which includes the primary ticket, all linked tickets (blocks / is blocked by / relates to / duplicates), epic parent, epic siblings, subtasks, and remote PR state. Do not triage from a bare ticket summary — if the bundle is missing link or epic context, stop and instruct the caller to run `/jira-read-ticket` first.
+Perform analytical triage on the JIRA ticket. The caller MUST have run `lisa:jira-read-ticket` first and provided the resulting context bundle — which includes the primary ticket, all linked tickets (blocks / is blocked by / relates to / duplicates), epic parent, epic siblings, subtasks, and remote PR state. Do not triage from a bare ticket summary — if the bundle is missing link or epic context, stop and instruct the caller to run `/lisa:jira-read-ticket` first.
 
 Repository name for scoped labels and comment headers: determine via `basename $(git rev-parse --show-toplevel)`.
 
 ## Phase 0 -- Pre-flight Description Gate
 
-Before any analytical work, confirm the ticket carries the content an implementer needs to start. The caller should already have run `jira-verify`; this phase consumes its output. If `jira-verify` returned `FAIL` for any of the following, emit `BLOCKED` immediately with the missing-requirements list and skip to Phase 6:
+Before any analytical work, confirm the ticket carries the content an implementer needs to start. The caller should already have run `lisa:jira-verify`; this phase consumes its output. If `lisa:jira-verify` returned `FAIL` for any of the following, emit `BLOCKED` immediately with the missing-requirements list and skip to Phase 6:
 
 - Epic parent missing (non-bug, non-epic)
 - Description quality failures (no Gherkin acceptance criteria, missing audience sections)
@@ -24,7 +24,7 @@ Before any analytical work, confirm the ticket carries the content an implemente
 
 The caller (jira-agent) is responsible for transitioning the ticket to `Blocked`, reassigning to the **Reporter**, and posting a comment listing the missing requirements. This skill only emits the verdict and the missing-requirements list.
 
-If `jira-verify` returned `PASS` for all the above, proceed to Phase 1.
+If `lisa:jira-verify` returned `PASS` for all the above, proceed to Phase 1.
 
 ## Phase 1 -- Relevance Check
 

package/plugins/lisa/skills/verify/SKILL.md

@@ -0,0 +1,32 @@
+---
+name: verify
+description: "Ship and verify code. Commits any pending changes, opens or updates the PR, handles the review loop, merges when green, monitors the deploy, and runs remote verification (health checks, Validation Journey replay, Sentry/log inspection) in the target environment. Folds in the legacy /ship alias."
+allowed-tools: ["Skill", "Bash", "Read", "Grep", "Glob"]
+---
+
+# Verify: $ARGUMENTS
+
+Ship the current branch and prove it works in the target environment.
+
+## Orchestration: agent team
+
+If you are NOT already operating inside an agent team (no prior `TeamCreate` in this session, not spawned via `Agent` with `team_name`), your FIRST tool call MUST be `TeamCreate`. Do not call `TaskCreate`, `Agent`, or implementation tools before the team exists.
+
+If you ARE already inside an agent team (e.g., a teammate invoked this skill via the Skill tool), do NOT call `TeamCreate` — the harness rejects double-creates. Continue within the existing team. The team lead created the team; teammates inherit it.
+
+## Flow
+
+Execute the **Verify** flow as defined in the `intent-routing` rule (loaded via the lisa plugin). The flow includes:
+
+1. **Commit** any pending changes via `lisa:git-commit`
+2. **Push and PR** via `lisa:git-submit-pr`
+3. **Review loop** — handle CodeRabbit / human review comments via `lisa:pull-request-review`
+4. **Merge** when CI is green
+5. **Remote verification** — invoke the `lisa:monitor` skill against the target environment to confirm the deploy actually works (health endpoints, recent logs/errors, Validation Journey replay if defined)
+6. **Evidence** — post results to the originating ticket via `lisa:jira-evidence` (or equivalent tracker adapter)
+
+The rule contains the canonical step sequence. Change it there, propagate everywhere.
+
+## Output
+
+A merged PR, a successful deploy to the target environment, and posted evidence on the originating work item.

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

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

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

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

package/plugins/lisa-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/lisa-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/lisa-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-nestjs/.claude-plugin/plugin.json

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

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "1.96.0",
+  "version": "2.1.0",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/{src/rails/commands/plan/fix-linter-error.md → lisa-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/{src/rails/commands/plan/lower-code-complexity.md → lisa-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/lisa-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/lisa-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/lisa-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/lisa-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/lisa-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/{src/rails/skills/plan-reduce-max-lines → lisa-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/{src/rails/skills/plan-reduce-max-lines-per-function → lisa-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/lisa-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/lisa-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/lisa-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-typescript/.claude-plugin/plugin.json

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

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

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

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

@@ -0,0 +1,6 @@
+---
+description: "Implement a single work item end-to-end. Vendor-agnostic: given a work-item URL/key (JIRA, Linear, GitHub Issues) or description, reads it, determines work type (Build/Fix/Improve/Investigate), assembles an agent team, runs the full lifecycle through PR + evidence. For batch processing of all Status=Ready tickets in a queue, use /lisa:intake instead."
+argument-hint: "<single-work-item-url | key | description>"
+---
+
+Use the /lisa:implement skill to take the work item from spec to shipped: read the source, determine work type, assemble an agent team, and run the full lifecycle through PR creation, code review, deploy, and empirical verification. $ARGUMENTS

package/plugins/{lisa/commands/plan/lower-code-complexity.md → src/base/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:plan-lower-code-complexity skill to lower code complexity.
+Use the /lisa:improve-code-complexity skill to lower code complexity.

package/plugins/src/base/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:plan-reduce-max-lines-per-function skill to reduce max function lines. $ARGUMENTS
+Use the /lisa:improve-max-lines-per-function skill to reduce max function lines. $ARGUMENTS

package/plugins/src/base/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:plan-reduce-max-lines skill to reduce max lines. $ARGUMENTS
+Use the /lisa:improve-max-lines skill to reduce max lines. $ARGUMENTS

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

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