@codyswann/lisa 2.10.0 → 2.11.0

package/plugins/lisa/skills/tracker-create/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: tracker-create
-description: "Vendor-neutral wrapper for creating tickets/issues from code files or descriptions. Reads `tracker` from .lisa.config.json (default: jira) and dispatches to lisa:jira-create or lisa:github-create. Plans hierarchy structure (epic / story / sub-task), then delegates each individual write through the tracker-write shim."
+description: "Vendor-neutral wrapper for creating tickets/issues from code files or descriptions. Reads `tracker` from .lisa.config.json (default: jira) and dispatches to lisa:jira-create, lisa:github-create, or lisa:linear-create. Plans hierarchy structure (epic / story / sub-task), then delegates each individual write through the tracker-write shim."
 allowed-tools: ["Skill", "Bash", "Read"]
 ---
 
@@ -8,7 +8,7 @@ allowed-tools: ["Skill", "Bash", "Read"]
 
 Thin dispatcher. Resolves the configured destination tracker and delegates to the matching vendor planning skill.
 
-See the `tracker-resolution` rule for configuration and dispatch table.
+See the `config-resolution` rule for configuration and dispatch table.
 
 ## Workflow
 
@@ -16,9 +16,11 @@ See the `tracker-resolution` rule for configuration and dispatch table.
 2. Dispatch:
    - `jira` → invoke `lisa:jira-create` with `$ARGUMENTS` verbatim.
    - `github` → invoke `lisa:github-create` with `$ARGUMENTS` verbatim.
+   - `linear` → invoke `lisa:linear-create` with `$ARGUMENTS` verbatim.
+   - Anything else → stop and report `"Unknown tracker '<value>' in .lisa.config.json. Expected 'jira', 'github', or 'linear'."`
 3. Pass through the output.
 
 ## Rules
 
-- Both vendor skills delegate every individual ticket write through `lisa:tracker-write`. They never call vendor-specific write tools directly.
+- All vendor skills delegate every individual ticket write through `lisa:tracker-write`. They never call vendor-specific write tools directly.
 - This shim is for ad-hoc creation from code files / descriptions. PRD-driven creation goes through the `*-to-tracker` skills (notion / confluence / linear / github).

package/plugins/lisa/skills/tracker-evidence/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: tracker-evidence
-description: "Vendor-neutral wrapper for posting verification evidence. Reads `tracker` from .lisa.config.json (default: jira) and dispatches to lisa:jira-evidence or lisa:github-evidence. Uploads evidence to the GitHub `pr-assets` release, updates the PR description, posts a comment on the originating ticket/issue, and transitions the ticket/issue to its post-build review state."
+description: "Vendor-neutral wrapper for posting verification evidence. Reads `tracker` from .lisa.config.json (default: jira) and dispatches to lisa:jira-evidence, lisa:github-evidence, or lisa:linear-evidence. Uploads evidence to the GitHub `pr-assets` release, updates the PR description, posts a comment on the originating ticket/issue, and transitions the ticket/issue to its post-build review state."
 allowed-tools: ["Skill", "Bash", "Read"]
 ---
 
@@ -8,7 +8,7 @@ allowed-tools: ["Skill", "Bash", "Read"]
 
 Thin dispatcher. Resolves the configured destination tracker and delegates to the matching vendor evidence skill.
 
-See the `tracker-resolution` rule for configuration and dispatch table.
+See the `config-resolution` rule for configuration and dispatch table.
 
 ## Workflow
 
@@ -16,9 +16,11 @@ See the `tracker-resolution` rule for configuration and dispatch table.
 2. Dispatch:
    - `jira` → invoke `lisa:jira-evidence` with `$ARGUMENTS` verbatim. Arg shape: `<TICKET_ID> <EVIDENCE_DIR> <PR_NUMBER>`.
    - `github` → invoke `lisa:github-evidence` with `$ARGUMENTS` verbatim. Arg shape: `<ISSUE_REF> <EVIDENCE_DIR> <PR_NUMBER>` where `ISSUE_REF` is `org/repo#<number>` or a GitHub issue URL.
+   - `linear` → invoke `lisa:linear-evidence` with `$ARGUMENTS` verbatim. Arg shape: `<IDENTIFIER> <EVIDENCE_DIR>` where `IDENTIFIER` is a Linear Issue identifier (e.g., `ENG-123`).
+   - Anything else → stop and report `"Unknown tracker '<value>' in .lisa.config.json. Expected 'jira', 'github', or 'linear'."`
 3. Pass through the vendor skill's output.
 
 ## Rules
 
-- The GitHub `pr-assets` release lives on the implementation repo (the one with the PR), regardless of which tracker hosts the ticket/issue. Both vendor skills upload there.
+- The GitHub `pr-assets` release lives on the implementation repo (the one with the PR), regardless of which tracker hosts the ticket/issue. All vendor skills upload there.
 - Never post evidence to a different ticket than the one named — `$ARGUMENTS` is the source of truth.

