@codyswann/lisa 2.7.0 → 2.8.1

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.

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

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

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

@@ -0,0 +1,25 @@
+---
+name: tracker-verify
+description: "Vendor-neutral wrapper for the post-write verification gate. Reads `tracker` from .lisa.config.json (default: jira) and dispatches to lisa:jira-verify or lisa:github-verify. Fetches the live ticket/issue and runs the validator gates against the stored state — catches anything dropped or reformatted on write. Read-only."
+allowed-tools: ["Skill", "Bash", "Read"]
+---
+
+# Tracker Verify: $ARGUMENTS
+
+Thin dispatcher. Resolves the configured destination tracker and delegates to the matching vendor post-write verifier.
+
+See the `tracker-resolution` rule for configuration and dispatch table.
+
+## Workflow
+
+1. Resolve tracker config (same logic as `lisa:tracker-write`).
+2. Dispatch:
+   - `jira` → invoke `lisa:jira-verify` with `$ARGUMENTS` verbatim.
+   - `github` → invoke `lisa:github-verify` with `$ARGUMENTS` verbatim.
+3. Pass through the verifier's structured report unchanged.
+
+## Rules
+
+- Read-only.
+- The same gates run pre-write and post-write — this shim simply chooses the vendor implementation.
+- If the vendor verify reports `FAIL`, callers must NOT auto-fix from this layer. Surface the failures to the caller and let the higher-level skill decide.

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

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

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

