@codyswann/lisa 2.0.0 → 2.1.1

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": "2.0.0",
+  "version": "2.1.1",
   "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": "2.0.0",
+  "version": "2.1.1",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/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/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/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/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/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/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": "2.0.0",
+  "version": "2.1.1",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 ---
-description: "Implement a work item end-to-end. Vendor-agnostic router: 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."
-argument-hint: "<work-item-url | key | description>"
+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 a work item from spec to shipped: read the source (whichever tracker it lives in), determine work type, assemble an agent team, and run the full lifecycle through PR creation, code review, deploy, and empirical verification. $ARGUMENTS
+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/src/base/commands/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/intake.md

@@ -0,0 +1,6 @@
+---
+description: "Vendor-agnostic batch scanner for Status=Ready queues. Notion PRD database URL → finds Ready PRDs and runs lisa:plan per item. JIRA project key or JQL → finds Ready tickets and runs lisa:implement per item. Designed as the cron target for /schedule."
+argument-hint: "<Notion-PRD-database-URL | JIRA-project-key | JQL-filter>"
+---
+
+Use the /lisa:intake skill to scan the queue for Status=Ready items and dispatch each one through the appropriate single-item lifecycle skill. $ARGUMENTS

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

@@ -1,10 +1,6 @@
 ---
-description: "Monitor application health. Checks health endpoints, logs, errors, and performance across environments."
+description: "Monitor application health across environments. Health endpoints, recent logs, error-rate spikes, performance, optional browser UAT. Routes to the stack-specific ops-specialist."
 argument-hint: "[environment]"
 ---
 
-Apply the `intent-routing` rule (loaded via the lisa plugin) and execute the **Monitor** sub-flow.
-
-This sub-flow is also invoked as part of the Verify flow's remote verification step. Delegates to `ops-specialist` for health checks, log inspection, error monitoring, and performance analysis.
-
-$ARGUMENTS
+Use the /lisa:monitor skill to check application health, logs, errors, and performance for the named environment. $ARGUMENTS

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

@@ -1,26 +1,6 @@
 ---
-description: "Plan work. Vendor-agnostic intake — given a PRD URL/path or description, extracts requirements, walks the live product, validates, and creates work items in the configured tracker."
-argument-hint: "<PRD-url | @file | ticket-id-or-url | description>"
+description: "Plan work from a single PRD or specification. Decomposes into ordered work items in the configured tracker. For batch scanning of all Status=Ready PRDs in a queue, use /lisa:intake instead."
+argument-hint: "<single-PRD-url | @file | ticket-id-or-url | description>"
 ---
 
-Apply the `intent-routing` rule (loaded via the lisa plugin) and execute the **Plan** flow.
-
-**Orchestration: agent team.** Plan is a multi-specialist flow feeding a shared decomposition. 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.
-
-## Source dispatch
-
-Detect the source type from `$ARGUMENTS` and route accordingly. The Plan flow is vendor-agnostic — the public interface speaks "PRD" and "work items", not "Notion" or "JIRA".
-
-| If `$ARGUMENTS` is... | Hand off to |
-|------------------------|-------------|
-| A Notion URL (`notion.so/...` or a Notion database/page ID) | The `notion-prd-intake` skill (single-PRD mode if one page; database-scan mode if a database URL). It runs the full pipeline: extract artifacts, walk live product, dry-run validate, create tickets in the configured tracker, run the coverage audit, transition Notion `Status`. |
-| A JIRA ticket ID or URL (e.g. `SE-123` or `*.atlassian.net/browse/SE-123`) | The `jira-agent`, which reads the ticket and extracts context. (Used when an existing JIRA epic *is* the spec — Plan decomposes it into stories/sub-tasks.) |
-| A Linear / GitHub Issues URL or key | *Not yet implemented.* Stop and tell the user the adapter doesn't exist yet — the architecture supports it, but no `linear-prd-intake` / `github-prd-intake` skill has been built. Don't fall back. |
-| A file path (`@plan.md`, `./spec.md`) | Read the file as the spec; run the Plan flow's core decomposition with the file content as input. |
-| A plain-text description | Use the description as the spec; run the Plan flow's core decomposition. |
-
-If no PRD or specification exists, suggest running the **Research** flow first to produce one.
-
-The underlying intake skills (e.g. `notion-prd-intake`) are internal — developers don't invoke them directly. They speak in vendor-agnostic terms (`/plan <PRD>`); the source/tracker choice is config.
-
-$ARGUMENTS
+Use the /lisa:plan skill to decompose the PRD/spec into ordered work items in the configured tracker. $ARGUMENTS

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

