@codyswann/lisa 2.6.4 → 2.8.0

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/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.

package/plugins/lisa/skills/codify-verification/SKILL.md

@@ -0,0 +1,152 @@
+---
+name: codify-verification
+description: "Convert empirical verification into a regression test so it never has to be re-proven manually. Runs after a verification passes — picks the appropriate test framework for the verification type (Playwright for UI/browser, integration test for API/DB/auth, benchmark for performance, etc.), generates the test, wires it into the project's test runner, and confirms it executes. Mandatory step in the verification lifecycle and in the Build/Fix/Improve flows."
+allowed-tools: ["Bash", "Read", "Edit", "Write", "Glob", "Grep", "Skill"]
+---
+
+# Codify Verification: $ARGUMENTS
+
+Take the empirical verification that just passed and encode it as an automated regression test. The manual proof becomes a repeatable check that catches future regressions.
+
+This skill is invoked from the verification lifecycle (between Execute and Spec Conformance) and from each work-type sub-flow (Build / Fix / Improve) after the local verification step.
+
+## When to invoke
+
+Invoke once per empirical verification that produced PASS evidence. If a single change had three verifications (UI flow, API endpoint, DB query), this skill runs three times — or once with the three verifications batched, but each must produce its own committed test.
+
+## When to skip
+
+Skip codification only for verification types whose proof is inherently non-behavioral:
+
+- **PR** — proof is the PR description itself
+- **Documentation** — proof is content review
+- **Deploy** — proof is deployment output and health endpoints (already covered by ops-verify-health)
+- **Investigate-Only spikes** — produce findings, not shipped code
+
+For every other verification type, codification is mandatory. If the codification is not possible (e.g., the test framework doesn't exist and can't be installed in scope), escalate via the lifecycle's Escalation Protocol — do not silently skip.
+
+## Inputs
+
+The caller must provide:
+
+- The verification type (UI, API, Database, Auth, Security, Performance, Background Jobs, Cache, Configuration, Email/Notification, Observability, Infrastructure)
+- The exact steps that were performed (URL visited, request made, query run, etc.)
+- The expected outcome (status code, UI state, row count, log entry, etc.)
+- The proof artifact captured (screenshot path, response body, query output, log excerpt)
+
+If any of these are missing, ask the caller before generating a test — a test built on guesswork will not match the verification it claims to encode.
+
+## Process
+
+### 1. Discover existing test infrastructure
+
+Before creating anything new, find what the project already has. Use the Tool Discovery Process from `verification-lifecycle`. Specifically check for:
+
+- **Browser/E2E**: `playwright.config.*`, `cypress.config.*`, `e2e/` directory, `tests/e2e/`, Playwright/Cypress in `package.json` devDependencies
+- **API/integration**: `tests/integration/`, `spec/`, `test/integration/`, supertest/fetch helpers, Vitest/Jest integration configs
+- **Database**: integration test setup with migrations, factory files, seed scripts
+- **Performance**: existing benchmark suite (`benchmarks/`, `bench/`), `vitest bench`, k6 scripts
+- **Mobile (RN/Expo)**: Detox config, Maestro flows
+- **Backend jobs**: existing job-test harness, queue integration tests
+
+Do NOT install a new framework if one already exists for the verification type. Use what's there.
+
+### 2. Map verification type → framework
+
+| Verification type | Preferred framework (use whichever the project already has) |
+|---|---|
+| UI (web) | Playwright > Cypress > Selenium |
+| UI (mobile) | Maestro > Detox > Playwright (mobile emulation) |
+| API | project's integration test runner (Vitest / Jest / RSpec / pytest) with HTTP client (supertest / fetch / faraday) |
+| Database | integration test with real DB + migrations applied |
+| Auth | API or UI test asserting role-gated access (multi-role coverage) |
+| Security | regression test that reproduces the attack and asserts safe handling |
+| Performance | benchmark in the project's bench harness, asserting against the baseline captured in the verification |
+| Background Jobs | integration test that enqueues, drains the queue, and asserts terminal state |
+| Cache | integration test asserting hit/miss/invalidation behavior |
+| Configuration | integration test that loads config and asserts effect |
+| Email/Notification | test capturing outbound message via project's mailer test mode |
+| Observability | test asserting structured log/metric/trace emission |
+| Infrastructure | test or script asserting infra state (terraform plan diff, CDK snapshot test) |
+
+If the project lacks the preferred framework AND no acceptable substitute exists, escalate.
+
+### 3. Generate the test
+
+The generated test must:
+
+- **Encode the exact verification that passed**, not a paraphrase. Same URL, same input, same assertion target.
+- **Assert the observable outcome**, not implementation details. If the verification confirmed "user sees order confirmation", the test asserts that text/element is visible — not that a particular function was called.
+- **Be deterministic.** No reliance on timing, network flakiness, real third-party services, or mutable shared state. Use the project's existing fixtures, factories, mocks, and seed data conventions.
+- **Be self-contained.** Set up its own preconditions and clean up after itself, following the project's existing test isolation patterns.
+- **Be named after the behavior, not the bug/ticket.** `displays order confirmation after checkout` not `fixes PROJ-1234`.
+- **Live in the project's existing test directory** for that type. Do not create a parallel test tree.
+
+For Playwright UI tests specifically:
+- Use the project's existing `test` fixture / `page` fixture / auth helper if one exists
+- Prefer role/text selectors (`getByRole`, `getByText`) over CSS/XPath — they survive markup churn
+- Capture a trace or screenshot only if the project's existing tests do; do not invent a new artifact convention
+- Mirror the project's existing config for base URL, retries, and test isolation
+
+### 4. Run the test in isolation
+
+Run only the new test, using whatever per-test invocation the project supports:
+
+- Playwright: `npx playwright test path/to/new.spec.ts`
+- Vitest: `npx vitest run path/to/new.spec.ts`
+- Jest: `npx jest path/to/new.test.ts`
+- RSpec: `bundle exec rspec path/to/new_spec.rb`
+
+Confirm:
+1. The test PASSES against the current code (the change being shipped)
+2. The test would have FAILED before the change (sanity check by mentally reverting, or for bug fixes, by running against the pre-fix commit if cheap)
+
+For a bug fix, step 2 is mandatory and easy: check out the failing commit, run the new test, see it fail, return to the fix branch. This proves the test actually guards the regression.
+
+### 5. Wire it into the suite
+
+Confirm the test is picked up by the project's standard test command (the one CI runs). Run that command and confirm the count went up by exactly the number of tests added.
+
+If the test is in a directory the standard test command excludes (e.g., E2E suite that runs separately in CI), confirm the appropriate CI workflow includes it.
+
+### 6. Commit
+
+Commit the test in the same PR as the change it codifies, in its own atomic commit:
+
+- Build/feature: `test: add e2e for <behavior>`
+- Bug fix: `test: add regression test for <bug behavior>`
+- Performance: `test: add benchmark asserting <metric> <baseline>`
+
+The commit message body should reference the verification it encodes (one line linking to the proof artifact or the verification report section).
+
+### 7. Record evidence
+
+Append to the verification report (or PR description):
+
+```markdown
+### Codified Verifications
+
+| # | Verification | Framework | Test file | Status |
+|---|--------------|-----------|-----------|--------|
+| 1 | <description> | Playwright | `e2e/checkout.spec.ts::displays order confirmation after checkout` | PASS |
+```
+
+This evidence shows the verification is now guarded.
+
+## Output
+
+For each empirical verification passed in:
+
+- A new test file (or extension to an existing test file) committed to the PR
+- Confirmation that the test passes against the current branch
+- The test file path + test name recorded in the verification report
+
+If codification was skipped, an explicit reason recorded in the report (one of the skip conditions above) — never silent.
+
+## Rules
+
+- Never claim a verification is codified without running the new test and observing it pass
+- Never disable, skip, or `.skip()` the new test "temporarily" to make CI green — fix the test or fix the underlying change
+- Never use `expect(true).toBe(true)` placeholders or smoke-only assertions that don't actually exercise the verified behavior
+- Never reuse the verification's manual artifact (screenshot, curl output) as a "test" — those are evidence, not regression coverage
+- If the project lacks the appropriate framework, escalate via Human Action Packet rather than installing one mid-task without approval

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)
 