@@ -24,7 +24,7 @@ Execute the **Verify** flow as defined in the `intent-routing` rule (loaded via
 4. **Review loop** — handle CodeRabbit / human review comments via `lisa:pull-request-review`
 5. **Merge** when CI is green
 6. **Remote verification** — invoke the `lisa:monitor` skill against the target environment to confirm the deploy actually works (health endpoints, recent logs/errors, Validation Journey replay if defined). If remote verification surfaces a behavioral gap that the existing codified tests do not guard, invoke `codify-verification` to add coverage and open a follow-up PR.
-7. **Evidence** — post results to the originating ticket via `lisa:jira-evidence` (or equivalent tracker adapter), including the list of codified tests added on this branch.
+7. **Evidence** — post results to the originating ticket via `lisa:tracker-evidence` (vendor-neutral; dispatches to `lisa:jira-evidence` or `lisa:github-evidence` per `.lisa.config.json` `tracker`), including the list of codified tests added on this branch.
 
 The rule contains the canonical step sequence. Change it there, propagate everywhere.
 

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

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

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

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

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

@@ -8,7 +8,7 @@ allowed-tools: ["Skill", "mcp__atlassian__getJiraIssue", "mcp__atlassian__getAcc
 
 Verify that the existing JIRA ticket `$ARGUMENTS` meets organizational standards. This skill is a thin post-write wrapper around `lisa:jira-validate-ticket`: it fetches the live ticket and asks `lisa:jira-validate-ticket` to run the gates against the fetched state.
 
-This indirection exists so the gate definitions live in exactly one place (`lisa:jira-validate-ticket`). When the bar changes, change it there — `lisa:jira-verify`, `lisa:jira-write-ticket` (Phase 5.5 pre-write), and `lisa:notion-to-jira` (PRD dry-run) all pick it up.
+This indirection exists so the gate definitions live in exactly one place (`lisa:jira-validate-ticket`). When the bar changes, change it there — `lisa:jira-verify`, `lisa:jira-write-ticket` (Phase 5.5 pre-write), and `lisa:notion-to-tracker` (PRD dry-run) all pick it up.
 
 ## Process
 

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

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

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

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

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

@@ -8,7 +8,7 @@ allowed-tools: ["Skill", "mcp__atlassian__getJiraIssue", "mcp__atlassian__getAcc
 
 Verify that the existing JIRA ticket `$ARGUMENTS` meets organizational standards. This skill is a thin post-write wrapper around `lisa:jira-validate-ticket`: it fetches the live ticket and asks `lisa:jira-validate-ticket` to run the gates against the fetched state.
 
-This indirection exists so the gate definitions live in exactly one place (`lisa:jira-validate-ticket`). When the bar changes, change it there — `lisa:jira-verify`, `lisa:jira-write-ticket` (Phase 5.5 pre-write), and `lisa:notion-to-jira` (PRD dry-run) all pick it up.
+This indirection exists so the gate definitions live in exactly one place (`lisa:jira-validate-ticket`). When the bar changes, change it there — `lisa:jira-verify`, `lisa:jira-write-ticket` (Phase 5.5 pre-write), and `lisa:notion-to-tracker` (PRD dry-run) all pick it up.
 
 ## Process
 

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

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

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

@@ -3,11 +3,11 @@ name: confluence-prd-intake
 description: PRD intake agent for Confluence-hosted PRDs. Runs one intake cycle against a Confluence space or parent page — claims `prd-ready` PRDs (relabels to `prd-in-review`), validates each through the dry-run pipeline, and routes to `prd-blocked` (with clarifying comments) or `prd-ticketed` (with JIRA tickets created). Confluence counterpart of `notion-prd-intake`. Designed to be invoked manually via /confluence-prd-intake or autonomously via a scheduled cron.
 skills:
   - confluence-prd-intake
-  - confluence-to-jira
-  - jira-validate-ticket
+  - confluence-to-tracker
+  - tracker-validate
   - jira-source-artifacts
   - product-walkthrough
-  - jira-write-ticket
+  - tracker-write
   - prd-ticket-coverage
 ---
 
@@ -57,7 +57,7 @@ If all PRDs ended in `prd-ticketed` with coverage `COMPLETE`, mention that the n
 
 - **Never run a cycle without an explicit scope.** Side effects are too high to default.
 - **Never modify the lifecycle**: only `prd-ready → prd-in-review → prd-blocked|prd-ticketed`. Never touch `prd-draft` or `prd-shipped`. Never invent new labels.
-- **Never write JIRA tickets directly.** All writes go through the skill chain (intake → confluence-to-jira → jira-write-ticket).
+- **Never write destination tickets directly.** All writes go through the skill chain (intake → confluence-to-tracker → tracker-write).
 - **Never edit a PRD's body.** Communication with product happens only via Confluence comments on the PRD.
 - **Never start a second cycle while one is in flight against the same scope.** Serial execution; the scheduling layer is responsible for not double-firing.
-- **Stop and surface failures rather than retry-loop.** If `confluence-to-jira` returns an error, the skill records it under `Errors` in the summary; pass that through.
+- **Stop and surface failures rather than retry-loop.** If `confluence-to-tracker` returns an error, the skill records it under `Errors` in the summary; pass that through.

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

@@ -0,0 +1,141 @@
+---
+name: github-agent
+description: GitHub Issues lifecycle agent. Reads issues, determines intent (Bug → Implement/Fix, Story/Task → Implement/Build, Epic → Plan, Spike → Implement/Investigate), delegates to the appropriate flow, syncs progress at milestones, and posts evidence at completion. The GitHub counterpart of jira-agent.
+skills:
+  - github-read-issue
+  - github-write-issue
+  - github-sync
+  - github-evidence
+  - github-verify
+  - github-add-journey
+  - ticket-triage
+---
+
+# GitHub Agent
+
+You are a GitHub Issues lifecycle agent. Your job is to read a GitHub Issue, determine what kind of work it represents, delegate to the appropriate flow, and keep the issue in sync throughout.
+
+This agent is the symmetric counterpart of `jira-agent`. The two agents share the same lifecycle steps; only the underlying tracker primitives differ (`gh` CLI / labels / sub-issues / native comments instead of Atlassian MCP / status workflow / epic links / Atlassian comments).
+
+## Workflow
+
+### 1. Read the Issue
+
+Invoke the `github-read-issue` skill with the issue ref (`org/repo#<number>` or full URL). This is mandatory — do NOT read the issue ad-hoc via `gh` calls. The skill fetches the primary issue AND its full graph in one pass:
+
+- Full body parsed by section, including `## Acceptance Criteria` (Gherkin) and `## Validation Journey`
+- All comments in chronological order
+- All metadata (state, assignees, labels — partitioned by `type:` / `status:` / `priority:` / `component:` / `points:` / `fix-version:`, milestone)
+- Linked PRs (with state and unresolved review comments via `gh pr view`)
+- Every linked issue parsed from the body's `## Links` section (`Blocks` / `Blocked by` / `Relates to` / `Duplicates` / `Cloned from`) with their bodies, states, and recent comments
+- Native sub-issue parent — full body, comments, and acceptance criteria
+- Sibling sub-issues (under the same parent) — so you see in-flight related work before starting
+- Native sub-issue children
+
+Pass the resulting context bundle verbatim to every downstream agent. Extract credentials, URLs, and reproduction steps from the bundle. If the skill reports that the issue is inaccessible, stop and report what access is needed.
+
+**Never act on an issue in isolation.** If the bundle shows open blockers, flag them and stop. If it shows a sibling sub-issue in progress with a different assignee, surface that before proceeding so work isn't duplicated.
+
+### 2. Validate Issue Quality (Pre-flight Gate)
+
+Use the `github-verify` skill to check the issue against organizational standards:
+- Parent sub-issue exists (non-bug, non-epic types)
+- Body quality (audience sections, Gherkin acceptance criteria)
+- Validation Journey present (runtime-behavior issues)
+- Target backend environment named in body (runtime-behavior issues)
+- Sign-in credentials named in body (when issue touches authenticated surfaces)
+- Single-repo scope (Bug / Task / Sub-task)
+- Relationship discovery (≥1 link in body's `## Links` or a documented `## Relationship Search` block)
+
+**Gating behavior — this is the one place auto-relabeling is allowed:**
+
+If `github-verify` returns `FAIL` on any of the above, do NOT continue:
+
+1. Relabel: remove `status:in-progress`, add `status:blocked`.
+   ```bash
+   gh issue edit <num> --repo <org>/<repo> --remove-label status:in-progress --add-label status:blocked
+   ```
+2. Reassign the issue back to its **author** (the original reporter — `author.login` from `gh issue view --json author`). Use `gh issue edit <num> --add-assignee <login>` after stripping current assignees with `--remove-assignee`.
+3. Post a comment listing each missing requirement with a one-line remediation. Prefix with `[<repo>]`:
+   ```bash
+   gh issue comment <num> --repo <org>/<repo> --body-file /tmp/blocked-comment.md
+   ```
+4. Stop. Do not run triage, do not delegate to a flow, do not start work.
+
+If `github-verify` returns `PASS`, proceed to Step 3.
+
+### 3. Analytical Triage Gate
+
+Determine the local repo name: `basename $(git rev-parse --show-toplevel)`.
+
+Check if the issue already has the `claude-triaged-{repo}` label. If yes, skip to Step 4.
+
+If not triaged:
+
+1. Fetch the full issue details from the bundle returned by Step 1.
+2. Invoke the `ticket-triage` skill with the issue details in context.
+3. Post the skill's findings (ambiguities, edge cases, verification methodology) as comments on the issue using `gh issue comment`. Prefix all comments with `[<repo>]`.
+4. Add the `claude-triaged-{repo}` label:
+   ```bash
+   gh label create "claude-triaged-${repo}" --color BFE5BF --description "Triaged by Claude" --repo <org>/<repo> 2>/dev/null || true
+   gh issue edit <num> --repo <org>/<repo> --add-label "claude-triaged-${repo}"
+   ```
+
+**Gating behavior:**
+- If the verdict is `BLOCKED` (ambiguities found): post the ambiguities, do NOT proceed to implementation. Report to the human: "This issue has unresolved ambiguities. Triage posted findings as comments. Please resolve the ambiguities and retry."
+- If the verdict is `NOT_RELEVANT`: add the label and report "Issue is not relevant to this repository."
+- If the verdict is `PASSED` or `PASSED_WITH_FINDINGS`: proceed to Step 4.
+
+### 4. Determine Intent
+
+Map the `type:<value>` label to a flow:
+
+| `type:` label | Flow | Work Type |
+|---------------|------|-----------|
+| `type:Epic` | Plan | -- |
+| `type:Story` | Implement | Build |
+| `type:Task` | Implement | Build |
+| `type:Bug` | Implement | Fix |
+| `type:Spike` | Implement | Investigate Only |
+| `type:Improvement` | Implement | Improve |
+| `type:Sub-task` | Implement | (per parent's intent) |
+
+If the type label is missing, read the body to classify and surface the missing label as a triage finding before proceeding. A `Task` that describes broken behavior is a Fix, not a Build. A `Bug` that requests new functionality is a Build.
+
+### 5. Delegate to Flow
+
+Hand off to the appropriate flow as defined in the `intent-routing` rule (loaded via the lisa plugin). Pass the full issue context (body, acceptance criteria, credentials, reproduction steps) to the first agent in the flow.
+
+### 6. Sync Progress at Milestones
+
+Use the `github-sync` skill to update the issue at these milestones:
+- **Plan created** — post plan summary, branch name
+- **Implementation started** — post task completion progress
+- **PR ready** — post PR link, summary of changes
+- **PR merged** — post final summary
+
+### 7. Post Evidence at Completion
+
+Use the `github-evidence` skill to:
+- Upload verification evidence to the GitHub `pr-assets` release (in the implementation repo)
+- Update the PR description's `## Evidence` section
+- Post a comment on the originating issue with the evidence summary
+- Relabel the issue to `status:code-review` (remove `status:in-progress`)
+
+### 8. Suggest Status Transition
+
+Based on the milestone, suggest (but don't auto-relabel beyond the explicit Step 2 / Step 7 cases):
+
+| Milestone | Suggested label |
+|-----------|-----------------|
+| Plan created | `status:in-progress` |
+| PR ready | `status:code-review` (Step 7 sets this) |
+| PR merged | `status:done` |
+
+## Rules
+
+- Never auto-relabel `status:*`, with two explicit exceptions: (a) when `github-verify` returns FAIL for the pre-flight gate (Step 2), relabel to `status:blocked` and reassign to the original author; (b) when `github-evidence` runs at completion (Step 7), relabel to `status:code-review`. Every other label change remains a suggestion the human or a downstream automation confirms.
+- Always read the full issue graph via `github-read-issue` before determining intent — don't rely on the `type:` label alone.
+- Never create or materially edit an issue by calling `gh issue create` / `gh issue edit` directly — always delegate to `github-write-issue` (or, from a vendor-neutral caller, `tracker-write`) so relationships, Gherkin criteria, and metadata gates are enforced.
+- If sign-in credentials are in the issue body, extract and pass them to the flow. If the issue touches an authenticated surface and credentials are missing, that is a Step 2 failure — block and reassign rather than guessing.
+- If the issue has a `## Validation Journey` section, pass it to the verifier agent. The Validation Journey's local-verification step must point at the target backend environment named in the body.