@@ -1,10 +1,6 @@
 ---
-description: "Research a problem space and produce a PRD. Investigates codebase, defines user flows, assesses technical feasibility."
+description: "Research a problem space and produce a PRD. Investigates the codebase, defines user flows, assesses technical feasibility, and outputs a specification ready for the Plan flow."
 argument-hint: "<problem-statement-or-feature-idea>"
 ---
 
-Apply the `intent-routing` rule (loaded via the lisa plugin) and execute the **Research** flow.
-
-**Orchestration: agent team.** Research is a multi-specialist flow feeding a shared PRD. 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.
-
-$ARGUMENTS
+Use the /lisa:research skill to research the problem and produce a PRD. $ARGUMENTS

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

@@ -1,10 +1,6 @@
 ---
-description: "Ship and verify code. Commits, opens PR, handles review loop, merges, deploys, and verifies in target environment."
+description: "Ship and verify code. Commits, opens PR, handles review loop, merges, monitors deploy, and runs remote verification in target environment. Folds in /ship."
 argument-hint: "[commit-message-hint]"
 ---
 
-Apply the `intent-routing` rule (loaded via the lisa plugin) and execute the **Verify** flow.
-
-This includes: atomic commits, PR creation, CI/review-fix loop, merge, deploy monitoring, and remote verification.
-
-$ARGUMENTS
+Use the /lisa:verify skill to commit, push, PR, merge, deploy, and verify in the target environment. $ARGUMENTS

package/plugins/src/base/rules/intent-routing.md

@@ -8,7 +8,7 @@ Each flow has a readiness gate that MUST pass before work begins. If the gate fa
 
 This protocol runs **once per session**, on the first user message. After that, every later message inherits the established flow — do not re-run classification.
 
-1. If the user invoked a slash command (`/fix`, `/build`, `/plan`, etc.), the flow is already determined -- skip classification.
+1. If the user invoked a slash command (`/lisa:research`, `/lisa:plan`, `/lisa:implement`, `/lisa:verify`, `/lisa:monitor`, `/lisa:intake`, etc.), the flow is already determined -- skip classification.
 2. Read the user's request and match it against the flow definitions below.
 3. If you cannot confidently classify the request:
    - **Interactive session** (user is present): present a multiple choice using AskUserQuestion with options: Research, Plan, Implement, Verify, No flow.
@@ -23,16 +23,20 @@ This protocol runs **once per session**, on the first user message. After that,
 
 ## Orchestration Selection Protocol
 
-Immediately after echoing the flow (and before any work begins), state the orchestration mode in the same message. The format is:
+Orchestration is owned by the **lifecycle skill** for the chosen flow, not by this rule. Each top-level lifecycle skill (`lisa:research`, `lisa:plan`, `lisa:implement`, `lisa:verify`, `lisa:monitor`, `lisa:intake`) contains its own cascade-safe orchestration preamble — that's where the team is created (or skipped, if already inside one).
 
-> **Orchestration: agent team** (or **single agent**)
-> One-sentence justification.
+What this rule still enforces:
 
-This echo is mandatory. The user must see the orchestration mode before any work begins. See the **Orchestration** section below for the full decision matrix and team-setup protocol.
+1. **Echo orchestration mode immediately after echoing the flow** (in the same message), so the user sees both before any work begins:
 
