@codyswann/lisa 2.7.0 → 2.8.0

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.0",
   "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.0",
   "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.0",
   "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.0",
   "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.0",
   "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.

package/plugins/src/base/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/src/base/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/src/base/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/src/base/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/src/base/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/src/base/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/src/base/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