@codyswann/lisa 2.7.0 → 2.8.0

package/plugins/{src/base/skills/notion-to-jira → lisa/skills/notion-to-tracker}/SKILL.md

@@ -1,30 +1,30 @@
 ---
-name: notion-to-jira
+name: notion-to-tracker
 description: >
-  Break down a Notion PRD into JIRA epics, stories, and sub-tasks. Use this skill whenever the user
-  shares a Notion PRD URL and wants it converted into JIRA tickets, or asks to "break down a PRD",
-  "create tickets from a PRD", "turn this PRD into JIRA", or similar. Also trigger when the user
+  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
+  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:
   fetching the PRD, analyzing comments, researching the codebase, identifying blockers, and creating
   all tickets with empirical verification plans.
 ---
 
-# Notion PRD to JIRA Breakdown
+# Notion PRD to Tracker Breakdown
 
-Convert a Notion PRD into a structured JIRA ticket hierarchy: Epics > Stories > Sub-tasks.
+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.
 Each sub-task is scoped to exactly one repo and includes an empirical verification plan.
 
 ## Modes
 
 This skill supports two modes, controlled by a `dry_run` flag in `$ARGUMENTS`:
 
-- **`dry_run: false`** (default — full mode): run all phases, write tickets via `lisa:jira-write-ticket`, run the preservation gate, report.
-- **`dry_run: true`** (planning + validation only — no writes): run Phases 1, 1.5, 1.6, 2, 3, 4 to plan the hierarchy and draft each ticket spec, then call `lisa:jira-validate-ticket` (with `--spec-only`) on every drafted ticket. Aggregate the per-ticket validator reports into a single dry-run report. **Skip Phase 5 (sub-task creation), Phase 5.5 (preservation gate), and Phase 6 (results report)** — none of those make sense without writes. Return the dry-run report so the caller (e.g. `lisa:notion-prd-intake`) can decide whether to proceed.
+- **`dry_run: false`** (default — full mode): run all phases, write tickets via `lisa:tracker-write`, run the preservation gate, report.
+- **`dry_run: true`** (planning + validation only — no writes): run Phases 1, 1.5, 1.6, 2, 3, 4 to plan the hierarchy and draft each ticket spec, then call `lisa:tracker-validate` (with `--spec-only`) on every drafted ticket. Aggregate the per-ticket validator reports into a single dry-run report. **Skip Phase 5 (sub-task creation), Phase 5.5 (preservation gate), and Phase 6 (results report)** — none of those make sense without writes. Return the dry-run report so the caller (e.g. `lisa:notion-prd-intake`) can decide whether to proceed.
 
 Dry-run output format:
 
 ```text
-## notion-to-jira dry-run: <PRD title>
+## notion-to-tracker dry-run: <PRD title>
 
 ### Planned hierarchy
 - Epic: <summary>
@@ -60,11 +60,11 @@ The `failures` array passes the validator's `Failure details` block through verb
 
 The dry-run mode never writes to JIRA and never calls `mcp__atlassian__createJiraIssue`. It also never sets a Notion status — that is the orchestrating skill's responsibility.
 
-## Hard Rule: All Writes Go Through `lisa:jira-write-ticket`
+## Hard Rule: All Writes Go Through `lisa:tracker-write`
 
-**Every JIRA ticket created by this skill — every epic, story, and sub-task — MUST be created by invoking the `lisa:jira-write-ticket` skill. Never call `mcp__atlassian__createJiraIssue`, `mcp__atlassian__editJiraIssue`, `mcp__atlassian__createIssueLink`, or any other Atlassian write tool directly from this skill or from any sub-agent it spawns.**
+**Every JIRA ticket created by this skill — every epic, story, and sub-task — MUST be created by invoking the `lisa:tracker-write` skill. Never call `mcp__atlassian__createJiraIssue`, `mcp__atlassian__editJiraIssue`, `mcp__atlassian__createIssueLink`, or any other Atlassian write tool directly from this skill or from any sub-agent it spawns.**
 
-`lisa:jira-write-ticket` enforces gates this skill does not:
+`lisa:tracker-write` enforces gates this skill does not:
 - 3-audience description (Context / Technical Approach / Acceptance Criteria)
 - Gherkin acceptance criteria
 - Epic parent validation
@@ -73,7 +73,7 @@ The dry-run mode never writes to JIRA and never calls `mcp__atlassian__createJir
 - Sign-in account and target environment recorded in description
 - Post-create verification
 
-Bypassing `lisa:jira-write-ticket` produces thin tickets that the rest of the lifecycle (triage, ticket-verify, journey, evidence) treats as broken. This is the most common failure mode this skill has had — calling `createJiraIssue` directly is a regression, not an optimization. The Atlassian read tools (`getJiraIssue`, `searchJiraIssuesUsingJql`, `getJiraIssueRemoteIssueLinks`, `getAccessibleAtlassianResources`, `getJiraProjectIssueTypesMetadata`, `getVisibleJiraProjects`) ARE allowed for context gathering and the Phase 5.5 preservation gate.
+Bypassing `lisa:tracker-write` produces thin tickets that the rest of the lifecycle (triage, ticket-verify, journey, evidence) treats as broken. This is the most common failure mode this skill has had — calling `createJiraIssue` directly is a regression, not an optimization. The Atlassian read tools (`getJiraIssue`, `searchJiraIssuesUsingJql`, `getJiraIssueRemoteIssueLinks`, `getAccessibleAtlassianResources`, `getJiraProjectIssueTypesMetadata`, `getVisibleJiraProjects`) ARE allowed for context gathering and the Phase 5.5 preservation gate.
 
 ## Input
 
@@ -160,9 +160,9 @@ Walkthrough findings are attached to the originating Notion PRD as a comment ("C
 
 ### Phase 3: Create Epics
 
-> **Mode guard**: In `dry_run: true` mode, do not invoke `lisa:jira-write-ticket` in this phase. Instead, draft the epic spec (summary, description_body, artifacts) and validate it with `lisa:jira-validate-ticket --spec-only`. Record the drafted spec (including a placeholder epic key like `DRY-RUN-EPIC-1`) for Phase 4 to use as parent references. In `dry_run: false` mode (default), proceed as described below.
+> **Mode guard**: In `dry_run: true` mode, do not invoke `lisa:tracker-write` in this phase. Instead, draft the epic spec (summary, description_body, artifacts) and validate it with `lisa:tracker-validate --spec-only`. Record the drafted spec (including a placeholder epic key like `DRY-RUN-EPIC-1`) for Phase 4 to use as parent references. In `dry_run: false` mode (default), proceed as described below.
 
-For each PRD epic, **invoke the `lisa:jira-write-ticket` skill** (do not call `createJiraIssue` directly). Pass it everything it needs to enforce its quality gates:
+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
 - `issue_type`: `Epic`
@@ -175,14 +175,14 @@ For each PRD epic, **invoke the `lisa:jira-write-ticket` skill** (do not call `c
   - Blockers and open questions
   - Dependencies on other epics or PRDs
   - A **Source Artifacts** section listing every artifact extracted in Phase 1.5 (grouped by domain)
-- `artifacts`: the full Phase 1.5 artifact list — every artifact, regardless of domain. The epic is the canonical hub, and anyone working on the epic or its descendants must be able to reach the full set from one place. No filtering at the epic level. `lisa:jira-write-ticket` Phase 4c attaches them as remote links.
+- `artifacts`: the full Phase 1.5 artifact list — every artifact, regardless of domain. The epic is the canonical hub, and anyone working on the epic or its descendants must be able to reach the full set from one place. No filtering at the epic level. `lisa:tracker-write` Phase 4c attaches them as remote links.
 - `priority`, `labels`, `components`, `fix_version`: as appropriate
 
 Capture the returned epic key — Phase 4 needs it as the parent for stories.
 
 ### Phase 4: Create Stories
 
-> **Mode guard**: In `dry_run: true` mode, do not invoke `lisa:jira-write-ticket` in this phase. Instead, draft each story spec and validate it with `lisa:jira-validate-ticket --spec-only`. Use placeholder keys (e.g. `DRY-RUN-STORY-1.1`) for any downstream references. In `dry_run: false` mode (default), proceed as described below.
+> **Mode guard**: In `dry_run: true` mode, do not invoke `lisa:tracker-write` in this phase. Instead, draft each story spec and validate it with `lisa:tracker-validate --spec-only`. Use placeholder keys (e.g. `DRY-RUN-STORY-1.1`) for any downstream references. In `dry_run: false` mode (default), proceed as described below.
 
 For each Epic, plan two kinds of stories:
 - **One "X.0 Setup" story** for data model and infrastructure prerequisites (new entities, migrations, new fields, infrastructure like S3 buckets or SQS queues)
@@ -193,24 +193,24 @@ For each Epic, plan two kinds of stories:
 - "Squad Planning" -> `[SP-1.1]`
 - Use your judgment for other PRDs
 
-For each story, **invoke `lisa:jira-write-ticket`** with:
+For each story, **invoke `lisa:tracker-write`** with:
 
 - `project_key`: from `JIRA_PROJECT` config
 - `issue_type`: `Story`
-- `epic_parent`: the Epic key captured in Phase 3 (mandatory — `lisa:jira-write-ticket` rejects non-bug, non-epic tickets without an epic parent)
+- `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
 - `description_body`: a draft of the 3-audience description containing:
   - **Context / Business Value**: the user story statement from the PRD
   - **Technical Approach**: notes from engineering comments and Phase 2 codebase research
-  - **Acceptance Criteria** (Gherkin) derived from the functional requirements — `lisa:jira-write-ticket` will reject prose-only acceptance criteria
+  - **Acceptance Criteria** (Gherkin) derived from the functional requirements — `lisa:tracker-write` will reject prose-only acceptance criteria
   - Blockers with recommendation + alternatives (if any), under `## Open Questions`
   - A **Source Artifacts** section listing the artifacts inherited from the epic that match this story's scope (see propagation rules below)
-- `artifacts`: the Phase 1.5 artifacts filtered by domain per the inheritance table below — `lisa:jira-write-ticket` Phase 4c attaches them as remote links
+- `artifacts`: the Phase 1.5 artifacts filtered by domain per the inheritance table below — `lisa:tracker-write` Phase 4c attaches them as remote links
 - `priority`, `labels`, `components`, `fix_version`: as appropriate
 
 Capture each returned story key — Phase 5 needs it as the parent for sub-tasks.
 
-**Inherit domain-matching artifacts as story remote links**. For each story, the artifact set passed to `lisa:jira-write-ticket` should be the Phase 1.5 artifacts whose domain matches the story's scope:
+**Inherit domain-matching artifacts as story remote links**. For each story, the artifact set passed to `lisa:tracker-write` should be the Phase 1.5 artifacts whose domain matches the story's scope:
 
 | Story type | Inherits domains |
 |------------|------------------|
@@ -223,10 +223,10 @@ When classification is ambiguous, err on the side of inclusion — a developer c
 
 ### Phase 5: Create Sub-tasks
 
-Delegate sub-task creation to **parallel agents** (one per epic or batch of stories) for efficiency. **Every spawned agent must invoke `lisa:jira-write-ticket` for each sub-task — no agent may call `createJiraIssue` directly.** This is non-negotiable; see the Agent Prompt Template at the bottom of this skill for the exact instructions to pass.
+Delegate sub-task creation to **parallel agents** (one per epic or batch of stories) for efficiency. **Every spawned agent must invoke `lisa:tracker-write` for each sub-task — no agent may call `createJiraIssue` directly.** This is non-negotiable; see the Agent Prompt Template at the bottom of this skill for the exact instructions to pass.
 
 Each sub-task MUST:
-1. **Be scoped to exactly ONE repo** — indicated in brackets in the summary: `[repo-name]`. `lisa:jira-write-ticket` enforces single-repo scope on Sub-task; cross-repo sub-tasks will be rejected and must be split before delegation.
+1. **Be scoped to exactly ONE repo** — indicated in brackets in the summary: `[repo-name]`. `lisa:tracker-write` enforces single-repo scope on Sub-task; cross-repo sub-tasks will be rejected and must be split before delegation.
 2. **Include an Empirical Verification Plan** — real user-like verification, NOT unit tests, linting, or typechecking
 
 **Verification plan examples by stack:**
@@ -234,11 +234,11 @@ Each sub-task MUST:
 - **Frontend web**: Playwright browser tests (login with test user, navigate, interact, screenshot)
 - **Infrastructure**: `cdk synth` / `terraform plan` verification, CLI checks after deploy
 
-Use the test user credentials from config for all verification plans. The credentials are passed to `lisa:jira-write-ticket` as the sign-in account so it can record them in the description per its own rules.
+Use the test user credentials from config for all verification plans. The credentials are passed to `lisa:tracker-write` as the sign-in account so it can record them in the description per its own rules.
 
-For each sub-task, the spawned agent invokes `lisa:jira-write-ticket` with `issue_type: "Sub-task"` and `parent` set to the Story key. The Story key is the parent — the epic relationship is inherited transitively.
+For each sub-task, the spawned agent invokes `lisa:tracker-write` with `issue_type: "Sub-task"` and `parent` set to the Story key. The Story key is the parent — the epic relationship is inherited transitively.
 
-Sub-tasks inherit their parent story's artifacts by reference (the parent link). Do not pass the same artifact list to every sub-task — that creates noise. The only exception is when a sub-task depends on an artifact that the parent story doesn't (e.g., a sub-task spec'd from a specific Figma frame that the broader story doesn't cite) — in that case, pass the specific artifact in the `artifacts` parameter to `lisa:jira-write-ticket`.
+Sub-tasks inherit their parent story's artifacts by reference (the parent link). Do not pass the same artifact list to every sub-task — that creates noise. The only exception is when a sub-task depends on an artifact that the parent story doesn't (e.g., a sub-task spec'd from a specific Figma frame that the broader story doesn't cite) — in that case, pass the specific artifact in the `artifacts` parameter to `lisa:tracker-write`.
 
 ### Phase 5.5: Artifact Preservation Gate (mandatory)
 
@@ -246,9 +246,9 @@ Run the preservation gate defined in `lisa:jira-source-artifacts` §8 against th
 
 To run the gate, this skill must:
 
-1. Pull the remote links of every epic and story created in this run via `mcp__atlassian__getJiraIssueRemoteIssueLinks`.
+1. Pull the remote links of every epic and story created in this run via `lisa:tracker-read (vendor-neutral; dispatches to jira-read-ticket or github-read-issue)`.
 2. Apply the §8 preservation matrix and verdict rules.
-3. If the gate fails: list each dropped/misrouted artifact (domain, title, source page, why it was dropped) and either re-attach via `lisa:jira-write-ticket` (UPDATE mode) or stop and ask the human. Never silently proceed past a gate failure.
+3. If the gate fails: list each dropped/misrouted artifact (domain, title, source page, why it was dropped) and either re-attach via `lisa:tracker-write` (UPDATE mode) or stop and ask the human. Never silently proceed past a gate failure.
 4. If the gate passes: print the matrix compactly and proceed to Phase 6.
 
 This gate is not optional. Skipping it is the failure mode the architecture exists to prevent.
@@ -287,13 +287,13 @@ When delegating to agents, provide this context. **The "MUST invoke jira-write-t
 ```text
 Create JIRA sub-tasks in the [PROJECT] project at [CLOUD_ID].
 
-CRITICAL: For each sub-task, invoke the `lisa:jira-write-ticket` skill via the Skill tool.
-Do NOT call `mcp__atlassian__createJiraIssue` directly. The `lisa:jira-write-ticket` skill
+CRITICAL: For each sub-task, invoke the `lisa:tracker-write` skill via the Skill tool.
+Do NOT call `mcp__atlassian__createJiraIssue` directly. The `lisa:tracker-write` skill
 enforces required quality gates (Gherkin acceptance criteria, 3-audience description,
 single-repo scope, sign-in/environment fields, post-create verification). Bypassing it
 produces broken tickets that downstream skills (triage, journey, evidence) cannot use.
 
-For each sub-task, invoke `lisa:jira-write-ticket` with:
+For each sub-task, invoke `lisa:tracker-write` with:
 - issue_type: "Sub-task"
 - parent: the parent story key
 - project_key: [PROJECT]
@@ -309,9 +309,9 @@ For each sub-task, invoke `lisa:jira-write-ticket` with:
 Each sub-task must:
 1. Be scoped to ONE repo only — repo named in brackets in the summary
 2. Include the Empirical Verification Plan in the description
-3. Be created via `lisa:jira-write-ticket`, not via direct MCP calls
+3. Be created via `lisa:tracker-write`, not via direct MCP calls
 
-If `lisa:jira-write-ticket` rejects a sub-task (cross-repo scope, missing Gherkin, missing
+If `lisa:tracker-write` rejects a sub-task (cross-repo scope, missing Gherkin, missing
 sign-in, etc.), fix the input and re-invoke. Do NOT fall back to a direct
 `createJiraIssue` call to bypass the gate.
 

package/plugins/lisa/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, an existing JIRA epic key, a markdown file, or a free-form description; the destination tracker is whatever the project is configured to use (JIRA today; GitHub Issues is pluggable). 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 or GitHub Issues). 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"]
 ---
 
@@ -20,14 +20,16 @@ Detect the input type from `$ARGUMENTS` and route to the appropriate source skil
 
 | If `$ARGUMENTS` is... | Hand off to |
 |------------------------|-------------|
-| A Notion **page** URL or page ID (single PRD) | `lisa:notion-to-jira` (with the PRD URL; runs the full pipeline: extract artifacts → walk live product → validate → write tickets → coverage audit) |
+| A Notion **page** URL or page ID (single PRD) | `lisa:notion-to-tracker` (with the PRD URL; runs the full pipeline: extract artifacts → walk live product → validate → write tickets → coverage audit) |
 | A Notion **database** URL or database ID | Stop and report — single-PRD mode only. Direct the caller to `lisa:intake` for batch scanning of a database. |
-| A Confluence **page** URL containing `/wiki/spaces/<KEY>/pages/<ID>/...` (single PRD) | `lisa:confluence-to-jira` (with the PRD URL; same full pipeline as the Notion path) |
+| A Confluence **page** URL containing `/wiki/spaces/<KEY>/pages/<ID>/...` (single PRD) | `lisa:confluence-to-tracker` (with the PRD URL; same full pipeline as the Notion path) |
 | A Confluence **space** URL (`/wiki/spaces/<KEY>` with no `/pages/...`) | Stop and report — single-PRD mode only. Direct the caller to `lisa:intake` for batch scanning of a space. |
-| A Linear **project** URL (`https://linear.app/<workspace>/project/<slug>-<id>`) | `lisa:linear-to-jira` (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 **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 GitHub Issues URL or key | Not yet implemented. Stop and tell the user the adapter doesn't exist yet — the architecture supports it, but no `github-prd-source` skill has been built. Don't fall back. |
+| 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. |
 | A file path (`@plan.md`, `./spec.md`) | Read the file as the spec; run the Plan flow's core decomposition with the file content as input. |
 | A plain-text description | Use the description as the spec; run the Plan flow's core decomposition. |
 
@@ -39,4 +41,4 @@ Execute the **Plan** flow as defined in the `intent-routing` rule (loaded via th
 
 ## Output
 
-Work items in the configured tracker (JIRA today; GitHub Issues when the adapter exists) 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 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.

package/plugins/lisa/skills/prd-ticket-coverage/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: prd-ticket-coverage
-description: "Verifies that every requirement in a PRD (Notion, Confluence, or Linear) is covered by at least one created JIRA ticket — 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 post-write to gate the Ticketed transition; can also be invoked standalone for after-the-fact audits."
-allowed-tools: ["Skill", "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"]
+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."
+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"]
 ---
 
 # PRD Ticket Coverage Audit: $ARGUMENTS
@@ -11,15 +11,21 @@ allowed-tools: ["Skill", "mcp__claude_ai_Notion__notion-fetch", "mcp__claude_ai_
 1. A PRD URL alone — auto-discover created tickets via the PRD's epic remote link.
 2. A PRD URL plus an explicit list of ticket keys — `<PRD URL> tickets=[KEY-1,KEY-2,...]`. Use this when called from `lisa:notion-prd-intake` or `lisa:confluence-prd-intake` (which know the keys they just created).
 
-The PRD URL can be a **Notion page URL**, a **Confluence page URL**, or a **Linear project URL**. Detect the vendor from the host:
+The PRD URL can be a **Notion page URL**, a **Confluence page URL**, a **Linear project URL**, or a **GitHub issue URL**. Detect the vendor from the host:
 
 - `notion.so` / `notion.site` → Notion. Fetch with `mcp__claude_ai_Notion__notion-fetch` (`include_discussions: true`) and `mcp__claude_ai_Notion__notion-get-comments`.
 - Atlassian Confluence host (e.g. `*.atlassian.net/wiki/...`) → Confluence. Fetch with `mcp__atlassian__getConfluencePage`, `mcp__atlassian__getConfluencePageDescendants` (for child epic pages), `mcp__atlassian__getConfluencePageFooterComments`, `mcp__atlassian__getConfluencePageInlineComments`, and `mcp__atlassian__getConfluenceCommentChildren` for nested replies.
 - `linear.app` host → Linear. Fetch with `mcp__linear-server__get_project` (capture description, labels, state, attached resources), `mcp__linear-server__list_documents({projectId})` + `mcp__linear-server__get_document` per attached document, `mcp__linear-server__list_issues({project})` for sub-issues that act as child epics / user stories, and `mcp__linear-server__list_comments({issueId})` per sub-issue for decisions and engineering notes. Comments do not exist on the project itself in the MCP surface — sub-issue comments are the substitute.
+- `github.com` host → GitHub Issues. Fetch with the `gh` CLI (no GitHub MCP — Lisa uses the CLI exclusively for GitHub):
+  - `gh issue view <number> --repo <org>/<repo> --json number,title,body,labels,milestone,assignees,author,createdAt,comments,url` for the PRD body and comments.
+  - `gh api graphql` with the `subIssues` field for native sub-issue children (these stand in for child epic pages — see `lisa:github-read-issue` Phase 3 for the exact query).
+  - `gh issue view <child-num> --repo <org>/<repo> --json body,comments` per child sub-issue, recursively to depth 3.
 
-All three vendors produce the same downstream artifact-extraction and coverage-matrix logic — only the fetch surface differs. The rest of this skill is vendor-agnostic.
+All four vendors produce the same downstream artifact-extraction and coverage-matrix logic — only the fetch surface differs. The rest of this skill is vendor-agnostic.
 
-Verify that every atomic item in the PRD is covered by at least one of the listed/discovered JIRA tickets. The output gates whether the PRD's lifecycle should remain at `Ticketed` (Notion `Status = Ticketed`, Confluence `prd-ticketed` label, Linear `prd-ticketed` project label) or revert to `Blocked`.
+Verify that every atomic item in the PRD is covered by at least one of the listed/discovered destination tickets. The output gates whether the PRD's lifecycle should remain at `Ticketed` (Notion `Status = Ticketed`, Confluence / Linear / GitHub `prd-ticketed` label) or revert to `Blocked`.
+
+The destination tickets are read via `lisa:tracker-read` (which dispatches to `lisa:jira-read-ticket` or `lisa:github-read-issue` per `.lisa.config.json` `tracker`) so this skill itself stays agnostic of which tracker hosts the work.
 
 ## Why this exists
 
@@ -36,16 +42,20 @@ Per-ticket gates (`lisa:jira-validate-ticket`) prove each created ticket is well
    - **Notion**: `notion-fetch` with `include_discussions: true`. Capture: title, body, child Epic pages, all comment threads.
    - **Confluence**: `getConfluencePage` (capture title, body, labels), `getConfluencePageFooterComments` + `getConfluencePageInlineComments` (capture all comments; walk replies via `getConfluenceCommentChildren` for any thread with children).
    - **Linear**: `get_project` (capture name, description, labels, state, attached resources). Capture sub-issues via `list_issues({project})` and per-issue comments via `list_comments({issueId})`.
-3. If the PRD has child Epic sub-pages (a multi-epic PRD), fetch each in parallel:
+   - **GitHub**: `gh issue view --json` for the source PRD issue (title, body, labels, comments). Capture sub-issues via the GraphQL `subIssues` traversal.
+3. If the PRD has child Epic sub-pages / sub-issues (a multi-epic PRD), fetch each in parallel:
    - **Notion**: `notion-fetch` per child page with `include_discussions: true`.
    - **Confluence**: enumerate descendants via `getConfluencePageDescendants`, then `getConfluencePage` per child plus its comment streams.
    - **Linear**: enumerate attached documents via `list_documents({projectId})` and fetch each via `get_document`. Treat each document as an extra body source. Sub-issues themselves stand in for "child epic pages" — their descriptions and comments are already captured in step 2.
+   - **GitHub**: enumerate native sub-issues via `gh api graphql` (`subIssues` field), then `gh issue view <child-num> --json body,comments` per child. Recurse to depth 3.
    The audit walks the full PRD tree.
-4. If `tickets=[...]` not provided, locate the JIRA epic by:
-   - Looking for a JIRA URL in the PRD body, comments, or the PRD's most recent "Ticketed by Claude" comment posted by `lisa:notion-prd-intake` / `lisa:confluence-prd-intake` / `lisa:linear-prd-intake` (for Linear, this comment lives on the project's sentinel feedback issue).
-   - Searching JIRA via `searchJiraIssuesUsingJql` for an epic whose summary or description references the PRD title or project ID.
+4. If `tickets=[...]` not provided, locate the destination Epic by:
+   - Looking for a destination URL in the PRD body, comments, or the PRD's most recent "Ticketed by Claude" comment posted by `lisa:notion-prd-intake` / `lisa:confluence-prd-intake` / `lisa:linear-prd-intake` / `lisa:github-prd-intake` (for Linear, this comment lives on the project's sentinel feedback issue; for the others, it lives on the PRD page / issue itself).
+   - Searching the destination tracker via `lisa:tracker-read` (or directly via `searchJiraIssuesUsingJql` / `gh issue list --search`) for an epic whose summary or description references the PRD title or project ID.
    - If no epic found, return verdict `NO_TICKETS_FOUND` with a clear remediation — coverage cannot be assessed without the ticket set.
-5. Once the epic is known, fetch all child stories and sub-tasks via JQL: `"Epic Link" = <EPIC-KEY>` and recursively for sub-tasks.
+5. Once the epic is known, fetch all child stories and sub-tasks:
+   - **JIRA destination**: JQL `"Epic Link" = <EPIC-KEY>` and recursively for sub-tasks.
+   - **GitHub destination**: `gh api graphql` `subIssues` traversal of the Epic, recursively for sub-tasks.
 
 ### Phase 2 — Extract atomic PRD items
 
@@ -147,7 +157,7 @@ Atomic PRD items extracted: <n>
 ### Scope-creep count: <n>
 ```
 
-`prd_anchor` and `prd_section` are built the same way as in `lisa:notion-to-jira` / `lisa:confluence-to-jira` / `lisa:linear-to-jira`. For Notion, `prd_anchor` is the `selection_with_ellipsis` start/end snippet; for Confluence, it's the inline-comment selection text accepted by `createConfluenceInlineComment`; for Linear, it's a sub-issue identifier (e.g. `LIN-123`) when the gap maps to a specific issue, otherwise `null` (the caller posts unanchored Linear gaps on the project's sentinel feedback issue). The downstream caller knows which vendor it's writing to and uses the right API; this skill just emits the anchor that vendor expects.
+`prd_anchor` and `prd_section` are built the same way as in `lisa:notion-to-tracker` / `lisa:confluence-to-tracker` / `lisa:linear-to-tracker` / `lisa:github-to-tracker`. For Notion, `prd_anchor` is the `selection_with_ellipsis` start/end snippet; for Confluence, it's the inline-comment selection text accepted by `createConfluenceInlineComment`; for Linear, it's a sub-issue identifier (e.g. `LIN-123`) when the gap maps to a specific issue, otherwise `null` (the caller posts unanchored Linear gaps on the project's sentinel feedback issue); for GitHub, it's the section heading from the PRD issue body when the gap traces to a specific section, otherwise `null` (the caller approximates inline anchoring by quoting a body excerpt at the top of the comment). The downstream caller knows which vendor it's writing to and uses the right API; this skill just emits the anchor that vendor expects.
 
 `category` is drawn from the same fixed taxonomy used by `lisa:jira-validate-ticket` so downstream callers can apply one consistent comment-formatting policy. Most coverage gaps map to `scope` (item not represented in any ticket) or `product-clarity` (item too vague to map). Use `acceptance-criteria` for missing pass/fail conditions and `design-ux` for missing visuals.
 
@@ -157,4 +167,4 @@ Atomic PRD items extracted: <n>
 - Never silently drop a PRD item from extraction. If an item is ambiguous about whether it's scope, include it in extraction with type `ambiguous` and let the matching phase resolve it. The point of the audit is to catch silent drops; the audit can't have its own.
 - Be explicit about confidence in matches — the matrix is for humans to skim; vague matches help no one. If a match is rule-3 ("scope inheritance"), say so.
 - Scope creep is INFORMATIONAL. It is normal for an agent to add infra tickets (`X.0 Setup`) the PRD doesn't explicitly enumerate. Only flag scope creep when the ticket genuinely doesn't trace to PRD content AND isn't standard scaffolding.
-- The `GAPS_FOUND` verdict is the gate. The caller (e.g. `lisa:notion-prd-intake`, `lisa:confluence-prd-intake`, `lisa:linear-prd-intake`) uses it to decide whether to revert the lifecycle from `Ticketed` to `Blocked`.
+- The `GAPS_FOUND` verdict is the gate. The caller (e.g. `lisa:notion-prd-intake`, `lisa:confluence-prd-intake`, `lisa:linear-prd-intake`, `lisa:github-prd-intake`) uses it to decide whether to revert the lifecycle from `Ticketed` to `Blocked`.

package/plugins/lisa/skills/product-walkthrough/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: product-walkthrough
-description: "Methodology for evaluating the live product via a real browser (Playwright MCP) when planning work or evaluating a PRD. Reading a PRD or a mock without seeing the current product produces tickets that misjudge the change — this skill grounds the analysis in what actually exists today. Invoke this skill from notion-to-jira (Phase 2b live-product walkthrough), jira-create, and any PRD intake flow whose work touches existing user-facing surfaces."
+description: "Methodology for evaluating the live product via a real browser (Playwright MCP) when planning work or evaluating a PRD. Reading a PRD or a mock without seeing the current product produces tickets that misjudge the change — this skill grounds the analysis in what actually exists today. Invoke this skill from notion-to-tracker (Phase 2b live-product walkthrough), jira-create, and any PRD intake flow whose work touches existing user-facing surfaces."
 allowed-tools: ["Skill", "Bash", "Read", "mcp__plugin_playwright_playwright__browser_navigate", "mcp__plugin_playwright_playwright__browser_snapshot", "mcp__plugin_playwright_playwright__browser_take_screenshot", "mcp__plugin_playwright_playwright__browser_click", "mcp__plugin_playwright_playwright__browser_type", "mcp__plugin_playwright_playwright__browser_select_option", "mcp__plugin_playwright_playwright__browser_fill_form", "mcp__plugin_playwright_playwright__browser_press_key", "mcp__plugin_playwright_playwright__browser_hover", "mcp__plugin_playwright_playwright__browser_navigate_back", "mcp__plugin_playwright_playwright__browser_resize", "mcp__plugin_playwright_playwright__browser_tabs", "mcp__plugin_playwright_playwright__browser_console_messages", "mcp__plugin_playwright_playwright__browser_network_requests", "mcp__plugin_playwright_playwright__browser_wait_for", "mcp__plugin_playwright_playwright__browser_close"]
 ---
 

package/plugins/lisa/skills/spec-conformance/SKILL.md

@@ -24,10 +24,9 @@ Based on the source, load the full spec:
 | Source | How to Load |
 |--------|-------------|
 | Plan file (`.md`) | `Read` the file |
-| JIRA key | Invoke `/jira-read-ticket <KEY>` to get the full context bundle (primary ticket + epic + linked tickets) |
+| 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" |
-| GitHub issue | `gh issue view <number> --json title,body,comments,labels,milestone` |
-| PRD | `Read` the file or fetch via Notion MCP if it's a Notion URL |
+| PRD | `Read` the file or fetch via Notion / Confluence MCP, or `gh issue view` for a GitHub PRD |
 
 ## Phase 2 — Extract Requirements
 

package/plugins/lisa/skills/ticket-triage/SKILL.md

@@ -1,30 +1,30 @@
 ---
 name: ticket-triage
-description: "Analytical triage gate for JIRA tickets. 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."
+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."
 allowed-tools: ["Read", "Glob", "Grep", "Bash"]
 ---
 
 # Ticket Triage: $ARGUMENTS
 
-Perform analytical triage on the JIRA ticket. The caller MUST have run `lisa:jira-read-ticket` first and provided the resulting context bundle — which includes the primary ticket, all linked tickets (blocks / is blocked by / relates to / duplicates), epic parent, epic siblings, subtasks, and remote PR state. Do not triage from a bare ticket summary — if the bundle is missing link or epic context, stop and instruct the caller to run `/lisa:jira-read-ticket` first.
+Perform analytical triage on the ticket. The caller MUST have run `lisa:tracker-read` (or its vendor-specific underlying skill — `lisa:jira-read-ticket` for JIRA, `lisa:github-read-issue` for GitHub) first and provided the resulting context bundle — which includes the primary ticket, all linked tickets (blocks / is blocked by / relates to / duplicates), parent (Epic in JIRA, parent sub-issue in GitHub), siblings, sub-tasks / sub-issues, and remote PR state. Do not triage from a bare ticket summary — if the bundle is missing link or parent context, stop and instruct the caller to run `/tracker-read` first.
 
 Repository name for scoped labels and comment headers: determine via `basename $(git rev-parse --show-toplevel)`.
 
 ## Phase 0 -- Pre-flight Description Gate
 
-Before any analytical work, confirm the ticket carries the content an implementer needs to start. The caller should already have run `lisa:jira-verify`; this phase consumes its output. If `lisa:jira-verify` returned `FAIL` for any of the following, emit `BLOCKED` immediately with the missing-requirements list and skip to Phase 6:
+Before any analytical work, confirm the ticket carries the content an implementer needs to start. The caller should already have run `lisa:tracker-verify`; this phase consumes its output. If `lisa:tracker-verify` returned `FAIL` for any of the following, emit `BLOCKED` immediately with the missing-requirements list and skip to Phase 6:
 
-- Epic parent missing (non-bug, non-epic)
+- Parent missing (Epic parent for JIRA non-bug-non-epic; parent sub-issue for GitHub non-bug-non-epic)
 - Description quality failures (no Gherkin acceptance criteria, missing audience sections)
 - Validation Journey missing on a runtime-behavior ticket
 - Target backend environment missing on a runtime-behavior ticket
 - Sign-in credentials missing on a ticket that touches authenticated surfaces
 - Single-repo scope violated (Bug / Task / Sub-task spanning repos)
-- Relationship discovery missing (no links AND no documented git+JQL search)
+- Relationship discovery missing (no links AND no documented git + tracker-search outcome)
 
-The caller (jira-agent) is responsible for transitioning the ticket to `Blocked`, reassigning to the **Reporter**, and posting a comment listing the missing requirements. This skill only emits the verdict and the missing-requirements list.
+The caller (jira-agent or github-agent) is responsible for transitioning the ticket to `Blocked` (JIRA status) or relabeling to `status:blocked` (GitHub), reassigning to the **Reporter / original author**, and posting a comment listing the missing requirements. This skill only emits the verdict and the missing-requirements list.
 
-If `lisa:jira-verify` returned `PASS` for all the above, proceed to Phase 1.
+If `lisa:tracker-verify` returned `PASS` for all the above, proceed to Phase 1.
 
 ## Phase 1 -- Relevance Check
 

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

@@ -0,0 +1,24 @@
+---
+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."
+allowed-tools: ["Skill", "Bash", "Read"]
+---
+
+# Tracker Add Journey: $ARGUMENTS
+
+Thin dispatcher. Resolves the configured destination tracker and delegates to the matching vendor skill.
+
+See the `tracker-resolution` rule for configuration and dispatch table.
+
+## Workflow
+
+1. Resolve tracker config (same logic as `lisa:tracker-write`).
+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.
+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`.
+- If the ticket already has a Validation Journey, the vendor skill reports it and stops. This shim does not retry.

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

@@ -0,0 +1,25 @@
+---
+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."
+allowed-tools: ["Skill", "Bash", "Read"]
+---
+
+# Tracker Build Intake: $ARGUMENTS
+
+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.
+
+## Workflow
+
+1. Resolve tracker config (same logic as `lisa:tracker-write`).
+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.
+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.
+- Never run two intake cycles concurrently against overlapping queues — the scheduling layer is responsible for serialization.

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

@@ -0,0 +1,24 @@
+---
+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."
+allowed-tools: ["Skill", "Bash", "Read"]
+---
+
+# Tracker Create: $ARGUMENTS
+
+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.
+
+## Workflow
+
+1. Resolve tracker config (same logic as `lisa:tracker-write`).
+2. Dispatch:
+   - `jira` → invoke `lisa:jira-create` with `$ARGUMENTS` verbatim.
+   - `github` → invoke `lisa:github-create` with `$ARGUMENTS` verbatim.
+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.
+- This shim is for ad-hoc creation from code files / descriptions. PRD-driven creation goes through the `*-to-tracker` skills (notion / confluence / linear / github).

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

@@ -0,0 +1,24 @@
+---
+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."
+allowed-tools: ["Skill", "Bash", "Read"]
+---
+
+# Tracker Evidence: $ARGUMENTS
+
+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.
+
+## Workflow
+
+1. Resolve tracker config (same logic as `lisa:tracker-write`).
+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.
+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.
+- Never post evidence to a different ticket than the one named — `$ARGUMENTS` is the source of truth.

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

@@ -0,0 +1,24 @@
+---
+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."
+allowed-tools: ["Skill", "Bash", "Read"]
+---
+
+# Tracker Journey: $ARGUMENTS
+
+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.
+
+## Workflow
+
+1. Resolve tracker config (same logic as `lisa:tracker-write`).
+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]`.
+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`).
+- Evidence posting always goes through `lisa:tracker-evidence` — never bypass.

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

@@ -0,0 +1,25 @@
+---
+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."
+allowed-tools: ["Skill", "Bash", "Read"]
+---
+
+# Tracker Read: $ARGUMENTS
+
+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.
+
+## Workflow
+
+1. Resolve tracker config (same logic as `lisa:tracker-write`).
+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.
+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.

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

@@ -0,0 +1,26 @@
+---
+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."
+allowed-tools: ["Skill", "Bash", "Read"]
+---
+
+# Tracker Sync: $ARGUMENTS
+
+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.
+
+## Workflow
+
+1. Resolve tracker config (same logic as `lisa:tracker-write`).
+2. Dispatch:
+   - `jira` → invoke `lisa:jira-sync` with `$ARGUMENTS` verbatim.
+   - `github` → invoke `lisa:github-sync` with `$ARGUMENTS` verbatim.
+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/`).
+
+## 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.