@codyswann/lisa 2.10.1 → 2.11.0

package/plugins/src/base/skills/linear-journey/SKILL.md

@@ -0,0 +1,134 @@
+---
+name: linear-journey
+description: "Parse a Linear Issue's Validation Journey section, execute the verification steps using appropriate tools (curl, test commands, database queries, Playwright), capture evidence at each [EVIDENCE: name] marker, and post to Linear + GitHub PR using the linear-evidence skill. Linear counterpart of lisa:jira-journey."
+allowed-tools: ["Bash", "Read", "Glob", "Grep", "Skill", "mcp__linear-server__list_teams", "mcp__linear-server__get_issue", "mcp__linear-server__save_issue"]
+---
+
+# Linear Validation Journey
+
+Parse a Linear Issue's Validation Journey, execute the verification steps using the appropriate tools for the change type, capture evidence at each `[EVIDENCE: name]` marker, and post to Linear + GitHub PR.
+
+This skill is the destination of the `lisa:tracker-journey` shim when `tracker = "linear"`.
+
+## Configuration
+
+Reads `linear.workspace`, `linear.teamKey` from `.lisa.config.json` (with `.local` override).
+
+## Arguments
+
+`$ARGUMENTS`: `<IDENTIFIER> [PR_NUMBER]`
+
+- `IDENTIFIER` (required): Linear Issue identifier (e.g. `ENG-123`)
+- `PR_NUMBER` (optional): GitHub PR number to update description
+
+## Prerequisites
+
+- Linear MCP authenticated
+- `gh` CLI authenticated
+- Appropriate services running for the verification type (dev server, database, etc.)
+
+## Workflow
+
+### Step 1: Parse the Validation Journey
+
+Fetch the Issue via `mcp__linear-server__get_issue` and extract the `## Validation Journey` section from the markdown description. Parse:
+
+- `### Prerequisites` — list of required services / env / setup
+- `### Steps` — numbered steps, each potentially containing `[EVIDENCE: name]` markers
+- `### Assertions` — what must be true after verification
+
+If the section is missing or has no steps, report `"No Validation Journey on <IDENTIFIER>. Run /linear-add-journey first."` and stop.
+
+### Step 2: Satisfy Prerequisites
+
+Before executing steps, verify each prerequisite:
+
+1. Required services running (dev server, database, queue worker)
+2. Database connectivity if needed
+3. Environment variables set
+4. Run any setup commands mentioned in prerequisites
+
+Stop and report if any prerequisite is not satisfied.
+
+### Step 3: Execute Steps and Capture Evidence
+
+Execute each step sequentially. Determine the verification approach based on the step text and change type:
+
+- **API endpoints** → Run curl commands, capture HTTP response to `evidence/NN-name.txt` (or `.json` for structured data)
+- **Database changes** → Run psql / migration commands, capture schema output
+- **Background jobs** → Trigger the job, check queue / state, capture logs
+- **Library / utility changes** → Run tests, capture output
+- **Security fixes** → Reproduce exploit attempt, verify fix
+- **UI / frontend** → Playwright browser flow, capture screenshots / DOM state
+
+At each `[EVIDENCE: name]` marker, capture stdout / stderr to a numbered file:
+
+#### Evidence Naming Convention
+
+`{NN}-{evidence-name}.{ext}`
+
+- `NN`: zero-padded sequential number (`01`, `02`, `03`...)
+- `evidence-name`: the value from `[EVIDENCE: name]`
+- `ext`: `.txt` for plain output, `.json` for structured data
+
+Example:
+
+```text
+evidence/
+  01-health-check.json
+  02-schema-after-migration.txt
+  03-rate-limit-response.txt
+  comment.txt
+  code-blocks.md
+```
+
+### Step 4: Generate Evidence Comment + Code Blocks
+
+After capturing all evidence, build:
+
+- `evidence/comment.txt` — human-readable summary of the verification (Linear comment body, markdown-supported)
+- `evidence/code-blocks.md` — fenced code blocks containing the captured evidence outputs (appended below `comment.txt` inside a `<details>` block)
+
+### Step 5: Post Evidence
+
+Invoke `lisa:linear-evidence` with `<IDENTIFIER> ./evidence` to:
+
+1. Upload large evidence files to the GitHub `pr-assets` release (if files present in `evidence/files/`).
+2. Update the GitHub PR description with an Evidence section (when a PR is open).
+3. Post the Linear comment (`comment.txt` + collapsible `code-blocks.md`).
+4. Transition labels: remove `status:in-progress`, add `status:code-review`.
+
+### Step 6: Verify
+
+Confirm:
+- Evidence appears as a comment on the Linear Issue.
+- The PR description shows the Evidence section.
+- The Issue's `status:*` label transitioned to `code-review`.
+
+## Verification Patterns Reference
+
+Use patterns from the project's `verification.md`:
+
+| Change Type | Verification Method | Evidence Format |
+|---|---|---|
+| API endpoint | `curl -s localhost:PORT/endpoint` | JSON response |
+| Database migration | `psql -c "\d table"` or migration output | Schema text |
+| Background job | Trigger + check state | Log output |
+| Library / utility | `bun run test -- path/to/test` | Test output |
+| Security fix | Reproduce + verify fix | Request / response |
+| Auth/authz | Multi-role verification | Status codes per role |
+| UI / frontend | Playwright `browser_*` MCP tools | Screenshot + DOM |
+
+## Troubleshooting
+
+### Evidence file is empty
+
+Ensure the command succeeded and produced output. Use `2>&1` to capture both stdout and stderr.
+
+### Parser returns no steps
+
+The Issue may not have a Validation Journey section. Run `/linear-add-journey <IDENTIFIER>` to add one.
+
+### Label transition fails
+
+Ensure `status:in-progress` and `status:code-review` exist on the team. `lisa:linear-evidence` creates them on demand if missing.

