@codyswann/lisa 2.0.0 → 2.1.1

package/plugins/lisa/skills/jira-write-ticket/SKILL.md

@@ -29,7 +29,7 @@ Required fields (stop and ask if missing — do not invent values):
 | Issue type | CREATE | Story, Task, Bug, Epic, Spike, Sub-task, Improvement |
 | Summary | CREATE, UPDATE | One line, imperative voice, under 100 chars |
 | Description | CREATE, UPDATE | Multi-section — see Phase 3 |
-| Epic parent | Non-bug, non-epic | Enforced by `jira-verify` |
+| Epic parent | Non-bug, non-epic | Enforced by `lisa:jira-verify` |
 | Priority | CREATE | Default to project default if unstated |
 | Acceptance criteria | Story, Task, Bug, Sub-task, Improvement | Gherkin — see Phase 3 |
 | Validation Journey | Runtime-behavior changes | Delegate to `/jira-add-journey` |
@@ -170,19 +170,19 @@ Identify and attach:
 - Confluence pages (design docs, RFCs, runbooks)
 - Dashboards (Grafana, Datadog, Sentry issue)
 - Incident tickets (PagerDuty, Statuspage)
-- **Source artifacts from the originating PRD / parent epic**: classify and inherit per the rules in `jira-source-artifacts` (invoke that skill if you haven't loaded the rules in this session). The short version: enumerate the parent epic's remote links and inherit the ones whose domain matches this ticket's scope (UI → `ui-design` + `ux-flow`; backend → `data`; infra → `ops`; always inherit `reference`). Never assume a developer will walk up to the epic to find design context — attach it here.
+- **Source artifacts from the originating PRD / parent epic**: classify and inherit per the rules in `lisa:jira-source-artifacts` (invoke that skill if you haven't loaded the rules in this session). The short version: enumerate the parent epic's remote links and inherit the ones whose domain matches this ticket's scope (UI → `ui-design` + `ux-flow`; backend → `data`; infra → `ops`; always inherit `reference`). Never assume a developer will walk up to the epic to find design context — attach it here.
 
-If the ticket was generated from a PRD (by `notion-to-jira` or similar) and the parent epic has no source artifacts, surface that as a smell and ask whether artifacts were missed during extraction before proceeding.
+If the ticket was generated from a PRD (by `lisa:notion-to-jira` or similar) and the parent epic has no source artifacts, surface that as a smell and ask whether artifacts were missed during extraction before proceeding.
 
 ### 4d. Source Precedence (must appear on the ticket)
 
-Source precedence rules and cross-axis conflict handling are defined in `jira-source-artifacts` §3 and §4. When a ticket carries both design artifacts and a description, record the precedence explicitly in the ticket description (under Technical Approach or a dedicated `## Source Precedence` subsection) so the implementer doesn't silently reconcile conflicts. Cross-axis conflicts go under `## Open Questions` as BLOCKER items.
+Source precedence rules and cross-axis conflict handling are defined in `lisa:jira-source-artifacts` §3 and §4. When a ticket carries both design artifacts and a description, record the precedence explicitly in the ticket description (under Technical Approach or a dedicated `## Source Precedence` subsection) so the implementer doesn't silently reconcile conflicts. Cross-axis conflicts go under `## Open Questions` as BLOCKER items.
 
-For UI-touching tickets, include the existing-component reuse expectation per `jira-source-artifacts` §7.
+For UI-touching tickets, include the existing-component reuse expectation per `lisa:jira-source-artifacts` §7.
 
 ### 4e. Live Product Walkthrough Findings (UI-touching tickets)
 
-If the ticket modifies an existing user-facing surface, a `product-walkthrough` should already have been run upstream (by `notion-to-jira` Phase 2b or `jira-create`). Inherit its findings under a `## Current Product` subsection in the ticket description so the implementer sees what's shipped today before changing it. If the upstream skill skipped the walkthrough but this ticket clearly modifies an existing surface, invoke `product-walkthrough` here before proceeding.
+If the ticket modifies an existing user-facing surface, a `lisa:product-walkthrough` should already have been run upstream (by `lisa:notion-to-jira` Phase 2b or `lisa:jira-create`). Inherit its findings under a `## Current Product` subsection in the ticket description so the implementer sees what's shipped today before changing it. If the upstream skill skipped the walkthrough but this ticket clearly modifies an existing surface, invoke `lisa:product-walkthrough` here before proceeding.
 
 Use Jira's web UI or `mcp__atlassian__editJiraIssue` to set the `Development` field / remote links where supported.
 
@@ -200,9 +200,9 @@ Before create/update, verify each field is populated where applicable:
 
 ## Phase 5.5 — Validate (Pre-write Gate)
 
-Before any write, invoke `jira-validate-ticket` with the full proposed spec assembled from Phases 2 / 3 / 4 / 5. Pass it as a YAML block per the `jira-validate-ticket` schema, including `runtime_behavior_change`, `authenticated_surface`, and `artifacts_attached` flags so the right gates run.
+Before any write, invoke `lisa:jira-validate-ticket` with the full proposed spec assembled from Phases 2 / 3 / 4 / 5. Pass it as a YAML block per the `lisa:jira-validate-ticket` schema, including `runtime_behavior_change`, `authenticated_surface`, and `artifacts_attached` flags so the right gates run.
 
-The validator is the **single source of truth** for what makes a valid ticket. The same gates are used by `notion-to-jira` dry-run, by `jira-verify` post-write, and here. Do not re-implement gate logic in this skill — if a gate needs to change, change `jira-validate-ticket` so every caller benefits.
+The validator is the **single source of truth** for what makes a valid ticket. The same gates are used by `lisa:notion-to-jira` dry-run, by `lisa:jira-verify` post-write, and here. Do not re-implement gate logic in this skill — if a gate needs to change, change `lisa:jira-validate-ticket` so every caller benefits.
 
 If the validator reports `FAIL`:
 - Surface the failure list and the per-gate remediation to the user.
@@ -219,7 +219,7 @@ If the validator reports `PASS`, continue to Phase 6.
 2. Capture the returned ticket key.
 3. For each relationship from Phase 4b, call `mcp__atlassian__createIssueLink` with the correct link type (verify names via `mcp__atlassian__getIssueLinkTypes` if unsure).
 4. Attach remote links from Phase 4c.
-5. If the ticket changes runtime behavior, invoke the `jira-add-journey` skill to append the Validation Journey section.
+5. If the ticket changes runtime behavior, invoke the `lisa:jira-add-journey` skill to append the Validation Journey section.
 
 ### UPDATE
 
@@ -229,7 +229,7 @@ If the validator reports `PASS`, continue to Phase 6.
 
 ## Phase 7 — Verify
 
-Call the `jira-verify` skill on the resulting ticket. `jira-verify` fetches the live ticket and runs `jira-validate-ticket` against it — same gates as Phase 5.5, but applied to what JIRA actually stored (catches anything dropped or reformatted on write). If it reports failures, fix them before returning. Do not report success on a ticket that fails verify.
+Call the `lisa:jira-verify` skill on the resulting ticket. `lisa:jira-verify` fetches the live ticket and runs `lisa:jira-validate-ticket` against it — same gates as Phase 5.5, but applied to what JIRA actually stored (catches anything dropped or reformatted on write). If it reports failures, fix them before returning. Do not report success on a ticket that fails verify.
 
 ## Phase 8 — Announce
 
@@ -249,5 +249,5 @@ Skip this step only on UPDATE when no material change was made.
 - Never include a runtime-behavior ticket without a target backend environment, and never include an authenticated-surface ticket without sign-in credentials in the description.
 - Never invent custom field values. If the project requires a field you don't have, stop and ask.
 - Never overwrite a description without reading the current version first.
-- All writes go through this skill so best practices are enforced uniformly. Downstream skills (e.g. `jira-create`) should delegate here rather than calling the MCP write tools directly.
-- The gate logic (what makes a valid ticket) lives in `jira-validate-ticket`, NOT in this skill. This skill calls the validator at Phase 5.5 (pre-write) and Phase 7 (via `jira-verify` post-write). When a gate needs to change, change it in `jira-validate-ticket` — every caller (write path, dry-run path, post-write verify) picks it up automatically.
+- All writes go through this skill so best practices are enforced uniformly. Downstream skills (e.g. `lisa:jira-create`) should delegate here rather than calling the MCP write tools directly.
+- The gate logic (what makes a valid ticket) lives in `lisa:jira-validate-ticket`, NOT in this skill. This skill calls the validator at Phase 5.5 (pre-write) and Phase 7 (via `lisa:jira-verify` post-write). When a gate needs to change, change it in `lisa:jira-validate-ticket` — every caller (write path, dry-run path, post-write verify) picks it up automatically.

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

@@ -0,0 +1,33 @@
+---
+name: monitor
+description: "Monitor application health across environments. Checks health endpoints, recent logs (CloudWatch / Sentry / browser console), error-rate spikes, performance hotspots, pending migrations, and runs Playwright smoke flows when relevant. Routes to the stack-specific ops-specialist agent (Expo, Rails, etc.). Also invoked as the post-deploy step of the lisa:verify skill."
+allowed-tools: ["Skill", "Bash", "Read", "Grep"]
+---
+
+# Monitor: $ARGUMENTS
+
+Spot-check application health in the named environment (`dev` / `staging` / `prod`). Useful both reactively (after a deploy, after a Sentry alert, before pushing a hot change) and as the post-deploy verification step inside `lisa:verify`.
+
+## 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 **Monitor** sub-flow as defined in the `intent-routing` rule (loaded via the lisa plugin). The Monitor sub-flow delegates to a stack-specific `ops-specialist` agent (Expo, Rails, etc.), which composes the underlying ops skills:
+
+- `ops-verify-health` — health endpoints
+- `ops-check-logs` — CloudWatch / browser console / device / Serverless logs
+- `ops-monitor-errors` — Sentry issues, error-rate spikes, regressions
+- `ops-performance` — slow queries, p99 latency, hotspots
+- `ops-browser-uat` — Playwright smoke flows against the deployed env
+- `ops-db-ops` — pending migrations, replication lag
+- `ops-deploy` — deploy status / rollback readiness
+
+The agent decides which subset to run based on the env, the situation, and any extra context provided. The rule contains the canonical decision logic.
+
+## Output
+
+A health summary with the relevant findings (failures, warnings, no-issue confirmations). For post-deploy verification (when called from `lisa:verify`), the summary becomes evidence on the originating work item.

package/plugins/lisa/skills/notion-prd-intake/SKILL.md

@@ -55,19 +55,19 @@ If the update fails (permission error, race), log it and skip this PRD. Do not p
 
 #### 3b. Dry-run validation
 
-Invoke the `notion-to-jira` skill with `dry_run: true` and the PRD's URL. The skill returns a structured report containing:
+Invoke the `lisa:notion-to-jira` skill with `dry_run: true` and the PRD's URL. The skill returns a structured report containing:
 - The planned ticket hierarchy
 - Per-ticket validation verdicts and remediation
 - An overall PASS / FAIL verdict
 - A failure count
 
-This call also indirectly invokes `jira-source-artifacts` (artifact extraction + classification) and `product-walkthrough` (when the PRD touches existing user-facing surfaces). All gate logic lives in `jira-validate-ticket`, which `notion-to-jira` calls per ticket.
+This call also indirectly invokes `lisa:jira-source-artifacts` (artifact extraction + classification) and `lisa:product-walkthrough` (when the PRD touches existing user-facing surfaces). All gate logic lives in `lisa:jira-validate-ticket`, which `lisa:notion-to-jira` calls per ticket.
 
 #### 3c. Branch on the verdict
 
 **If `PASS`** (every planned ticket passed every applicable gate):
 
-1. Re-invoke `notion-to-jira` with `dry_run: false` to actually write the tickets. This re-runs Phases 1-5 and runs the preservation gate (Phase 5.5).
+1. Re-invoke `lisa:notion-to-jira` with `dry_run: false` to actually write the tickets. This re-runs Phases 1-5 and runs the preservation gate (Phase 5.5).
 2. Capture the created ticket keys from the skill's output.
 3. Post a Notion comment on the PRD via `mcp__claude_ai_Notion__notion-create-comment` listing the created tickets (epic, stories, sub-tasks) with their JIRA URLs. Lead with: `"Ticketed by Claude. Created N JIRA issues — see below. Move Status to Shipped after the work is delivered."`
 4. Set `Status = Ticketed` via `notion-update-page`.
@@ -75,9 +75,9 @@ This call also indirectly invokes `jira-source-artifacts` (artifact extraction +
 
 #### 3e. Coverage audit (mandatory after Ticketed)
 
-Per-ticket gates prove each ticket is well-formed; they do NOT prove the *set* of created tickets covers the *whole* PRD. Silent drops happen — invoke the `prd-ticket-coverage` skill to catch them.
+Per-ticket gates prove each ticket is well-formed; they do NOT prove the *set* of created tickets covers the *whole* PRD. Silent drops happen — invoke the `lisa:prd-ticket-coverage` skill to catch them.
 
-1. Invoke `prd-ticket-coverage` with `<PRD URL> tickets=[<created ticket keys from step 2 above>]`.
+1. Invoke `lisa:prd-ticket-coverage` with `<PRD URL> tickets=[<created ticket keys from step 2 above>]`.
 2. Read the verdict:
 
    | Verdict | Action |
@@ -87,7 +87,7 @@ Per-ticket gates prove each ticket is well-formed; they do NOT prove the *set* o
    | `GAPS_FOUND` | The created ticket set is incomplete. (a) For each gap, post a Notion comment naming the missing PRD item and where it appears in the PRD, with the suggested fix from the audit report. (b) Post one summary comment listing the tickets that *were* successfully created (so product knows what to keep vs. what to extend). (c) Transition `Status` from `Ticketed` back to `Blocked` via `notion-update-page`. |
    | `NO_TICKETS_FOUND` | Should not happen if step 2 succeeded. If it does, log it as an Error in the cycle summary and leave `Status = Ticketed` with a comment flagging the audit failure for human review. |
 
-3. The created tickets remain in JIRA regardless of the verdict — they are valid in their own right (they passed `jira-validate-ticket`). The audit only tells us whether *more* are needed.
+3. The created tickets remain in JIRA regardless of the verdict — they are valid in their own right (they passed `lisa:jira-validate-ticket`). The audit only tells us whether *more* are needed.
 
 The audit's report should be summarized in the cycle summary alongside the per-PRD outcome (e.g., `Ticketed (coverage: COMPLETE)` or `Blocked (coverage gaps: 3)`).
 
@@ -144,7 +144,7 @@ Print to the agent's output. Do not write this summary to Notion or JIRA — it'
 ## Idempotency & safety
 
 - **Single-cycle scope**: this skill processes the Ready set as it exists at the start of Phase 2. New `Ready` PRDs added mid-cycle are picked up next run.
-- **No writes outside the lifecycle**: this skill only ever writes to JIRA via `notion-to-jira` (which delegates to `jira-write-ticket`), and only ever changes Notion `Status` to `In Review`, `Blocked`, or `Ticketed`. It never edits PRD content, never touches `Draft` or `Shipped`, never deletes pages.
+- **No writes outside the lifecycle**: this skill only ever writes to JIRA via `lisa:notion-to-jira` (which delegates to `lisa:jira-write-ticket`), and only ever changes Notion `Status` to `In Review`, `Blocked`, or `Ticketed`. It never edits PRD content, never touches `Draft` or `Shipped`, never deletes pages.
 - **Claim-first ordering**: `Status = In Review` is set BEFORE validation runs, so a re-entrant call won't double-process.
 - **Failure isolation**: an exception processing one PRD must not stop the cycle. Catch, record under "Errors" in the summary, continue to the next PRD. The PRD that errored is left in `In Review` — the human investigates from there.
 
@@ -154,16 +154,16 @@ This skill reads project configuration from environment variables (or `$ARGUMENT
 
 | Variable | Purpose |
 |----------|---------|
-| `JIRA_PROJECT` | JIRA project key for ticket creation (passed to `notion-to-jira`) |
+| `JIRA_PROJECT` | JIRA project key for ticket creation (passed to `lisa:notion-to-jira`) |
 | `JIRA_SERVER` | Atlassian instance host |
-| `E2E_BASE_URL` | Frontend URL for `product-walkthrough` |
+| `E2E_BASE_URL` | Frontend URL for `lisa:product-walkthrough` |
 | `E2E_TEST_PHONE` / `E2E_TEST_OTP` / `E2E_TEST_ORG` | Test user creds for walkthrough + verification plans |
 | `E2E_GRAPHQL_URL` | API URL for verification plans |
 
 ## Rules
 
-- Never write to JIRA outside of `notion-to-jira` → `jira-write-ticket`. The validator's verdict gates progress; bypassing it produces broken tickets.
+- Never write to JIRA outside of `lisa:notion-to-jira` → `lisa:jira-write-ticket`. The validator's verdict gates progress; bypassing it produces broken tickets.
 - Never set Notion `Status` to a value this skill doesn't own (`In Review`, `Blocked`, `Ticketed`). Product owns `Draft`, `Ready`, `Shipped`.
 - Never edit the PRD's body. Communication with product happens only through Notion comments.
 - Never run more than one intake cycle concurrently against the same database. This skill assumes serial execution. (Scheduling is a separate concern; the runtime should not start a new cycle if a previous one is still in flight.)
-- If `notion-to-jira` returns errors (e.g. unreachable artifact, malformed PRD structure), treat them as gate failures: comment + Blocked. Don't silently fail.
+- If `lisa:notion-to-jira` returns errors (e.g. unreachable artifact, malformed PRD structure), treat them as gate failures: comment + Blocked. Don't silently fail.

package/plugins/lisa/skills/notion-to-jira/SKILL.md

@@ -18,8 +18,8 @@ Each sub-task is scoped to exactly one repo and includes an empirical verificati
 
 This skill supports two modes, controlled by a `dry_run` flag in `$ARGUMENTS`:
 
-- **`dry_run: false`** (default — full mode): run all phases, write tickets via `jira-write-ticket`, run the preservation gate, report.
-- **`dry_run: true`** (planning + validation only — no writes): run Phases 1, 1.5, 1.6, 2, 3, 4 to plan the hierarchy and draft each ticket spec, then call `jira-validate-ticket` (with `--spec-only`) on every drafted ticket. Aggregate the per-ticket validator reports into a single dry-run report. **Skip Phase 5 (sub-task creation), Phase 5.5 (preservation gate), and Phase 6 (results report)** — none of those make sense without writes. Return the dry-run report so the caller (e.g. `notion-prd-intake`) can decide whether to proceed.
+- **`dry_run: false`** (default — full mode): run all phases, write tickets via `lisa:jira-write-ticket`, run the preservation gate, report.
+- **`dry_run: true`** (planning + validation only — no writes): run Phases 1, 1.5, 1.6, 2, 3, 4 to plan the hierarchy and draft each ticket spec, then call `lisa:jira-validate-ticket` (with `--spec-only`) on every drafted ticket. Aggregate the per-ticket validator reports into a single dry-run report. **Skip Phase 5 (sub-task creation), Phase 5.5 (preservation gate), and Phase 6 (results report)** — none of those make sense without writes. Return the dry-run report so the caller (e.g. `lisa:notion-prd-intake`) can decide whether to proceed.
 
 Dry-run output format:
 
@@ -43,11 +43,11 @@ Dry-run output format:
 
 The dry-run mode never writes to JIRA and never calls `mcp__atlassian__createJiraIssue`. It also never sets a Notion status — that is the orchestrating skill's responsibility.
 
-## Hard Rule: All Writes Go Through `jira-write-ticket`
+## Hard Rule: All Writes Go Through `lisa:jira-write-ticket`
 
-**Every JIRA ticket created by this skill — every epic, story, and sub-task — MUST be created by invoking the `jira-write-ticket` skill. Never call `mcp__atlassian__createJiraIssue`, `mcp__atlassian__editJiraIssue`, `mcp__atlassian__createIssueLink`, or any other Atlassian write tool directly from this skill or from any sub-agent it spawns.**
+**Every JIRA ticket created by this skill — every epic, story, and sub-task — MUST be created by invoking the `lisa:jira-write-ticket` skill. Never call `mcp__atlassian__createJiraIssue`, `mcp__atlassian__editJiraIssue`, `mcp__atlassian__createIssueLink`, or any other Atlassian write tool directly from this skill or from any sub-agent it spawns.**
 
-`jira-write-ticket` enforces gates this skill does not:
+`lisa:jira-write-ticket` enforces gates this skill does not:
 - 3-audience description (Context / Technical Approach / Acceptance Criteria)
 - Gherkin acceptance criteria
 - Epic parent validation
@@ -56,7 +56,7 @@ The dry-run mode never writes to JIRA and never calls `mcp__atlassian__createJir
 - Sign-in account and target environment recorded in description
 - Post-create verification
 
-Bypassing `jira-write-ticket` produces thin tickets that the rest of the lifecycle (triage, ticket-verify, journey, evidence) treats as broken. This is the most common failure mode this skill has had — calling `createJiraIssue` directly is a regression, not an optimization. The Atlassian read tools (`getJiraIssue`, `searchJiraIssuesUsingJql`, `getJiraIssueRemoteIssueLinks`, `getAccessibleAtlassianResources`, `getJiraProjectIssueTypesMetadata`, `getVisibleJiraProjects`) ARE allowed for context gathering and the Phase 5.5 preservation gate.
+Bypassing `lisa:jira-write-ticket` produces thin tickets that the rest of the lifecycle (triage, ticket-verify, journey, evidence) treats as broken. This is the most common failure mode this skill has had — calling `createJiraIssue` directly is a regression, not an optimization. The Atlassian read tools (`getJiraIssue`, `searchJiraIssuesUsingJql`, `getJiraIssueRemoteIssueLinks`, `getAccessibleAtlassianResources`, `getJiraProjectIssueTypesMetadata`, `getVisibleJiraProjects`) ARE allowed for context gathering and the Phase 5.5 preservation gate.
 
 ## Input
 
@@ -111,17 +111,17 @@ PRDs typically reference external design, UX, and data artifacts (Figma files, L
    - Embedded images and file attachments on the page itself
    - Fenced code blocks with example data (JSON, SQL, GraphQL, cURL request/response)
 
-2. **Classify each artifact and apply taxonomy rules** by invoking the `jira-source-artifacts` skill. That skill is the single source of truth for: domains (`ui-design` / `ux-flow` / `data` / `ops` / `reference`), per-tool classification rules (Figma `/proto/` vs design, Lovable as `ux-flow`, Loom, screenshots), and coverage smells. Do not restate the rules here — invoke the skill so any drift in the rules propagates uniformly.
+2. **Classify each artifact and apply taxonomy rules** by invoking the `lisa:jira-source-artifacts` skill. That skill is the single source of truth for: domains (`ui-design` / `ux-flow` / `data` / `ops` / `reference`), per-tool classification rules (Figma `/proto/` vs design, Lovable as `ux-flow`, Loom, screenshots), and coverage smells. Do not restate the rules here — invoke the skill so any drift in the rules propagates uniformly.
 
 3. **Build an `artifacts` map** keyed by domain. Each entry: `{ url, title, domain, source_page, source_page_url, classification_reason }`. The `classification_reason` makes disambiguation auditable ("Figma URL contains `/proto/` → ux-flow"). The `source_page` lets you trace each reference back to where it appeared in the PRD.
 
-4. **Surface coverage smells** as defined in `jira-source-artifacts` §5 (zero artifacts, prototype-without-mock, mock-without-prototype, Lovable-without-business-rules). Record any detected smells on the epic.
+4. **Surface coverage smells** as defined in `lisa:jira-source-artifacts` §5 (zero artifacts, prototype-without-mock, mock-without-prototype, Lovable-without-business-rules). Record any detected smells on the epic.
 
 ### Phase 1.6: Source Precedence & Conflict Resolution
 
-Source precedence rules and cross-axis conflict handling are defined in `jira-source-artifacts` §3 and §4. Apply them during ticket synthesis: every conflict between artifacts must be recorded under `## Open Questions` on the affected ticket, never silently reconciled.
+Source precedence rules and cross-axis conflict handling are defined in `lisa:jira-source-artifacts` §3 and §4. Apply them during ticket synthesis: every conflict between artifacts must be recorded under `## Open Questions` on the affected ticket, never silently reconciled.
 
-The existing-component reuse expectation (mocks define visual intent, not implementation shortcut) is defined in `jira-source-artifacts` §7. Encode it on every UI-touching story.
+The existing-component reuse expectation (mocks define visual intent, not implementation shortcut) is defined in `lisa:jira-source-artifacts` §7. Encode it on every UI-touching story.
 
 ### Phase 2: Codebase + Live Product Research
 
@@ -135,7 +135,7 @@ Key things to look for:
 - Data model gaps the PRD requires (new fields, new entities)
 - The tech stack per repo (framework, ORM, UI library, deployment)
 
-**2b. Live product walkthrough.** If the PRD touches existing user-facing surfaces (modifies a screen, adds something next to existing functionality, fixes current behavior, re-styles an existing flow), invoke the `product-walkthrough` skill against `E2E_BASE_URL` using the test user from config. This grounds the ticket plan in what's actually shipped — design-vs-current-product divergence, reuse candidates, and behavioral surprises that the PRD didn't anticipate become inputs to ticket creation rather than discoveries during implementation.
+**2b. Live product walkthrough.** If the PRD touches existing user-facing surfaces (modifies a screen, adds something next to existing functionality, fixes current behavior, re-styles an existing flow), invoke the `lisa:product-walkthrough` skill against `E2E_BASE_URL` using the test user from config. This grounds the ticket plan in what's actually shipped — design-vs-current-product divergence, reuse candidates, and behavioral surprises that the PRD didn't anticipate become inputs to ticket creation rather than discoveries during implementation.
 
 Skip 2b only when the work is purely backend with no user-visible surface, or affects a screen that does not yet exist in dev/prod.
 
@@ -143,9 +143,9 @@ Walkthrough findings are attached to the originating Notion PRD as a comment ("C
 
 ### Phase 3: Create Epics
 
-> **Mode guard**: In `dry_run: true` mode, do not invoke `jira-write-ticket` in this phase. Instead, draft the epic spec (summary, description_body, artifacts) and validate it with `jira-validate-ticket --spec-only`. Record the drafted spec (including a placeholder epic key like `DRY-RUN-EPIC-1`) for Phase 4 to use as parent references. In `dry_run: false` mode (default), proceed as described below.
+> **Mode guard**: In `dry_run: true` mode, do not invoke `lisa:jira-write-ticket` in this phase. Instead, draft the epic spec (summary, description_body, artifacts) and validate it with `lisa:jira-validate-ticket --spec-only`. Record the drafted spec (including a placeholder epic key like `DRY-RUN-EPIC-1`) for Phase 4 to use as parent references. In `dry_run: false` mode (default), proceed as described below.
 
-For each PRD epic, **invoke the `jira-write-ticket` skill** (do not call `createJiraIssue` directly). Pass it everything it needs to enforce its quality gates:
+For each PRD epic, **invoke the `lisa:jira-write-ticket` skill** (do not call `createJiraIssue` directly). Pass it everything it needs to enforce its quality gates:
 
 - `project_key`: from `JIRA_PROJECT` config
 - `issue_type`: `Epic`
@@ -158,14 +158,14 @@ For each PRD epic, **invoke the `jira-write-ticket` skill** (do not call `create
   - Blockers and open questions
   - Dependencies on other epics or PRDs
   - A **Source Artifacts** section listing every artifact extracted in Phase 1.5 (grouped by domain)
-- `artifacts`: the full Phase 1.5 artifact list — every artifact, regardless of domain. The epic is the canonical hub, and anyone working on the epic or its descendants must be able to reach the full set from one place. No filtering at the epic level. `jira-write-ticket` Phase 4c attaches them as remote links.
+- `artifacts`: the full Phase 1.5 artifact list — every artifact, regardless of domain. The epic is the canonical hub, and anyone working on the epic or its descendants must be able to reach the full set from one place. No filtering at the epic level. `lisa:jira-write-ticket` Phase 4c attaches them as remote links.
 - `priority`, `labels`, `components`, `fix_version`: as appropriate
 
 Capture the returned epic key — Phase 4 needs it as the parent for stories.
 
 ### Phase 4: Create Stories
 
-> **Mode guard**: In `dry_run: true` mode, do not invoke `jira-write-ticket` in this phase. Instead, draft each story spec and validate it with `jira-validate-ticket --spec-only`. Use placeholder keys (e.g. `DRY-RUN-STORY-1.1`) for any downstream references. In `dry_run: false` mode (default), proceed as described below.
+> **Mode guard**: In `dry_run: true` mode, do not invoke `lisa:jira-write-ticket` in this phase. Instead, draft each story spec and validate it with `lisa:jira-validate-ticket --spec-only`. Use placeholder keys (e.g. `DRY-RUN-STORY-1.1`) for any downstream references. In `dry_run: false` mode (default), proceed as described below.
 
 For each Epic, plan two kinds of stories:
 - **One "X.0 Setup" story** for data model and infrastructure prerequisites (new entities, migrations, new fields, infrastructure like S3 buckets or SQS queues)
@@ -176,24 +176,24 @@ For each Epic, plan two kinds of stories:
 - "Squad Planning" -> `[SP-1.1]`
 - Use your judgment for other PRDs
 
-For each story, **invoke `jira-write-ticket`** with:
+For each story, **invoke `lisa:jira-write-ticket`** with:
 
 - `project_key`: from `JIRA_PROJECT` config
 - `issue_type`: `Story`
-- `epic_parent`: the Epic key captured in Phase 3 (mandatory — `jira-write-ticket` rejects non-bug, non-epic tickets without an epic parent)
+- `epic_parent`: the Epic key captured in Phase 3 (mandatory — `lisa:jira-write-ticket` rejects non-bug, non-epic tickets without an epic parent)
 - `summary`: prefixed per the naming convention above
 - `description_body`: a draft of the 3-audience description containing:
   - **Context / Business Value**: the user story statement from the PRD
   - **Technical Approach**: notes from engineering comments and Phase 2 codebase research
-  - **Acceptance Criteria** (Gherkin) derived from the functional requirements — `jira-write-ticket` will reject prose-only acceptance criteria
+  - **Acceptance Criteria** (Gherkin) derived from the functional requirements — `lisa:jira-write-ticket` will reject prose-only acceptance criteria
   - Blockers with recommendation + alternatives (if any), under `## Open Questions`
   - A **Source Artifacts** section listing the artifacts inherited from the epic that match this story's scope (see propagation rules below)
-- `artifacts`: the Phase 1.5 artifacts filtered by domain per the inheritance table below — `jira-write-ticket` Phase 4c attaches them as remote links
+- `artifacts`: the Phase 1.5 artifacts filtered by domain per the inheritance table below — `lisa:jira-write-ticket` Phase 4c attaches them as remote links
 - `priority`, `labels`, `components`, `fix_version`: as appropriate
 
 Capture each returned story key — Phase 5 needs it as the parent for sub-tasks.
 
-**Inherit domain-matching artifacts as story remote links**. For each story, the artifact set passed to `jira-write-ticket` should be the Phase 1.5 artifacts whose domain matches the story's scope:
+**Inherit domain-matching artifacts as story remote links**. For each story, the artifact set passed to `lisa:jira-write-ticket` should be the Phase 1.5 artifacts whose domain matches the story's scope:
 
 | Story type | Inherits domains |
 |------------|------------------|
@@ -206,10 +206,10 @@ When classification is ambiguous, err on the side of inclusion — a developer c
 
 ### Phase 5: Create Sub-tasks
 
-Delegate sub-task creation to **parallel agents** (one per epic or batch of stories) for efficiency. **Every spawned agent must invoke `jira-write-ticket` for each sub-task — no agent may call `createJiraIssue` directly.** This is non-negotiable; see the Agent Prompt Template at the bottom of this skill for the exact instructions to pass.
+Delegate sub-task creation to **parallel agents** (one per epic or batch of stories) for efficiency. **Every spawned agent must invoke `lisa:jira-write-ticket` for each sub-task — no agent may call `createJiraIssue` directly.** This is non-negotiable; see the Agent Prompt Template at the bottom of this skill for the exact instructions to pass.
 
 Each sub-task MUST:
-1. **Be scoped to exactly ONE repo** — indicated in brackets in the summary: `[repo-name]`. `jira-write-ticket` enforces single-repo scope on Sub-task; cross-repo sub-tasks will be rejected and must be split before delegation.
+1. **Be scoped to exactly ONE repo** — indicated in brackets in the summary: `[repo-name]`. `lisa:jira-write-ticket` enforces single-repo scope on Sub-task; cross-repo sub-tasks will be rejected and must be split before delegation.
 2. **Include an Empirical Verification Plan** — real user-like verification, NOT unit tests, linting, or typechecking
 
 **Verification plan examples by stack:**
@@ -217,21 +217,21 @@ Each sub-task MUST:
 - **Frontend web**: Playwright browser tests (login with test user, navigate, interact, screenshot)
 - **Infrastructure**: `cdk synth` / `terraform plan` verification, CLI checks after deploy
 
-Use the test user credentials from config for all verification plans. The credentials are passed to `jira-write-ticket` as the sign-in account so it can record them in the description per its own rules.
+Use the test user credentials from config for all verification plans. The credentials are passed to `lisa:jira-write-ticket` as the sign-in account so it can record them in the description per its own rules.
 
-For each sub-task, the spawned agent invokes `jira-write-ticket` with `issue_type: "Sub-task"` and `parent` set to the Story key. The Story key is the parent — the epic relationship is inherited transitively.
+For each sub-task, the spawned agent invokes `lisa:jira-write-ticket` with `issue_type: "Sub-task"` and `parent` set to the Story key. The Story key is the parent — the epic relationship is inherited transitively.
 
-Sub-tasks inherit their parent story's artifacts by reference (the parent link). Do not pass the same artifact list to every sub-task — that creates noise. The only exception is when a sub-task depends on an artifact that the parent story doesn't (e.g., a sub-task spec'd from a specific Figma frame that the broader story doesn't cite) — in that case, pass the specific artifact in the `artifacts` parameter to `jira-write-ticket`.
+Sub-tasks inherit their parent story's artifacts by reference (the parent link). Do not pass the same artifact list to every sub-task — that creates noise. The only exception is when a sub-task depends on an artifact that the parent story doesn't (e.g., a sub-task spec'd from a specific Figma frame that the broader story doesn't cite) — in that case, pass the specific artifact in the `artifacts` parameter to `lisa:jira-write-ticket`.
 
 ### Phase 5.5: Artifact Preservation Gate (mandatory)
 
-Run the preservation gate defined in `jira-source-artifacts` §8 against the artifacts extracted in Phase 1.5 and the tickets just created. Do NOT restate or modify the gate logic here — invoke the rules from `jira-source-artifacts` so any rule change propagates uniformly.
+Run the preservation gate defined in `lisa:jira-source-artifacts` §8 against the artifacts extracted in Phase 1.5 and the tickets just created. Do NOT restate or modify the gate logic here — invoke the rules from `lisa:jira-source-artifacts` so any rule change propagates uniformly.
 
 To run the gate, this skill must:
 
 1. Pull the remote links of every epic and story created in this run via `mcp__atlassian__getJiraIssueRemoteIssueLinks`.
 2. Apply the §8 preservation matrix and verdict rules.
-3. If the gate fails: list each dropped/misrouted artifact (domain, title, source page, why it was dropped) and either re-attach via `jira-write-ticket` (UPDATE mode) or stop and ask the human. Never silently proceed past a gate failure.
+3. If the gate fails: list each dropped/misrouted artifact (domain, title, source page, why it was dropped) and either re-attach via `lisa:jira-write-ticket` (UPDATE mode) or stop and ask the human. Never silently proceed past a gate failure.
 4. If the gate passes: print the matrix compactly and proceed to Phase 6.
 
 This gate is not optional. Skipping it is the failure mode the architecture exists to prevent.
@@ -270,13 +270,13 @@ When delegating to agents, provide this context. **The "MUST invoke jira-write-t
 ```text
 Create JIRA sub-tasks in the [PROJECT] project at [CLOUD_ID].
 
-CRITICAL: For each sub-task, invoke the `jira-write-ticket` skill via the Skill tool.
-Do NOT call `mcp__atlassian__createJiraIssue` directly. The `jira-write-ticket` skill
+CRITICAL: For each sub-task, invoke the `lisa:jira-write-ticket` skill via the Skill tool.
+Do NOT call `mcp__atlassian__createJiraIssue` directly. The `lisa:jira-write-ticket` skill
 enforces required quality gates (Gherkin acceptance criteria, 3-audience description,
 single-repo scope, sign-in/environment fields, post-create verification). Bypassing it
 produces broken tickets that downstream skills (triage, journey, evidence) cannot use.
 
-For each sub-task, invoke `jira-write-ticket` with:
+For each sub-task, invoke `lisa:jira-write-ticket` with:
 - issue_type: "Sub-task"
 - parent: the parent story key
 - project_key: [PROJECT]
@@ -292,9 +292,9 @@ For each sub-task, invoke `jira-write-ticket` with:
 Each sub-task must:
 1. Be scoped to ONE repo only — repo named in brackets in the summary
 2. Include the Empirical Verification Plan in the description
-3. Be created via `jira-write-ticket`, not via direct MCP calls
+3. Be created via `lisa:jira-write-ticket`, not via direct MCP calls
 
-If `jira-write-ticket` rejects a sub-task (cross-repo scope, missing Gherkin, missing
+If `lisa:jira-write-ticket` rejects a sub-task (cross-repo scope, missing Gherkin, missing
 sign-in, etc.), fix the input and re-invoke. Do NOT fall back to a direct
 `createJiraIssue` call to bypass the gate.
 

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

@@ -0,0 +1,38 @@
+---
+name: plan
+description: "Decompose a single PRD or specification into ordered work items in the configured tracker. Vendor-agnostic — the source can be a Notion PRD URL, an existing JIRA epic key, a markdown file, or a free-form description; the destination tracker is whatever the project is configured to use (JIRA today; Linear/GitHub Issues are pluggable). Single-PRD mode only — for batch scanning of all Status=Ready PRDs in a queue, use the lisa:intake skill."
+allowed-tools: ["Skill", "Bash", "Read", "Glob", "Grep"]
+---
+
+# Plan: $ARGUMENTS
+
+Decompose the PRD/spec at `$ARGUMENTS` into ordered work items with acceptance criteria, dependencies, and recommended skills/agents.
+
+## 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.
+
+## Source dispatch
+
+Detect the input type from `$ARGUMENTS` and route to the appropriate source skill:
+
+| If `$ARGUMENTS` is... | Hand off to |
+|------------------------|-------------|
+| A Notion **page** URL or page ID (single PRD) | `lisa:notion-to-jira` (with the PRD URL; runs the full pipeline: extract artifacts → walk live product → validate → write tickets → coverage audit) |
+| A Notion **database** URL or database ID | Stop and report — single-PRD mode only. Direct the caller to `lisa:intake` for batch scanning of a database. |
+| A JIRA ticket ID/URL of an Epic (existing epic *is* the spec) | `lisa:jira-agent` (read epic, decompose 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-source` / `github-prd-source` 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 `lisa:research` skill first to produce one.
+
+## Flow
+
+Execute the **Plan** flow as defined in the `intent-routing` rule (loaded via the lisa plugin). The rule contains the canonical step sequence (gates, sub-flows, output structure). This skill does NOT restate flow steps — change them in the rule, propagate everywhere.
+
+## Output
+
+Work items in the configured tracker (JIRA today; Linear/GitHub Issues when adapters exist) with acceptance criteria, dependencies, and recommended skills/agents per item. Ordered by dependency. If the specification cannot be decomposed without further clarification, stop and report what is missing.

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/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": "2.0.0",
+  "version": "2.1.1",
   "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": "2.0.0",
+  "version": "2.1.1",
   "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