@codyswann/lisa 2.10.1 → 2.11.1

package/plugins/src/base/skills/notion-to-tracker/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: notion-to-tracker
 description: >
-  Break down a Notion PRD into Epics, Stories, and Sub-tasks in the configured destination tracker (JIRA or GitHub Issues per .lisa.config.json). Use this skill whenever the user
+  Break down a Notion PRD into Epics, Stories, and Sub-tasks in the configured destination tracker (JIRA, GitHub Issues, or Linear per .lisa.config.json). Use this skill whenever the user
   shares a Notion PRD URL and wants it converted into tracker tickets, or asks to "break down a PRD",
   "create tickets from a PRD", "turn this PRD into tickets", or similar. Also trigger when the user
   mentions creating epics/stories/tasks from a Notion document. This skill handles the full pipeline:
@@ -11,7 +11,7 @@ description: >
 
 # Notion PRD to Tracker Breakdown
 
-Convert a Notion PRD into a structured ticket hierarchy in the configured destination tracker (JIRA or GitHub Issues per .lisa.config.json): Epics > Stories > Sub-tasks.
+Convert a Notion PRD into a structured ticket hierarchy in the configured destination tracker (JIRA, GitHub Issues, or Linear per .lisa.config.json): Epics > Stories > Sub-tasks.
 Each sub-task is scoped to exactly one repo and includes an empirical verification plan.
 
 ## Modes
@@ -84,21 +84,27 @@ A Notion PRD URL. The PRD is expected to have:
 
 ## Configuration
 
-This skill reads project-specific configuration from environment variables. If these are not set,
-ask the user for the values before proceeding.
+This skill reads project configuration from `.lisa.config.json` (with `.lisa.config.local.json` overriding per key) and operational E2E test config from environment variables. See the `config-resolution` rule for the full schema.
+
+### From `.lisa.config.json`
+
+This skill is a **PRD source** (Notion); destination tracker resolution is handled by `lisa:tracker-write` and `lisa:tracker-validate` internally — this skill does NOT read `tracker` directly. The relevant config for the source side:
+
+| Field | Purpose | Required when |
+|-------|---------|---------------|
+| `notion.prdDatabaseId` | Notion database hosting PRDs | invoked without an explicit Notion page URL (batch / arg-less mode) |
+
+### From environment variables (E2E test config — operational, not tracker)
 
 | Variable | Purpose | Example |
 |----------|---------|---------|
-| `JIRA_PROJECT` | JIRA project key for ticket creation | `SE` |
-| `JIRA_SERVER` | Atlassian instance URL (site host) | `mycompany.atlassian.net` |
 | `E2E_TEST_PHONE` | Test user phone number for verification plans | `0000000099` |
 | `E2E_TEST_OTP` | Test user OTP code | `555555` |
 | `E2E_TEST_ORG` | Test organization name | `Arsenal` |
 | `E2E_BASE_URL` | Frontend base URL for Playwright tests | `https://dev.example.io/` |
 | `E2E_GRAPHQL_URL` | GraphQL API URL for curl verification | `https://gql.dev.example.io/graphql` |
 
-If env vars are not available, ask the user to provide them explicitly before proceeding.
-Do not retrieve credentials from repository files or local agent settings.
+If env vars are not available, ask the user to provide them explicitly before proceeding. Do not retrieve credentials from repository files or local agent settings.
 
 ## Workflow
 
@@ -128,17 +134,17 @@ PRDs typically reference external design, UX, and data artifacts (Figma files, L
    - Embedded images and file attachments on the page itself
    - Fenced code blocks with example data (JSON, SQL, GraphQL, cURL request/response)
 
-2. **Classify each artifact and apply taxonomy rules** by invoking the `lisa:jira-source-artifacts` skill. That skill is the single source of truth for: domains (`ui-design` / `ux-flow` / `data` / `ops` / `reference`), per-tool classification rules (Figma `/proto/` vs design, Lovable as `ux-flow`, Loom, screenshots), and coverage smells. Do not restate the rules here — invoke the skill so any drift in the rules propagates uniformly.
+2. **Classify each artifact and apply taxonomy rules** by invoking the `lisa:tracker-source-artifacts` skill. That skill is the single source of truth for: domains (`ui-design` / `ux-flow` / `data` / `ops` / `reference`), per-tool classification rules (Figma `/proto/` vs design, Lovable as `ux-flow`, Loom, screenshots), and coverage smells. Do not restate the rules here — invoke the skill so any drift in the rules propagates uniformly.
 
 3. **Build an `artifacts` map** keyed by domain. Each entry: `{ url, title, domain, source_page, source_page_url, classification_reason }`. The `classification_reason` makes disambiguation auditable ("Figma URL contains `/proto/` → ux-flow"). The `source_page` lets you trace each reference back to where it appeared in the PRD.
 
-4. **Surface coverage smells** as defined in `lisa:jira-source-artifacts` §5 (zero artifacts, prototype-without-mock, mock-without-prototype, Lovable-without-business-rules). Record any detected smells on the epic.
+4. **Surface coverage smells** as defined in `lisa:tracker-source-artifacts` §5 (zero artifacts, prototype-without-mock, mock-without-prototype, Lovable-without-business-rules). Record any detected smells on the epic.
 
 ### Phase 1.6: Source Precedence & Conflict Resolution
 
-Source precedence rules and cross-axis conflict handling are defined in `lisa:jira-source-artifacts` §3 and §4. Apply them during ticket synthesis: every conflict between artifacts must be recorded under `## Open Questions` on the affected ticket, never silently reconciled.
+Source precedence rules and cross-axis conflict handling are defined in `lisa:tracker-source-artifacts` §3 and §4. Apply them during ticket synthesis: every conflict between artifacts must be recorded under `## Open Questions` on the affected ticket, never silently reconciled.
 
-The existing-component reuse expectation (mocks define visual intent, not implementation shortcut) is defined in `lisa:jira-source-artifacts` §7. Encode it on every UI-touching story.
+The existing-component reuse expectation (mocks define visual intent, not implementation shortcut) is defined in `lisa:tracker-source-artifacts` §7. Encode it on every UI-touching story.
 
 ### Phase 2: Codebase + Live Product Research
 
@@ -164,7 +170,7 @@ Walkthrough findings are attached to the originating Notion PRD as a comment ("C
 
 For each PRD epic, **invoke the `lisa:tracker-write` skill** (do not call `createJiraIssue` directly). Pass it everything it needs to enforce its quality gates:
 
-- `project_key`: from `JIRA_PROJECT` config
+- `project_key`: resolved by `lisa:tracker-write` from `.lisa.config.json`
 - `issue_type`: `Epic`
 - `summary`: epic title from the PRD
 - `description_body`: a draft of the 3-audience description containing:
@@ -195,7 +201,7 @@ For each Epic, plan two kinds of stories:
 
 For each story, **invoke `lisa:tracker-write`** with:
 
-- `project_key`: from `JIRA_PROJECT` config
+- `project_key`: resolved by `lisa:tracker-write` from `.lisa.config.json`
 - `issue_type`: `Story`
 - `epic_parent`: the Epic key captured in Phase 3 (mandatory — `lisa:tracker-write` rejects non-bug, non-epic tickets without an epic parent)
 - `summary`: prefixed per the naming convention above
@@ -242,7 +248,7 @@ Sub-tasks inherit their parent story's artifacts by reference (the parent link).
 
 ### Phase 5.5: Artifact Preservation Gate (mandatory)
 
-Run the preservation gate defined in `lisa:jira-source-artifacts` §8 against the artifacts extracted in Phase 1.5 and the tickets just created. Do NOT restate or modify the gate logic here — invoke the rules from `lisa:jira-source-artifacts` so any rule change propagates uniformly.
+Run the preservation gate defined in `lisa:tracker-source-artifacts` §8 against the artifacts extracted in Phase 1.5 and the tickets just created. Do NOT restate or modify the gate logic here — invoke the rules from `lisa:tracker-source-artifacts` so any rule change propagates uniformly.
 
 To run the gate, this skill must:
 

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

@@ -1,6 +1,6 @@
 ---
 name: plan
-description: "Decompose a single PRD or specification into ordered work items in the configured tracker. Vendor-agnostic — the source can be a Notion PRD URL, a Confluence PRD URL, a Linear project URL, a GitHub Issue URL, an existing JIRA epic key, a markdown file, or a free-form description; the destination tracker is whatever the project is configured to use via `.lisa.config.json` `tracker` (JIRA or GitHub Issues). Single-PRD mode only — for batch scanning of all Ready PRDs in a queue, use the lisa:intake skill."
+description: "Decompose a single PRD or specification into ordered work items in the configured tracker. Vendor-agnostic — the source can be a Notion PRD URL, a Confluence PRD URL, a Linear project URL, a GitHub Issue URL, an existing JIRA epic key, a markdown file, or a free-form description; the destination tracker is whatever the project is configured to use via `.lisa.config.json` `tracker` (JIRA, GitHub Issues, or Linear). Single-PRD mode only — for batch scanning of all Ready PRDs in a queue, use the lisa:intake skill."
 allowed-tools: ["Skill", "Bash", "Read", "Glob", "Grep"]
 ---
 
@@ -32,6 +32,7 @@ Detect the input type from `$ARGUMENTS` and route to the appropriate source skil
 | A Linear **project** URL (`https://linear.app/<workspace>/project/<slug>-<id>`) | `lisa:linear-to-tracker` (with the project URL; same full pipeline as the Notion / Confluence paths). The Linear project's description, attached documents, and sub-issues form the PRD body. |
 | A Linear **workspace** URL (`https://linear.app/<workspace>` with no `/project/...`) or **team** URL | Stop and report — single-PRD mode only. Direct the caller to `lisa:intake` for batch scanning of a workspace or team. |
 | A JIRA ticket ID/URL of an Epic (existing epic *is* the spec) | `lisa:jira-agent` (read epic, decompose into stories/sub-tasks) |
+| A Linear Project URL of a Project that *is* the spec, when destination tracker = `linear` | `lisa:linear-agent` (read project, decompose into Issues / sub-Issues). Symmetric counterpart to the JIRA-Epic and GitHub-Epic branches. |
 | A GitHub **issue** URL (`https://github.com/<org>/<repo>/issues/<number>`) or `<org>/<repo>#<number>` token (single PRD) | `lisa:github-to-tracker` (with the issue ref; runs the full pipeline: extract artifacts → walk live product → validate → write tickets → coverage audit). The destination tracker is read from `.lisa.config.json` `tracker`. |
 | A GitHub **repository** URL or `<org>/<repo>` token (no issue number) | Stop and report — single-PRD mode only. Direct the caller to `lisa:intake` for batch scanning of a GitHub repo. |
 | A GitHub Issue URL of a build-side ticket (`type:Epic` / `type:Story` / etc., not `prd-*`-labelled) when `tracker = github` | `lisa:github-agent` (read issue, decompose into Sub-tasks). Symmetric counterpart to the JIRA-Epic branch above. |
@@ -46,4 +47,4 @@ Execute the **Plan** flow as defined in the `intent-routing` rule (loaded via th
 
 ## Output
 
-Work items in the configured tracker (JIRA or GitHub Issues, per `.lisa.config.json` `tracker`) with acceptance criteria, dependencies, and recommended skills/agents per item. Ordered by dependency. If the specification cannot be decomposed without further clarification, stop and report what is missing.
+Work items in the configured tracker (JIRA, GitHub Issues, or Linear, per `.lisa.config.json` `tracker`) with acceptance criteria, dependencies, and recommended skills/agents per item. Ordered by dependency. If the specification cannot be decomposed without further clarification, stop and report what is missing.

package/plugins/src/base/skills/prd-ticket-coverage/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: prd-ticket-coverage
-description: "Verifies that every requirement in a PRD (Notion, Confluence, Linear, or GitHub Issues) is covered by at least one created destination ticket (JIRA or GitHub Issues) — no silent drops. Parses the PRD into atomic items (goals, user stories, functional/non-functional requirements, acceptance criteria, important notes), maps each to the created tickets, and produces a coverage matrix and verdict (COMPLETE / COMPLETE_WITH_SCOPE_CREEP / GAPS_FOUND / NO_TICKETS_FOUND). Used by notion-prd-intake / confluence-prd-intake / linear-prd-intake / github-prd-intake post-write to gate the Ticketed transition; can also be invoked standalone for after-the-fact audits."
+description: "Verifies that every requirement in a PRD (Notion, Confluence, Linear, or GitHub Issues) is covered by at least one created destination ticket (JIRA, GitHub Issues, or Linear) — no silent drops. Parses the PRD into atomic items (goals, user stories, functional/non-functional requirements, acceptance criteria, important notes), maps each to the created tickets, and produces a coverage matrix and verdict (COMPLETE / COMPLETE_WITH_SCOPE_CREEP / GAPS_FOUND / NO_TICKETS_FOUND). Used by notion-prd-intake / confluence-prd-intake / linear-prd-intake / github-prd-intake post-write to gate the Ticketed transition; can also be invoked standalone for after-the-fact audits."
 allowed-tools: ["Skill", "Bash", "mcp__claude_ai_Notion__notion-fetch", "mcp__claude_ai_Notion__notion-get-comments", "mcp__atlassian__getConfluencePage", "mcp__atlassian__getConfluencePageDescendants", "mcp__atlassian__getConfluencePageFooterComments", "mcp__atlassian__getConfluencePageInlineComments", "mcp__atlassian__getConfluenceCommentChildren", "mcp__atlassian__getJiraIssue", "mcp__atlassian__searchJiraIssuesUsingJql", "mcp__atlassian__getAccessibleAtlassianResources", "mcp__linear-server__get_project", "mcp__linear-server__list_documents", "mcp__linear-server__get_document", "mcp__linear-server__list_issues", "mcp__linear-server__get_issue", "mcp__linear-server__list_comments"]
 ---
 

package/plugins/src/base/skills/product-walkthrough/SKILL.md

@@ -66,8 +66,8 @@ For every walkthrough, record:
 
 - **What exists today**: a short prose description of the current flow, the components in use (if you can identify them from the DOM via `browser_snapshot`), and the states observed.
 - **What the PRD changes**: explicit delta — added screens, removed screens, modified components, new states, removed states.
-- **Existing-component reuse candidates**: components in the current product that could absorb the new behavior. The PRD-vs-current-product comparison drives which existing components a developer should reuse instead of building new (see `lisa:jira-source-artifacts` §7).
-- **Design-vs-current-product divergence**: places where the mock/prototype materially diverges from what's shipped. Each divergence is a discussion item, not an automatic "rebuild from scratch" — see `lisa:jira-source-artifacts` §3 (mocks define visual intent, not implementation shortcut).
+- **Existing-component reuse candidates**: components in the current product that could absorb the new behavior. The PRD-vs-current-product comparison drives which existing components a developer should reuse instead of building new (see `lisa:tracker-source-artifacts` §7).
+- **Design-vs-current-product divergence**: places where the mock/prototype materially diverges from what's shipped. Each divergence is a discussion item, not an automatic "rebuild from scratch" — see `lisa:tracker-source-artifacts` §3 (mocks define visual intent, not implementation shortcut).
 - **Coverage smells**: states the PRD doesn't address that exist today (e.g., the mock shows the empty state but ignores the populated state that has 90% of users).
 - **Behavioral surprises**: anything that doesn't match the PRD's assumptions about current behavior — these are usually the most valuable findings, because they invalidate parts of the PRD.
 

package/plugins/src/base/skills/spec-conformance/SKILL.md

@@ -24,8 +24,7 @@ Based on the source, load the full spec:
 | Source | How to Load |
 |--------|-------------|
 | Plan file (`.md`) | `Read` the file |
-| JIRA key or GitHub issue ref | Invoke `/tracker-read <ref>` (vendor-neutral; dispatches to `/jira-read-ticket` or `/github-read-issue` per `.lisa.config.json` `tracker`) to get the full context bundle (primary ticket + epic / parent + linked tickets) |
-| Linear key | Fetch via Linear MCP if available; else `Bash` with Linear CLI; else report "Linear reader unavailable" |
+| JIRA key, GitHub issue ref, or Linear identifier | Invoke `/tracker-read <ref>` (vendor-neutral; dispatches to `/jira-read-ticket`, `/github-read-issue`, or `/linear-read-issue` per `.lisa.config.json` `tracker`) to get the full context bundle (primary item + epic / project / parent + linked items) |
 | PRD | `Read` the file or fetch via Notion / Confluence MCP, or `gh issue view` for a GitHub PRD |
 
 ## Phase 2 — Extract Requirements

package/plugins/src/base/skills/ticket-triage/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: ticket-triage
-description: "Analytical triage gate for tickets in the configured destination tracker (JIRA or GitHub Issues). Detects requirement ambiguities, identifies edge cases from codebase analysis, and plans verification methodology. Posts findings to the ticket and produces a verdict (BLOCKED/PASSED_WITH_FINDINGS/PASSED) that gates whether implementation can proceed. Vendor-neutral: the caller (jira-agent or github-agent) is responsible for fetching the ticket via lisa:tracker-read, running the pre-flight gate via lisa:tracker-verify, and posting findings via the matching vendor comment tool."
+description: "Analytical triage gate for tickets in the configured destination tracker (JIRA, GitHub Issues, or Linear). Detects requirement ambiguities, identifies edge cases from codebase analysis, and plans verification methodology. Posts findings to the ticket and produces a verdict (BLOCKED/PASSED_WITH_FINDINGS/PASSED) that gates whether implementation can proceed. Vendor-neutral: the caller (jira-agent or github-agent) is responsible for fetching the ticket via lisa:tracker-read, running the pre-flight gate via lisa:tracker-verify, and posting findings via the matching vendor comment tool."
 allowed-tools: ["Read", "Glob", "Grep", "Bash"]
 ---
 

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

@@ -1,6 +1,6 @@
 ---
 name: tracker-add-journey
-description: "Vendor-neutral wrapper for appending a Validation Journey section to an existing ticket/issue. Reads `tracker` from .lisa.config.json (default: jira) and dispatches to lisa:jira-add-journey or lisa:github-add-journey."
+description: "Vendor-neutral wrapper for appending a Validation Journey section to an existing ticket/issue. Reads `tracker` from .lisa.config.json (default: jira) and dispatches to lisa:jira-add-journey, lisa:github-add-journey, or lisa:linear-add-journey."
 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 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-add-journey` with `$ARGUMENTS` verbatim. Arg: a JIRA ticket key.
    - `github` → invoke `lisa:github-add-journey` with `$ARGUMENTS` verbatim. Arg: `org/repo#<number>` or a GitHub issue URL.
+   - `linear` → invoke `lisa:linear-add-journey` with `$ARGUMENTS` verbatim. Arg: 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 output.
 
 ## Rules
 
-- The Validation Journey content format is identical across both vendors (markdown sections with `[EVIDENCE: name]` markers). The only difference is how the section is appended — JIRA via `editJiraIssue`, GitHub via `gh issue edit --body-file`.
+- The Validation Journey content format is identical across all vendors (markdown sections with `[EVIDENCE: name]` markers). The only difference is how the section is appended — JIRA via `editJiraIssue` (Jira wiki markup), GitHub via `gh issue edit --body-file` (markdown), Linear via `save_issue` (markdown).
 - If the ticket already has a Validation Journey, the vendor skill reports it and stops. This shim does not retry.

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

@@ -1,6 +1,6 @@
 ---
 name: tracker-build-intake
-description: "Vendor-neutral wrapper for the build-queue batch scanner. Reads `tracker` from .lisa.config.json (default: jira) and dispatches to lisa:jira-build-intake (JQL/project-key queue) or lisa:github-build-intake (GitHub repo queue keyed off the `status:ready` label). Counterpart to lisa:intake's PRD-side dispatchers."
+description: "Vendor-neutral wrapper for the build-queue batch scanner. Reads `tracker` from .lisa.config.json (default: jira) and dispatches to lisa:jira-build-intake (JQL/project-key queue), lisa:github-build-intake (GitHub repo queue keyed off the `status:ready` label), or lisa:linear-build-intake (Linear team queue keyed off the `status:ready` label). Counterpart to lisa:intake's PRD-side dispatchers."
 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 build-queue scanner.
 
-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-build-intake` with `$ARGUMENTS` verbatim. Arg shape: a JIRA project key (e.g., `SE`) or a JQL filter.
    - `github` → invoke `lisa:github-build-intake` with `$ARGUMENTS` verbatim. Arg shape: a GitHub `org/repo` token or a full GitHub repo URL.
+   - `linear` → invoke `lisa:linear-build-intake` with `$ARGUMENTS` verbatim. Arg shape: a Linear team key (e.g., `ENG`) or the literal token `linear` (which falls back to `linear.teamKey`).
+   - Anything else → stop and report `"Unknown tracker '<value>' in .lisa.config.json. Expected 'jira', 'github', or 'linear'."`
 3. Pass through the cycle summary verbatim.
 
 ## Rules
 
 - Single cycle per invocation — the vendor skill processes the current `Ready` set and exits.
-- The vendor skills run their own pre-flight checks (JIRA workflow transitions for the JIRA path; label namespace adoption for the GitHub path) before processing items. Never bypass.
+- The vendor skills run their own pre-flight checks (JIRA workflow transitions for the JIRA path; label namespace adoption for the GitHub and Linear paths) before processing items. Never bypass.
 - Never run two intake cycles concurrently against overlapping queues — the scheduling layer is responsible for serialization.

package/plugins/src/base/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/src/base/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/src/base/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/src/base/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/src/base/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/src/base/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/src/base/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/src/base/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/src/base/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/src/base/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/src/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.