package/plugins/src/base/skills/linear-prd-intake/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: linear-prd-intake
-description: "Scans a Linear workspace (or a specific team) for projects labelled `prd-ready` and runs each one through the dry-run validation pipeline. Projects that pass every gate get tickets written and the label flipped to `prd-ticketed`; projects that fail get clarifying-question comments (on a sentinel feedback issue under the project) and the label flipped to `prd-blocked`. Linear counterpart of `lisa:notion-prd-intake` and `lisa:confluence-prd-intake` — the workflow is identical; only the source-of-truth tools differ. Composes existing skills (linear-to-tracker, tracker-validate, jira-source-artifacts, product-walkthrough)."
+description: "Scans a Linear workspace (or a specific team) for projects labelled `prd-ready` and runs each one through the dry-run validation pipeline. Projects that pass every gate get tickets written and the label flipped to `prd-ticketed`; projects that fail get clarifying-question comments (on a sentinel feedback issue under the project) and the label flipped to `prd-blocked`. Linear counterpart of `lisa:notion-prd-intake` and `lisa:confluence-prd-intake` — the workflow is identical; only the source-of-truth tools differ. Composes existing skills (linear-to-tracker, tracker-validate, tracker-source-artifacts, product-walkthrough)."
 allowed-tools: ["Skill", "Bash", "mcp__linear-server__list_projects", "mcp__linear-server__get_project", "mcp__linear-server__save_project", "mcp__linear-server__list_project_labels", "mcp__linear-server__list_issues", "mcp__linear-server__get_issue", "mcp__linear-server__save_issue", "mcp__linear-server__list_comments", "mcp__linear-server__save_comment", "mcp__linear-server__list_issue_labels", "mcp__linear-server__create_issue_label", "mcp__linear-server__list_documents", "mcp__linear-server__get_document", "mcp__linear-server__list_teams"]
 ---
 