package/plugins/lisa/skills/tracker-journey/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: tracker-journey
-description: "Vendor-neutral wrapper for executing a ticket/issue's Validation Journey end-to-end. Reads `tracker` from .lisa.config.json (default: jira) and dispatches to lisa:jira-journey or lisa:github-journey. Parses the journey, satisfies prerequisites, executes the steps, captures evidence at each marker, and posts results via tracker-evidence."
+description: "Vendor-neutral wrapper for executing a ticket/issue's Validation Journey end-to-end. Reads `tracker` from .lisa.config.json (default: jira) and dispatches to lisa:jira-journey, lisa:github-journey, or lisa:linear-journey. Parses the journey, satisfies prerequisites, executes the steps, captures evidence at each marker, and posts results via tracker-evidence."
 allowed-tools: ["Skill", "Bash", "Read"]
 ---
 
@@ -8,7 +8,7 @@ allowed-tools: ["Skill", "Bash", "Read"]
 
 Thin dispatcher. Resolves the configured destination tracker and delegates to the matching vendor journey skill.
 
-See the `tracker-resolution` rule for configuration and dispatch table.
+See the `config-resolution` rule for configuration and dispatch table.
 
 ## Workflow
 
@@ -16,9 +16,11 @@ See the `tracker-resolution` rule for configuration and dispatch table.
 2. Dispatch:
    - `jira` → invoke `lisa:jira-journey` with `$ARGUMENTS` verbatim. Arg shape: `<TICKET_ID> [PR_NUMBER]`.
    - `github` → invoke `lisa:github-journey` with `$ARGUMENTS` verbatim. Arg shape: `<ISSUE_REF> [PR_NUMBER]`.
+   - `linear` → invoke `lisa:linear-journey` with `$ARGUMENTS` verbatim. Arg shape: `<IDENTIFIER> [PR_NUMBER]`.
+   - Anything else → stop and report `"Unknown tracker '<value>' in .lisa.config.json. Expected 'jira', 'github', or 'linear'."`
 3. Pass through the output.
 
 ## Rules
 
-- The journey content is identical across vendors; only the parser source differs (the JIRA vendor reads description via Atlassian MCP; the GitHub vendor reads body via `gh issue view --json body`).
+- The journey content is identical across vendors; only the parser source differs (the JIRA vendor reads description via Atlassian MCP; the GitHub vendor reads body via `gh issue view --json body`; the Linear vendor reads description via `mcp__linear-server__get_issue`).
 - Evidence posting always goes through `lisa:tracker-evidence` — never bypass.

package/plugins/lisa/skills/tracker-read/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: tracker-read
-description: "Vendor-neutral wrapper for fetching the full scope of a ticket/issue and its related graph. Reads `tracker` from .lisa.config.json (default: jira) and dispatches to lisa:jira-read-ticket or lisa:github-read-issue. Returns a consolidated context bundle so downstream agents never act on a single ticket in isolation."
+description: "Vendor-neutral wrapper for fetching the full scope of a ticket/issue and its related graph. Reads `tracker` from .lisa.config.json (default: jira) and dispatches to lisa:jira-read-ticket, lisa:github-read-issue, or lisa:linear-read-issue. Returns a consolidated context bundle so downstream agents never act on a single ticket in isolation."
 allowed-tools: ["Skill", "Bash", "Read"]
 ---
 
@@ -8,7 +8,7 @@ allowed-tools: ["Skill", "Bash", "Read"]
 
 Thin dispatcher. Resolves the configured destination tracker and delegates to the matching vendor read skill.
 
-See the `tracker-resolution` rule for configuration and dispatch table.
+See the `config-resolution` rule for configuration and dispatch table.
 
 ## Workflow
 
@@ -16,10 +16,12 @@ See the `tracker-resolution` rule for configuration and dispatch table.
 2. Dispatch:
    - `jira` → invoke `lisa:jira-read-ticket` with `$ARGUMENTS` verbatim. The argument is a JIRA key (e.g., `PROJ-123`).
    - `github` → invoke `lisa:github-read-issue` with `$ARGUMENTS` verbatim. The argument is `org/repo#<number>` or a full GitHub issue URL.
+   - `linear` → invoke `lisa:linear-read-issue` with `$ARGUMENTS` verbatim. The argument is a Linear identifier (e.g., `ENG-123`) or a project URL.
+   - Anything else → stop and report `"Unknown tracker '<value>' in .lisa.config.json. Expected 'jira', 'github', or 'linear'."`
 3. Return the vendor skill's context bundle verbatim.
 
 ## Rules
 
 - Read-only — never modify the ticket/issue.
-- The two vendors emit different context-bundle formats (because their data models differ). Callers must be tolerant of both — or, more precisely, agents at the next layer (e.g. `tracker-agent`-equivalent) parse the per-vendor bundle.
-- If the input format doesn't match the configured tracker (e.g. tracker is jira but `$ARGUMENTS` looks like a GitHub URL), stop and report — never auto-translate.
+- The three vendors emit different context-bundle formats (because their data models differ). Callers must be tolerant of all — or, more precisely, agents at the next layer parse the per-vendor bundle.
+- If the input format doesn't match the configured tracker (e.g. tracker is jira but `$ARGUMENTS` looks like a Linear identifier), stop and report — never auto-translate.

package/plugins/lisa/skills/{jira-source-artifacts → tracker-source-artifacts}/SKILL.md

@@ -1,14 +1,14 @@
 ---
-name: jira-source-artifacts
-description: "Canonical taxonomy and rules for handling source artifacts (Figma, Lovable, Loom, screenshots, design docs, data samples) when generating or evaluating JIRA tickets. Defines: (1) artifact domains, (2) classification rules per tool, (3) source precedence (which artifact is authoritative for which question), (4) inheritance from epic to story to sub-task, (5) cross-axis conflict handling. Invoke this skill from any flow that extracts, attaches, or reasons about external design/UX/data artifacts so the rules don't drift across skills."
+name: tracker-source-artifacts
+description: "Canonical, vendor-neutral taxonomy and rules for handling source artifacts (Figma, Lovable, Loom, screenshots, design docs, data samples) when generating or evaluating tracker tickets (JIRA, GitHub Issues, Linear). Defines: (1) artifact domains, (2) classification rules per tool, (3) source precedence (which artifact is authoritative for which question), (4) inheritance from epic to story to sub-task, (5) cross-axis conflict handling. Invoke this skill from any flow that extracts, attaches, or reasons about external design/UX/data artifacts so the rules don't drift across skills."
 allowed-tools: []
 ---
 
-# JIRA Source Artifact Taxonomy and Rules
+# Tracker Source Artifact Taxonomy and Rules
 
-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.
+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 taxonomy is vendor-neutral: it applies equally to JIRA tickets, GitHub Issues, and Linear Issues.
 
-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-tracker`, `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.
+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-tracker`, `lisa:tracker-create`, and `lisa:tracker-write`, agents will silently route artifacts wrong and developers will lose source of truth. Edit here, propagate everywhere.
 
 ## 1. Domains
 

package/plugins/lisa/skills/tracker-sync/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: tracker-sync
-description: "Vendor-neutral wrapper for posting milestone updates to the linked ticket/issue. Reads `tracker` from .lisa.config.json (default: jira) and dispatches to lisa:jira-sync or lisa:github-sync. Posts at: plan created, implementation in progress, PR ready, PR merged. Suggests (never auto-transitions) the next status."
+description: "Vendor-neutral wrapper for posting milestone updates to the linked ticket/issue. Reads `tracker` from .lisa.config.json (default: jira) and dispatches to lisa:jira-sync, lisa:github-sync, or lisa:linear-sync. Posts at: plan created, implementation in progress, PR ready, PR merged. Suggests (never auto-transitions) the next status."
 allowed-tools: ["Skill", "Bash", "Read"]
 ---
 
@@ -8,7 +8,7 @@ allowed-tools: ["Skill", "Bash", "Read"]
 
 Thin dispatcher. Resolves the configured destination tracker and delegates to the matching vendor sync skill.
 
-See the `tracker-resolution` rule for configuration and dispatch table.
+See the `config-resolution` rule for configuration and dispatch table.
 
 ## Workflow
 
@@ -16,11 +16,13 @@ See the `tracker-resolution` rule for configuration and dispatch table.
 2. Dispatch:
    - `jira` → invoke `lisa:jira-sync` with `$ARGUMENTS` verbatim.
    - `github` → invoke `lisa:github-sync` with `$ARGUMENTS` verbatim.
+   - `linear` → invoke `lisa:linear-sync` with `$ARGUMENTS` verbatim.
+   - Anything else → stop and report `"Unknown tracker '<value>' in .lisa.config.json. Expected 'jira', 'github', or 'linear'."`
 3. Pass through the output.
 
-If `$ARGUMENTS` is empty, both vendor skills auto-detect a ticket reference from the active plan file (most recently modified `.md` in `plans/`).
+If `$ARGUMENTS` is empty, all vendor skills auto-detect a ticket reference from the active plan file (most recently modified `.md` in `plans/`).
 
 ## Rules
 
 - Idempotent updates — running sync at the same milestone twice should not produce duplicate comments. Vendor skills enforce this.
-- Never auto-transition status. Suggestions only.
+- Never auto-transition the underlying state. Linear's label-based transition (`status:*`) is the canonical signal and is updated only when the caller passes `--update-label`. Native states stay as suggestions.

package/plugins/lisa/skills/tracker-validate/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: tracker-validate
-description: "Vendor-neutral wrapper for the pre-write quality gate. Reads `tracker` from .lisa.config.json (default: jira) and dispatches to lisa:jira-validate-ticket or lisa:github-validate-issue. Read-only — never writes to either tracker. Used by tracker-write Phase 5.5 (pre-write gate), tracker-verify (post-write checks), and the *-to-tracker dry-run paths. Output is structured PASS/FAIL per gate so callers can parse it."
+description: "Vendor-neutral wrapper for the pre-write quality gate. Reads `tracker` from .lisa.config.json (default: jira) and dispatches to lisa:jira-validate-ticket, lisa:github-validate-issue, or lisa:linear-validate-issue. Read-only — never writes to any tracker. Used by tracker-write Phase 5.5 (pre-write gate), tracker-verify (post-write checks), and the *-to-tracker dry-run paths. Output is structured PASS/FAIL per gate so callers can parse it."
 allowed-tools: ["Skill", "Bash", "Read"]
 ---
 
@@ -8,28 +8,29 @@ allowed-tools: ["Skill", "Bash", "Read"]
 
 Thin dispatcher. Resolves the configured destination tracker and delegates to the matching vendor validator.
 
-See the `tracker-resolution` rule for the full configuration schema and skill-mapping table.
+See the `config-resolution` rule for the full configuration schema and skill-mapping table.
 
 ## Workflow
 
 1. **Resolve tracker config** (same logic as `lisa:tracker-write` Step 1):
 
    ```bash
-   tracker=$(jq -r '.tracker // "jira"' .lisa.config.local.json 2>/dev/null \
-     || jq -r '.tracker // "jira"' .lisa.config.json 2>/dev/null \
-     || echo "jira")
+   local_tracker=$(jq -r '.tracker // empty' .lisa.config.local.json 2>/dev/null)
+   global_tracker=$(jq -r '.tracker // empty' .lisa.config.json 2>/dev/null)
+   tracker="${local_tracker:-${global_tracker:-jira}}"
    ```
 
 2. **Dispatch**
 
    - `jira` → invoke `lisa:jira-validate-ticket` with `$ARGUMENTS` verbatim.
    - `github` → invoke `lisa:github-validate-issue` with `$ARGUMENTS` verbatim.
-   - Anything else → stop and report `"Unknown tracker '<value>' in .lisa.config.json."`
+   - `linear` → invoke `lisa:linear-validate-issue` with `$ARGUMENTS` verbatim.
+   - Anything else → stop and report `"Unknown tracker '<value>' in .lisa.config.json. Expected 'jira', 'github', or 'linear'."`
 
 3. **Pass through the validator's structured report unchanged.** Callers (e.g. `lisa:jira-write-ticket` Phase 5.5) parse the gate lines; do not paraphrase.
 
 ## Rules
 
-- Read-only — never write to either tracker.
+- Read-only — never write to any tracker.
 - Never re-implement gate logic here. The gate definitions are the vendor validator's responsibility.
 - Never silently transform the input — pass `$ARGUMENTS` through verbatim.

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

@@ -1,6 +1,6 @@
 ---
 name: tracker-verify
-description: "Vendor-neutral wrapper for the post-write verification gate. Reads `tracker` from .lisa.config.json (default: jira) and dispatches to lisa:jira-verify or lisa:github-verify. Fetches the live ticket/issue and runs the validator gates against the stored state — catches anything dropped or reformatted on write. Read-only."
+description: "Vendor-neutral wrapper for the post-write verification gate. Reads `tracker` from .lisa.config.json (default: jira) and dispatches to lisa:jira-verify, lisa:github-verify, or lisa:linear-verify. Fetches the live ticket/issue and runs the validator gates against the stored state — catches anything dropped or reformatted on write. Read-only."
 allowed-tools: ["Skill", "Bash", "Read"]
 ---
 
@@ -8,7 +8,7 @@ allowed-tools: ["Skill", "Bash", "Read"]
 
 Thin dispatcher. Resolves the configured destination tracker and delegates to the matching vendor post-write verifier.
 
-See the `tracker-resolution` rule for configuration and dispatch table.
+See the `config-resolution` rule for configuration and dispatch table.
 
 ## Workflow
 
@@ -16,6 +16,8 @@ See the `tracker-resolution` rule for configuration and dispatch table.
 2. Dispatch:
    - `jira` → invoke `lisa:jira-verify` with `$ARGUMENTS` verbatim.
    - `github` → invoke `lisa:github-verify` with `$ARGUMENTS` verbatim.
+   - `linear` → invoke `lisa:linear-verify` with `$ARGUMENTS` verbatim.
+   - Anything else → stop and report `"Unknown tracker '<value>' in .lisa.config.json. Expected 'jira', 'github', or 'linear'."`
 3. Pass through the verifier's structured report unchanged.
 
 ## Rules

package/plugins/lisa/skills/tracker-write/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: tracker-write
-description: "Vendor-neutral wrapper for ticket creation and updates. Reads `tracker` from .lisa.config.json (default: jira) and dispatches to lisa:jira-write-ticket or lisa:github-write-issue. Callers in vendor-neutral skills (notion-to-tracker, linear-to-tracker, confluence-to-tracker, github-to-tracker, implement, verify) MUST invoke this skill instead of the vendor-specific ones — that is what makes the tracker switchable per project. The Phase-5.5 validate-pre-write gate, post-write verify, and Phase-8 announce-comment behavior live in the vendor skills; this shim is dispatch only."
+description: "Vendor-neutral wrapper for ticket creation and updates. Reads `tracker` from .lisa.config.json (default: jira) and dispatches to lisa:jira-write-ticket, lisa:github-write-issue, or lisa:linear-write-issue. Callers in vendor-neutral skills (notion-to-tracker, linear-to-tracker, confluence-to-tracker, github-to-tracker, implement, verify) MUST invoke this skill instead of the vendor-specific ones — that is what makes the tracker switchable per project. The Phase-5.5 validate-pre-write gate, post-write verify, and Phase-8 announce-comment behavior live in the vendor skills; this shim is dispatch only."
 allowed-tools: ["Skill", "Bash", "Read"]
 ---
 
@@ -8,7 +8,7 @@ allowed-tools: ["Skill", "Bash", "Read"]
 
 Thin dispatcher. Resolves the configured destination tracker and delegates to the matching vendor write skill.
 
-See the `tracker-resolution` rule for the full configuration schema and skill-mapping table.
+See the `config-resolution` rule for the full configuration schema and skill-mapping table.
 
 ## Workflow
 
@@ -17,27 +17,29 @@ See the `tracker-resolution` rule for the full configuration schema and skill-ma
    Read `.lisa.config.local.json` first (if present), then `.lisa.config.json`. Local overrides global on a per-key basis. Use `jq` — never hand-parse JSON.
 
    ```bash
-   tracker=$(jq -r '.tracker // "jira"' .lisa.config.local.json 2>/dev/null \
-     || jq -r '.tracker // "jira"' .lisa.config.json 2>/dev/null \
-     || echo "jira")
+   local_tracker=$(jq -r '.tracker // empty' .lisa.config.local.json 2>/dev/null)
+   global_tracker=$(jq -r '.tracker // empty' .lisa.config.json 2>/dev/null)
+   tracker="${local_tracker:-${global_tracker:-jira}}"
    ```
 
 2. **Validate the value**
 
-   - `jira` → continue to Step 3a.
-   - `github` → continue to Step 3b. Also confirm `github.org` and `github.repo` are present. If either is missing, stop and report: `"tracker=github but github.org and github.repo are not set in .lisa.config.json."`
-   - Any other value → stop and report: `"Unknown tracker '<value>' in .lisa.config.json. Expected 'jira' or 'github'."`
+   - `jira` → confirm `atlassian.cloudId` and `jira.project` are present. If either is missing, stop and report: `"tracker=jira but atlassian.cloudId and jira.project are not set in .lisa.config.json."` Continue to Step 3a.
+   - `github` → confirm `github.org` and `github.repo` are present. If either is missing, stop and report: `"tracker=github but github.org and github.repo are not set in .lisa.config.json."` Continue to Step 3b.
+   - `linear` → confirm `linear.workspace` and `linear.teamKey` are present. If either is missing, stop and report: `"tracker=linear but linear.workspace and linear.teamKey are not set in .lisa.config.json."` Continue to Step 3c.
+   - Any other value → stop and report: `"Unknown tracker '<value>' in .lisa.config.json. Expected 'jira', 'github', or 'linear'."`
 
 3. **Dispatch**
 
    - **3a (jira):** Invoke `lisa:jira-write-ticket` via the Skill tool, passing `$ARGUMENTS` verbatim.
    - **3b (github):** Invoke `lisa:github-write-issue` via the Skill tool, passing `$ARGUMENTS` verbatim.
+   - **3c (linear):** Invoke `lisa:linear-write-issue` via the Skill tool, passing `$ARGUMENTS` verbatim.
 
 4. **Surface the vendor skill's output unchanged.** Do not paraphrase; downstream callers parse the structured response.
 
 ## Rules
 
 - Never bypass dispatch — calling the vendor skill directly from a vendor-neutral caller defeats the per-project switch.
-- Never invent a third tracker.
+- Never accept a tracker value outside `{jira, github, linear}`.
 - Never mutate `$ARGUMENTS` between layers. The vendor skills define their own input contract.
-- Never inline gate logic here. All validation rules live in the vendor skills (`lisa:jira-validate-ticket` / `lisa:github-validate-issue`); this skill only routes.
+- Never inline gate logic here. All validation rules live in the vendor skills (`lisa:jira-validate-ticket` / `lisa:github-validate-issue` / `lisa:linear-validate-issue`); this skill only routes.

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

@@ -29,7 +29,7 @@ Execute the **Verify** flow as defined in the `intent-routing` rule (loaded via
 4. **Review loop** — handle CodeRabbit / human review comments via `lisa:pull-request-review`
 5. **Merge** when CI is green
 6. **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). If remote verification surfaces a behavioral gap that the existing codified tests do not guard, invoke `codify-verification` to add coverage and open a follow-up PR.
-7. **Evidence** — post results to the originating ticket via `lisa:tracker-evidence` (vendor-neutral; dispatches to `lisa:jira-evidence` or `lisa:github-evidence` per `.lisa.config.json` `tracker`), including the list of codified tests added on this branch.
+7. **Evidence** — post results to the originating ticket via `lisa:tracker-evidence` (vendor-neutral; dispatches to `lisa:jira-evidence`, `lisa:github-evidence`, or `lisa:linear-evidence` per `.lisa.config.json` `tracker`), including the list of codified tests added on this branch.
 
 The rule contains the canonical step sequence. Change it there, propagate everywhere.
 

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

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

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

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

package/plugins/lisa-expo/skills/jira-create/SKILL.md

@@ -11,7 +11,7 @@ Analyze the provided file(s) and plan a JIRA hierarchy. **This skill plans struc
 ## Process
 
 1. **Analyze**: Read $ARGUMENTS to understand scope.
-2. **Extract source artifacts**: invoke the `lisa:jira-source-artifacts` skill, then enumerate every external URL, embed, attachment, or example payload and classify each by domain per its rules. Build the `artifacts` map. See "Source Artifacts" below.
+2. **Extract source artifacts**: invoke the `lisa:tracker-source-artifacts` skill, then enumerate every external URL, embed, attachment, or example payload and classify each by domain per its rules. Build the `artifacts` map. See "Source Artifacts" below.
 3. **Walk the live product** (when applicable): if the work touches existing user-facing surfaces, invoke the `lisa:product-walkthrough` skill to capture current behavior, design-vs-product divergence, and reuse candidates. Especially load-bearing for Expo/React Native — a UI ticket without a current-product walkthrough is missing context the implementer needs. Skip only when the work is purely backend or affects a screen that does not yet exist. See "Live Product Walkthrough" below.
 4. **Determine structure**:
    - Epic needed if: multiple features, major changes, >3 related files
@@ -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 `lisa:jira-write-ticket`** in dependency order (epic first, then stories with the epic as parent, then sub-tasks with their story as parent). Pass the artifacts (filtered by domain per `lisa:jira-source-artifacts` inheritance rules), the walkthrough findings (under `## Current Product`), and — for UI tickets — the Validation Journey draft with `[SCREENSHOT: ...]` markers. See "Delegation to jira-write-ticket" below.
-7. **Run the artifact preservation gate** (`lisa:jira-source-artifacts` §8): after all writes complete, build the preservation matrix and verify every extracted artifact is reachable from the created tickets. Fail loudly if anything was dropped.
+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:tracker-source-artifacts` inheritance rules), the walkthrough findings (under `## Current Product`), and — for UI tickets — the Validation Journey draft with `[SCREENSHOT: ...]` markers. See "Delegation to jira-write-ticket" below.
+7. **Run the artifact preservation gate** (`lisa:tracker-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
 
@@ -95,7 +95,7 @@ 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 `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 `lisa:tracker-source-artifacts` skill** for the canonical rules: domains, per-tool classification (Figma `/proto/` vs design, Lovable, Loom, screenshots), source precedence, conflict handling under `## Open Questions`, inheritance from epic → story → sub-task, and the existing-component reuse expectation. Do not restate the rules here.
 
 Expo-specific note: the existing-component reuse rule is especially load-bearing for React Native — the project has an established component library; pixel-matching a mock instead of reusing components is the most common drift mode.
 

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

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

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

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

package/plugins/lisa-rails/skills/jira-create/SKILL.md

@@ -11,7 +11,7 @@ Analyze the provided file(s) and plan a JIRA hierarchy. **This skill plans struc
 ## Process
 
 1. **Analyze**: Read $ARGUMENTS to understand scope.
-2. **Extract source artifacts**: invoke the `lisa:jira-source-artifacts` skill, then enumerate every external URL, embed, attachment, or example payload and classify each by domain per its rules. Build the `artifacts` map. See "Source Artifacts" below.
+2. **Extract source artifacts**: invoke the `lisa:tracker-source-artifacts` skill, then enumerate every external URL, embed, attachment, or example payload and classify each by domain per its rules. Build the `artifacts` map. See "Source Artifacts" below.
 3. **Walk the live product** (when applicable): if the work touches existing user-facing surfaces, invoke the `lisa:product-walkthrough` skill to capture current behavior, design-vs-product divergence, and reuse candidates. Skip only when the work is purely backend or affects a screen that does not yet exist. See "Live Product Walkthrough" below.
 4. **Determine structure**:
    - Epic needed if: multiple features, major changes, >3 related files
@@ -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 `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.
+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:tracker-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:tracker-source-artifacts` §8): after all writes complete, build the preservation matrix and verify every extracted artifact is reachable from the created tickets. Fail loudly if anything was dropped.
 
 ## Mandatory for Every Code Issue
 
