@codyswann/lisa 1.96.0 → 2.1.0

package/plugins/src/base/commands/{plan/improve-tests.md → improve/tests.md}

@@ -4,4 +4,4 @@ allowed-tools: ["Skill"]
 argument-hint: "<target-description>"
 ---
 
-Use the /lisa:plan-improve-tests skill to improve test quality. $ARGUMENTS
+Use the /lisa:improve-tests skill to improve test quality. $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,14 +1,6 @@
 ---
-description: "Plan work. Defines acceptance criteria, researches codebase, maps dependencies, and breaks down into ordered work items."
-argument-hint: "<description-or-ticket-id-or-url>"
+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.
-
-If no PRD or specification exists, suggest running the **Research** flow first to produce one.
-
-If the argument is a JIRA ticket ID or URL, hand off to the `jira-agent` which will read the ticket and extract context.
-
-$ARGUMENTS
+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/{lisa/commands/plan/local-code-review.md → src/base/commands/review/local.md}

@@ -3,4 +3,4 @@ description: "Review local branch changes compared to main"
 allowed-tools: ["Skill"]
 ---
 
-Use the /lisa:plan-local-code-review skill to review local changes.
+Use the /lisa:review-local skill to review local changes.

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/{lisa/skills/plan-fix-linter-error → src/base/skills/fix-linter-error}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: plan-fix-linter-error
+name: fix-linter-error
 description: This skill should be used when fixing all violations of one or more ESLint rules across the codebase. It runs the linter, groups violations by rule and file, generates a brief with fix strategies, and creates a plan with tasks to implement the fixes.
 allowed-tools: ["Read", "Bash", "Glob", "Grep"]
 
@@ -42,4 +42,4 @@ Fix strategies: extract functions, early returns, apply formatting, add types
 Verification: `bun run lint 2>&1 | grep -E "($ARGUMENTS)" | wc -l` → Expected: 0
 ```
 
-Invoke `/plan-execute` with this brief to create the implementation plan.
+Invoke `/implement` with this brief to create the implementation plan.

package/plugins/src/base/skills/{plan-execute → implement}/SKILL.md

@@ -1,19 +1,34 @@
 ---
-name: plan-execute
+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:

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

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

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

@@ -1,5 +1,5 @@
 ---
-name: plan-reduce-max-lines
+name: improve-max-lines
 description: This skill should be used when reducing the maximum file lines threshold and fixing all violations. It updates the eslint threshold configuration, identifies files exceeding the new limit, generates a brief with refactoring strategies, and creates a plan with tasks to split oversized files.
 allowed-tools: ["Read", "Bash", "Glob", "Grep"]
 
@@ -42,4 +42,4 @@ Refactoring strategies: extract modules, remove duplication, delete dead code, s
 Verification: `bun run lint 2>&1 | grep "max-lines" | wc -l` → Expected: 0
 ```
 
-Invoke `/plan-execute` with this brief to create the implementation plan.
+Invoke `/implement` with this brief to create the implementation plan.

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

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

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

@@ -1,5 +1,5 @@
 ---
-name: plan-add-test-coverage
+name: improve-test-coverage
 description: This skill should be used when increasing test coverage to a specified threshold percentage. It runs the coverage report, identifies files with the lowest coverage, generates a brief with coverage gaps, and creates a plan with tasks to add the missing tests.
 allowed-tools: ["Read", "Bash", "Glob", "Grep"]
 
@@ -41,4 +41,4 @@ Configuration: [config file path], update thresholds to $ARGUMENTS%
 Verification: `bun run test:cov` → Expected: All thresholds pass at $ARGUMENTS%
 ```
 
-Invoke `/plan-execute` with this brief to create the implementation plan.
+Invoke `/implement` with this brief to create the implementation plan.

package/plugins/{lisa/skills/plan-improve-tests → src/base/skills/improve-tests}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: plan-improve-tests
+name: improve-tests
 description: This skill should be used when improving test quality. It scans the test suite for weak, brittle, or poorly-written tests, generates a brief with improvement opportunities, and creates a plan with tasks to strengthen the tests.
 allowed-tools: ["Read", "Bash", "Glob", "Grep"]
 ---
@@ -44,4 +44,4 @@ Test files needing improvement (ordered by impact):
 Verification: `bun run test` -> Expected: All tests pass, improved assertions and coverage
 ```
 
-Invoke `/plan-execute` with this brief to create the implementation plan.
+Invoke `/implement` with this brief to create the implementation plan.

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

@@ -0,0 +1,56 @@
+---
+name: intake
+description: "Vendor-agnostic batch scanner for Status=Ready queues. Given a Notion PRD database URL → finds Ready PRDs and runs lisa:plan per item. Given a JIRA project key or JQL filter → finds Ready tickets and runs lisa:implement per item. Designed as the cron target for /schedule — one cycle per invocation, processes everything currently Ready, exits cleanly on empty. Symmetric counterpart to the single-item lisa:plan and lisa:implement skills."
+allowed-tools: ["Skill", "Bash", "mcp__claude_ai_Notion__notion-fetch", "mcp__claude_ai_Notion__notion-search", "mcp__atlassian__getAccessibleAtlassianResources", "mcp__atlassian__searchJiraIssuesUsingJql", "mcp__atlassian__getJiraIssue"]
+---
+
+# Intake: $ARGUMENTS
+
+Run one batch-intake cycle against the queue identified by `$ARGUMENTS`. Scans for `Status = Ready`, claims each item, and dispatches to the appropriate single-item lifecycle skill.
+
+## 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.
+
+The cycle's outer team is created by Intake. Each item it processes (a PRD via `lisa:plan`, a ticket via `lisa:implement`) executes within the same team — those skills' orchestration preambles detect the existing team and skip TeamCreate. One team per cron cycle, processes everything currently Ready.
+
+## Source dispatch
+
+Detect the queue type from `$ARGUMENTS` and route:
+
+| If `$ARGUMENTS` is... | Queue type | Per-item dispatch |
+|------------------------|------------|---------------------|
+| A Notion **database** URL or database ID | PRD queue (Notion) | Invoke `lisa:notion-prd-intake` (which scans the DB for Status=Ready, claims each, runs `lisa:plan` per PRD via the dry-run validate → branch → write pipeline) |
+| A JIRA project key (e.g. `SE`) | Work queue (JIRA) | Invoke `lisa:jira-build-intake` (which scans the project for Status=Ready, claims each via In Progress, runs `lisa:implement` per ticket, transitions to On Dev on success) |
+| A full JQL filter (e.g. `project = SE AND component = "frontend"`) | Work queue (JIRA, narrowed) | Invoke `lisa:jira-build-intake` with the JQL |
+| A Linear / GitHub Issues queue | Not yet implemented | Stop and report — no `linear-tracker` or `github-tracker` adapter has been built. Don't fall back. |
+
+The single-item skills (`lisa:plan`, `lisa:implement`) and the per-vendor batch skills (`lisa:notion-prd-intake`, `lisa:jira-build-intake`) are internal — Intake is the public entry point. Developers schedule `/lisa:intake <queue>`; the rest is composition.
+
+## Cycle behavior
+
+1. **Resolve the queue** — fetch the database/project metadata, confirm the Status property/workflow has the expected `Ready` value.
+2. **Pre-flight check** — for JIRA, confirm `In Progress` and `On Dev` are reachable transitions before doing any per-ticket work. Stop with a clear error if the workflow is misconfigured.
+3. **Find Ready items** — query the queue. Empty → exit cleanly with `"No items with Status=Ready. Nothing to do."` This is the common idle case for a scheduled run.
+4. **Process each Ready item serially** (claim-first ordering for idempotency):
+   - Notion PRDs → `lisa:notion-prd-intake` handles per-item: claim, dry-run validate, branch to Blocked or Ticketed, coverage audit
+   - JIRA tickets → `lisa:jira-build-intake` handles per-item: claim, dispatch to `lisa:jira-agent`, transition to On Dev on success
+5. **Failure isolation** — one item failing does not stop the cycle; record under "Errors" and continue.
+6. **Summary report** — per-item outcomes, total processed, total errors.
+
+## Schedule examples
+
+```text
+/schedule "every 30 minutes" /lisa:intake https://www.notion.so/<workspace>/<database-id>
+/schedule "every 30 minutes" /lisa:intake SE
+/schedule "every hour" /lisa:intake "project = SE AND component = 'frontend'"
+```
+
+## Rules
+
+- Never run a cycle without an explicit queue. Side effects too high to default.
+- Never modify the source/destination lifecycles directly — Intake delegates per-item to the vendor adapter, which owns status transitions.
+- Never run two Intake cycles concurrently against overlapping queues — concurrent claims could race. The scheduling layer is responsible for serialization.
+- Stop and surface failures rather than retry-loop.

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

@@ -115,6 +115,6 @@ python3 .claude/skills/jira-journey/scripts/parse-plan.py <TICKET_ID>
 ## 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
 - Before starting work on a ticket, to ensure verification steps are documented

package/plugins/src/base/skills/jira-build-intake/SKILL.md

@@ -11,7 +11,7 @@ allowed-tools: ["Skill", "Bash", "mcp__atlassian__getAccessibleAtlassianResource
 1. A JIRA project key (e.g. `SE`) — scans that project for `Status = Ready` tickets.
 2. A full JQL filter (e.g. `project = SE AND component = "frontend" AND Status = Ready`) — used as-is. The skill will not append a `Status = Ready` clause if the JQL already names a status, so callers can intentionally widen.
 
-Run one build-intake cycle. Each Ready ticket is claimed, built via the `jira-agent` flow, and transitioned to `On Dev` (or the equivalent next-status for that project). The cycle is the symmetric mirror of `notion-prd-intake`: humans flip `Ready`, agents pick up and progress.
+Run one build-intake cycle. Each Ready ticket is claimed, built via the `lisa:jira-agent` flow, and transitioned to `On Dev` (or the equivalent next-status for that project). The cycle is the symmetric mirror of `lisa:notion-prd-intake`: humans flip `Ready`, agents pick up and progress.
 
 ## Lifecycle assumed
 
@@ -55,28 +55,28 @@ If the transition fails (permission, missing transition, race), log under "Error
 
 #### 3b. Run the build flow
 
-Invoke the `jira-agent` (existing per-ticket lifecycle agent) with the ticket key. `jira-agent` owns:
-- Reading the full ticket graph (`jira-read-ticket`)
-- Running its own pre-flight quality gate (`jira-verify`)
-- Running ticket triage (`ticket-triage`)
+Invoke the `lisa:jira-agent` (existing per-ticket lifecycle agent) with the ticket key. `lisa:jira-agent` owns:
+- Reading the full ticket graph (`lisa:jira-read-ticket`)
+- Running its own pre-flight quality gate (`lisa:jira-verify`)
+- Running ticket triage (`lisa:ticket-triage`)
 - Routing to the appropriate flow (Build / Fix / Investigate / Improve based on type)
-- Posting progress comments via `jira-sync`
-- Posting evidence via `jira-evidence`
+- Posting progress comments via `lisa:jira-sync`
+- Posting evidence via `lisa:jira-evidence`
 
-Wait for `jira-agent` to return. Capture its outcome:
+Wait for `lisa:jira-agent` to return. Capture its outcome:
 - **Success** — PR is ready (open or merged); evidence posted; ready for next status.
-- **Blocked by jira-verify pre-flight gate** — `jira-agent` itself transitions the ticket to `Blocked` and reassigns to Reporter. This is correct and expected — let it stand. Record the outcome and move on.
-- **Blocked by ticket-triage ambiguities** — `jira-agent` posts findings and stops. The ticket stays in `In Progress`. Surface to human; do not auto-transition. Record under "Errors" with reason `"Triage found ambiguities — see comments on <ticket-key>"`.
+- **Blocked by jira-verify pre-flight gate** — `lisa:jira-agent` itself transitions the ticket to `Blocked` and reassigns to Reporter. This is correct and expected — let it stand. Record the outcome and move on.
+- **Blocked by ticket-triage ambiguities** — `lisa:jira-agent` posts findings and stops. The ticket stays in `In Progress`. Surface to human; do not auto-transition. Record under "Errors" with reason `"Triage found ambiguities — see comments on <ticket-key>"`.
 - **Errored** — exception, missing config, etc. Leave the ticket in `In Progress` for human investigation. Record under "Errors" with the exception summary.
 
 #### 3c. Transition to On Dev (only on Success)
 
-If `jira-agent` returned Success:
+If `lisa:jira-agent` returned Success:
 1. Use `getTransitionsForJiraIssue` to find the transition ID for `On Dev` (or the configured next-after-build status).
 2. Transition via `transitionJiraIssue`.
 3. Post a `[claude-build-intake]` comment: `"Build complete. PR <URL>. Transitioned to On Dev."`
 
-For any non-Success outcome, do NOT transition. The ticket sits in `In Progress` (or wherever `jira-agent` left it for the Blocked case) — the cycle's job is done; humans take it from there.
+For any non-Success outcome, do NOT transition. The ticket sits in `In Progress` (or wherever `lisa:jira-agent` left it for the Blocked case) — the cycle's job is done; humans take it from there.
 
 #### 3d. Continue
 
@@ -106,10 +106,10 @@ Total PRs opened: <n>
 
 ## Idempotency & safety
 
-- **Claim-first ordering**: `In Progress` set BEFORE `jira-agent` invocation — no double-pickup.
-- **No writes outside the lifecycle**: this skill only transitions `Ready → In Progress` and `In Progress → On Dev`. Every other status change is owned by `jira-agent` (which suggests transitions but only auto-transitions on the verify-FAIL path).
+- **Claim-first ordering**: `In Progress` set BEFORE `lisa:jira-agent` invocation — no double-pickup.
+- **No writes outside the lifecycle**: this skill only transitions `Ready → In Progress` and `In Progress → On Dev`. Every other status change is owned by `lisa:jira-agent` (which suggests transitions but only auto-transitions on the verify-FAIL path).
 - **Failure isolation**: per-ticket exceptions caught and recorded; the cycle continues.
-- **Single cycle per query**: do not run two `jira-build-intake` cycles in parallel against overlapping queries — concurrent claims could race. The scheduling layer (when added) is responsible for serialization.
+- **Single cycle per query**: do not run two `lisa:jira-build-intake` cycles in parallel against overlapping queries — concurrent claims could race. The scheduling layer (when added) is responsible for serialization.
 - **Never invent a transition**: if `In Progress` or `On Dev` aren't valid transitions in the project's workflow, stop and report rather than guessing alternative names.
 
 ## Configuration
@@ -128,7 +128,7 @@ If a `Ready` status does not exist in the JIRA project's workflow, this skill ca
 ## Rules
 
 - Never transition a ticket the cycle didn't claim. The `In Progress` transition is the signature of cycle ownership.
-- Never bypass `jira-agent` to do build work directly. `jira-agent` owns the per-ticket lifecycle (read, verify, triage, route, sync, evidence). This skill is the dispatcher, not the builder.
+- Never bypass `lisa:jira-agent` to do build work directly. `lisa:jira-agent` owns the per-ticket lifecycle (read, verify, triage, route, sync, evidence). This skill is the dispatcher, not the builder.
 - Never auto-transition past `On Dev`. Downstream statuses (`On QA`, `Done`) are owned by QA / product / a future verification-intake skill — not this one.
-- If the ticket has no Validation Journey or no sign-in credentials in its description, `jira-agent`'s pre-flight verify will catch it and transition to `Blocked` — **don't try to fix the ticket from here**. Pre-flight gating is `jira-agent`'s job; running build work on a thin ticket produces broken work.
-- On any unexpected response from `jira-agent` (status it doesn't claim, missing PR URL on success, etc.), record as Error and surface — never assume.
+- If the ticket has no Validation Journey or no sign-in credentials in its description, `lisa:jira-agent`'s pre-flight verify will catch it and transition to `Blocked` — **don't try to fix the ticket from here**. Pre-flight gating is `lisa:jira-agent`'s job; running build work on a thin ticket produces broken work.
+- On any unexpected response from `lisa:jira-agent` (status it doesn't claim, missing PR URL on success, etc.), record as Error and surface — never assume.

package/plugins/src/base/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 in the input and classify each by domain per its rules. Build the `artifacts` map (one entry per artifact: url, title, domain, source page, classification reason). 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 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 in the input and classify each by domain per its rules. Build the `artifacts` map (one entry per artifact: url, title, domain, source page, classification reason). 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 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
 
@@ -32,7 +32,7 @@ Analyze the provided file(s) and plan a JIRA hierarchy. **This skill plans struc
 
 ## Validation Journey
 
-Tickets that change runtime behavior should include a `Validation Journey` section in the description. This section is consumed by the `jira-journey` skill to automate verification.
+Tickets that change runtime behavior should include a `Validation Journey` section in the description. This section is consumed by the `lisa:jira-journey` skill to automate verification.
 
 ### When to Include
 
@@ -89,13 +89,13 @@ 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 skill so any rule change propagates uniformly.
+**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 — invoke the skill so any rule change propagates uniformly.
 
-When delegating actual writes to `jira-write-ticket`, pass the extracted artifact list so its Phase 4c (Remote Links) step can attach them.
+When delegating actual writes to `lisa:jira-write-ticket`, pass the extracted artifact list so its Phase 4c (Remote Links) step can attach them.
 
 ## Live Product Walkthrough
 
-When the work touches existing user-facing surfaces, invoke the `product-walkthrough` skill before drafting tickets. The walkthrough 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. The walkthrough 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
 
@@ -110,9 +110,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)
@@ -126,9 +126,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
 
@@ -137,8 +137,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
 
@@ -149,4 +149,4 @@ This skill owns:
 - Threading parent keys through subsequent writes
 - Running the Phase 5.5-style preservation check after all writes complete
 
-It does not own the actual JIRA write — that's `jira-write-ticket`'s job.
+It does not own the actual JIRA write — that's `lisa:jira-write-ticket`'s job.

package/plugins/src/base/skills/jira-source-artifacts/SKILL.md

@@ -8,7 +8,7 @@ allowed-tools: []
 
 This skill is doctrine, not action — it defines the rules. Skills that need to extract, classify, attach, or reason about external artifacts (design files, prototypes, recordings, data samples) invoke this skill to load the taxonomy and apply it.
 
-The reason this lives in one place: silent drift across skills is the failure mode this body of rules exists to prevent. If the rules differ between `notion-to-jira`, `jira-create`, and `jira-write-ticket`, agents will silently route artifacts wrong and developers will lose source of truth. Edit here, propagate everywhere.
+The reason this lives in one place: silent drift across skills is the failure mode this body of rules exists to prevent. If the rules differ between `lisa:notion-to-jira`, `lisa:jira-create`, and `lisa:jira-write-ticket`, agents will silently route artifacts wrong and developers will lose source of truth. Edit here, propagate everywhere.
 
 ## 1. Domains
 

package/plugins/src/base/skills/jira-validate-ticket/SKILL.md

@@ -6,7 +6,7 @@ allowed-tools: ["Bash", "mcp__atlassian__getJiraIssue", "mcp__atlassian__searchJ
 
 # Validate JIRA Ticket: $ARGUMENTS
 
-Run all organizational quality gates against a ticket spec OR an existing ticket. **This skill is read-only — it never writes to JIRA.** The output is a structured report consumed by callers (`jira-write-ticket` for pre-write gating, `notion-to-jira` for PRD dry-run, `jira-verify` for post-write checks).
+Run all organizational quality gates against a ticket spec OR an existing ticket. **This skill is read-only — it never writes to JIRA.** The output is a structured report consumed by callers (`lisa:jira-write-ticket` for pre-write gating, `lisa:notion-to-jira` for PRD dry-run, `lisa:jira-verify` for post-write checks).
 
 ## Input
 
@@ -132,8 +132,8 @@ Story / Epic / Spike / Improvement: skipped (may span repos).
 When `runtime_behavior_change = true`, description must contain `h2. Validation Journey`. Skipped for doc-only / config-only / type-only / Epic.
 
 The caller controls the strictness by passing `journey_followup: "auto"` or `journey_followup: "none"` in the spec:
-- `auto` (default): if the section is absent, return `FAIL` with remediation `"Invoke jira-add-journey to append the section after create"`. Callers like `jira-write-ticket` know to chain `jira-add-journey` automatically, so this counts as a fixable failure they can resolve in-line — they re-run validation after appending.
-- `none`: missing section is a `FAIL` that the caller will not auto-fix, so the verdict gates progress (used by dry-run paths like `notion-to-jira` PRD intake, where there's no agent standing by to add the journey).
+- `auto` (default): if the section is absent, return `FAIL` with remediation `"Invoke lisa:jira-add-journey to append the section after create"`. Callers like `lisa:jira-write-ticket` know to chain `lisa:jira-add-journey` automatically, so this counts as a fixable failure they can resolve in-line — they re-run validation after appending.
+- `none`: missing section is a `FAIL` that the caller will not auto-fix, so the verdict gates progress (used by dry-run paths like `lisa:notion-to-jira` PRD intake, where there's no agent standing by to add the journey).
 
 Either way the gate emits `FAIL`, not a third state. Strictness is the caller's policy, not the validator's.
 
@@ -141,7 +141,7 @@ Either way the gate emits `FAIL`, not a third state. Strictness is the caller's
 
 When `artifacts_attached = true`, description must include source-precedence guidance covering: business rules → PRD body, visual treatment → mocks, flow → prototypes, API/data → data artifacts. Cross-axis conflicts surfaced under `## Open Questions`.
 
-Accept either placement — both are valid per `jira-source-artifacts`:
+Accept either placement — both are valid per `lisa:jira-source-artifacts`:
 - A dedicated `## Source Precedence` (or `h2. Source Precedence`) subsection, OR
 - A "Source Precedence" / "source precedence" / "authoritative source" paragraph under `Technical Approach` that covers the four axes above.