package/plugins/lisa/skills/{confluence-to-jira → confluence-to-tracker}/SKILL.md

@@ -1,21 +1,21 @@
 ---
-name: confluence-to-jira
+name: confluence-to-tracker
 description: >
-  Break down a Confluence PRD page into JIRA epics, stories, and sub-tasks. Use this skill whenever the
-  user shares a Confluence PRD URL and wants it converted into JIRA tickets, or asks to "break down
-  this Confluence spec", "create tickets from a Confluence page", "turn this Confluence doc into JIRA",
-  or similar. This skill mirrors `lisa:notion-to-jira` for projects whose PRDs live in Confluence —
+  Break down a Confluence PRD page into Epics, Stories, and Sub-tasks in the configured destination tracker (JIRA or GitHub Issues per .lisa.config.json). Use this skill whenever the
+  user shares a Confluence PRD URL and wants it converted into tracker tickets, or asks to "break down
+  this Confluence spec", "create tickets from a Confluence page", "turn this Confluence doc into tickets",
+  or similar. This skill mirrors `lisa:notion-to-tracker` for projects whose PRDs live in Confluence —
   the workflow, gates, dry-run mode, and validation rules are identical; only the source-of-truth tool
   surface differs (Confluence MCP instead of Notion MCP).
-allowed-tools: ["Skill", "Bash", "mcp__atlassian__getConfluencePage", "mcp__atlassian__getConfluencePageDescendants", "mcp__atlassian__getConfluencePageFooterComments", "mcp__atlassian__getConfluencePageInlineComments", "mcp__atlassian__getConfluenceCommentChildren", "mcp__atlassian__searchConfluenceUsingCql", "mcp__atlassian__getAccessibleAtlassianResources", "mcp__atlassian__getJiraIssueRemoteIssueLinks"]
+allowed-tools: ["Skill", "Bash", "mcp__atlassian__getConfluencePage", "mcp__atlassian__getConfluencePageDescendants", "mcp__atlassian__getConfluencePageFooterComments", "mcp__atlassian__getConfluencePageInlineComments", "mcp__atlassian__getConfluenceCommentChildren", "mcp__atlassian__searchConfluenceUsingCql", "mcp__atlassian__getAccessibleAtlassianResources"]
 ---
 