-Quick rule: Research, Plan, Implement (Build/Fix/Improve), and any flow invoking the Review sub-flow → **agent team**. Verify standalone, Monitor standalone, Investigate Only spikes → **single agent**. When in doubt, use a team.
+   > **Orchestration: agent team** (or **single agent**)
+   > One-sentence justification.
 
-If the mode is `agent team`, the first tool call after the echo MUST be `TeamCreate`. Do not call `TaskCreate`, `Agent`, or direct implementation tools before the team exists.
+2. **Cascade rule (load-bearing)**: Before calling `TeamCreate`, check whether you are already operating inside an agent team. Signs you are inside a team: a prior `TeamCreate` exists in this session; you were spawned via `Agent` with `team_name`; your context references a team lead. If any of these are true, **do NOT call `TeamCreate`** — the harness rejects double-creates and the work stalls. Continue within the existing team. Invoke flows via the Skill tool; the team lead inherits responsibility for orchestration.
+
+3. **Default mode**: All top-level lifecycle flows (`Research`, `Plan`, `Implement`, `Verify`, `Monitor`, `Intake`) run as agent teams. Single-agent mode is reserved for diagnostics that don't compose multiple specialists (`product-walkthrough` standalone, ad-hoc Investigate-Only spikes that explicitly opt out). When in doubt, use a team.
+
+The mechanical "first tool call MUST be TeamCreate" directive lives inside each lifecycle skill — see those skills' orchestration preambles for the exact wording.
 
 ## Readiness Gate Protocol
 
@@ -59,7 +63,6 @@ Gate:
 - If none is provided, ask: "What problem are you trying to solve or what capability are you trying to add?"
 
 Sequence:
-0. **Create agent team via `TeamCreate`** (see Orchestration section) -- Research is a multi-specialist flow; do this before any other work.
 1. **Investigate sub-flow** -- gather context from codebase, git history, existing behavior, and external sources
 2. `product-specialist` -- define user goals, user flows (Gherkin), acceptance criteria, error states, UX concerns, and out-of-scope items
 3. `architecture-specialist` -- assess technical feasibility, identify constraints, map existing system boundaries
@@ -80,7 +83,6 @@ Gate:
 - If the specification has unresolved ambiguities, stop and list them
 
 Sequence:
-0. **Create agent team via `TeamCreate`** (see Orchestration section) -- Plan is a multi-specialist flow feeding a shared decomposition; do this before any other work.
 1. **Investigate sub-flow** -- explore codebase for architecture, patterns, dependencies relevant to the spec
 2. `product-specialist` -- validate and refine acceptance criteria for the whole scope
 3. `architecture-specialist` -- map dependencies, identify cross-cutting concerns, determine execution order
@@ -110,7 +112,6 @@ Determine the work type and execute the matching variant:
 
 #### Build (features, stories, tasks)
 
-0. **Create agent team via `TeamCreate`** (see Orchestration section) -- Build runs a long sequence with parallel review; do this before any other work.
 1. **Investigate sub-flow** -- explore codebase for related code, patterns, dependencies
 2. `product-specialist` -- define acceptance criteria, user flows, error states
 3. `architecture-specialist` -- design approach, map files to modify, identify reusable code
@@ -124,7 +125,6 @@ Determine the work type and execute the matching variant:
 
 #### Fix (bugs)
 
-0. **Create agent team via `TeamCreate`** (see Orchestration section) -- Fix runs a long sequence with parallel review; do this before any other work.
 1. **Reproduce sub-flow** -- write failing test or script that demonstrates the bug (MANDATORY before any fix is attempted)
 2. **Investigate sub-flow** -- git history, root cause analysis
 3. `debug-specialist` -- prove root cause with evidence
@@ -139,7 +139,6 @@ Determine the work type and execute the matching variant:
 
 #### Improve (refactoring, optimization, coverage improvement)
 
-0. **Create agent team via `TeamCreate`** (see Orchestration section) -- Improve runs a long sequence with parallel review; do this before any other work.
 1. **Investigate sub-flow** -- understand current state, measure baseline
 2. `architecture-specialist` -- identify target, plan approach
 3. `test-specialist` -- ensure existing test coverage before refactoring (safety net)
