@codyswann/lisa 2.6.4 → 2.8.0

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/agents/verification-specialist.md

@@ -3,6 +3,7 @@ name: verification-specialist
 description: Verification specialist agent. Discovers project tooling and executes verification for all required types. Plans and executes empirical proof that work is done by running the actual system and observing results.
 skills:
   - verification-lifecycle
+  - codify-verification
   - jira-journey
   - spec-conformance
 ---
@@ -19,7 +20,7 @@ Read `.claude/rules/verification.md` at the start of every investigation for the
 
 ## Verification Process
 
-Follow the verification lifecycle: **confirm quality gates, classify, check tooling, fail fast, plan, execute, loop.**
+Follow the verification lifecycle: **confirm quality gates, classify, check tooling, fail fast, plan, execute, codify, spec conformance, loop.**
 
 ### 1. Confirm Quality Gates
 
@@ -76,6 +77,10 @@ Run the verification and capture output. Always include:
 
 If any verification fails, fix and re-verify. Do not declare done until all required types pass.
 
+### 6. Codify
+
+For every empirical verification that produced PASS evidence, invoke the `codify-verification` skill to encode it as a regression test in the appropriate framework (Playwright for UI, integration test for API/DB/auth, benchmark for performance, etc.). The new test must run, pass, and be committed in the same PR. Skipping codification is allowed only for non-behavioral types (PR, Documentation, Deploy) and Investigate-Only spikes — for everything else, codify or escalate.
+
 ## Output Format
 
 ```
@@ -117,7 +122,8 @@ If any verification fails, fix and re-verify. Do not declare done until all requ
 ## Rules
 
 - Always read `.claude/rules/verification.md` first for the project's verification standards and type taxonomy
-- Follow the verification lifecycle: confirm quality gates, classify, check tooling, fail fast, plan, execute, loop
+- Follow the verification lifecycle: confirm quality gates, classify, check tooling, fail fast, plan, execute, codify, spec conformance, loop
+- Every passing empirical verification must be codified as a regression test via `codify-verification` before declaring done (skip allowed only for PR / Documentation / Deploy / Investigate-Only)
 - Tests, typecheck, lint, and format are quality gates (prerequisites), NOT verification — never report them as verification evidence
 - Discover existing project scripts and tools before creating new ones
 - Every verification must produce observable output -- a status code, a response body, a UI state, a test result

package/plugins/src/base/commands/codify-verification.md

@@ -0,0 +1,6 @@
+---
+description: "Convert empirical verification into a regression test (Playwright for UI, integration test for API/DB, benchmark for performance, etc.) so it doesn't regress. Mandatory step after verification passes — invoked from verification-lifecycle and from each Build/Fix/Improve flow."
+argument-hint: "<verification-type> <what-was-verified>"
+---
+
+Use the /lisa:codify-verification skill to encode the empirical verification that just passed as a regression test, in the appropriate framework for the verification type. $ARGUMENTS

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/hooks/block-no-verify.sh

@@ -0,0 +1,37 @@
+#!/usr/bin/env bash
+# PreToolUse hook for Bash: blocks any command containing --no-verify.
+# --no-verify on git commit/push (and equivalents) bypasses pre-commit/pre-push
+# hooks that exist for a reason. The fix is to address the underlying issue,
+# not silence the check. See feedback_never_no_verify in user memory.
+#
+# Word-boundary match avoids false positives on flags like --no-verify-ssl,
+# --no-verify-host, etc.
+set -euo pipefail
+
+input="$(cat)"
+
+tool_name="$(printf '%s' "$input" | jq -r '.tool_name // empty')"
+if [ "$tool_name" != "Bash" ]; then
+  exit 0
+fi
+
+command_str="$(printf '%s' "$input" | jq -r '.tool_input.command // empty')"
+if [ -z "$command_str" ]; then
+  exit 0
+fi
+
+# Match --no-verify bounded by non-token characters (not alphanumeric, _, or -).
+# This catches all syntactic positions including subshells (e.g. `(git commit --no-verify)`)
+# while excluding longer flags like --no-verify-ssl, --no-verify-host, etc.
+if printf '%s' "$command_str" | grep -Eq '(^|[^[:alnum:]_-])--no-verify($|[^[:alnum:]_-])'; then
+  cat >&2 <<'EOF'
+Blocked: --no-verify bypasses pre-commit/pre-push hooks. Fix the underlying
+issue (lint error, failing test, formatting) or ask the user before bypassing.
+
+If the user has explicitly authorized the bypass for this specific command,
+re-run after they confirm.
+EOF
+  exit 2
+fi
+
+exit 0

package/plugins/src/base/rules/intent-routing.md

@@ -119,7 +119,7 @@ Determine the work type and execute the matching variant:
 5. `builder` -- implement via TDD (acceptance criteria become tests)
 6. Run quality gates: lint, typecheck, tests (these are prerequisites, NOT verification)
 7. `verification-specialist` -- verify locally (run the software, observe behavior)
-8. Write e2e test encoding the verification
+8. `verification-specialist` -- invoke `codify-verification` skill per passing verification (Playwright for UI, integration test for API/DB/auth, etc.); commit each test in the same PR
 9. **Review sub-flow**
 10. `learner` -- capture discoveries
 
@@ -133,7 +133,7 @@ Determine the work type and execute the matching variant:
 6. `bug-fixer` -- implement fix via TDD (reproduction becomes failing test)
 7. Run quality gates: lint, typecheck, tests (these are prerequisites, NOT verification)
 8. `verification-specialist` -- verify locally (prove the bug is fixed)
-9. Write e2e test encoding the verification
+9. `verification-specialist` -- invoke `codify-verification` skill to encode the fix as a regression test (mandatory for bug fixes — the test must fail against the pre-fix commit and pass against the fix); commit in the same PR
 10. **Review sub-flow**
 11. `learner` -- capture discoveries
 
@@ -145,7 +145,7 @@ Determine the work type and execute the matching variant:
 4. `builder` -- implement improvements via TDD
 5. Run quality gates: lint, typecheck, tests (these are prerequisites, NOT verification)
 6. `verification-specialist` -- measure again, prove improvement over baseline
-7. Write e2e test encoding the verification (if applicable)
+7. `verification-specialist` -- invoke `codify-verification` skill (typically a benchmark asserting against baseline for performance work, or a regression test for behavioral refactors); commit in the same PR
 8. **Review sub-flow**
 9. `learner` -- capture discoveries
 
@@ -156,7 +156,7 @@ Determine the work type and execute the matching variant:
 3. Recommend next action (Research, Plan, Implement, or escalate)
 4. `learner` -- capture discoveries
 
-Output: Code passing all quality gates + local empirical verification + e2e test (except for spikes, which produce findings only).
+Output: Code passing all quality gates + local empirical verification + codified regression test for each verification (except for spikes, which produce findings only, and non-behavioral verification types — PR / Documentation / Deploy — which carry their own proof).
 
 ### Verify
 
@@ -165,6 +165,7 @@ When: Code is ready to ship. All quality gates pass and local empirical verifica
 Gate:
 - Code must pass quality gates (lint, typecheck, tests)
 - Local empirical verification must be complete
+- Each passing local verification must be codified as a regression test (or carry a documented skip from the allowed set: PR / Documentation / Deploy / Investigate-Only). If verifications are not codified, return to the Implement flow's codify step before shipping
 - If quality gates fail, go back to **Implement**
 - If no code changes exist, there is nothing to verify
 
@@ -232,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 |
 |-------------|------|-----------|
@@ -251,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/src/base/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/src/base/rules/verification.md

@@ -24,7 +24,7 @@ Verification is mandatory. Never skip it, defer it, or claim it was unnecessary.
 
 Before starting implementation, state your verification plan — how you will use the resulting software to prove it works. A verification plan that only lists test/typecheck/lint commands is not a verification plan. Do not begin implementation until the plan is confirmed.
 
-After verifying a change empirically, encode that verification as automated tests. The manual proof that something works should become a repeatable regression test that catches future regressions. Every verification should answer: "How do I turn this into a test?"
+After verifying a change empirically, encode that verification as an automated regression test via the `codify-verification` skill. The manual proof that something works must become a repeatable test that catches future regressions — Playwright for UI/browser flows, integration test for API/DB/auth, benchmark for performance, etc. Codification is mandatory for every empirical verification type except the inherently non-behavioral ones (PR, Documentation, Deploy) and Investigate-Only spikes. If codification is genuinely impossible, escalate via the Escalation Protocol — never silently skip.
 
 Every pull request must include step-by-step instructions for reviewers to independently replicate the verification. These are not test commands — they are the exact steps a human would follow to use the software and confirm the change works. If a reviewer cannot reproduce your verification from the PR description alone, the PR is incomplete.
 
@@ -101,7 +101,7 @@ Every change requires one or more verification types. Classify the change first,
 Verification happens at two stages in the workflow:
 
 - **Quality gates** (enforced automatically): Tests, typecheck, lint, and format run via hooks at write-time, commit-time, and push-time. These are prerequisites, not verification.
-- **Local verification** (part of the Implement flow): After quality gates pass, empirically verify the change by running the actual system in a local or preview environment — make HTTP requests, interact with the UI, execute CLI commands, query the database. This proves the change works before shipping. After local verification succeeds, encode it as an e2e test.
+- **Local verification** (part of the Implement flow): After quality gates pass, empirically verify the change by running the actual system in a local or preview environment — make HTTP requests, interact with the UI, execute CLI commands, query the database. This proves the change works before shipping. After local verification succeeds, invoke `codify-verification` to encode it as a regression test (Playwright for UI, integration test for API/DB/auth, benchmark for performance, etc.) and commit the test in the same PR.
 - **Remote verification** (part of the Verify flow): After the PR is merged and deployed, repeat the same empirical verification against the target environment. This proves the change works in production, not just locally. If remote verification fails, fix and re-deploy.
 
 Both levels use the same verification types table above. The difference is the environment, not the rigor.