-# Confluence PRD to JIRA Breakdown
+# Confluence PRD to Tracker Breakdown
 
-Convert a Confluence PRD into a structured JIRA ticket hierarchy: Epics > Stories > Sub-tasks.
+Convert a Confluence PRD into a structured ticket hierarchy in the configured destination tracker (JIRA or GitHub Issues per .lisa.config.json): Epics > Stories > Sub-tasks.
 Each sub-task is scoped to exactly one repo and includes an empirical verification plan.
 
-This skill is the Confluence counterpart of `lisa:notion-to-jira`. The two skills share the same
+This skill is the Confluence counterpart of `lisa:notion-to-tracker`. The two skills share the same
 phases, gates, dry-run contract, and per-ticket validation logic. Only the PRD-side fetch / comment
 tools differ. When changing workflow logic, change BOTH skills together so the two source vendors
 stay behaviorally identical.
@@ -24,16 +24,16 @@ stay behaviorally identical.
 
 This skill supports two modes, controlled by a `dry_run` flag in `$ARGUMENTS`:
 
-- **`dry_run: false`** (default — full mode): run all phases, write tickets via `lisa:jira-write-ticket`, run the preservation gate, report.
-- **`dry_run: true`** (planning + validation only — no writes): run Phases 1, 1.5, 1.6, 2, 3, 4 to plan the hierarchy and draft each ticket spec, then call `lisa:jira-validate-ticket` (with `--spec-only`) on every drafted ticket. Aggregate the per-ticket validator reports into a single dry-run report. **Skip Phase 5 (sub-task creation), Phase 5.5 (preservation gate), and Phase 6 (results report)** — none of those make sense without writes. Return the dry-run report so the caller (e.g. `lisa:confluence-prd-intake`) can decide whether to proceed.
+- **`dry_run: false`** (default — full mode): run all phases, write tickets via `lisa:tracker-write`, run the preservation gate, report.
+- **`dry_run: true`** (planning + validation only — no writes): run Phases 1, 1.5, 1.6, 2, 3, 4 to plan the hierarchy and draft each ticket spec, then call `lisa:tracker-validate` (with `--spec-only`) on every drafted ticket. Aggregate the per-ticket validator reports into a single dry-run report. **Skip Phase 5 (sub-task creation), Phase 5.5 (preservation gate), and Phase 6 (results report)** — none of those make sense without writes. Return the dry-run report so the caller (e.g. `lisa:confluence-prd-intake`) can decide whether to proceed.
 
-Dry-run output format is identical to `lisa:notion-to-jira`'s. Reuse the same fields, including
+Dry-run output format is identical to `lisa:notion-to-tracker`'s. Reuse the same fields, including
 `prd_anchor` and `prd_section`. The only difference: `prd_anchor` is the inline-comment anchor text
 that `createConfluenceInlineComment` accepts (typically the full selected substring; truncate if it
 exceeds the tool's max anchor length and emit `null` if no resolvable anchor exists).
 
 ```text
-## confluence-to-jira dry-run: <PRD title>
+## confluence-to-tracker dry-run: <PRD title>
 
 ### Planned hierarchy
 - Epic: <summary>
@@ -67,11 +67,11 @@ The dry-run mode never writes to JIRA and never calls `mcp__atlassian__createJir
 modifies the source Confluence page, never adds/removes labels, and never posts comments — that is the
 orchestrating skill's responsibility (`lisa:confluence-prd-intake`).
 
-## Hard Rule: All Writes Go Through `lisa:jira-write-ticket`
+## Hard Rule: All Writes Go Through `lisa:tracker-write`
 
-**Every JIRA ticket created by this skill — every epic, story, and sub-task — MUST be created by invoking the `lisa:jira-write-ticket` skill. Never call `mcp__atlassian__createJiraIssue`, `mcp__atlassian__editJiraIssue`, `mcp__atlassian__createIssueLink`, or any other Atlassian write tool directly from this skill or from any sub-agent it spawns.**
+**Every JIRA ticket created by this skill — every epic, story, and sub-task — MUST be created by invoking the `lisa:tracker-write` skill. Never call `mcp__atlassian__createJiraIssue`, `mcp__atlassian__editJiraIssue`, `mcp__atlassian__createIssueLink`, or any other Atlassian write tool directly from this skill or from any sub-agent it spawns.**
 
-`lisa:jira-write-ticket` enforces gates this skill does not:
+`lisa:tracker-write` enforces gates this skill does not:
 - 3-audience description (Context / Technical Approach / Acceptance Criteria)
 - Gherkin acceptance criteria
 - Epic parent validation
@@ -80,7 +80,7 @@ orchestrating skill's responsibility (`lisa:confluence-prd-intake`).
 - Sign-in account and target environment recorded in description
 - Post-create verification
 
-Bypassing `lisa:jira-write-ticket` produces thin tickets that the rest of the lifecycle (triage, ticket-verify, journey, evidence) treats as broken. The Atlassian read tools (`getJiraIssue`, `searchJiraIssuesUsingJql`, `getJiraIssueRemoteIssueLinks`, `getAccessibleAtlassianResources`, `getJiraProjectIssueTypesMetadata`, `getVisibleJiraProjects`, and the Confluence read endpoints listed in `allowed-tools` above) ARE allowed for context gathering and the Phase 5.5 preservation gate.
+Bypassing `lisa:tracker-write` produces thin tickets that the rest of the lifecycle (triage, ticket-verify, journey, evidence) treats as broken. The Atlassian read tools (`getJiraIssue`, `searchJiraIssuesUsingJql`, `getJiraIssueRemoteIssueLinks`, `getAccessibleAtlassianResources`, `getJiraProjectIssueTypesMetadata`, `getVisibleJiraProjects`, and the Confluence read endpoints listed in `allowed-tools` above) ARE allowed for context gathering and the Phase 5.5 preservation gate.
 
 ## Input
 
@@ -165,7 +165,7 @@ The existing-component reuse expectation is defined in `lisa:jira-source-artifac
 
 ### Phase 2: Codebase + Live Product Research
 
-Identical to `lisa:notion-to-jira` Phase 2. Two complementary inputs ground PRD analysis: the **code** (what's there to reuse / extend) and the **live product** (what users see today). Skipping either produces tickets that misjudge the change.
+Identical to `lisa:notion-to-tracker` Phase 2. Two complementary inputs ground PRD analysis: the **code** (what's there to reuse / extend) and the **live product** (what users see today). Skipping either produces tickets that misjudge the change.
 
 **2a. Codebase research.** If the session doesn't already have codebase context, explore the repos to understand what exists. Use Explore agents for repos not yet examined.
 
@@ -177,9 +177,9 @@ Walkthrough findings are attached to the originating Confluence PRD as a **foote
 
 ### Phase 3: Create Epics
 
-> **Mode guard**: In `dry_run: true` mode, do not invoke `lisa:jira-write-ticket` in this phase. Instead, draft the epic spec (summary, description_body, artifacts) and validate it with `lisa:jira-validate-ticket --spec-only`. Record the drafted spec (including a placeholder epic key like `DRY-RUN-EPIC-1`) for Phase 4 to use as parent references. In `dry_run: false` mode (default), proceed as described below.
+> **Mode guard**: In `dry_run: true` mode, do not invoke `lisa:tracker-write` in this phase. Instead, draft the epic spec (summary, description_body, artifacts) and validate it with `lisa:tracker-validate --spec-only`. Record the drafted spec (including a placeholder epic key like `DRY-RUN-EPIC-1`) for Phase 4 to use as parent references. In `dry_run: false` mode (default), proceed as described below.
 
-For each PRD epic, **invoke the `lisa:jira-write-ticket` skill** (do not call `createJiraIssue` directly). Pass it everything it needs to enforce its quality gates:
+For each PRD epic, **invoke the `lisa:tracker-write` skill** (do not call `createJiraIssue` directly). Pass it everything it needs to enforce its quality gates:
 
 - `project_key`: from `JIRA_PROJECT` config
 - `issue_type`: `Epic`
@@ -199,7 +199,7 @@ Capture the returned epic key — Phase 4 needs it as the parent for stories.
 
 ### Phase 4: Create Stories
 
-> **Mode guard**: In `dry_run: true` mode, do not invoke `lisa:jira-write-ticket` in this phase. Instead, draft each story spec and validate it with `lisa:jira-validate-ticket --spec-only`. Use placeholder keys (e.g. `DRY-RUN-STORY-1.1`) for any downstream references. In `dry_run: false` mode (default), proceed as described below.
+> **Mode guard**: In `dry_run: true` mode, do not invoke `lisa:tracker-write` in this phase. Instead, draft each story spec and validate it with `lisa:tracker-validate --spec-only`. Use placeholder keys (e.g. `DRY-RUN-STORY-1.1`) for any downstream references. In `dry_run: false` mode (default), proceed as described below.
 
 For each Epic, plan two kinds of stories:
 - **One "X.0 Setup" story** for data model and infrastructure prerequisites
@@ -207,13 +207,13 @@ For each Epic, plan two kinds of stories:
 
 **Story naming convention**: Prefix the summary with a short code derived from the PRD title (e.g., `[CU-1.1]` for "Contract Upload").
 
-For each story, **invoke `lisa:jira-write-ticket`** with:
+For each story, **invoke `lisa:tracker-write`** with:
 
 - `project_key`: from `JIRA_PROJECT` config
 - `issue_type`: `Story`
 - `epic_parent`: the Epic key captured in Phase 3 (mandatory)
 - `summary`: prefixed per the naming convention above
-- `description_body`: 3-audience description as in `lisa:notion-to-jira` Phase 4
+- `description_body`: 3-audience description as in `lisa:notion-to-tracker` Phase 4
 - `artifacts`: the Phase 1.5 artifacts filtered by domain per the inheritance table below
 
 | Story type | Inherits domains |
@@ -227,7 +227,7 @@ Capture each returned story key — Phase 5 needs it as the parent for sub-tasks
 
 ### Phase 5: Create Sub-tasks
 
-Delegate sub-task creation to **parallel agents** (one per epic or batch of stories) for efficiency. **Every spawned agent must invoke `lisa:jira-write-ticket` for each sub-task — no agent may call `createJiraIssue` directly.**
+Delegate sub-task creation to **parallel agents** (one per epic or batch of stories) for efficiency. **Every spawned agent must invoke `lisa:tracker-write` for each sub-task — no agent may call `createJiraIssue` directly.**
 
 Each sub-task MUST:
 1. **Be scoped to exactly ONE repo** — indicated in brackets in the summary: `[repo-name]`
@@ -241,9 +241,9 @@ Run the preservation gate defined in `lisa:jira-source-artifacts` §8 against th
 
 To run the gate, this skill must:
 
-1. Pull the remote links of every epic and story created in this run via `mcp__atlassian__getJiraIssueRemoteIssueLinks`.
+1. Pull the remote links of every epic and story created in this run via `lisa:tracker-read (vendor-neutral; dispatches to jira-read-ticket or github-read-issue)`.
 2. Apply the §8 preservation matrix and verdict rules.
-3. If the gate fails: list each dropped/misrouted artifact and either re-attach via `lisa:jira-write-ticket` (UPDATE mode) or stop and ask the human.
+3. If the gate fails: list each dropped/misrouted artifact and either re-attach via `lisa:tracker-write` (UPDATE mode) or stop and ask the human.
 4. If the gate passes: print the matrix compactly and proceed to Phase 6.
 
 This gate is not optional.
@@ -275,13 +275,13 @@ When delegating to agents, provide this context. **The "MUST invoke jira-write-t
 ```text
 Create JIRA sub-tasks in the [PROJECT] project at [CLOUD_ID].
 
-CRITICAL: For each sub-task, invoke the `lisa:jira-write-ticket` skill via the Skill tool.
-Do NOT call `mcp__atlassian__createJiraIssue` directly. The `lisa:jira-write-ticket` skill
+CRITICAL: For each sub-task, invoke the `lisa:tracker-write` skill via the Skill tool.
+Do NOT call `mcp__atlassian__createJiraIssue` directly. The `lisa:tracker-write` skill
 enforces required quality gates (Gherkin acceptance criteria, 3-audience description,
 single-repo scope, sign-in/environment fields, post-create verification). Bypassing it
 produces broken tickets that downstream skills (triage, journey, evidence) cannot use.
 
-For each sub-task, invoke `lisa:jira-write-ticket` with:
+For each sub-task, invoke `lisa:tracker-write` with:
 - issue_type: "Sub-task"
 - parent: the parent story key
 - project_key: [PROJECT]
@@ -297,9 +297,9 @@ For each sub-task, invoke `lisa:jira-write-ticket` with:
 Each sub-task must:
 1. Be scoped to ONE repo only — repo named in brackets in the summary
 2. Include the Empirical Verification Plan in the description
-3. Be created via `lisa:jira-write-ticket`, not via direct MCP calls
+3. Be created via `lisa:tracker-write`, not via direct MCP calls
 
-If `lisa:jira-write-ticket` rejects a sub-task, fix the input and re-invoke. Do NOT fall back
+If `lisa:tracker-write` rejects a sub-task, fix the input and re-invoke. Do NOT fall back
 to a direct `createJiraIssue` call to bypass the gate.
 
 Test user info: [credentials from config]

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

@@ -0,0 +1,114 @@
+---
+name: github-add-journey
+description: "Add a Validation Journey section to an existing GitHub Issue by analyzing the change type and generating appropriate verification steps with evidence markers. The GitHub counterpart of lisa:jira-add-journey."
+allowed-tools: ["Bash", "Skill"]
+---
+
+# Add Validation Journey to Existing GitHub Issue
+
+Read an existing GitHub Issue, analyze the change type, and append a `## Validation Journey` markdown section with appropriate verification steps based on the project's verification patterns.
+
+## Arguments
+
+`$ARGUMENTS`: `<ISSUE_REF>`
+
+- `ISSUE_REF` (required): GitHub issue ref — `org/repo#<number>` or full GitHub issue URL.
+
+## Prerequisites
+
+- `gh` CLI authenticated (`gh auth status`).
+
+## Workflow
+
+### Step 1: Read the Issue
+
+```bash
+gh issue view <number> --repo <org>/<repo> --json number,title,body,labels,assignees,milestone,url
+```
+
+Extract: title, body, type (from `type:` label), components (from `component:` labels), assignees, linked PRs.
+
+### Step 2: Check for Existing Journey
+
+Parse the body for an existing `## Validation Journey` heading. If present and the section contains at least one `[EVIDENCE: <name>]` marker, the issue already has a journey — report this to the user and stop.
+
+### Step 3: Analyze the Change Type
+
+Examine the body, acceptance criteria, and codebase to determine the change type:
+
+1. **API/GraphQL changes** — New or modified endpoints, request/response schemas
+2. **Database migration** — Schema changes, new tables/columns, indexes
+3. **Background job/queue** — New job processors, queue consumers, event handlers
+4. **Library/utility** — Exported functions, shared modules, npm package changes
+5. **Security fix** — Auth, authorization, input validation, OWASP vulnerabilities
+6. **Authentication/authorization** — Role-based access, session management, tokens
+
+Use Explore agents or read the codebase directly to understand which files are affected.
+
+### Step 4: Map Change Type to Verification Pattern
+
+| Change Type | Verification Approach |
+|---|---|
+| API/GraphQL | curl commands verifying endpoints, status codes, response schemas |
+| Database migration | Migration execution + schema verification + rollback check |
+| Background job/queue | Enqueue + process + state change verification |
+| Library/utility | Test execution + build verification + export check |
+| Security fix | Exploit reproduction pre-fix + exploit failure post-fix |
+| Auth/authz | Multi-role verification with explicit status codes |
+
+### Step 5: Draft the Validation Journey
+
+Compose the journey with `[EVIDENCE: name]` markers at key verification points:
+
+```markdown
+## Validation Journey
+
+### Prerequisites
+- List required services, database, env vars
+
+### Steps
+1. Verify current state before changes
+2. Apply the change
+3. Verify expected new state [EVIDENCE: state-name]
+4. Test error/edge cases [EVIDENCE: error-case]
+5. Verify rollback if applicable [EVIDENCE: rollback]
+
+### Assertions
+- Describe what must be true after verification
+```
+
+### Guidelines for Drafting
+
+1. **2–5 evidence markers** — Focus on proving the change works and handles errors.
+2. **Concrete, runnable steps** — `Run \`curl -s localhost:3000/health | jq .status\`` not "Check the endpoint".
+3. **Include environment setup** — Database connection, running services, env vars.
+4. **Evidence names in kebab-case** — `api-response`, `schema-check`, `rate-limit-hit`.
+5. **Assertions are measurable** — `Returns 200 with {status: ok}` not "API works correctly".
+6. **Cover happy path AND error path** — At minimum, one success and one failure marker.
+
+### Step 6: Present to User for Approval
+
+Display the drafted Validation Journey and ask for confirmation before appending it to the issue body. (If invoked from a parent skill running unattended — e.g., `lisa:github-write-issue` Phase 6 step 5 — proceed without the prompt.)
+
+### Step 7: Append to Issue Body
+
+After approval:
+
+```bash
+current_body=$(gh issue view <number> --repo <org>/<repo> --json body --jq '.body')
+# Compose new body: existing + "\n\n## Validation Journey\n..." (or replace if present)
+gh issue edit <number> --repo <org>/<repo> --body-file /tmp/updated-body.md
+```
+
+Preserve every other section verbatim — never re-render the body from parsed fields, since the issue may carry `extra_sections` we don't recognize.
+
+### Step 8: Verify
+
+Re-read the issue and confirm the `## Validation Journey` section is present and includes at least one `[EVIDENCE: <name>]` marker.
+
+## When to Use This Skill
+
+- Issue was created before the Validation Journey convention was established.
+- Issue was created manually without following `lisa:github-create` guidelines.
+- Issue needs a journey added or updated based on implementation progress.
+- Before starting work on an issue, to ensure verification steps are documented.