@@ -274,7 +273,9 @@ Flows reference sub-flows by name. When a flow says "Investigate sub-flow", exec
 
 ## Orchestration
 
-How a flow dispatches its agents depends on the flow's shape. Pick the orchestration mode that matches the work — do not default to the heaviest one.
+> **Note**: Orchestration authority belongs to lifecycle skills (see `## Orchestration Selection Protocol` above). This section documents the patterns that lifecycle skills implement — it is reference material, not a directive for this rule to choose modes independently.
+
+Lifecycle skills dispatch their agents according to the flow's shape. The following patterns are how they do it — do not default to the heaviest one.
 
 ### Agent Teams (default for multi-step flows)
 

package/plugins/src/base/skills/implement/SKILL.md

@@ -3,17 +3,32 @@ name: implement
 description: This skill should be used for any non-trivial request — features, bugs, stories, epics, spikes, or multi-step tasks. It accepts a ticket URL (Jira, Linear, GitHub), a file path containing a spec, or a plain-text prompt. It assembles an agent team, breaks the work into structured tasks, and manages the full lifecycle from research through implementation, code review, deploy, and empirical verification.
 ---
 
+# Implement: $ARGUMENTS
 
-$ARGUMENTS is either a url to a ticket containing the request, a pointer to a file containing the request or the request in text format.
+## Orchestration: agent team
 
-If it's a ticket, use either the Jira CLI (if it's a jira ticket), the Linear CLI (if it's a linear ticket) or the Github CLI (if it's a github ticket) to read and fully understand the request, including any comments or meta data associated with the ticket.
+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 it's a file, read the entire file without offset or limit to understand the request.
+If you ARE already inside an agent team (e.g., a teammate invoked this skill via the Skill tool, or `lisa:intake` is running this skill per Ready ticket), do NOT call `TeamCreate` — the harness rejects double-creates. Continue within the existing team. The team lead created the team; teammates inherit it.
 
-Is this a simple request? Just execute it as usual and ignore the rest...
+When you do create the team, spawn every agent with `mode: "plan"` so they must submit their plan for team lead approval before making any file changes. Every team must include the Explore agent.
 
-Otherwise:
+## Resolve the input
 
+$ARGUMENTS is either a url to a ticket containing the request, a pointer to a file containing the request, or the request in text format.
+
+If it's a ticket, use the appropriate vendor adapter to read and fully understand the request:
+- JIRA ticket → `lisa:jira-read-ticket` (preferred) or the Jira CLI
+- Linear ticket → the Linear CLI (no `lisa:linear-*` adapter built yet)
+- GitHub ticket → the Github CLI
+
+Capture comments and metadata, not just the description.
+
+If it's a file, read the entire file without offset or limit.
+
+If this is a simple, self-contained request that requires no complex orchestration, execute it directly within the current team context and skip the agent roster and task planning below.
+
+## Select the agent roster
 
 Review all available agent types listed in the Task tool's `subagent_type` options. This includes built-in agents (like `Explore`, `general-purpose`), custom agents (from `.claude/agents/`), and plugin agents (from `.claude/settings.json` `enabledPlugins`). For each agent, explain in one sentence why it IS or IS NOT relevant to this task. Then select all agents that are relevant. You MUST justify excluding an agent — inclusion is the default.
 
@@ -22,12 +37,6 @@ When deciding the agents to use, consider:
 * Each task must be reviewed by the team to make sure their verification passes.
 * Each task must have their learnings reviewed by the learner subagent.
 
-NOTE: Every team must include the Explore agent
-
-Create an agent team composed of the selected agents. Spawn every agent with `mode: "plan"` so they must submit their plan for team lead approval before making any file changes.
-
-Use the TeamCreate tool to create the team before doing anything else.
-
 Using the general-purpose agent in Team Lead session, Determine the name of this plan
 
 Using the general-purpose agent in Team Lead session, Determine what branch to use: