@codyswann/lisa 1.96.0 → 2.1.0

package/package.json

@@ -78,7 +78,7 @@
     "lodash": ">=4.18.1"
   },
   "name": "@codyswann/lisa",
-  "version": "1.96.0",
+  "version": "2.1.0",
   "description": "Claude Code governance framework that applies guardrails, guidance, and automated enforcement to projects",
   "main": "dist/index.js",
   "exports": {

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa",
-  "version": "1.96.0",
+  "version": "2.1.0",
   "description": "Universal governance — agents, skills, commands, hooks, and rules for all projects",
   "author": {
     "name": "Cody Swann"

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

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

package/plugins/lisa/commands/implement.md

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

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

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

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

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

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

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

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

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

package/plugins/lisa/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/lisa/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/lisa/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/lisa/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/lisa/commands/research.md

@@ -1,10 +1,6 @@
 ---
-description: "Research a problem space and produce a PRD. Investigates codebase, defines user flows, assesses technical feasibility."
+description: "Research a problem space and produce a PRD. Investigates the codebase, defines user flows, assesses technical feasibility, and outputs a specification ready for the Plan flow."
 argument-hint: "<problem-statement-or-feature-idea>"
 ---
 
-Apply the `intent-routing` rule (loaded via the lisa plugin) and execute the **Research** flow.
-
-**Orchestration: agent team.** Research is a multi-specialist flow feeding a shared PRD. After echoing the flow and orchestration mode, your FIRST tool call MUST be `TeamCreate`. Do not call `TaskCreate`, `Agent`, or implementation tools before the team exists.
-
-$ARGUMENTS
+Use the /lisa:research skill to research the problem and produce a PRD. $ARGUMENTS

package/plugins/{src/base/commands/plan/local-code-review.md → lisa/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/lisa/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/lisa/rules/intent-routing.md

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

package/plugins/{src/base/skills/plan-fix-linter-error → lisa/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/lisa/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/lisa/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/lisa/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/{src/base/skills/plan-reduce-max-lines-per-function → lisa/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/lisa/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/{src/base/skills/plan-improve-tests → lisa/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/lisa/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/lisa/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/lisa/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.