@@ -35,7 +35,7 @@ Analyze the provided file(s) and plan a JIRA hierarchy. **This skill plans struc
 
 If $ARGUMENTS includes (or references) any external artifact — PRD, design doc, Figma URL, Lovable prototype, Loom walkthrough, screenshot, example payload — those references MUST be preserved as remote links on the created tickets. Silent artifact loss is the single most common quality failure in this pipeline.
 
-**Invoke the `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 `lisa:tracker-source-artifacts` skill** for the canonical rules: domains, per-tool classification (Figma `/proto/` vs design, Lovable, Loom, screenshots), source precedence, conflict handling under `## Open Questions`, inheritance from epic → story → sub-task, and the existing-component reuse expectation. Do not restate the rules here.
 
 Rails-specific note: the existing-component reuse rule applies to view partials and ViewComponents — the closest existing partial/component is usually the right answer over pixel-matching a mock from scratch.
 

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

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

package/plugins/src/base/agents/confluence-prd-intake.md

@@ -5,7 +5,7 @@ skills:
   - confluence-prd-intake
   - confluence-to-tracker
   - tracker-validate
-  - jira-source-artifacts
+  - tracker-source-artifacts
   - product-walkthrough
   - tracker-write
   - prd-ticket-coverage

package/plugins/src/base/agents/github-prd-intake.md

@@ -1,11 +1,11 @@
 ---
 name: github-prd-intake
-description: PRD intake agent for GitHub Issues hosted PRDs. Runs one intake cycle against a GitHub repository — claims `prd-ready` issues (relabels to `prd-in-review`), validates each through the dry-run pipeline, and routes to `prd-blocked` (with clarifying comments on the PRD issue) or `prd-ticketed` (with destination tickets created in JIRA or GitHub Issues per .lisa.config.json). GitHub counterpart of `notion-prd-intake`, `confluence-prd-intake`, and `linear-prd-intake`. Designed to be invoked manually via /github-prd-intake or autonomously via a scheduled cron.
+description: PRD intake agent for GitHub Issues hosted PRDs. Runs one intake cycle against a GitHub repository — claims `prd-ready` issues (relabels to `prd-in-review`), validates each through the dry-run pipeline, and routes to `prd-blocked` (with clarifying comments on the PRD issue) or `prd-ticketed` (with destination tickets created in JIRA, GitHub Issues, or Linear per .lisa.config.json). GitHub counterpart of `notion-prd-intake`, `confluence-prd-intake`, and `linear-prd-intake`. Designed to be invoked manually via /github-prd-intake or autonomously via a scheduled cron.
 skills:
   - github-prd-intake
   - github-to-tracker
   - tracker-validate
-  - jira-source-artifacts
+  - tracker-source-artifacts
   - product-walkthrough
   - tracker-write
   - prd-ticket-coverage

package/plugins/src/base/agents/linear-agent.md

@@ -0,0 +1,128 @@
+---
+name: linear-agent
+description: Linear lifecycle agent. Reads Issues, determines intent (Bug → Implement/Fix, Story/Task → Implement/Build, Epic Project → Plan, Spike → Implement/Investigate), delegates to the appropriate flow, syncs progress at milestones, and posts evidence at completion. Linear counterpart of jira-agent and github-agent.
+skills:
+  - linear-read-issue
+  - linear-write-issue
+  - linear-sync
+  - linear-evidence
+  - linear-verify
+  - linear-add-journey
+  - ticket-triage
+---
+
+# Linear Agent
+
+You are a Linear lifecycle agent. Your job is to read a Linear work item, determine what kind of work it represents, delegate to the appropriate flow, and keep the item in sync throughout.
+
+## Workflow
+
+### 1. Read the Item
+
+Invoke the `linear-read-issue` skill with the identifier. This is mandatory — do NOT read the item ad-hoc via MCP calls. The skill fetches the primary item AND its full graph in one pass:
+
+- Full description, acceptance criteria, Validation Journey
+- All comments in chronological order (with thread structure)
+- All metadata (state, priority, assignee, labels, project, parent, cycle, milestone, estimate)
+- Attachments — PRs (with state and unresolved review comments via `gh`), Confluence pages, dashboards
+- Every native relation (`blocks`, `blocked_by`, `relates_to`, `duplicates`) with descriptions, states, recent comments
+- Project parent (Epic-equivalent) — full description, comments, milestones, attached documents
+- Project siblings — so you see in-flight related work before starting
+- Sub-Issues
+
+Pass the resulting context bundle verbatim to every downstream agent. Extract credentials, URLs, and reproduction steps from the bundle. If the skill reports the item is inaccessible, stop and report what access is needed.
+
+**Never act on an item in isolation.** If the bundle shows open blockers, flag them and stop. If it shows a Project sibling in progress with a different assignee, surface that before proceeding so work isn't duplicated.
+
+### 2. Validate Item Quality (Pre-flight Gate)
+
+Use the `linear-verify` skill to check the item against organizational standards:
+- Project parent exists (Stories under Epic), parent Issue exists (Sub-tasks under Story)
+- Description quality (audience sections, Gherkin acceptance criteria)
+- Validation Journey present (runtime-behavior items)
+- Target backend environment named in description (runtime-behavior items)
+- Sign-in credentials named in description (when item touches authenticated surfaces)
+- Single-repo scope (Bug / Task / Sub-task)
+- Relationship discovery (≥1 relation or documented git + Linear search)
+
+**Gating behavior — this is the one place auto-transitioning is allowed:**
+
+If `linear-verify` returns `FAIL` on any of the above, do NOT continue:
+1. Update labels via `mcp__linear-server__save_issue`: remove the current `status:*` label, add `status:blocked`. (Create `status:blocked` via `create_issue_label` if needed.)
+2. Reassign the item to the **Issue creator** (the human who filed it — Linear's `creator` field).
+3. Post a comment via `mcp__linear-server__save_comment` listing each missing requirement with a one-line remediation. Prefix with `[{repo}]`.
+4. Stop. Do not run triage, do not delegate to a flow, do not start work.
+
+If `linear-verify` returns `PASS`, proceed to Step 3.
+
+### 3. Analytical Triage Gate
+
+Determine the repo name: `basename $(git rev-parse --show-toplevel)`
+
+Check if the item already has the `claude-triaged-{repo}` label. If yes, skip to Step 4.
+
+If not triaged:
+1. Fetch the full item details from the context bundle.
+2. Invoke the `ticket-triage` skill with the item details.
+3. Post the skill's findings (ambiguities, edge cases, verification methodology) as comments via `save_comment`. Prefix all comments with `[{repo}]`.
+4. Add the `claude-triaged-{repo}` label via `save_issue` (creating it via `create_issue_label` if missing).
+
+**Gating behavior:**
+- `BLOCKED` (ambiguities found): post the ambiguities; do NOT proceed. Report to the human: "This item has unresolved ambiguities. Triage posted findings as comments. Please resolve and retry."
+- `NOT_RELEVANT`: add the label and report "Item is not relevant to this repository."
+- `PASSED` or `PASSED_WITH_FINDINGS`: proceed to Step 4.
+
+### 4. Determine Intent
+
+Map the item to a flow:
+
+| Item kind | Flow | Work Type |
+|-----------|------|-----------|
+| Project (Epic) | Plan | -- |
+| Story Issue (with `projectId`) | Implement | Build |
+| Task Issue | Implement | Build |
+| Bug Issue | Implement | Fix |
+| Spike Issue | Implement | Investigate Only |
+| Improvement Issue | Implement | Improve |
+| Sub-Issue | Implement | Same as parent's work type |
+
+Linear doesn't have a single "issue type" field like JIRA — type is typically encoded as a label (`type:story`, `type:bug`) or inferred from the description. If the type is ambiguous, read the description to classify. A "Task" describing broken behavior is a Fix; a "Bug" requesting new functionality is a Build.
+
+### 5. Delegate to Flow
+
+Hand off to the appropriate flow as defined in the `intent-routing` rule. Pass the full item context (description, acceptance criteria, credentials, reproduction steps) to the first agent in the flow.
+
+### 6. Sync Progress at Milestones
+
+Use the `linear-sync` skill to update the item at these milestones:
+- **Plan created** — post plan summary, branch name
+- **Implementation started** — post task completion progress
+- **PR ready** — post PR link, summary of changes
+- **PR merged** — post final summary
+
+### 7. Post Evidence at Completion
+
+Use the `linear-evidence` skill to:
+- Upload verification evidence to the GitHub PR
+- Post evidence summary as a Linear comment
+- Transition labels: remove `status:in-progress`, add `status:code-review`
+
+### 8. Suggest Status Transition
+
+Based on the milestone, suggest (but don't auto-transition the native Linear `state`):
+
+| Milestone | Suggested label transition |
+|-----------|---------------------------|
+| Plan created | `status:in-progress` |
+| PR ready | `status:code-review` |
+| PR merged | `status:on-dev` (build-intake will perform if dispatched via that flow) |
+
+The label transitions ARE the canonical signal. The native `state` field stays as the human / triage decision.
+
+## Rules
+
+- Never auto-transition the native Linear `state`, with one explicit exception: when `linear-verify` returns `FAIL` for the pre-flight gate (Step 2), update labels to `status:blocked` and reassign to the creator. Every other status change remains a label-driven suggestion.
+- Always read the full item graph via `linear-read-issue` before determining intent — don't rely on type labels alone.
+- Never create or materially edit an item by calling MCP write tools directly — always delegate to `linear-write-issue` so relationships, Gherkin criteria, and metadata gates are enforced. Two explicit exceptions are permitted: (1) the Step 2 pre-flight failure path (when `linear-verify` returns `FAIL`) may call `mcp__linear-server__save_issue` and `mcp__linear-server__save_comment` directly to set `status:blocked` and reassign to the creator — this narrow exception is already granted by the rule above; (2) the Step 3 triage path may call `mcp__linear-server__save_comment` to post triage findings and `mcp__linear-server__save_issue` to add the `claude-triaged-{repo}` label — these are lightweight metadata updates that do not create or materially edit ticket content and therefore do not need to route through `linear-write-issue`.
+- If sign-in credentials are in the item, extract and pass them to the flow. If the item touches an authenticated surface and credentials are missing, that is a Step 2 failure — block and reassign rather than guessing.
+- If the item has a Validation Journey section, pass it to the verifier agent. The Validation Journey's local-verification step must point at the target backend environment named in the description.