@@ -10,7 +10,7 @@ allowed-tools: ["Skill", "Bash", "mcp__linear-server__list_projects", "mcp__line
 
 - A Linear **workspace** URL — scans every project in the workspace whose labels include `prd-ready`. Example: `https://linear.app/acme`.
 - A Linear **team** URL or team key — scans every project on the team whose labels include `prd-ready`. Example: `https://linear.app/acme/team/ENG/projects` or bare `ENG`.
-- The literal token `linear` — equivalent to "the default Linear workspace"; only valid if `LINEAR_WORKSPACE` is configured.
+- The literal token `linear` — equivalent to "the default Linear workspace"; only valid if `linear.workspace` is configured in `.lisa.config.json`.
 
 Run one intake cycle against that scope. Each project with the `prd-ready` label is claimed, validated, and routed to either `prd-blocked` (with clarifying comments on a sentinel feedback issue) or `prd-ticketed` (with JIRA tickets created).
 
@@ -29,7 +29,7 @@ Specifically forbidden:
 
 The only legitimate reasons to stop early:
 
-- Missing scope argument or required configuration (`JIRA_PROJECT`, `JIRA_SERVER`, `LINEAR_WORKSPACE`, `E2E_BASE_URL`, etc.). Surface the missing key(s) and exit this cycle — never invent values.
+- Missing scope argument or required configuration (`linear.workspace` in `.lisa.config.json`, `E2E_BASE_URL`, etc.). Surface the missing key(s) and exit this cycle — never invent values.
 - Workspace/team unreachable, or the labelling convention not yet adopted (no projects carry any of `prd-ready` / `prd-in-review` / `prd-blocked` / `prd-ticketed`). Surface and exit.
 - Empty `prd-ready` set. Exit cleanly with `"No Linear projects labelled prd-ready. Nothing to do."`
 
@@ -63,7 +63,7 @@ If the project does not yet use `prd-*` labels, this skill cannot run. Adopting
    - Workspace URL (`https://linear.app/<workspace>`) → extract workspace slug; the scope is the entire workspace.
    - Team URL containing `/team/<KEY>/...` → extract team key; the scope is that team.
    - Bare team key → use as-is; the scope is that team.
-   - The literal `linear` → fall back to `LINEAR_WORKSPACE` env var; error if not set.
+   - The literal `linear` → fall back to `linear.workspace` from `.lisa.config.json`; error if not set.
 2. Verify the scope is reachable:
    - For a workspace: call `mcp__linear-server__list_teams` and confirm at least one team is returned (non-empty workspaces are readable; empty results indicate auth or workspace-mismatch).
    - For a team: call `mcp__linear-server__list_teams({query: <KEY>})` and confirm the team resolves.
@@ -106,7 +106,7 @@ Invoke the `lisa:linear-to-tracker` skill with `dry_run: true` and the project's
 - An overall PASS / FAIL verdict
 - A failure count
 
-This call also 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 `lisa:linear-to-tracker` calls per ticket.
+This call also 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 `lisa:linear-to-tracker` calls per ticket.
 
 #### 3c. Branch on the verdict
 
@@ -250,7 +250,12 @@ Idempotency: the helper finds-or-creates. Re-runs of the cycle reuse the same se
 
 ## Configuration
 
-Same env vars as `lisa:linear-to-tracker` — `JIRA_PROJECT`, `JIRA_SERVER`, `LINEAR_WORKSPACE`, `E2E_BASE_URL`, `E2E_TEST_PHONE`, `E2E_TEST_OTP`, `E2E_TEST_ORG`, `E2E_GRAPHQL_URL`. If any required value is missing, surface the missing key(s) and exit this cycle — never invent values.
+Same configuration as `lisa:linear-to-tracker`. See that skill for the full table. Key items:
+
+- **From `.lisa.config.json`**: `linear.workspace` (required for Linear MCP). When the destination tracker is `linear`, also `linear.teamKey`.
+- **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 the missing key(s) and exit this cycle — never invent values.
 
 ## Rules
 

package/plugins/src/base/skills/linear-read-issue/SKILL.md

@@ -0,0 +1,200 @@
+---
+name: linear-read-issue
+description: "Fetches the full scope of a Linear work item — Issue or Project — including metadata, description, acceptance criteria, all comments, attachments, native relations (blocks/blocked_by/relates_to/duplicates), Project parent (if any) with siblings, and sub-Issues. Produces a consolidated context bundle that downstream agents consume so they never act on a single item in isolation."
+allowed-tools: ["Bash", "Skill", "mcp__linear-server__list_teams", "mcp__linear-server__get_issue", "mcp__linear-server__get_project", "mcp__linear-server__list_issues", "mcp__linear-server__list_comments", "mcp__linear-server__list_documents", "mcp__linear-server__get_document"]
+---
+
+# Read Linear Work Item: $ARGUMENTS
+
+Fetch the full scope of the item AND its related graph. Downstream agents must never act on an item in isolation — always call this skill first so they see blockers, project siblings, linked PRs, and historical comments.
+
+This skill is the destination of the `lisa:tracker-read` shim when `tracker = "linear"`. Read-only.
+
+Repository name for scoped comments and logs: `basename $(git rev-parse --show-toplevel)`.
+
+## Configuration
+
+Reads `linear.workspace`, `linear.teamKey` from `.lisa.config.json` (with `.local` override).
+
+## Phase 1 — Resolve Context
+
+1. If `$ARGUMENTS` matches `<TEAM>-<n>` → Issue mode.
+2. If `$ARGUMENTS` is a URL containing `/project/<slug>-<short-id>` → Project mode (extract `<short-id>`).
+3. Otherwise stop and report. Do NOT guess.
+4. Resolve team ID via `mcp__linear-server__list_teams({query: <teamKey>})`.
+
+## Phase 2 — Fetch Primary Item
+
+### Issue mode
+
+Call `mcp__linear-server__get_issue`. Extract and preserve:
+
+**Metadata**
+- Identifier, title, issue type (typically a label or workflow state), state, priority (0–4)
+- Assignee, creator, subscribers
+- Labels (capture full names — `status:*`, `component:*`, `priority:*`, `prd-*`)
+- Project (parent), parent Issue (if Sub-task), cycle, milestone (ProjectMilestone)
+- Estimate, due date
+- Created, updated, completed dates
+
+**Body**
+- Full description (preserve markdown)
+- **Validation Journey** section if present (pass verbatim to downstream)
+- Attachment URLs (capture, do not download unless needed)
+
+**Comments**
+Fetch ALL comments via `mcp__linear-server__list_comments({issueId: <id>})` in chronological order. Walk thread parents/children — Linear comments are threaded via `parentId`. Do not truncate. For each comment:
+- Author, timestamp, body
+- Flag comments that contain: credentials, reproduction steps, status updates from stakeholders, decisions, or triage headers.
+
+### Project mode
+
+Call `mcp__linear-server__get_project` with `includeMilestones: true`, `includeResources: true`. Extract:
+
+**Metadata**
+- ID, slug, name, state, priority, lead, color
+- Teams, labels, milestones, target date, start date
+- Created, updated dates
+
+**Body**
+- Description (markdown)
+- Attached documents — call `mcp__linear-server__list_documents({projectId})` then `get_document` per result. Treat each as additional spec content.
+
+**Member Issues**
+- Call `mcp__linear-server__list_issues({project: <id>})` to enumerate the Project's Issues. Capture identifier, title, state, parent Issue (for sub-Issue tree).
+
+## Phase 3 — Fetch Attachments / Remote Links
+
+Linear stores remote URLs as attachments on the Issue. For each:
+
+- **GitHub PR or commit**: run `gh pr view <url> --json title,state,body,mergedAt,reviewDecision,comments,reviews` (PRs) or `gh api repos/<owner>/<repo>/commits/<sha>` (commits). Capture title, state, unresolved review comments, merge status.
+- **Confluence page**: capture title and URL. Do not fetch body unless a downstream task explicitly needs it.
+- **Dashboard / log link / external URL**: capture title and URL only.
+
+If `gh` is not authenticated, note "gh auth required" and continue — do not abort.
+
+## Phase 4 — Fetch Relations
+
+Linear native Issue relations are returned in the `get_issue` response under `relations`. Group by type:
+
+- `blocks` / `blocked_by`
+- `relates_to`
+- `duplicates` / `duplicated_by`
+
+For each related Issue, call `mcp__linear-server__get_issue` and capture:
+- Identifier, title, state, priority, assignee
+- Description (full, unless cancelled — then summary only)
+- Acceptance Criteria section
+- Last 10 comments (chronological)
+- Attachments (URLs only — skip deep PR fetch unless the relation is `blocks` or `blocked_by`)
+
+**Special handling for `blocked_by`:** fetch full PR details via `gh` for each blocker's GitHub attachments so the agent knows whether the blocker is actually shipped.
+
+For Project-level relationships (Project ↔ Project), Linear doesn't model native relations — check the Project description and resources for cross-references and capture them as plain links.
+
+## Phase 5 — Fetch Project Context
+
+If the primary Item is an Issue with a Project parent:
+
+1. Fetch the Project via `mcp__linear-server__get_project` — full description, milestones, labels, lead.
+2. Fetch Project documents (Phase 2 procedure).
+3. Find Project siblings via `mcp__linear-server__list_issues({project: <projectId>})` excluding the primary identifier.
+4. For each sibling, capture: identifier, title, state, priority, assignee, summary (first paragraph of description).
+5. If a sibling is `Started` or `In Review` with a different assignee, flag it prominently.
+
+If the primary Item IS a Project, Phase 5 is the same as fetching all member Issues (already done in Phase 2 Project mode).
+
+## Phase 6 — Fetch Sub-Issues
+
+If the primary Issue has children (sub-Issues), fetch each via `mcp__linear-server__get_issue`: identifier, title, state, assignee, description (first paragraph), Acceptance Criteria.
+
+## Phase 7 — Assemble Context Bundle
+
+Produce a single structured output the caller can pass verbatim to downstream agents.
+
+```text
+# Linear Work Item Context: <IDENTIFIER>
+
+## Primary Item
+- Identifier: <ID>
+- Type: <Issue | Project>
+- State: <state>
+- Priority: <0–4 or named>
+- Assignee: <name or none>
+- Project (parent): <project-slug — name> or none
+- Parent Issue: <ID — title> or none (Sub-task only)
+- Cycle: <name or none>
+- Milestone: <project-milestone or none>
+- Labels: <comma-separated>
+- Estimate: <points>
+
+### Description
+<full description>
+
+### Acceptance Criteria
+<criteria>
+
+### Validation Journey
+<section or "None">
+
+### Comments (<count>)
+<chronological comments, flagged items called out>
+
+### Attachments
+<list of URLs with titles>
+
+## Remote Links
+### Pull Requests (<count>)
+- <url> — <title> — <state> — <reviewDecision>
+  <body summary + unresolved review comments>
+
+### Confluence
+- <title> — <url>
+
+### Other
+- <title> — <url>
+
+## Relations
+### Blocks (<count>)
+<per-issue block>
+
+### Blocked By (<count>)
+<per-issue block with PR state>
+
+### Relates To (<count>)
+<per-issue block>
+
+### Duplicates / Duplicated By
+<per-issue block>
+
+## Project Context (when primary is an Issue under a Project)
+### Project <slug> — <name>
+- State: <state>
+- Description: <full markdown>
+- Milestones: <list>
+- Documents: <list of doc titles + identifiers>
+
+### Siblings In-Flight (<count>)
+- <ID> — <state> — <assignee> — <title>  **[FLAG: in progress by other assignee]**
+
+### Other Siblings (<count>)
+- <ID> — <state> — <title>
+
+## Sub-Issues (<count>)
+- <ID> — <state> — <assignee> — <title>
+
+## Summary for Downstream
+- Full item count pulled: <N>
+- Blockers still open: <list>
+- Related in-flight work: <list>
+- Relevant PRs: <list with state>
+```
+
+## Rules
+
+- Never summarize or truncate the primary item's description or Validation Journey.
+- Never skip a relation type, even if it seems unrelated — the downstream agent decides relevance.
+- If a related item returns an access error, capture the error and continue. Do not abort the read.
+- Flag in-flight sibling work prominently so the caller can avoid duplicate implementation.
+- If the Issue has no Project parent, state this explicitly — do not silently skip Phase 5.
+- Output is pure context. This skill never modifies the item.

package/plugins/src/base/skills/linear-sync/SKILL.md

@@ -0,0 +1,89 @@
+---
+name: linear-sync
+description: "Syncs plan progress to a linked Linear Issue. Posts plan contents, progress updates, branch links, and PR links at key milestones. Use this skill throughout the plan lifecycle to keep Linear Issues in sync. The Linear counterpart of lisa:jira-sync and lisa:github-sync."
+allowed-tools: ["Bash", "Skill", "mcp__linear-server__list_teams", "mcp__linear-server__get_issue", "mcp__linear-server__save_comment", "mcp__linear-server__list_issue_labels", "mcp__linear-server__create_issue_label", "mcp__linear-server__save_issue"]
+---
+
+# Sync Plan to Linear: $ARGUMENTS
+
+Post milestone updates to the linked Linear Issue at key plan-lifecycle moments. This skill is the destination of the `lisa:tracker-sync` shim when `tracker = "linear"`.
+
+## Configuration
+
+Reads `linear.workspace`, `linear.teamKey` from `.lisa.config.json` (with `.local` override).
+
+## When to invoke
+
+Callers (planning skills, lifecycle skills) invoke this skill at:
+
+| Milestone | What to post |
+|-----------|--------------|
+| Plan created | Plan contents (sections + ordered tasks) as a comment, suggest transition `Backlog → Todo` (label: `status:ready`) |
+| Implementation in progress | Branch URL + first commit, suggest transition `Todo → In Progress` (label: `status:in-progress`) |
+| PR ready for review | PR URL + summary, the implementation handoff comment, suggest transition `In Progress → In Review` (label: `status:code-review`) |
+| PR merged | Merge SHA + deploy environment (if known), suggest transition `In Review → Done` (label: `status:done`) |
+
+This skill **suggests** transitions but does not auto-transition the native Linear `state` field. It DOES update the `status:*` label set when the caller asks (the build queue is keyed off labels). Native state transitions remain a human / triage decision.
+
+## Input
+
+`$ARGUMENTS` is `<IDENTIFIER> <milestone>` where:
+
+- `<IDENTIFIER>` is the Linear Issue identifier (e.g. `ENG-123`). If not provided, the skill searches the active plan file for a linked Linear Issue.
+- `<milestone>` is one of `plan-created`, `implementation-in-progress`, `pr-ready`, `pr-merged`.
+
+## Phase 1 — Resolve Issue
+
+1. If `$ARGUMENTS` includes an identifier, parse it.
+2. Else search for the active plan file (most recent file under `plans/`) and extract the linked Linear Issue identifier from its frontmatter.
+3. Fetch the Issue via `mcp__linear-server__get_issue` to confirm it exists.
+
+## Phase 2 — Compose Milestone Comment
+
+Per the milestone, build the comment body. Include:
+
+- A milestone header (e.g. `**Plan created** — <plan-file>`)
+- Relevant links (plan file, branch, PR)
+- A short summary (first 5 lines of the plan section / commit message / PR description)
+- The suggested status transition
+
+Example for `plan-created`:
+
+```markdown
+**Plan created** — `plans/feat-X.md`
+
+Sections:
+- Phase 1: Schema doc
+- Phase 2: Linear destination skills
+- ...
+
+Tasks: 7 ordered items.
+
+Next: implementation begins. Suggested status: **Todo** (label: `status:ready`).
+```
+
+## Phase 3 — Post Comment
+
+Call `mcp__linear-server__save_comment({issueId: <id>, body: <comment>})`.
+
+## Phase 4 — Update Status Label (when caller requests)
+
+If the caller passes `--update-label`, update the `status:*` label set via `mcp__linear-server__save_issue`:
+
+- `plan-created` → add `status:ready`
+- `implementation-in-progress` → remove `status:ready`, add `status:in-progress`
+- `pr-ready` → remove `status:in-progress`, add `status:code-review`
+- `pr-merged` → remove `status:code-review`, add `status:done`
+
+If the requested label doesn't exist on the team, create it via `mcp__linear-server__create_issue_label`.
+
+Verify exactly one `status:*` label remains after the update — having two simultaneously breaks the build-queue invariant.
+
+Without `--update-label`, this skill posts the comment only and does NOT touch labels.
+
+## Rules
+
+- Never auto-transition the native Linear `state` — only the label, and only when the caller explicitly asks.
+- Never post empty or minimal comments — if a milestone has no meaningful content, skip the post.
+- Do not delete prior milestone comments. They are the audit trail.
+- If `save_comment` fails, retry once. If it fails again, surface the error.

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

@@ -1,7 +1,7 @@
 ---
 name: linear-to-tracker
 description: >
-  Break down a Linear PRD (a Linear Project) into Epics, Stories, and Sub-tasks in the configured destination tracker (JIRA or GitHub Issues per .lisa.config.json). Use this skill
+  Break down a Linear PRD (a Linear Project) 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 Linear project URL and wants it converted into tracker tickets, or asks to
   "break down this Linear project", "create tickets from a Linear project", "turn this Linear PRD into tickets", or similar. This skill mirrors `lisa:notion-to-tracker` and `lisa:confluence-to-tracker` for projects
   whose PRDs live in Linear — the workflow, gates, dry-run mode, and validation rules are identical;
@@ -11,7 +11,7 @@ allowed-tools: ["Skill", "Bash", "mcp__linear-server__get_project", "mcp__linear
 
 # Linear PRD to Tracker Breakdown
 
-Convert a Linear PRD (a Linear **Project**) into a structured ticket hierarchy in the configured destination tracker (JIRA or GitHub Issues per .lisa.config.json): Epics > Stories > Sub-tasks.
+Convert a Linear PRD (a Linear **Project**) 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 Linear counterpart of `lisa:notion-to-tracker` and `lisa:confluence-to-tracker`. The three skills share the same phases, gates, dry-run contract, and per-ticket validation logic. Only the PRD-side fetch tools differ. When changing workflow logic, change ALL THREE skills together so the source vendors stay behaviorally identical.
@@ -101,13 +101,20 @@ Extract the trailing `<short-id>` (the alphanumeric segment after the last `-` i
 
 ## 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** (Linear); 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 |
+|-------|---------|---------------|
+| `linear.workspace` | Linear workspace slug (used for URL synthesis on remote links) | always |
+
+### 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` |
-| `LINEAR_WORKSPACE` | Linear workspace slug (used for URL synthesis on JIRA remote links) | `acme` |
 | `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` |
@@ -144,17 +151,17 @@ PRDs typically reference external design, UX, and data artifacts (Figma files, L
    - Embedded images and file attachments referenced in the project / documents
    - 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 (project description vs a specific document title vs a specific sub-issue comment).
 
-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
 
@@ -174,7 +181,7 @@ Walkthrough findings are surfaced back to product via the orchestrating intake s
 
 For each epic identified in Phase 1, **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:
@@ -202,7 +209,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
@@ -230,7 +237,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: