@codyswann/lisa 2.10.1 → 2.11.0

package/plugins/lisa/skills/confluence-to-tracker/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: confluence-to-tracker
 description: >
-  Break down a Confluence PRD page into Epics, Stories, and Sub-tasks in the configured destination tracker (JIRA or GitHub Issues per .lisa.config.json). Use this skill whenever the
+  Break down a Confluence PRD page 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 Confluence PRD URL and wants it converted into tracker tickets, or asks to "break down
   this Confluence spec", "create tickets from a Confluence page", "turn this Confluence doc into tickets",
   or similar. This skill mirrors `lisa:notion-to-tracker` for projects whose PRDs live in Confluence —
@@ -12,7 +12,7 @@ allowed-tools: ["Skill", "Bash", "mcp__atlassian__getConfluencePage", "mcp__atla
 
 # Confluence PRD to Tracker Breakdown
 
-Convert a Confluence 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 Confluence 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.
 
 This skill is the Confluence counterpart of `lisa:notion-to-tracker`. The two skills share the same
@@ -102,22 +102,29 @@ page. The caller wanted `lisa:confluence-prd-intake` (batch mode).
 
 ## 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** (Confluence); 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 |
+|-------|---------|---------------|
+| `atlassian.cloudId` | Atlassian Cloud site UUID for Confluence MCP calls | always |
+| `confluence.spaceKey` | Confluence space hosting PRDs | invoked without an explicit page URL (batch / arg-less mode) and `confluence.parentPageId` is unset |
+| `confluence.parentPageId` | Confluence parent page under which PRDs live | invoked without an explicit page URL (batch / arg-less mode) and `confluence.spaceKey` is unset |
+
+### 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` |
-| `CONFLUENCE_HOST` | Confluence host (often same as `JIRA_SERVER`) | `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
 
@@ -151,17 +158,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. 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. Record any detected smells on the epic.
+4. **Surface coverage smells** as defined in `lisa:tracker-source-artifacts` §5. 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 is defined in `lisa:jira-source-artifacts` §7. Encode it on every UI-touching story.
+The existing-component reuse expectation is defined in `lisa:tracker-source-artifacts` §7. Encode it on every UI-touching story.
 
 ### Phase 2: Codebase + Live Product Research
 
@@ -181,7 +188,7 @@ Walkthrough findings are attached to the originating Confluence PRD as a **foote
 
 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:
@@ -209,7 +216,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)
 - `summary`: prefixed per the naming convention above
@@ -237,7 +244,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`.
+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`.
 
 To run the gate, this skill must:
 

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

@@ -11,7 +11,7 @@ Analyze the provided file(s) and plan a GitHub Issue hierarchy. **This skill pla
 ## Process
 
 1. **Analyze**: Read `$ARGUMENTS` to understand scope.
-2. **Extract source artifacts**: invoke the `lisa:jira-source-artifacts` skill (vendor-neutral), then enumerate every external URL, embed, attachment, or example payload in the input and classify each by domain per its rules. Build the `artifacts` map (one entry per artifact: url, title, domain, source page, classification reason).
+2. **Extract source artifacts**: invoke the `lisa:tracker-source-artifacts` skill (vendor-neutral), then enumerate every external URL, embed, attachment, or example payload in the input and classify each by domain per its rules. Build the `artifacts` map (one entry per artifact: url, title, domain, source page, classification reason).
 3. **Walk the live product** (when applicable): if the work touches existing user-facing surfaces, invoke the `lisa:product-walkthrough` skill.
 4. **Determine structure**:
    - Epic needed if: multiple features, major changes, >3 related files.
@@ -22,8 +22,8 @@ Analyze the provided file(s) and plan a GitHub Issue hierarchy. **This skill pla
    Epic → Story → Sub-tasks (test, implement, document, cleanup)
    ```
 
-6. **Delegate every write to `lisa:github-write-issue`** in dependency order (Epic first, then Stories with the Epic as parent sub-issue, then Sub-tasks with their Story as parent). Pass artifacts (filtered by domain per `lisa:jira-source-artifacts` inheritance rules) and walkthrough findings (under `## Current Product`).
-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 issues. Fail loudly if anything was dropped.
+6. **Delegate every write to `lisa:github-write-issue`** in dependency order (Epic first, then Stories with the Epic as parent sub-issue, then Sub-tasks with their Story as parent). Pass artifacts (filtered by domain per `lisa:tracker-source-artifacts` inheritance rules) and walkthrough findings (under `## Current Product`).
+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 issues. Fail loudly if anything was dropped.
 
 ## Mandatory for Every Code Issue
 
@@ -40,7 +40,7 @@ Issues that change runtime behavior should include a `## Validation Journey` sec
 
 If `$ARGUMENTS` references any external artifact — PRD, design doc, Figma URL, Lovable prototype, Loom walkthrough, screenshot, example payload — those references MUST be preserved as `## Links` and `## Source Artifacts` sections on the created issues. Silent artifact loss is the single most common quality failure in this pipeline.
 
-**Invoke `lisa:jira-source-artifacts`** for the canonical rules: domains, per-tool classification, source precedence, conflict handling under `## Open Questions`, inheritance from epic → story → sub-task, and the existing-component reuse expectation. This skill is vendor-neutral and used by both the JIRA and the GitHub paths.
+**Invoke `lisa:tracker-source-artifacts`** for the canonical rules: domains, per-tool classification, source precedence, conflict handling under `## Open Questions`, inheritance from epic → story → sub-task, and the existing-component reuse expectation. This skill is vendor-neutral and used by both the JIRA and the GitHub paths.
 
 When delegating actual writes to `lisa:github-write-issue`, pass the extracted artifact list so its Phase 4c (Remote Links / Source Artifacts) step attaches them.
 

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

@@ -1,6 +1,6 @@
 ---
 name: github-prd-intake
-description: "Scans a GitHub repository for issues labeled `prd-ready` and runs each one through the dry-run validation pipeline. PRDs that pass every gate get tickets written (to whatever destination tracker is configured — JIRA or GitHub Issues itself) and the label flipped to `prd-ticketed`; PRDs that fail get clarifying-question comments and the label flipped to `prd-blocked`. The GitHub counterpart of lisa:notion-prd-intake / lisa:confluence-prd-intake / lisa:linear-prd-intake. Composes existing skills (github-to-tracker, tracker-validate, jira-source-artifacts, product-walkthrough)."
+description: "Scans a GitHub repository for issues labeled `prd-ready` and runs each one through the dry-run validation pipeline. PRDs that pass every gate get tickets written (to whatever destination tracker is configured — JIRA, GitHub Issues itself, or Linear) and the label flipped to `prd-ticketed`; PRDs that fail get clarifying-question comments and the label flipped to `prd-blocked`. The GitHub counterpart of lisa:notion-prd-intake / lisa:confluence-prd-intake / lisa:linear-prd-intake. Composes existing skills (github-to-tracker, tracker-validate, tracker-source-artifacts, product-walkthrough)."
 allowed-tools: ["Skill", "Bash"]
 ---
 
@@ -116,7 +116,7 @@ Invoke the `lisa:github-to-tracker` skill with `dry_run: true` and the PRD issue
 - An overall PASS / FAIL verdict
 - A failure count
 
-This call indirectly invokes `lisa:jira-source-artifacts` (artifact extraction + classification) and `lisa:product-walkthrough` (when the PRD touches existing user-facing surfaces). All gate logic lives in `lisa:tracker-validate` (which dispatches to `lisa:jira-validate-ticket` or `lisa:github-validate-issue` depending on the configured destination).
+This call indirectly invokes `lisa:tracker-source-artifacts` (artifact extraction + classification) and `lisa:product-walkthrough` (when the PRD touches existing user-facing surfaces). All gate logic lives in `lisa:tracker-validate` (which dispatches to `lisa:jira-validate-ticket` or `lisa:github-validate-issue` depending on the configured destination).
 
 #### 3c. Branch on the verdict
 
@@ -254,7 +254,12 @@ When the configured destination tracker is GitHub Issues AND the PRD repo is the
 
 ## Configuration
 
-Same env vars as `lisa:github-to-tracker` plus `.lisa.config.json` `github.org` / `github.repo`. If any required value is missing, surface and exit — never invent values.
+Same configuration as `lisa:github-to-tracker`. See that skill for the full table. Key items:
+
+- **From `.lisa.config.json`**: `github.org` and `github.repo` (required for the source repo, and also for the destination repo when `tracker = "github"` — self-host case).
+- **From environment variables**: `E2E_BASE_URL`, `E2E_TEST_PHONE`, `E2E_TEST_OTP`, `E2E_TEST_ORG`, `E2E_GRAPHQL_URL` (operational E2E test config).
+
+Destination tracker config (jira / github / linear) is consumed by `lisa:tracker-write` internally — this skill does NOT read it. If any required value is missing, surface and exit — never invent values.
 
 ## Rules
 

package/plugins/lisa/skills/github-to-tracker/SKILL.md

@@ -103,20 +103,29 @@ Resolve `<org>/<repo>` from `.lisa.config.json` if `$ARGUMENTS` is just `#<n>` o
 
 ## Configuration
 
-This skill reads project-specific configuration from environment variables and from `.lisa.config.json`. If these are not set, ask the user before proceeding — never invent values.
-
-| Variable / config | Purpose | Example |
-|-------------------|---------|---------|
-| `.lisa.config.json` `tracker` | Destination tracker (jira / github) | `github` |
-| `.lisa.config.json` `github.org` / `github.repo` | GitHub org/repo when tracker=github (and the source repo) | `acme` / `frontend-v2` |
-| `JIRA_PROJECT` | Destination JIRA project key when tracker=jira | `SE` |
-| `JIRA_SERVER` | Atlassian instance URL | `mycompany.atlassian.net` |
+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** (GitHub Issues). Destination tracker resolution is handled by `lisa:tracker-write` / `lisa:tracker-validate` internally; this skill reads only the source-side config.
+
+| Field | Purpose | Required when |
+|-------|---------|---------------|
+| `github.org` | GitHub org hosting the PRD repo | always (source repo); also when `tracker = "github"` (destination repo, can be the same in self-host case) |
+| `github.repo` | GitHub repo hosting the PRD | same |
+
+### From environment variables (E2E test config — operational, not tracker)
+
+| Variable | Purpose | Example |
+|----------|---------|---------|
 | `E2E_TEST_PHONE` | Test user phone 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.
+
 ## Workflow
 
 ### Phase 1: Fetch & Analyze the PRD
@@ -146,17 +155,17 @@ PRDs typically reference external design, UX, and data artifacts (Figma files, L
    - Embedded images and file attachments referenced in the body
    - 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, and coverage smells.
+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, and coverage smells.
 
 3. **Build an `artifacts` map** keyed by domain. Each entry: `{ url, title, domain, source_page, source_page_url, classification_reason }`. `source_page` lets you trace each reference back to where it appeared (PRD body vs a specific sub-issue vs a specific comment).
 
-4. **Surface coverage smells** as defined in `lisa:jira-source-artifacts` §5. Record on the Epic.
+4. **Surface coverage smells** as defined in `lisa:tracker-source-artifacts` §5. Record 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 is defined in `lisa:jira-source-artifacts` §7. Encode it on every UI-touching story.
+The existing-component reuse expectation is defined in `lisa:tracker-source-artifacts` §7. Encode it on every UI-touching story.
 
 ### Phase 2: Codebase + Live Product Research
 
@@ -230,7 +239,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`.
+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`.
 
 To run the gate, this skill must:
 

package/plugins/lisa/skills/github-write-issue/SKILL.md

@@ -92,7 +92,7 @@ Scenario: <name>
 ## Source Artifacts
 [Group by domain (UI / UX flow / Data / Ops / Reference). One bullet per
  artifact with title and URL. Inherited from the parent epic per the rules
- in lisa:jira-source-artifacts.]
+ in lisa:tracker-source-artifacts.]
 
 ## Source Precedence
 [When artifacts are attached, name the authoritative source per axis:
@@ -175,7 +175,7 @@ Identify and attach (under `## Links`):
 - Related GitHub PRs, branches, or commits.
 - Confluence / Notion / Linear PRD pages (the originating PRD).
 - Dashboards (Grafana, Datadog, Sentry).
-- **Source artifacts from the originating PRD / parent Epic**: classify and inherit per `lisa:jira-source-artifacts`. Inherit by domain — UI → `ui-design` + `ux-flow`; backend → `data`; infra → `ops`; always inherit `reference`. Never assume a developer will walk up to the Epic to find design context.
+- **Source artifacts from the originating PRD / parent Epic**: classify and inherit per `lisa:tracker-source-artifacts`. Inherit by domain — UI → `ui-design` + `ux-flow`; backend → `data`; infra → `ops`; always inherit `reference`. Never assume a developer will walk up to the Epic to find design context.
 
 If the issue was generated from a PRD and the parent Epic has no source artifacts, surface that as a smell and ask whether artifacts were missed during extraction.
 

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

@@ -27,7 +27,7 @@ The team lead does NOT read the input directly. The first task on the team's pla
 - If it's a ticket, calls `lisa:tracker-read` (preferred — vendor-agnostic; dispatches per `.lisa.config.json` `tracker`). **Mismatch guard**: if the ticket format doesn't match the configured tracker (e.g., a GitHub URL when `tracker` is `jira`), `tracker-read` stops and reports the error — never auto-translates vendors:
   - JIRA ticket → `lisa:tracker-read` → `lisa:jira-read-ticket`
   - GitHub Issue → `lisa:tracker-read` → `lisa:github-read-issue`
-  - Linear ticket → the Linear CLI (no `lisa:linear-*` build-side adapter; Linear is a PRD source only)
+  - Linear identifier or project URL → `lisa:tracker-read` → `lisa:linear-read-issue`
   - Captures comments and metadata, not just the description.
 - If it's a file, reads the entire file without offset or limit.
 - If it's a plain-text request, uses the provided text verbatim as the resolved input.

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

@@ -49,7 +49,7 @@ Detect the queue type from `$ARGUMENTS` and route:
 | A Confluence **parent page** URL or page ID (the page whose descendants are PRDs) | PRD queue (Confluence, narrowed) | Invoke `lisa:confluence-prd-intake` with the parent ID (CQL: `ancestor = <id> AND label = "prd-ready"`) |
 | A Linear **workspace** URL (e.g. `https://linear.app/acme`) | PRD queue (Linear) | Invoke `lisa:linear-prd-intake` (which queries `list_projects({label: "prd-ready"})` across the workspace, claims each by relabeling to `prd-in-review`, runs the dry-run validate → branch → write pipeline) |
 | A Linear **team** URL (e.g. `https://linear.app/acme/team/ENG/projects`) or a token already routed as a Linear team key | PRD queue (Linear, narrowed) | Invoke `lisa:linear-prd-intake` with the team key (`list_projects({team, label: "prd-ready"})`) |
-| The literal token `linear` | PRD queue (Linear, default workspace) | Invoke `lisa:linear-prd-intake linear` — only valid if `LINEAR_WORKSPACE` is configured |
+| The literal token `linear` | PRD queue (Linear, default workspace) | Invoke `lisa:linear-prd-intake linear` — only valid if `linear.workspace` is configured in `.lisa.config.json` |
 | A JIRA project key (e.g. `SE`) | Work queue (JIRA) | Invoke `lisa:jira-build-intake` (which scans the project for Status=Ready, claims each via In Progress, runs `lisa:implement` per ticket, transitions to On Dev on success) |
 | A full JQL filter (e.g. `project = SE AND component = "frontend"`) | Work queue (JIRA, narrowed) | Invoke `lisa:jira-build-intake` with the JQL |
 | A GitHub **repository** URL or `org/repo` token (e.g. `https://github.com/acme/product-prds` or `acme/product-prds`) when used for **PRDs** | PRD queue (GitHub) | Invoke `lisa:github-prd-intake` (which queries `gh issue list --label prd-ready`, claims each by relabeling to `prd-in-review`, runs the dry-run validate → branch → write pipeline). PRD discovery is independent of the destination tracker — the resulting tickets land wherever `.lisa.config.json` `tracker` says. |
@@ -62,10 +62,10 @@ Disambiguation rules:
 - An Atlassian Confluence URL containing `/wiki/spaces/<KEY>` with no `/pages/...` segment → Confluence space queue.
 - An Atlassian Confluence URL containing `/wiki/spaces/<KEY>/pages/<ID>/...` → Confluence parent-page queue (the page is the parent whose descendants are PRDs). If the user actually meant "this single page is a PRD, plan it", route to `lisa:plan` instead — this skill is batch-only.
 - A `linear.app` URL → Linear queue. If the path is `/<workspace>` only or `/<workspace>/team/<KEY>/...`, route here. If the path includes `/project/<slug>-<id>` it's a single-PRD URL — direct the caller to `lisa:plan` instead, this skill is batch-only.
-- The literal token `linear` (case-insensitive) → Linear queue, default workspace from `LINEAR_WORKSPACE`.
+- The literal token `linear` (case-insensitive) → Linear queue, default workspace from `linear.workspace` in `.lisa.config.json`.
 - A `github.com` URL or an `<org>/<repo>` token → GitHub queue. The PRD-vs-build dispatch is determined by which label namespace the repo currently uses: PRD-side (`prd-ready`) → `lisa:github-prd-intake`; build-side (`status:ready` and `tracker = github` in `.lisa.config.json`) → `lisa:tracker-build-intake`. If both namespaces are present, prefer the PRD queue unless `$ARGUMENTS` includes `intake_mode=build`. If the URL points at a single issue (`https://github.com/<org>/<repo>/issues/<n>`), this skill is batch-only — direct the caller to `lisa:plan` (for a single PRD issue) or `lisa:implement` (for a single build issue).
 - The literal token `github` (case-insensitive) → GitHub queue, default repo from `.lisa.config.json` `github.org` / `github.repo`.
-- A bare alphanumeric token that matches the configured `JIRA_PROJECT` regex (uppercase letters / digits / hyphen, ≤10 chars) is treated as a JIRA project key by default. A token that does not match the regex is treated as a Confluence space key. If it does not resolve as a Confluence space key either, attempt to resolve as a Linear team key via `mcp__linear-server__list_teams({query})` before giving up. The only time to stop and ask is when the token resolves to more than one of {JIRA project, Confluence space, Linear team, GitHub `org/repo`} simultaneously — in that overlap the user must disambiguate which queue to scan.
+- A bare alphanumeric token that matches the JIRA project key regex (uppercase letters / digits / hyphen, ≤10 chars — typically the value of `jira.project` in `.lisa.config.json`) is treated as a JIRA project key by default. A token that does not match the regex is treated as a Confluence space key. If it does not resolve as a Confluence space key either, attempt to resolve as a Linear team key via `mcp__linear-server__list_teams({query})` before giving up. The only time to stop and ask is when the token resolves to more than one of {JIRA project, Confluence space, Linear team, GitHub `org/repo`} simultaneously — in that overlap the user must disambiguate which queue to scan.
 - An `<org>/<repo>` token (slash-separated, both halves are GitHub-name-shaped) → GitHub queue.
 - A string starting with `project = ` or containing JQL operators (`AND`, `OR`, `=`, `!=`, `~`, etc.) → JQL filter.
 

package/plugins/lisa/skills/jira-build-intake/SKILL.md

@@ -131,13 +131,16 @@ Total PRs opened: <n>
 
 ## Configuration
 
+Reads `atlassian.cloudId` and `jira.project` from `.lisa.config.json` (with `.lisa.config.local.json` overriding per key). The project key is also accepted as `$ARGUMENTS` for ad-hoc invocations.
+
 Status names default to `Ready`, `In Progress`, `On Dev`. If a project uses different names (`Open` instead of `TODO`, `In Development` instead of `In Progress`, `Code Review` instead of `On Dev`), pass overrides in `$ARGUMENTS` as `claim_status="In Development" done_status="Code Review"`.
 
 If a `Ready` status does not exist in the JIRA project's workflow, this skill cannot run. The remediation is to add `Ready` to the project workflow scheme — JIRA admin task, not something this skill can do.
 
-| Variable | Default | Purpose |
-|----------|---------|---------|
-| `JIRA_PROJECT` | (from `$ARGUMENTS`) | Project key for the default JQL |
+| Field / variable | Default | Purpose |
+|------------------|---------|---------|
+| `.lisa.config.json` `jira.project` | (from `$ARGUMENTS`) | Project key for the default JQL |
+| `.lisa.config.json` `atlassian.cloudId` | — | Atlassian Cloud site UUID (required) |
 | Status: queue | `Ready` | The status that signals "human says this is buildable" |
 | Status: claim | `In Progress` | The intermediate status the agent sets on pickup |
 | Status: done | `On Dev` | The status set after a successful build |

package/plugins/lisa/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 in the input and classify each by domain per its rules. Build the `artifacts` map (one entry per artifact: url, title, domain, source page, classification reason). See "Source Artifacts" below.
+2. **Extract source artifacts**: invoke the `lisa:tracker-source-artifacts` skill, then enumerate every external URL, embed, attachment, or example payload in the input and classify each by domain per its rules. Build the `artifacts` map (one entry per artifact: url, title, domain, source page, classification reason). See "Source Artifacts" below.
 3. **Walk the live product** (when applicable): if the work touches existing user-facing surfaces, invoke the `lisa:product-walkthrough` skill to capture current behavior, design-vs-product divergence, and reuse candidates. Skip when the work is purely backend or affects a screen that does not yet exist. See "Live Product Walkthrough" below.
 4. **Determine structure**:
    - Epic needed if: multiple features, major changes, >3 related files
@@ -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
 
@@ -89,7 +89,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 skill so any rule change propagates uniformly.
+**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 — invoke the skill so any rule change propagates uniformly.
 
 When delegating actual writes to `lisa:jira-write-ticket`, pass the extracted artifact list so its Phase 4c (Remote Links) step can attach them.
 

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

@@ -174,7 +174,7 @@ Either way the gate emits `FAIL`, not a third state. Strictness is the caller's
 
 When `artifacts_attached = true`, description must include source-precedence guidance covering: business rules → PRD body, visual treatment → mocks, flow → prototypes, API/data → data artifacts. Cross-axis conflicts surfaced under `## Open Questions`.
 
-Accept either placement — both are valid per `lisa:jira-source-artifacts`:
+Accept either placement — both are valid per `lisa:tracker-source-artifacts`:
 - A dedicated `## Source Precedence` (or `h2. Source Precedence`) subsection, OR
 - A "Source Precedence" / "source precedence" / "authoritative source" paragraph under `Technical Approach` that covers the four axes above.
 

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

@@ -170,15 +170,15 @@ Identify and attach:
 - Confluence pages (design docs, RFCs, runbooks)
 - Dashboards (Grafana, Datadog, Sentry issue)
 - Incident tickets (PagerDuty, Statuspage)
-- **Source artifacts from the originating PRD / parent epic**: classify and inherit per the rules in `lisa:jira-source-artifacts` (invoke that skill if you haven't loaded the rules in this session). The short version: enumerate the parent epic's remote links and inherit the ones whose domain matches this ticket's scope (UI → `ui-design` + `ux-flow`; backend → `data`; infra → `ops`; always inherit `reference`). Never assume a developer will walk up to the epic to find design context — attach it here.
+- **Source artifacts from the originating PRD / parent epic**: classify and inherit per the rules in `lisa:tracker-source-artifacts` (invoke that skill if you haven't loaded the rules in this session). The short version: enumerate the parent epic's remote links and inherit the ones whose domain matches this ticket's scope (UI → `ui-design` + `ux-flow`; backend → `data`; infra → `ops`; always inherit `reference`). Never assume a developer will walk up to the epic to find design context — attach it here.
 
 If the ticket was generated from a PRD (by `lisa:notion-to-tracker` or similar) and the parent epic has no source artifacts, surface that as a smell and ask whether artifacts were missed during extraction before proceeding.
 
 ### 4d. Source Precedence (must appear on the ticket)
 
-Source precedence rules and cross-axis conflict handling are defined in `lisa:jira-source-artifacts` §3 and §4. When a ticket carries both design artifacts and a description, record the precedence explicitly in the ticket description (under Technical Approach or a dedicated `## Source Precedence` subsection) so the implementer doesn't silently reconcile conflicts. Cross-axis conflicts go under `## Open Questions` as BLOCKER items.
+Source precedence rules and cross-axis conflict handling are defined in `lisa:tracker-source-artifacts` §3 and §4. When a ticket carries both design artifacts and a description, record the precedence explicitly in the ticket description (under Technical Approach or a dedicated `## Source Precedence` subsection) so the implementer doesn't silently reconcile conflicts. Cross-axis conflicts go under `## Open Questions` as BLOCKER items.
 
-For UI-touching tickets, include the existing-component reuse expectation per `lisa:jira-source-artifacts` §7.
+For UI-touching tickets, include the existing-component reuse expectation per `lisa:tracker-source-artifacts` §7.
 
 ### 4e. Live Product Walkthrough Findings (UI-touching tickets)
 

package/plugins/lisa/skills/linear-add-journey/SKILL.md

@@ -0,0 +1,104 @@
+---
+name: linear-add-journey
+description: "Add a Validation Journey section to an existing Linear Issue by analyzing the change type and generating appropriate verification steps with evidence markers. Linear counterpart of lisa:jira-add-journey."
+allowed-tools: ["Bash", "Read", "Glob", "Grep", "Skill", "mcp__linear-server__list_teams", "mcp__linear-server__get_issue", "mcp__linear-server__save_issue"]
+---
+
+# Add Validation Journey to Existing Linear Issue
+
+Read an existing Linear Issue, analyze the change type, and append a Validation Journey section to the description with appropriate verification steps based on the project's verification patterns.
+
+This skill is the destination of the `lisa:tracker-add-journey` shim when `tracker = "linear"`.
+
+## Configuration
+
+Reads `linear.workspace`, `linear.teamKey` from `.lisa.config.json` (with `.local` override).
+
+## Arguments
+
+`$ARGUMENTS`: `<IDENTIFIER>` — Linear Issue identifier (e.g. `ENG-123`).
+
+## Workflow
+
+### Step 1: Read the Issue
+
+Fetch via `mcp__linear-server__get_issue` and extract: title, description (markdown), labels, project, parent, attachments.
+
+### Step 2: Check for Existing Journey
+
+If the description already contains a `## Validation Journey` section, report and stop — never overwrite an existing journey without explicit instruction.
+
+### Step 3: Analyze the Change Type
+
+Examine the description, acceptance criteria, and codebase to determine the change type:
+
+1. **API/GraphQL** — New or modified endpoints, request/response schemas
+2. **Database migration** — Schema changes, new tables/columns, indexes
+3. **Background job/queue** — New job processors, queue consumers, event handlers
+4. **Library/utility** — Exported functions, shared modules, npm package changes
+5. **Security fix** — Auth, authorization, input validation, OWASP vulnerabilities
+6. **Authentication/authorization** — Role-based access, session management, tokens
+7. **UI/frontend** — Components, flows, browser-driven verification
+
+Use Explore agents or read the codebase to understand which files are affected and what verification approach is appropriate.
+
+### Step 4: Map Change Type to Verification Pattern
+
+| Change Type | Verification Approach |
+|---|---|
+| API/GraphQL | curl commands verifying endpoints, status codes, response schemas |
+| Database migration | Migration execution + schema verification + rollback check |
+| Background job/queue | Enqueue + process + state change verification |
+| Library/utility | Test execution + build verification + export check |
+| Security fix | Exploit reproduction pre-fix + exploit failure post-fix |
+| Auth/authz | Multi-role verification with explicit status codes |
+| UI/frontend | Playwright browser flow + visual evidence |
+
+### Step 5: Draft the Validation Journey (markdown)
+
+Linear descriptions are markdown. Use `##` and `###` headings — not Jira wiki markup.
+
+```markdown
+## Validation Journey
+
+### Prerequisites
+- List required services, database, env vars
+
+### Steps
+1. Verify current state before changes
+2. Apply the change
+3. Verify expected new state [EVIDENCE: state-name]
+4. Test error/edge cases [EVIDENCE: error-case]
+5. Verify rollback if applicable [EVIDENCE: rollback]
+
+### Assertions
+- Describe what must be true after verification
+```
+
+### Guidelines for Drafting
+
+1. **2–5 evidence markers** — Focus on proving the change works and handles errors.
+2. **Concrete, runnable steps** — `Run \`curl -s localhost:3000/health | jq .status\`` not "Check the endpoint".
+3. **Include environment setup** — Database connection, running services, env vars.
+4. **Evidence names in kebab-case** — `api-response`, `schema-check`, `rate-limit-hit`.
+5. **Assertions are measurable** — "Returns 200 with `{status: ok}`" not "API works correctly".
+6. **Cover happy path and error path** — At minimum, one success and one failure evidence marker.
+
+### Step 6: Present to User for Approval
+
+Display the drafted journey and ask for confirmation before appending.
+
+### Step 7: Append to Issue Description
+
+After approval, fetch the current description, append the new Validation Journey section, and update via `mcp__linear-server__save_issue({id, description: <new-description>})`. Preserve all existing description content — never overwrite.
+
+### Step 8: Verify
+
+Re-fetch the issue and confirm the section is present.
+
+## When to Use This Skill
+
+- Issue was created before the Validation Journey convention was established
+- Issue was created manually without following `lisa:linear-create` guidelines
+- Issue needs a journey added or updated based on implementation progress
+- Before starting work on an Issue, to ensure verification steps are documented