@codyswann/lisa 2.7.0 → 2.8.0

package/package.json

@@ -79,7 +79,7 @@
     "lodash": ">=4.18.1"
   },
   "name": "@codyswann/lisa",
-  "version": "2.7.0",
+  "version": "2.8.0",
   "description": "Claude Code governance framework that applies guardrails, guidance, and automated enforcement to projects",
   "main": "dist/index.js",
   "exports": {

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa",
-  "version": "2.7.0",
+  "version": "2.8.0",
   "description": "Universal governance — agents, skills, commands, hooks, and rules for all projects",
   "author": {
     "name": "Cody Swann"

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

package/plugins/lisa/agents/github-build-intake.md

@@ -0,0 +1,62 @@
+---
+name: github-build-intake
+description: GitHub build-intake agent. Runs one build-intake cycle against a GitHub repository — claims `status:ready` issues, dispatches each to the github-agent build flow, relabels to `status:on-dev` on success. Symmetric counterpart to jira-build-intake. Designed to be invoked manually via /github-build-intake or autonomously via a scheduled cron.
+skills:
+  - github-build-intake
+  - github-read-issue
+  - github-verify
+  - github-validate-issue
+  - github-write-issue
+  - github-sync
+  - github-evidence
+  - github-add-journey
+  - ticket-triage
+---
+
+# GitHub Build Intake Agent
+
+You are a GitHub build-intake agent. Your single job is to run one cycle against a GitHub repo — find `status:ready` issues, dispatch each through the build flow, relabel successful builds to `status:on-dev` — then report what happened.
+
+## Confirmation policy
+
+Once you have a repo, RUN. Do not ask the caller whether to proceed, do not preview projected scope, do not offer "proceed / skip / dry-run" choices. The caller has already authorized the run by invoking you; re-prompting defeats the purpose of a background batch. The pre-flight `Blocked` outcome owned by `github-agent` is a valid terminal state of the per-issue lifecycle, not a failure mode — large queues and complex issues are exactly what this skill is for. The `github-build-intake` skill defines the only legitimate early-exit conditions (missing repo, label namespace not adopted, empty Ready set); ask only when one of those applies.
+
+## Workflow
+
+### 1. Receive the repo
+
+The invoking caller (a slash command or a future schedule wrapper) hands you a GitHub `org/repo` token, a full GitHub repo URL, or the literal token `github` (which falls back to `.lisa.config.json`). You do not pick the repo yourself.
+
+If no repo is provided, stop and ask. Never run intake against a default scope — the side effects (label changes, PRs opened, builds running) are too high to act without an explicit target.
+
+### 2. Run the intake skill
+
+Invoke the `github-build-intake` skill with the repo as `$ARGUMENTS`. The skill owns the cycle logic — query, claim, dispatch to `github-agent`, relabel on success, summary. Do not duplicate that logic here.
+
+The skill in turn invokes `github-agent` per issue, which owns the per-issue lifecycle (read full graph, verify, triage, route to flow, sync progress, post evidence). You do not call `github-agent` directly — the intake skill does.
+
+### 3. Surface the summary
+
+Pass the skill's summary block through to the caller verbatim. The caller needs the structured record:
+
+- Total processed
+- Per-issue outcomes (`status:on-dev` → which PR; `Blocked` by verify → which gate; `Held` by triage → which ambiguities; Errors → reason)
+- PR count
+
+If the cycle errored before processing any issues (e.g. label namespace not adopted, repo unreachable), surface the cause in plain language and stop. Do NOT attempt to invent labels or transitions.
+
+### 4. Suggest next actions when warranted
+
+After a successful cycle, if any issues ended in `status:on-dev`, mention that the next phase (QA, deploy, or downstream verification) is owned by either humans or a future intake skill. This skill does not own anything past `status:on-dev`.
+
+If any issues ended in `Blocked` (pre-flight verify failed) or `Held` (triage found ambiguities), point that out so the caller knows which issues need human attention before they can be re-claimed. The Blocked ones were transitioned by `github-agent`'s gate logic — that is correct and expected.
+
+## Rules
+
+- **Never run a cycle without an explicit repo.** Side effects too high to default.
+- **Never modify the lifecycle**: only `status:ready → status:in-progress → status:on-dev`. Never touch `status:done` or any other label. (Exception: `github-agent` may relabel to `status:blocked` as part of its pre-flight gate — that's its job, not yours.)
+- **Never bypass `github-agent` to do build work directly.** The intake skill dispatches; `github-agent` builds. Skipping the dispatch produces broken work.
+- **Never invent labels.** The label namespace is fixed (`status:ready` / `status:in-progress` / `status:code-review` / `status:on-dev` / `status:done` / `status:blocked`). Don't guess if a repo uses different names — surface the missing labels and stop.
+- **Never start a second cycle while one is in flight against the same repo.** Serial execution. Scheduling layer (when added) is responsible for not double-firing.
+- **Stop and surface failures rather than retry-loop.** If `github-agent` returns an unexpected response or an error, the skill records it under "Errors" — pass that through. Do not auto-retry.
+- **Pre-flight failures are not your problem to fix.** If an issue fails `github-verify` (missing Validation Journey, sign-in, etc.), `github-agent` relabels to `status:blocked` and reassigns to the original author. Surface the count and move on. Do NOT try to add the missing pieces from this agent.

package/plugins/lisa/agents/github-prd-intake.md

@@ -0,0 +1,64 @@
+---
+name: github-prd-intake
+description: PRD intake agent for GitHub Issues hosted PRDs. Runs one intake cycle against a GitHub repository — claims `prd-ready` issues (relabels to `prd-in-review`), validates each through the dry-run pipeline, and routes to `prd-blocked` (with clarifying comments on the PRD issue) or `prd-ticketed` (with destination tickets created in JIRA or GitHub Issues per .lisa.config.json). GitHub counterpart of `notion-prd-intake`, `confluence-prd-intake`, and `linear-prd-intake`. Designed to be invoked manually via /github-prd-intake or autonomously via a scheduled cron.
+skills:
+  - github-prd-intake
+  - github-to-tracker
+  - tracker-validate
+  - jira-source-artifacts
+  - product-walkthrough
+  - tracker-write
+  - prd-ticket-coverage
+---
+
+# PRD Intake Agent (GitHub)
+
+You are a PRD intake agent. Your single job is to run one intake cycle against the GitHub repository given to you, then report what happened.
+
+This agent is the GitHub counterpart of `notion-prd-intake`, `confluence-prd-intake`, and `linear-prd-intake`. The behavior is identical apart from the source-of-truth tool surface (the `gh` CLI instead of an MCP). If you have a Notion database, use the Notion agent; if you have a Confluence space, use the Confluence agent; if you have a Linear workspace, use the Linear agent.
+
+## Confirmation policy
+
+Once you have a repo, RUN. Do not ask the caller whether to proceed, do not preview projected scope, do not offer "proceed / skip / dry-run" choices. The caller has already authorized the run by invoking you; re-prompting defeats the purpose of a background batch. `prd-blocked` is a valid terminal state of the lifecycle, not a failure mode — large PRDs and PRDs full of open questions are exactly what this skill is for. The `github-prd-intake` skill defines the only legitimate early-exit conditions (missing repo, unreachable repo, label convention not yet adopted, empty Ready set); ask only when one of those applies.
+
+## Workflow
+
+### 1. Receive the repo
+
+The invoking caller (a slash command, a scheduled cron, or a parent agent) hands you a GitHub `org/repo` token, a full GitHub repo URL, or the literal token `github` (which falls back to `.lisa.config.json`). You do not pick the repo yourself.
+
+If no repo is provided, stop and ask. Never run intake against a default or guessed repo — the side effects (label changes, comments posted, destination tickets created) are too high to act without an explicit target.
+
+### 2. Run the intake skill
+
+Invoke the `github-prd-intake` skill with the repo as `$ARGUMENTS`. The skill owns the cycle logic — claim, dry-run, branch, write or comment, label transitions, summary. Do not duplicate that logic here.
+
+Treat the skill's output as the source of truth. If it reports `prd-ticketed: 3 / prd-blocked: 1 / Errors: 0`, that's what you report.
+
+### 3. Surface the summary
+
+Pass the skill's summary block through to the caller verbatim — do not paraphrase or condense. The caller (often a human running `/github-prd-intake` ad-hoc, or a scheduled cron) needs the structured record:
+
+- Total processed
+- Per-PRD outcomes (`prd-ticketed` → which tickets created in which destination tracker; `prd-blocked` → how many gate failures; Errors → reason)
+- Total ticket count
+
+If the cycle errored before processing any PRDs (e.g. repo unreachable, missing config, label convention not yet adopted), surface the failure cause in plain language and stop.
+
+### 4. Suggest next actions when warranted
+
+After a successful cycle, if any PRDs ended in `prd-blocked`, mention to the caller that those PRDs need product attention before they can be re-ticketed. Do not auto-notify product — comments on the PRD issue are the channel; the caller decides whether to ping anyone.
+
+When reporting `prd-blocked` outcomes, distinguish the cause: **pre-write gate failure** (per-ticket validator caught a problem before any tickets were created) vs **post-write coverage gap** (tickets were created and remain in the destination tracker, but the PRD has uncovered requirements that the next intake cycle will address). Both result in `prd-blocked`, but the implication for product is different — coverage gaps mean some tickets are already real and product should not re-author the PRD from scratch.
+
+If all PRDs ended in `prd-ticketed` with coverage `COMPLETE`, mention that the next step is for product to monitor the created tickets and apply the `prd-shipped` label after delivery. If any are `COMPLETE_WITH_SCOPE_CREEP`, point that out so product can review the flagged tickets.
+
+## Rules
+
+- **Never run a cycle without an explicit repo.** 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 destination tickets directly.** All writes go through the skill chain (intake → github-to-tracker → tracker-write).
+- **Never edit a PRD's body.** Communication with product happens only via comments on the PRD issue.
+- **Never close, archive, or repurpose a PRD issue.** Even after `prd-ticketed`, the issue stays open and labeled `prd-ticketed` until product flips it to `prd-shipped`.
+- **Never start a second cycle while one is in flight against the same repo.** Serial execution; the scheduling layer is responsible for not double-firing.
+- **Stop and surface failures rather than retry-loop.** If `github-to-tracker` returns an error, the skill records it under `Errors` in the summary; pass that through.

package/plugins/lisa/agents/linear-prd-intake.md

@@ -3,11 +3,11 @@ name: linear-prd-intake
 description: PRD intake agent for Linear-hosted PRDs. Runs one intake cycle against a Linear workspace or team — claims `prd-ready` projects (relabels to `prd-in-review`), validates each through the dry-run pipeline, and routes to `prd-blocked` (with clarifying comments on a sentinel feedback issue) or `prd-ticketed` (with JIRA tickets created). Linear counterpart of `notion-prd-intake` and `confluence-prd-intake`. Designed to be invoked manually via /linear-prd-intake or autonomously via a scheduled cron.
 skills:
   - linear-prd-intake
-  - linear-to-jira
-  - jira-validate-ticket
+  - linear-to-tracker
+  - tracker-validate
   - jira-source-artifacts
   - product-walkthrough
-  - jira-write-ticket
+  - tracker-write
   - prd-ticket-coverage
 ---
 
@@ -57,8 +57,8 @@ 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 → linear-to-jira → jira-write-ticket).
+- **Never write destination tickets directly.** All writes go through the skill chain (intake → linear-to-tracker → tracker-write).
 - **Never edit a project's description or any attached Linear document.** Communication with product happens only via comments — on specific sub-issues for anchored failures, on the sentinel feedback issue otherwise.
 - **Never close, archive, or repurpose the sentinel feedback issue.** It is reused across cycles; its longevity is the audit trail.
 - **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 `linear-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 `linear-to-tracker` returns an error, the skill records it under `Errors` in the summary; pass that through.

package/plugins/lisa/agents/notion-prd-intake.md

@@ -3,11 +3,11 @@ name: notion-prd-intake
 description: PRD intake agent. Runs one intake cycle against a Notion PRD database — claims Ready PRDs, validates each through the dry-run pipeline, and routes to Blocked (with clarifying comments) or Ticketed (with JIRA tickets created). Designed to be invoked manually via /notion-prd-intake or autonomously via a scheduled cron.
 skills:
   - notion-prd-intake
-  - notion-to-jira
-  - jira-validate-ticket
+  - notion-to-tracker
+  - tracker-validate
   - jira-source-artifacts
   - product-walkthrough
-  - jira-write-ticket
+  - tracker-write
   - prd-ticket-coverage
 ---
 
@@ -55,7 +55,7 @@ If all PRDs ended in `Ticketed` with coverage `COMPLETE`, mention that the next
 
 - **Never run a cycle without an explicit database URL.** Side effects are too high to default.
 - **Never modify the lifecycle**: only `Ready → In Review → Blocked|Ticketed`. Never touch `Draft` or `Shipped`. Never invent new status values.
-- **Never write JIRA tickets directly.** All writes go through the skill chain (intake → notion-to-jira → jira-write-ticket). Bypassing this skips quality gates.
+- **Never write destination tickets directly.** All writes go through the skill chain (intake → notion-to-tracker → tracker-write). Bypassing this skips quality gates.
 - **Never edit a PRD's body.** Communication with product happens only via Notion comments on the PRD.
 - **Never start a second cycle while one is in flight against the same database.** This agent assumes serial execution; the scheduling layer is responsible for not double-firing.
-- **Stop and surface failures rather than retry-loop.** If `notion-to-jira` returns an error, the skill records it under `Errors` in the summary; pass that through. Do not auto-retry.
+- **Stop and surface failures rather than retry-loop.** If `notion-to-tracker` returns an error, the skill records it under `Errors` in the summary; pass that through. Do not auto-retry.

package/plugins/lisa/commands/intake.md

@@ -1,6 +1,6 @@
 ---
-description: "Vendor-agnostic batch scanner for Ready queues. Notion PRD database URL → finds Status=Ready PRDs and runs lisa:plan per item. Confluence space or parent-page URL → finds prd-ready PRDs and runs lisa:plan per item. Linear workspace or team URL → finds prd-ready Linear projects and runs lisa:plan per item. JIRA project key or JQL → finds Ready tickets and runs lisa:implement per item. Designed as the cron target for /schedule."
-argument-hint: "<Notion-PRD-database-URL | Confluence-space-URL | Confluence-parent-page-URL | Linear-workspace-URL | Linear-team-URL | JIRA-project-key | JQL-filter>"
+description: "Vendor-agnostic batch scanner for Ready queues. Notion PRD database URL → finds Status=Ready PRDs and runs lisa:plan per item. Confluence space or parent-page URL → finds prd-ready PRDs and runs lisa:plan per item. Linear workspace or team URL → finds prd-ready Linear projects and runs lisa:plan per item. GitHub repo URL or org/repo token → finds prd-ready GitHub issues and runs lisa:plan per item (PRD-source mode), or finds status:ready issues and runs lisa:implement per item when tracker=github (build-queue mode). JIRA project key or JQL → finds Ready tickets and runs lisa:implement per item. Designed as the cron target for /schedule."
+argument-hint: "<Notion-PRD-database-URL | Confluence-space-URL | Confluence-parent-page-URL | Linear-workspace-URL | Linear-team-URL | GitHub-repo-URL | org/repo | JIRA-project-key | JQL-filter>"
 ---
 
 Use the /lisa:intake skill to scan the queue for Ready items and dispatch each one through the appropriate single-item lifecycle skill. $ARGUMENTS

package/plugins/lisa/commands/plan.md

@@ -1,6 +1,6 @@
 ---
-description: "Plan work from a single PRD or specification. Decomposes into ordered work items in the configured tracker. For batch scanning of all Status=Ready PRDs in a queue, use /lisa:intake instead."
-argument-hint: "<single-PRD-url | @file | ticket-id-or-url | description>"
+description: "Plan work from a single PRD or specification. Decomposes into ordered work items in the configured tracker (JIRA or GitHub Issues per .lisa.config.json). Source can be a Notion / Confluence / Linear / GitHub Issue URL, a JIRA epic key, a markdown file, or a free-form description. For batch scanning of all Ready PRDs in a queue, use /lisa:intake instead."
+argument-hint: "<single-PRD-url | GitHub-issue-url | @file | ticket-id-or-url | description>"
 ---
 
 Use the /lisa:plan skill to decompose the PRD/spec into ordered work items in the configured tracker. $ARGUMENTS

package/plugins/lisa/rules/intent-routing.md

@@ -233,16 +233,16 @@ Sequence:
 1. `ops-specialist` -- health checks, log inspection, error monitoring, performance analysis
 2. Report findings, escalate if action needed
 
-## JIRA Entry Point
+## Tracker Entry Point (JIRA or GitHub Issues)
 
-When the request references a JIRA ticket (ticket ID like PROJ-123 or a JIRA URL):
+When the request references a tracker ticket (a JIRA key like `PROJ-123`, a JIRA URL, a GitHub issue URL, or an `org/repo#<n>` token):
 
-1. Hand off to `jira-agent`
-2. `jira-agent` reads the ticket fully (description, comments, attachments, linked issues)
-3. `jira-agent` validates ticket quality via `jira-verify` skill
-4. `jira-agent` runs analytical triage via `ticket-triage` skill
-5. If triage finds unresolved ambiguities (`BLOCKED` verdict), `jira-agent` posts findings and STOPS -- no work begins
-6. `jira-agent` determines intent and delegates to the appropriate flow:
+1. Hand off to the matching vendor agent — `jira-agent` (for JIRA refs) or `github-agent` (for GitHub Issue refs). The configured destination tracker (`.lisa.config.json` `tracker`) is the default when the ref shape is ambiguous.
+2. The agent reads the ticket fully via the matching read skill (`jira-read-ticket` / `github-read-issue`) — description / body, comments, attachments, linked issues, parent (Epic / parent sub-issue), siblings.
+3. The agent validates ticket quality via the matching verify skill (`jira-verify` / `github-verify`).
+4. The agent runs analytical triage via the vendor-neutral `ticket-triage` skill.
+5. If triage finds unresolved ambiguities (`BLOCKED` verdict), the agent posts findings and STOPS -- no work begins.
+6. The agent determines intent and delegates to the appropriate flow:
 
 | Ticket Type | Flow | Work Type |
 |-------------|------|-----------|
@@ -252,11 +252,16 @@ When the request references a JIRA ticket (ticket ID like PROJ-123 or a JIRA URL
 | Bug | Implement | Fix |
 | Spike | Implement | Investigate Only |
 | Improvement | Implement | Improve |
+| Sub-task | Implement | (per parent's intent) |
 
-If the ticket type is ambiguous, read the description to classify. A "Task" that describes broken behavior is a Fix. A "Bug" that requests new functionality is a Build.
+For JIRA, the type comes from the ticket's issue type. For GitHub, the type comes from the `type:<value>` label.
 
-7. `jira-agent` syncs progress at milestones via `jira-sync` skill
-8. `jira-agent` posts evidence at completion via `jira-evidence` skill
+If the ticket type is ambiguous, read the description / body to classify. A "Task" that describes broken behavior is a Fix. A "Bug" that requests new functionality is a Build.
+
+7. The agent syncs progress at milestones via the matching sync skill (`jira-sync` / `github-sync`).
+8. The agent posts evidence at completion via the matching evidence skill (`jira-evidence` / `github-evidence`).
+
+Vendor-neutral callers (e.g., `implement`, `verify`) should invoke the `tracker-*` shims — they dispatch to the right vendor automatically.
 
 ## Flow Chaining
 

package/plugins/lisa/rules/tracker-resolution.md

@@ -0,0 +1,76 @@
+# Tracker Resolution
+
+Lisa supports two destination trackers: **JIRA** (default, original) and **GitHub Issues**. The active tracker is resolved per project from `.lisa.config.json`.
+
+This rule is the single source of truth for how every vendor-neutral skill (the `tracker-*` family, the `*-to-tracker` PRD-source skills, and the lifecycle skills `implement` / `verify` / `monitor`) decides which destination to write to.
+
+## Configuration
+
+Read `.lisa.config.json` (or `.lisa.config.local.json` if present — local overrides global) from the repo root. The schema additions:
+
+```json
+{
+  "tracker": "jira",
+  "github": {
+    "org": "<org-or-user>",
+    "repo": "<repo>"
+  }
+}
+```
+
+| Field | Required | Default | Notes |
+|-------|----------|---------|-------|
+| `tracker` | no | `"jira"` | One of `"jira"` or `"github"`. Missing key resolves to `"jira"` for back-compat. |
+| `github.org` | when `tracker = "github"` | — | GitHub org or user name. |
+| `github.repo` | when `tracker = "github"` | — | GitHub repository name. |
+
+## Resolution algorithm
+
+Every `tracker-*` shim and every vendor-neutral caller follows this:
+
+1. Read `.lisa.config.json` (or `.lisa.config.local.json` if it exists; local takes precedence on per-key basis). Use `jq` from Bash; never hand-parse JSON.
+2. Extract the `tracker` field. If missing or null, default to `"jira"`.
+3. If `tracker = "jira"`, delegate to the matching `jira-*` skill.
+4. If `tracker = "github"`, delegate to the matching `github-*` skill, AND ensure `github.org` and `github.repo` are present — stop and report if either is missing.
+5. Any other value: stop and report `"Unknown tracker '<value>' in .lisa.config.json. Expected 'jira' or 'github'."`
+
+## Skill mapping
+
+The shim → vendor mapping is fixed:
+
+| Shim | jira tracker | github tracker |
+|------|--------------|----------------|
+| `lisa:tracker-write` | `lisa:jira-write-ticket` | `lisa:github-write-issue` |
+| `lisa:tracker-validate` | `lisa:jira-validate-ticket` | `lisa:github-validate-issue` |
+| `lisa:tracker-verify` | `lisa:jira-verify` | `lisa:github-verify` |
+| `lisa:tracker-read` | `lisa:jira-read-ticket` | `lisa:github-read-issue` |
+| `lisa:tracker-evidence` | `lisa:jira-evidence` | `lisa:github-evidence` |
+| `lisa:tracker-sync` | `lisa:jira-sync` | `lisa:github-sync` |
+| `lisa:tracker-add-journey` | `lisa:jira-add-journey` | `lisa:github-add-journey` |
+| `lisa:tracker-journey` | `lisa:jira-journey` | `lisa:github-journey` |
+| `lisa:tracker-create` | `lisa:jira-create` | `lisa:github-create` |
+| `lisa:tracker-build-intake` | `lisa:jira-build-intake` | `lisa:github-build-intake` |
+
+The `jira-source-artifacts` skill is read-only and vendor-neutral — it has no shim and no GitHub counterpart. Both vendors invoke it directly.
+
+## Caller responsibilities
+
+- **PRD-source skills** (`notion-to-tracker`, `confluence-to-tracker`, `linear-to-tracker`, `github-to-tracker`) must invoke `tracker-write` and `tracker-validate` — never `jira-write-ticket` / `github-write-issue` directly. This is what makes a project's tracker switchable via config.
+- **Lifecycle skills** (`implement`, `verify`, `monitor`) must invoke `tracker-read`, `tracker-evidence`, `tracker-sync` for ticket interaction — never the vendor-specific equivalents.
+- **Per-vendor PRD intake skills** (`notion-prd-intake`, `confluence-prd-intake`, `linear-prd-intake`, `github-prd-intake`) compose the PRD-source skills (which in turn invoke the shims) — they do not need to read `tracker` themselves.
+
+## Invariants
+
+- Project tracker selection is **persistent** within a project — always read from config, never infer from the shape of `$ARGUMENTS`. If a developer wants a different destination for one run, they edit `.lisa.config.local.json`.
+- A vendor-neutral skill never embeds vendor-specific terminology in its prompts (no "JIRA ticket key", "epic parent" — use "tracker key", "parent issue"). The vendor skill is responsible for translating its inputs.
+- The shim layer is intentionally thin — its only job is dispatch. Gate logic, validation rules, and field schemas all live in the vendor skills.
+
+## Self-host edge case (GitHub PRDs → GitHub destination)
+
+When `github-to-tracker` is invoked AND `tracker = "github"`, both reads and writes hit the same GitHub repo. Label namespaces are kept separate so the two flows don't collide:
+
+- PRD-source labels: `prd-draft`, `prd-ready`, `prd-in-review`, `prd-blocked`, `prd-ticketed`, `prd-shipped` — owned by `github-prd-intake` and the human PM.
+- Build-queue labels: `status:ready`, `status:in-progress`, `status:code-review`, `status:on-dev`, `status:done` — owned by `github-build-intake` and `github-agent`.
+- Sentinel issue label: `prd-intake-feedback` — owned by `github-prd-intake`.
+
+Never overload one label across both lifecycles.

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

@@ -1,6 +1,6 @@
 ---
 name: confluence-prd-intake
-description: "Scans a Confluence space (or a parent page) for PRD pages labelled `prd-ready` and runs each one through the dry-run validation pipeline. PRDs that pass every gate get tickets written and the label flipped to `prd-ticketed`; PRDs that fail get clarifying-question comments and the label flipped to `prd-blocked`. Confluence counterpart of `lisa:notion-prd-intake` — the workflow is identical; only the source-of-truth tools differ. Composes existing skills (confluence-to-jira, jira-validate-ticket, jira-source-artifacts, product-walkthrough)."
+description: "Scans a Confluence space (or a parent page) for PRD pages labelled `prd-ready` and runs each one through the dry-run validation pipeline. PRDs that pass every gate get tickets written and the label flipped to `prd-ticketed`; PRDs that fail get clarifying-question comments and the label flipped to `prd-blocked`. Confluence counterpart of `lisa:notion-prd-intake` — the workflow is identical; only the source-of-truth tools differ. Composes existing skills (confluence-to-tracker, tracker-validate, jira-source-artifacts, product-walkthrough)."
 allowed-tools: ["Skill", "Bash", "mcp__atlassian__getConfluencePage", "mcp__atlassian__getConfluenceSpaces", "mcp__atlassian__getPagesInConfluenceSpace", "mcp__atlassian__getConfluencePageDescendants", "mcp__atlassian__searchConfluenceUsingCql", "mcp__atlassian__updateConfluencePage", "mcp__atlassian__createConfluenceFooterComment", "mcp__atlassian__createConfluenceInlineComment", "mcp__atlassian__getConfluencePageFooterComments", "mcp__atlassian__getConfluencePageInlineComments", "mcp__atlassian__getAccessibleAtlassianResources"]
 ---
 
@@ -99,19 +99,19 @@ The `updateConfluencePage` call must preserve the page body; only the labels cha
 
 #### 3b. Dry-run validation
 
-Invoke the `lisa:confluence-to-jira` skill with `dry_run: true` and the PRD's URL. The skill returns a structured report containing:
+Invoke the `lisa:confluence-to-tracker` skill with `dry_run: true` and the PRD's URL. The skill returns a structured report containing:
 - The planned ticket hierarchy
 - Per-ticket validation verdicts and remediation
 - 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:jira-validate-ticket`, which `lisa:confluence-to-jira` calls per ticket.
+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:confluence-to-tracker` calls per ticket.
 
 #### 3c. Branch on the verdict
 
 **If `PASS`** (every planned ticket passed every applicable gate):
 
-1. Re-invoke `lisa:confluence-to-jira` with `dry_run: false` to actually write the tickets. This re-runs Phases 1-5 and runs the preservation gate (Phase 5.5).
+1. Re-invoke `lisa:confluence-to-tracker` with `dry_run: false` to actually write the tickets. This re-runs Phases 1-5 and runs the preservation gate (Phase 5.5).
 2. Capture the created ticket keys from the skill's output.
 3. Post a Confluence **footer comment** on the PRD via `mcp__atlassian__createConfluenceFooterComment` listing the created tickets (epic, stories, sub-tasks) with their JIRA URLs. Lead with: `"Ticketed by Claude. Created N JIRA issues — see below. Add the prd-shipped label after the work is delivered."`
 4. Transition labels: remove `prd-in-review`, add `prd-ticketed` via `updateConfluencePage`.
@@ -124,7 +124,7 @@ The audience for these comments is the **product team**, not engineers. They are
 ##### 3c.1 Partition failures
 
 1. Drop every failure where `product_relevant = false`. Those are internal data-quality problems — the agent should fix its own spec rather than ask product to clarify a missing core field. Record the dropped failures under `Errors` in the cycle summary so engineers can see them; never surface them on the PRD.
-2. Group the remaining product-relevant failures by `prd_anchor` (the inline-comment anchor from `confluence-to-jira`'s dry-run report). Failures that share an anchor become one comment thread on that block. Failures with `prd_anchor: null` are batched into one footer comment, since they have no source section to attach to.
+2. Group the remaining product-relevant failures by `prd_anchor` (the inline-comment anchor from `confluence-to-tracker`'s dry-run report). Failures that share an anchor become one comment thread on that block. Failures with `prd_anchor: null` are batched into one footer comment, since they have no source section to attach to.
 
 ##### 3c.2 Render each comment
 
@@ -173,7 +173,7 @@ Use these exact badge labels — they are the validator's category values transl
 
 - Gate IDs (`S4`, `F2`, etc.). Never appear in a comment body.
 - JIRA terminology that has no product meaning (e.g. "Gherkin", "epic parent", "issue link", "validation journey", "sub-task hierarchy"). Paraphrase before posting.
-- Internal skill names (`lisa:jira-validate-ticket`, `confluence-to-jira`).
+- Internal skill names (`lisa:tracker-validate`, `confluence-to-tracker`).
 - Engineering shorthand (`AC`, `OOS`, `repo`, `env var`).
 - "Clarify this" / "Please specify" without candidate resolutions. The validator is required to provide candidates; if `recommendation` is empty or vague, treat the failure as an Error and surface internally rather than posting a useless comment.
 
@@ -199,7 +199,7 @@ Per-ticket gates prove each ticket is well-formed; they do NOT prove the *set* o
    | `GAPS_FOUND` | The created ticket set is incomplete. (a) For each gap, post a comment using the same product-facing template as Phase 3c.3 — inline-anchored when `prd_anchor` is non-null, footer otherwise; category badge from the gap's `category` field; `What's unclear` and `Recommendation` from the audit report's `what` and `recommendation` fields. Apply the same forbidden-language rules from Phase 3c.5. (b) Post one footer summary comment listing the tickets that *were* successfully created (so product knows what to keep vs. what to extend). (c) Transition labels from `prd-ticketed` back to `prd-blocked` via `updateConfluencePage`. |
    | `NO_TICKETS_FOUND` | Should not happen if step 2 succeeded. If it does, log it as an Error in the cycle summary and leave label as `prd-ticketed` with a comment flagging the audit failure for human review. |
 
-3. The created tickets remain in JIRA regardless of the verdict — they are valid in their own right. The audit only tells us whether *more* are needed.
+3. The created tickets remain in the destination tracker regardless of the verdict — they are valid in their own right. The audit only tells us whether *more* are needed.
 
 ### Phase 4 — Summary report
 
@@ -229,24 +229,24 @@ Print to the agent's output. Do not write this summary to Confluence or JIRA —
 ## Idempotency & safety
 
 - **Single-cycle scope**: this skill processes the `prd-ready` set as it exists at the start of Phase 2. New `prd-ready` PRDs added mid-cycle are picked up next run.
-- **No writes outside the lifecycle**: this skill only ever writes to JIRA via `lisa:confluence-to-jira` (which delegates to `lisa:jira-write-ticket`), and only ever changes Confluence labels among `prd-in-review`, `prd-blocked`, `prd-ticketed`. It never edits PRD body content, never touches `prd-draft` or `prd-shipped`, never deletes pages.
+- **No writes outside the lifecycle**: this skill only ever writes to the destination tracker via `lisa:confluence-to-tracker` (which delegates to `lisa:tracker-write`), and only ever changes Confluence labels among `prd-in-review`, `prd-blocked`, `prd-ticketed`. It never edits PRD body content, never touches `prd-draft` or `prd-shipped`, never deletes pages.
 - **Claim-first ordering**: the label flip to `prd-in-review` happens BEFORE validation runs, so a re-entrant call won't double-process.
 - **Failure isolation**: an exception processing one PRD must not stop the cycle. Catch, record under "Errors" in the summary, continue to the next PRD. The PRD that errored is left labelled `prd-in-review` — the human investigates from there.
 - **Single-label invariant**: after every transition, verify exactly one lifecycle label is present on the page. If two are present (rare race), surface as an Error and skip — do NOT auto-resolve, the human decides.
 
 ## Configuration
 
-Same env vars as `lisa:confluence-to-jira` — `JIRA_PROJECT`, `JIRA_SERVER`, `CONFLUENCE_HOST`, `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 env vars as `lisa:confluence-to-tracker` — `JIRA_PROJECT`, `JIRA_SERVER`, `CONFLUENCE_HOST`, `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.
 
 ## Rules
 
-- Never write to JIRA outside of `lisa:confluence-to-jira` → `lisa:jira-write-ticket`. The validator's verdict gates progress; bypassing it produces broken tickets.
+- Never write to the destination tracker outside of `lisa:confluence-to-tracker` → `lisa:tracker-write`. The validator's verdict gates progress; bypassing it produces broken tickets.
 - Never add or remove a label this skill doesn't own (`prd-in-review`, `prd-blocked`, `prd-ticketed`). Product owns `prd-draft`, `prd-ready`, `prd-shipped`.
 - Never edit the PRD's body. Communication with product happens only through Confluence comments. If `updateConfluencePage` requires a body in the payload, refetch and pass it back unchanged.
 - Never post a single page-level dump of all gate failures. One inline comment per `prd_anchor` group (or one footer summary for unanchored failures only). Comments must be inline-anchored where possible, categorized, plain-language, and contain a concrete recommendation.
 - Never include a gate ID, internal skill name, or engineering shorthand in a comment body.
 - Never run more than one intake cycle concurrently against the same scope. This skill assumes serial execution.
-- If `lisa:confluence-to-jira` returns errors, treat them as gate failures: comment + `prd-blocked`. Don't silently fail.
+- If `lisa:confluence-to-tracker` returns errors, treat them as gate failures: comment + `prd-blocked`. Don't silently fail.
 
 ## Adoption (one-time per project)