@codyswann/lisa 2.189.7 → 2.189.9

package/plugins/src/base/skills/ticket-triage/SKILL.md

@@ -1,186 +0,0 @@
----
-name: ticket-triage
-description: "Analytical triage gate for tickets in the configured destination tracker (JIRA, GitHub Issues, or Linear). Detects requirement ambiguities, identifies edge cases from codebase analysis, and plans verification methodology. Posts findings to the ticket and produces a verdict (DUPLICATE_ALREADY_FIXED/BLOCKED/PASSED_WITH_FINDINGS/PASSED) that gates whether implementation can proceed. Vendor-neutral: the caller (jira-agent or github-agent) is responsible for fetching the ticket via lisa:tracker-read, running the pre-flight gate via lisa:tracker-verify, and posting findings via the matching vendor comment tool."
-allowed-tools: ["Read", "Glob", "Grep", "Bash"]
----
-
-# Ticket Triage: $ARGUMENTS
-
-Perform analytical triage on the ticket. The caller MUST have run `lisa:tracker-read` (or its vendor-specific underlying skill — `lisa:jira-read-ticket` for JIRA, `lisa:github-read-issue` for GitHub) first and provided the resulting context bundle — which includes the primary ticket, all linked tickets (blocks / is blocked by / relates to / duplicates), parent (Epic in JIRA, parent sub-issue in GitHub), siblings, sub-tasks / sub-issues, and remote PR state. Do not triage from a bare ticket summary — if the bundle is missing link or parent context, stop and instruct the caller to run `/tracker-read` first.
-
-Repository name for scoped labels and comment headers: determine via `basename $(git rev-parse --show-toplevel)`.
-
-## Phase 0 -- Pre-flight Description Gate
-
-Before any analytical work, confirm the ticket carries the content an implementer needs to start. The caller should already have run `lisa:tracker-verify`; this phase consumes its output. If `lisa:tracker-verify` returned `FAIL` for any of the following, emit `BLOCKED` immediately with the missing-requirements list and skip to Phase 6:
-
-- Parent missing (Epic parent for JIRA non-bug-non-epic; parent sub-issue for GitHub non-bug-non-epic)
-- Description quality failures (no Gherkin acceptance criteria, missing audience sections)
-- Validation Journey missing on a runtime-behavior ticket
-- Target backend environment missing on a runtime-behavior ticket
-- Sign-in credentials missing on a ticket that touches authenticated surfaces
-- Relationship discovery missing (no links AND no documented git + tracker-search outcome)
-
-Single-repo scope is handled separately — see below.
-
-The caller (jira-agent or github-agent) is responsible for transitioning the ticket to `Blocked` (JIRA status) or relabeling to `status:blocked` (GitHub), reassigning to the **Reporter / original author**, and posting a comment listing the missing requirements. This skill only emits the verdict and the missing-requirements list.
-
-**Single-repo scope is split, not blocked.** A cross-repo leaf work unit (Bug / Task / Sub-task / Improvement spanning repos) is a decomposition error the agent owns, not a terminal BLOCKED. Do not emit BLOCKED for it. The caller runs the **work-time split procedure** in the `repo-scope-split` rule (narrow the original to one repo, spin off a sibling per additional repo, link the producer→consumer dependency), then re-runs `tracker-verify` and re-enters triage on the now single-repo ticket. Only fall back to BLOCKED if the split is ambiguous (see "When to block instead of split" in that rule).
-
-If `lisa:tracker-verify` returned `PASS` for all the above, proceed to Phase 1.
-
-## Phase 1 -- Relevance Check
-
-Search the local codebase using Glob and Grep for code related to the ticket's subject matter:
-- Keywords from summary and description
-- Component names, API endpoints, database tables
-- Error messages or log strings mentioned in the ticket
-
-If NO relevant code is found in this repo:
-- Output: `## Verdict: NOT_RELEVANT`
-- Instruct caller to add the label `claude-triaged-{repo}` and skip this ticket
-
-If relevant code IS found, proceed to Phase 2.
-
-## Phase 1.5 -- Relationship & Epic Awareness
-
-From the context bundle, evaluate relationships before analyzing this ticket in isolation:
-
-- **Open blockers (`is blocked by`)**: if any blocker is not `Done` or its linked PR is not merged, raise an ambiguity: "Blocker {KEY} is not shipped — work cannot meaningfully start." This is an automatic `BLOCKED` verdict unless the human confirms the blocker state is acceptable.
-- **Epic siblings in progress**: if a sibling under the same epic is `In Progress` / `In Review` with a different assignee and overlapping scope, raise it as an edge case in Phase 4 ("Duplicate-work risk with {KEY}").
-- **`duplicates` / `is duplicated by` links**:
-  - If this ticket is a duplicate of an open canonical ticket whose fix is not yet merged into the base branch, verdict is `BLOCKED` with the recommendation to close as duplicate manually rather than implement.
-  - If this ticket is a duplicate of canonical work that is already merged/deployed, verdict is `DUPLICATE_ALREADY_FIXED`. This verdict must carry the canonical ticket reference, the canonical PR/commit reference, and empirical evidence that the canonical fix is present on the relevant base branch. Never emit this verdict from a name/label match alone.
-- **`relates to` links with shipped PRs**: flag the PRs in the verification methodology (Phase 5) as prior art worth reviewing before writing new code.
-
-Do not re-fetch tickets — the bundle already has the context.
-If Phase 1.5 finds an automatic blocker condition (`is blocked by` not shipped, or duplicate-of-open), emit `BLOCKED` immediately and skip to Phase 6 output formatting. If it finds a duplicate whose canonical fix is empirically present on the base branch, emit `DUPLICATE_ALREADY_FIXED` immediately and skip to Phase 6 output formatting.
-
-## Phase 2 -- Cross-Repo Awareness
-
-Parse the ticket's existing comments for triage headers from OTHER repositories. Look for patterns like:
-- `*[some-repo-name] Ambiguity detected*`
-- `*[some-repo-name] Edge cases*`
-- `*[some-repo-name] Verification methodology*`
-
-Note which phases other repos have already covered and what findings they posted. In subsequent phases:
-- Do NOT duplicate findings already posted by another repo
-- DO add supplementary findings specific to THIS repo's codebase
-
-## Phase 3 -- Ambiguity Detection
-
-Examine the ticket summary, description, and acceptance criteria. Look for:
-
-| Signal | Example |
-|--------|---------|
-| Vague language | "should work properly", "handle edge cases", "improve performance" |
-| Untestable criteria | No measurable outcome defined |
-| Undefined terms | Acronyms or domain terms not explained in context |
-| Missing scope boundaries | What's included vs excluded is unclear |
-| Implicit assumptions | Assumptions not stated explicitly |
-
-Skip ambiguities already raised by another repo's triage comments.
-
-For each NEW ambiguity found, produce:
-
-```text
-### Ambiguity: [short title]
-**Description:** [what is ambiguous]
-**Suggested clarification:** [specific question to resolve it]
-```
-
-Be specific -- every ambiguity must have a concrete clarifying question.
-
-## Phase 4 -- Edge Case Analysis
-
-Search the codebase using Glob and Grep for files related to the ticket's subject matter. Check git history for recent changes in those areas:
-
-```bash
-git log --oneline -20 -- <relevant-paths>
-```
-
-Identify:
-- Boundary conditions (empty inputs, max values, concurrent access)
-- Error handling gaps in related code
-- Integration risks with other components
-- Data migration or backward compatibility concerns
-
-Reference only files in THIS repo. Acknowledge edge cases from other repos if relevant, but do not duplicate them.
-
-For each edge case, produce:
-
-```text
-### Edge Case: [title]
-**Description:** [what could go wrong]
-**Code reference:** [file path and relevant lines or patterns]
-```
-
-Every edge case must reference specific code files or patterns found in the codebase. If no relevant code exists, note that this appears to be a new feature with no existing code to analyze.
-
-## Phase 5 -- Verification Methodology
-
-For each acceptance criterion, specify a concrete verification method scoped to what THIS repo can test:
-
-| Verification Type | When to Use | What to Specify |
-|-------------------|-------------|-----------------|
-| UI | Change affects user-visible interface | Playwright test description with specific assertions |
-| API | Change affects HTTP/GraphQL/RPC endpoints | curl command with expected response status and body |
-| Data | Change involves schema, migrations, queries | Database query or service call to verify state |
-| Performance | Change claims performance improvement | Benchmark description with target metrics |
-
-Do not duplicate verification methods already posted by other repos.
-
-Produce a table:
-
-```text
-| Acceptance Criterion | Verification Method | Type |
-|---------------------|--------------------| -----|
-```
-
-Every verification method must be specific enough that an automated agent could execute it.
-
-## Phase 6 -- Verdict
-
-Evaluate the findings and produce exactly one verdict:
-
-- **`NOT_RELEVANT`** -- No relevant code was found in this repository (Phase 1). The caller should add the triage label and skip implementation in this repo.
-- **`DUPLICATE_ALREADY_FIXED`** -- This ticket duplicates canonical work whose fix is already merged/deployed and empirically confirmed present on the relevant base branch. Work MUST NOT proceed. The caller must post the triage finding, ensure the native `duplicates <canonical>` link exists when the tracker supports one, and return the structured canonical reference/evidence to build intake for terminal duplicate closeout.
-- **`BLOCKED`** -- Blocking conditions were found in Phase 0 (missing required description content), Phase 1.5 (open blockers, duplicate-of-open), and/or Phase 3 (ambiguities). Work MUST NOT proceed until resolved by a human. When the block is from Phase 0, the caller (jira-agent) MUST transition the ticket to `Blocked` and reassign to the Reporter — not just leave it in place. For Phase 1.5 / Phase 3 blocks, post findings, add the triage label, and STOP.
-- **`PASSED_WITH_FINDINGS`** -- No ambiguities, but edge cases or verification findings were identified. Work can proceed. The caller should post findings and add the triage label.
-- **`PASSED`** -- No ambiguities, edge cases, or verification gaps found. Work can proceed. The caller should add the triage label.
-
-Output format:
-
-```text
-## Verdict: [NOT_RELEVANT | DUPLICATE_ALREADY_FIXED | BLOCKED | PASSED_WITH_FINDINGS | PASSED]
-
-**Ambiguities found:** [count]
-**Edge cases identified:** [count]
-**Verification methods defined:** [count]
-```
-
-## Output Structure
-
-Structure all output with clear section headers so the caller can parse and post findings:
-
-```text
-## Triage: [TICKET-KEY] ([repo-name])
-
-### Ambiguities
-[Phase 3 findings, or "None found."]
-
-### Edge Cases
-[Phase 4 findings, or "None found."]
-
-### Verification Methodology
-[Phase 5 table, or "No acceptance criteria to verify."]
-
-## Verdict: [NOT_RELEVANT | DUPLICATE_ALREADY_FIXED | BLOCKED | PASSED_WITH_FINDINGS | PASSED]
-```
-
-The caller is responsible for:
-1. Posting the findings as comments on the ticket (using whatever Jira mechanism is available)
-2. Adding the `claude-triaged-{repo}` label to the ticket
-3. If `BLOCKED` due to Phase 0 (missing required description content): transitioning the ticket to `Blocked`, reassigning to the **Reporter**, posting a comment listing the missing requirements, and stopping all work.
-4. If `DUPLICATE_ALREADY_FIXED`: return the canonical ticket reference and empirical base-branch evidence to build intake so it can close the ticket as a terminal duplicate without opening a PR.
-5. If `BLOCKED` due to Phase 1.5 (open blockers, duplicate-of-open) or Phase 3 (ambiguities): stopping all work and reporting to the human; do NOT auto-transition status in these cases.

package/plugins/src/base/skills/tracker-add-journey/SKILL.md

@@ -1,26 +0,0 @@
----
-name: tracker-add-journey
-description: "Vendor-neutral wrapper for appending a Validation Journey section to an existing ticket/issue. Reads `tracker` from .lisa.config.json (default: jira) and dispatches to lisa:jira-add-journey, lisa:github-add-journey, or lisa:linear-add-journey."
-allowed-tools: ["Skill", "Bash", "Read"]
----
-
-# Tracker Add Journey: $ARGUMENTS
-
-Thin dispatcher. Resolves the configured destination tracker and delegates to the matching vendor skill.
-
-See the `config-resolution` rule for configuration and dispatch table.
-
-## Workflow
-
-1. Resolve tracker config (same logic as `lisa:tracker-write`).
-2. Dispatch:
-   - `jira` → invoke `lisa:jira-add-journey` with `$ARGUMENTS` verbatim. Arg: a JIRA ticket key.
-   - `github` → invoke `lisa:github-add-journey` with `$ARGUMENTS` verbatim. Arg: `org/repo#<number>` or a GitHub issue URL.
-   - `linear` → invoke `lisa:linear-add-journey` with `$ARGUMENTS` verbatim. Arg: a Linear Issue identifier (e.g., `ENG-123`).
-   - Anything else → stop and report `"Unknown tracker '<value>' in .lisa.config.json. Expected 'jira', 'github', or 'linear'."`
-3. Pass through the output.
-
-## Rules
-
-- The Validation Journey content format is identical across all vendors (markdown sections with `[EVIDENCE: name]` markers). The only difference is how the section is appended — JIRA via `editJiraIssue` (Jira wiki markup), GitHub via `gh issue edit --body-file` (markdown), Linear via `save_issue` (markdown).
-- If the ticket already has a Validation Journey, the vendor skill reports it and stops. This shim does not retry.

package/plugins/src/base/skills/tracker-build-intake/SKILL.md

@@ -1,85 +0,0 @@
----
-name: tracker-build-intake
-description: "Vendor-neutral wrapper for the build-queue scanner. Reads `tracker` from .lisa.config.json (default: jira) and dispatches to lisa:jira-build-intake (JQL/project-key queue), lisa:github-build-intake (GitHub repo queue keyed off the `status:ready` label), or lisa:linear-build-intake (Linear team queue keyed off the `status:ready` label). Every vendor scanner processes at most one eligible item per cycle and enforces the claim-time arm of the `leaf-only-lifecycle` rule — dispatch leaf work units only; move or safe-block a container with open child work (or a childless Epic) that carries a stale build-ready role according to the vendor's lifecycle semantics. Counterpart to lisa:intake's PRD-side dispatchers."
-allowed-tools: ["Skill", "Bash", "Read"]
----
-
-# Tracker Build Intake: $ARGUMENTS
-
-Thin dispatcher. Resolves the configured destination tracker and delegates to the matching vendor build-queue scanner.
-
-See the `config-resolution` rule for configuration and dispatch table.
-
-The vendor scanners also own the terminal native-closure step from `leaf-only-lifecycle`: after a leaf reaches the true terminal `done` value, they close / resolve / complete the native tracker item where supported, while leaving intermediate env states open.
-
-They also forward the narrow duplicate terminal exception from `ticket-triage`: when a claimed item returns `DUPLICATE_ALREADY_FIXED` with a canonical item reference and empirical base-branch evidence, the vendor scanner posts the triage finding, ensures a native `duplicates <canonical>` link where supported, and closes the item as a duplicate without opening a PR. This is distinct from `BLOCKED`; open blockers, ambiguous tickets, and duplicate-of-open findings stay held for human action.
-
-## Workflow
-
-1. Resolve tracker config (same logic as `lisa:tracker-write`).
-2. Dispatch:
-   - `jira` → invoke `lisa:jira-build-intake` with `$ARGUMENTS` verbatim. Arg shape: a JIRA project key (e.g., `SE`) or a JQL filter.
-   - `github` → invoke `lisa:github-build-intake` with `$ARGUMENTS` verbatim. Arg shape: a GitHub `org/repo` token or a full GitHub repo URL.
-   - `linear` → invoke `lisa:linear-build-intake` with `$ARGUMENTS` verbatim. Arg shape: a Linear team key (e.g., `ENG`) or the literal token `linear` (which falls back to `linear.teamKey`).
-   - Anything else → stop and report `"Unknown tracker '<value>' in .lisa.config.json. Expected 'jira', 'github', or 'linear'."`
-3. Pass through the cycle summary verbatim.
-
-## Leaf-only claim contract (forwarded to every vendor)
-
-This shim is dispatch only — it does not reclassify or re-gate items — but the contract it forwards is part of the build-intake API, so it is documented here once and the three vendor scanners implement it identically. Per the vendor-neutral `leaf-only-lifecycle` rule, **build intake claims only independently implementable leaf work units**:
-
-- A **leaf work unit** (Bug, Task, Sub-task, Improvement, or a childless Story/Spike — anything with no open child work except an Epic) is claimed and built.
-- A **container** — anything with open child work, or a childless Epic — that still carries a stale build-ready role is **never dispatched**. The GitHub scanner moves it out of the pickup queue by replacing `status:ready` with `status:in-progress` and posting an idempotent lifecycle-repair comment; other vendor scanners skip or safe-block according to their native lifecycle semantics.
-
-This is the claim-time arm of the rule. Its siblings are the write-time labeling (`lisa:tracker-write` → the vendor `*-write-*` skills apply build-ready to leaves only) and the validate-time S15 gate (`lisa:tracker-validate` → the vendor `*-validate-*` skills FAIL a build-ready container). All three arms cite `leaf-only-lifecycle` so no vendor drifts. Each vendor scanner implements the gate against its own hierarchy:
-
-| Tracker | Vendor scanner | Hierarchy used to detect open child work |
-|---|---|---|
-| `github` | `lisa:github-build-intake` (Phase 3a) | native sub-issues (GraphQL) + body parentage |
-| `jira` | `lisa:jira-build-intake` (Phase 3a) | native Epic → Story → Sub-task parentage |
-| `linear` | `lisa:linear-build-intake` (Phase 3a) | native sub-issues via `parentId` + Project grouping |
-
-The shim never needs to inspect the item itself — it forwards `$ARGUMENTS` verbatim and the resolved vendor scanner runs its Phase 3a gate before any claim.
-
-## Repo-scope claim contract (forwarded to every vendor)
-
-Equally part of the build-intake API, and forwarded identically: when the tracker oversees multiple repos, each vendor scanner claims only tickets for the repo it is running in. Per the `repo-scope-split` rule's "Claim-time repo scoping" section, before the leaf-only gate each scanner (Phase 3a.0) resolves the current repo (`config-resolution` "Repo scoping": `repo` → `github.repo` → git remote basename), then for each ready candidate: skips a ticket labeled `repo:<other>`, determines + stamps `repo:<name>` on an unlabeled one, splits a multi-repo leaf into single-repo build-ready siblings, and claims only a single-repo leaf for the current repo. This shim does not re-implement the gate — it relies on the vendor scanner's Phase 3a.0 — but the contract is uniform across `jira`, `github`, and `linear` so behavior never drifts by tracker. It is the claim-time complement to the write-time S10 scope gate (`lisa:tracker-validate`) and `task-decomposition` step 1.5; all cite `repo-scope-split`.
-
-## Terminal native-closure contract (forwarded to every vendor)
-
-This shim also forwards the `leaf-only-lifecycle` terminal native-closure contract. It does not decide whether a `done` value is terminal; the vendor scanner resolves that from its own config and deployment topology after the per-item agent succeeds.
-
-| Tracker | Vendor scanner behavior at true terminal `done` |
-|---|---|
-| `github` | apply the terminal `done` label, then `gh issue close --reason completed` |
-| `jira` | transition to the configured terminal status and verify native resolved / closed state |
-| `linear` | apply the terminal `done` label, then move the Issue to the configured completed workflow state |
-
-Intermediate env states are not native closure. A vendor scanner that resolves `On Dev`, `On Stg`, `status:on-dev`, `status:on-stg`, or a configured equivalent leaves the item open / unresolved.
-
-## Duplicate-already-fixed terminal contract (forwarded to every vendor)
-
-`DUPLICATE_ALREADY_FIXED` is the only triage verdict that may close a claimed build item without a PR from the current cycle. The vendor scanner must require:
-
-- canonical ticket/issue reference;
-- canonical PR/commit reference;
-- empirical evidence that the canonical fix is present on the relevant base branch.
-
-Vendor closeout behavior:
-
-| Tracker | Duplicate closeout |
-|---|---|
-| `github` | apply terminal `$DONE`, ensure/link `duplicates <canonical>` where available, then `gh issue close --reason "not planned"` |
-| `jira` | transition to terminal `$DONE` with resolution `Duplicate` and ensure the native duplicates link |
-| `linear` | apply terminal `$DONE`, ensure/link duplicate relationship where available, then move to the configured canceled-as-duplicate or terminal duplicate state |
-
-If the canonical fix is merged but not yet on the production branch, the close comment must preserve the production-promotion caveat: the production error can recur until the canonical item promotes, and recurrence is tracked by the canonical item rather than by reopening this duplicate.
-
-## Rules
-
-- Single cycle per invocation — the vendor skill processes at most one eligible `Ready` item and exits. Scheduler repetition works the rest of the queue.
-- The vendor skills run their own pre-flight checks (JIRA workflow transitions for the JIRA path; label namespace adoption for the GitHub and Linear paths) before processing items. Never bypass.
-- **Leaf-only dispatch, every vendor.** Per the `leaf-only-lifecycle` rule, each vendor scanner dispatches leaf work units only and moves or safe-blocks a container (open child work, or a childless Epic) carrying a stale build-ready role according to its lifecycle semantics. This shim does not re-implement the gate — it relies on the vendor scanner's Phase 3a — but the contract is uniform across `jira`, `github`, and `linear` so behavior never drifts by tracker.
-- **Terminal native closure, every capable vendor.** Per the same rule, each vendor scanner finalizes native open/closed state only at the true terminal `done` value. This shim never performs native closure itself, but callers can rely on the dispatched vendor scanner to apply the contract.
-- **Duplicate already fixed, every vendor.** Auto-close without a PR is allowed only for `DUPLICATE_ALREADY_FIXED` with canonical reference and empirical base-branch evidence. Do not conflate this with `BLOCKED`.
-- Never run two intake cycles concurrently against overlapping queues — the scheduling layer is responsible for serialization.

package/plugins/src/base/skills/tracker-create/SKILL.md

@@ -1,26 +0,0 @@
----
-name: tracker-create
-description: "Vendor-neutral wrapper for creating tickets/issues from code files or descriptions. Reads `tracker` from .lisa.config.json (default: jira) and dispatches to lisa:jira-create, lisa:github-create, or lisa:linear-create. Plans hierarchy structure (epic / story / sub-task), then delegates each individual write through the tracker-write shim."
-allowed-tools: ["Skill", "Bash", "Read"]
----
-
-# Tracker Create: $ARGUMENTS
-
-Thin dispatcher. Resolves the configured destination tracker and delegates to the matching vendor planning skill.
-
-See the `config-resolution` rule for configuration and dispatch table.
-
-## Workflow
-
-1. Resolve tracker config (same logic as `lisa:tracker-write`).
-2. Dispatch:
-   - `jira` → invoke `lisa:jira-create` with `$ARGUMENTS` verbatim.
-   - `github` → invoke `lisa:github-create` with `$ARGUMENTS` verbatim.
-   - `linear` → invoke `lisa:linear-create` with `$ARGUMENTS` verbatim.
-   - Anything else → stop and report `"Unknown tracker '<value>' in .lisa.config.json. Expected 'jira', 'github', or 'linear'."`
-3. Pass through the output.
-
-## Rules
-
-- All vendor skills delegate every individual ticket write through `lisa:tracker-write`. They never call vendor-specific write tools directly.
-- This shim is for ad-hoc creation from code files / descriptions. PRD-driven creation goes through the `*-to-tracker` skills (notion / confluence / linear / github).

package/plugins/src/base/skills/tracker-evidence/SKILL.md

@@ -1,52 +0,0 @@
----
-name: tracker-evidence
-description: "Vendor-neutral wrapper for posting verification evidence. Reads `tracker` from .lisa.config.json (default: jira) and dispatches to lisa:jira-evidence, lisa:github-evidence, or lisa:linear-evidence. Uploads evidence to the GitHub `pr-assets` release, updates the PR description, posts a comment on the originating ticket/issue, and leaves workflow transitions to the tracker-specific lifecycle owner."
-allowed-tools: ["Skill", "Bash", "Read"]
----
-
-# Tracker Evidence: $ARGUMENTS
-
-Thin dispatcher. Resolves the configured destination tracker and delegates to the matching vendor evidence skill.
-
-See the `config-resolution` rule for configuration and dispatch table.
-
-## Workflow
-
-1. Resolve tracker config (same logic as `lisa:tracker-write`).
-2. Before dispatching, update the generated evidence artifact through `lisa:usage-accounting` so the comment body / PR evidence section carries a direct `verify` usage entry in the canonical `## Lisa Usage` section. If the originating work item's parentage or child refs are already known, prefer `record_and_rollup` so ancestor totals refresh in the same write; otherwise still write the direct entry, and if trustworthy runtime usage is unavailable, write `source: unavailable` with nullable token/cost fields instead of skipping the row.
-3. Dispatch:
-   - `jira` → invoke `lisa:jira-evidence` with `$ARGUMENTS` verbatim. Arg shape: `<TICKET_ID> <EVIDENCE_DIR> <PR_NUMBER>`.
-   - `github` → invoke `lisa:github-evidence` with `$ARGUMENTS` verbatim. Arg shape: `<ISSUE_REF> <EVIDENCE_DIR> <PR_NUMBER>` where `ISSUE_REF` is `org/repo#<number>` or a GitHub issue URL.
-   - `linear` → invoke `lisa:linear-evidence` with `$ARGUMENTS` verbatim. Arg shape: `<IDENTIFIER> <EVIDENCE_DIR>` where `IDENTIFIER` is a Linear Issue identifier (e.g., `ENG-123`).
-   - Anything else → stop and report `"Unknown tracker '<value>' in .lisa.config.json. Expected 'jira', 'github', or 'linear'."`
-4. Pass through the vendor skill's output.
-
-## Rules
-
-- The GitHub `pr-assets` release lives on the implementation repo (the one with the PR), regardless of which tracker hosts the ticket/issue. All vendor skills upload there.
-- Never post evidence to a different ticket than the one named — `$ARGUMENTS` is the source of truth.
-- Never invent a verify-specific usage footer. Evidence artifact usage must flow through `lisa:usage-accounting`, preserve the canonical `## Lisa Usage` section, and surface `source: unavailable` explicitly when the runtime cannot provide trustworthy numbers.
-- **Evidence-manifest gate (leaf work units).** Before dispatching to a vendor skill that transitions the ticket, confirm `EVIDENCE_DIR` contains a non-empty artifact for every `[EVIDENCE: name]` marker declared in the ticket's Validation Journey. If any declared marker has no captured artifact (or only an empty one), stop and report the missing markers by name instead of posting — a leaf work unit (Bug / Task / Sub-task / Improvement) may not advance to its review/Done state with an unsatisfied manifest (see the "Per-Work-Unit Evidence Contract" in the `verification` rule). Epics / Stories / Spikes, and leaf units without a Validation Journey, are exempt.
-
-## UI Evidence Checklist (when work is UI-visible)
-
-Apply this when authoring `evidence/comment.md` (and `evidence/comment.txt` for JIRA wiki markup) for any ticket whose work touches a user-facing surface — bug fix, new component, new flow, UX polish, design implementation. Skip the checklist for non-UI work (API, infra, migrations, etc.); the plain-text evidence path is fine there.
-
-The checklist is tracker-agnostic — the same shape works on JIRA, GitHub Issues, and Linear. Vendor skills only own the post/transition mechanics; the comment body is your responsibility.
-
-1. **AI disclosure at the top.** Lead with "Update from Claude (AI agent, not a human)" and address the reporter / QA / PM by name.
-2. **Own any prior mistake explicitly.** If an earlier triage or build pass got something wrong, say so up front. Don't bury it.
-3. **Numbered step-by-step walk** of what you actually did in the browser/app, in plain language a non-engineer can follow:
-   - Exact env (URL, viewport size — e.g. `402×874` for an iOS-sized mobile flow)
-   - Login creds shape — e.g. `(000) 000-0002` + OTP `555555`
-   - Exact record/player name, exact button labels as they appear on screen
-   - Full happy-path **and** any non-obvious edge state worth showing (empty state, loading, post-completion)
-4. **One screenshot per step**, captured live via Playwright MCP at the matching viewport. Upload via `gh release upload pr-assets <files> --clobber` and reference each one as a **plain URL** in the comment body — *not* `![alt](url)` markdown embeds. Plain URLs render as smartlinks/auto-embeds across all three trackers and stay individually viewable; markdown embeds collapse on JIRA when there are ≥2.
-5. **"What this shows" section.** Tailor to ticket type:
-   - **Bug repro:** state plainly whether the bug reproduces or not, and the most likely 1–2 reasons their retest still failed (different env, native app vs. web, stuck backend row, etc.).
-   - **Feature/UX completion:** state plainly which acceptance criteria each screenshot covers, and call out any deferred or out-of-scope surface explicitly so QA/PM doesn't have to infer.
-6. **"What would help me confirm" (bug) / "How to QA" (feature) section.** Concrete actionable retest steps with the exact selection criteria (e.g., "pick a record whose Status column shows `—`, not `Processing` or `Pending Review`").
-7. **Explicit invitation to be corrected.** End with a line like *"If any of the steps I listed are different from what you expected / actually did, please tell me explicitly which step I got wrong."* Non-optional — small differences (which record, which device, exact tap order, expected behavior) change everything, and naming the door open short-circuits ticket bounce-loops.
-8. **Workflow transition** is the vendor skill's job, not yours — it'll move the ticket per the configured tracker (JIRA: Reassign to reporter for bug repro / move to the configured review status when one exists, otherwise leave it in `claimed`; GitHub: direct `claimed` → configured `done` after a successful build; Linear: equivalent state). You don't transition manually.
-
-**Why this format:** It (a) gives the reporter a frame-by-frame they can compare against, (b) avoids the JIRA image-collapse failure mode while still working everywhere else, (c) names the most plausible discrepancies up front so the loop short-circuits, (d) explicitly opens the door to being corrected so tickets don't bounce on assumed alignment. The same mechanics that resolve a stuck bug ticket also give QA an unambiguous handoff for a freshly-built feature.

package/plugins/src/base/skills/tracker-journey/SKILL.md

@@ -1,26 +0,0 @@
----
-name: tracker-journey
-description: "Vendor-neutral wrapper for executing a ticket/issue's Validation Journey end-to-end. Reads `tracker` from .lisa.config.json (default: jira) and dispatches to lisa:jira-journey, lisa:github-journey, or lisa:linear-journey. Parses the journey, satisfies prerequisites, executes the steps, captures evidence at each marker, and posts results via tracker-evidence."
-allowed-tools: ["Skill", "Bash", "Read"]
----
-
-# Tracker Journey: $ARGUMENTS
-
-Thin dispatcher. Resolves the configured destination tracker and delegates to the matching vendor journey skill.
-
-See the `config-resolution` rule for configuration and dispatch table.
-
-## Workflow
-
-1. Resolve tracker config (same logic as `lisa:tracker-write`).
-2. Dispatch:
-   - `jira` → invoke `lisa:jira-journey` with `$ARGUMENTS` verbatim. Arg shape: `<TICKET_ID> [PR_NUMBER]`.
-   - `github` → invoke `lisa:github-journey` with `$ARGUMENTS` verbatim. Arg shape: `<ISSUE_REF> [PR_NUMBER]`.
-   - `linear` → invoke `lisa:linear-journey` with `$ARGUMENTS` verbatim. Arg shape: `<IDENTIFIER> [PR_NUMBER]`.
-   - Anything else → stop and report `"Unknown tracker '<value>' in .lisa.config.json. Expected 'jira', 'github', or 'linear'."`
-3. Pass through the output.
-
-## Rules
-
-- The journey content is identical across vendors; only the parser source differs (the JIRA vendor reads description via Atlassian MCP; the GitHub vendor reads body via `gh issue view --json body`; the Linear vendor reads description via `lisa:linear-access operation: get-issue`).
-- Evidence posting always goes through `lisa:tracker-evidence` — never bypass.

package/plugins/src/base/skills/tracker-read/SKILL.md

@@ -1,27 +0,0 @@
----
-name: tracker-read
-description: "Vendor-neutral wrapper for fetching the full scope of a ticket/issue and its related graph. Reads `tracker` from .lisa.config.json (default: jira) and dispatches to lisa:jira-read-ticket, lisa:github-read-issue, or lisa:linear-read-issue. Returns a consolidated context bundle so downstream agents never act on a single ticket in isolation."
-allowed-tools: ["Skill", "Bash", "Read"]
----
-
-# Tracker Read: $ARGUMENTS
-
-Thin dispatcher. Resolves the configured destination tracker and delegates to the matching vendor read skill.
-
-See the `config-resolution` rule for configuration and dispatch table.
-
-## Workflow
-
-1. Resolve tracker config (same logic as `lisa:tracker-write`).
-2. Dispatch:
-   - `jira` → invoke `lisa:jira-read-ticket` with `$ARGUMENTS` verbatim. The argument is a JIRA key (e.g., `PROJ-123`).
-   - `github` → invoke `lisa:github-read-issue` with `$ARGUMENTS` verbatim. The argument is `org/repo#<number>` or a full GitHub issue URL.
-   - `linear` → invoke `lisa:linear-read-issue` with `$ARGUMENTS` verbatim. The argument is a Linear identifier (e.g., `ENG-123`) or a project URL.
-   - Anything else → stop and report `"Unknown tracker '<value>' in .lisa.config.json. Expected 'jira', 'github', or 'linear'."`
-3. Return the vendor skill's context bundle verbatim.
-
-## Rules
-
-- Read-only — never modify the ticket/issue.
-- The three vendors emit different context-bundle formats (because their data models differ). Callers must be tolerant of all — or, more precisely, agents at the next layer parse the per-vendor bundle.
-- If the input format doesn't match the configured tracker (e.g. tracker is jira but `$ARGUMENTS` looks like a Linear identifier), stop and report — never auto-translate.

package/plugins/src/base/skills/tracker-source-artifacts/SKILL.md

@@ -1,107 +0,0 @@
----
-name: tracker-source-artifacts
-description: "Canonical, vendor-neutral taxonomy and rules for handling source artifacts (Figma, Lovable, Loom, screenshots, design docs, data samples) when generating or evaluating tracker tickets (JIRA, GitHub Issues, Linear). Defines: (1) artifact domains, (2) classification rules per tool, (3) source precedence (which artifact is authoritative for which question), (4) inheritance from epic to story to sub-task, (5) cross-axis conflict handling. Invoke this skill from any flow that extracts, attaches, or reasons about external design/UX/data artifacts so the rules don't drift across skills."
-allowed-tools: []
----
-
-# Tracker Source Artifact Taxonomy and Rules
-
-This skill is doctrine, not action — it defines the rules. Skills that need to extract, classify, attach, or reason about external artifacts (design files, prototypes, recordings, data samples) invoke this skill to load the taxonomy and apply it. The taxonomy is vendor-neutral: it applies equally to JIRA tickets, GitHub Issues, and Linear Issues.
-
-The reason this lives in one place: silent drift across skills is the failure mode this body of rules exists to prevent. If the rules differ between `lisa:notion-to-tracker`, `lisa:tracker-create`, and `lisa:tracker-write`, agents will silently route artifacts wrong and developers will lose source of truth. Edit here, propagate everywhere.
-
-## 1. Domains
-
-Every artifact is classified into exactly one domain. The domain determines what the artifact is the source of truth for, and which tickets inherit it.
-
-| Domain | What it defines | Examples |
-|--------|-----------------|----------|
-| `ui-design` (mocks) | **Visual treatment only** — layout, spacing, typography, color, iconography | Figma design frames, Framer static frames, bare screenshots, mockup PNGs |
-| `ux-flow` (prototypes) | **Interaction and flow only** — navigation, transitions, state changes, timing, empty/error/loading states | Lovable output, Loom walkthroughs, Figma prototype links, annotated screenshots, Miro/Mural flow diagrams, user journey maps |
-| `data` | Request/response shape, schema constraints, contracts | Example JSON, SQL schemas, GraphQL snippets, API contracts, sample payloads |
-| `ops` | Deployment / runtime context | Runbooks, dashboards, Terraform refs, deployment diagrams |
-| `reference` | Cross-cutting context | Confluence, Notion peer pages, Google Docs, related PRDs, RFCs |
-
-## 2. Classification rules per tool
-
-These rules exist because agents consistently misclassify Figma and Lovable artifacts, which are the two most common sources of dropped or misrouted context.
-
-- **Figma**: classify as `ux-flow` if the URL is a prototype share link — it contains `/proto/`, has `starting-point-node-id=` in the query, or the sharing context labels it "prototype" / "play mode". Otherwise classify as `ui-design`. Never assume; inspect the URL.
-- **Figma file with both design frames and a prototype**: emit two entries — one `ui-design` for the file, one `ux-flow` for the prototype URL — so both propagate correctly.
-- **Lovable output**: always `ux-flow`. Lovable ships working code, but its code, styling, and any embedded business rules are NOT authoritative. Treat strictly as a UX/flow reference. Implementation uses existing project components; business rules come from the PRD body, not from Lovable.
-- **Loom / video walkthrough**: `ux-flow` in the vast majority of cases. The rare exception — a video that's purely a static-frame design review with no interaction — is still `ux-flow` for routing purposes (both UX and UI stories benefit).
-- **Screenshot**: bare unannotated screenshot → `ui-design`. Screenshot with arrows between frames, flow labels, or numbered steps → `ux-flow`. Side-by-side gallery of state variants (empty/error/loading) → `ui-design` with the state variants noted.
-- **Confluence / Notion peer / Google Doc**: `reference` unless it is specifically a runbook (`ops`) or contains canonical API contracts (`data`).
-- **Grafana / Datadog / Sentry**: `ops`.
-- **Code blocks with example payloads** (JSON, SQL, GraphQL, cURL): `data`.
-
-When an artifact could plausibly fit multiple domains and the rules above don't disambiguate, err on the side of inclusion — emit it under both, or use the broader domain. Misclassification is caught downstream by the preservation gate; underclassification is silent drop.
-
-## 3. Source precedence
-
-When artifacts disagree, silent reconciliation is a known failure mode. The rules below define which source wins which question. **Record this precedence on every ticket that carries design artifacts** (under Technical Approach or a dedicated `## Source Precedence` subsection) so the implementer doesn't reconcile silently.
-
-| Question | Authoritative source |
-|----------|---------------------|
-| Does this field exist? Is it required? Who can see/edit it? What validation applies? Permission rules, edge cases, data constraints? | **Description / PRD body** (business rules) |
-| What does it look like — layout, spacing, typography, color, iconography? | **Mocks (`ui-design`)** |
-| How does it flow — navigation, transitions, state changes, timing, empty/error/loading states? | **Prototypes (`ux-flow`)** |
-| Where does the data come from, what shape is it, what are the API contracts? | **`data` artifacts** |
-| Where does it run, who's on call, what's the dashboard? | **`ops` artifacts** |
-
-## 4. Cross-axis conflict handling
-
-Conflicts MUST be surfaced under `## Open Questions` on the affected ticket — never silently reconciled.
-
-- Mock shows a field the description doesn't mention → BLOCKER: "Figma shows field `X` not in PRD; confirm it exists, and if so add business rules (required/optional, validation, permissions)."
-- Description mandates behavior the prototype contradicts → BLOCKER: "PRD says Y, prototype shows Z; which is correct?"
-- Prototype shows a flow the mocks don't cover (e.g., an error state) → Note: "Error state flow from prototype; no mock exists. Use existing error component or request mock."
-- Multiple artifacts of the same domain disagree (two Figma links showing different layouts) → BLOCKER: list both, ask which is current.
-- Lovable output without a description covering business rules → BLOCKER: "Business rules missing. Lovable's embedded logic is not authoritative; PRD must explicitly state required fields, validation, permissions, and edge cases."
-
-## 5. Coverage smells
-
-Incomplete artifact sets are a common root cause of implementation drift. Surface these on the epic when extracting:
-
-- **Zero artifacts on a non-trivial PRD**: almost always an extraction bug, not a design decision. Say so explicitly.
-- **`ux-flow` present, `ui-design` absent**: flag "missing UI mocks". UI will be inferred from prototype frames — note that prototype styling is typically placeholder and must NOT be treated as visual source of truth.
-- **`ui-design` present, `ux-flow` absent**: flag "missing UX prototype". UX will be inferred from static mock states (empty/error/loading/hover) — any flow not explicitly depicted must be raised as a BLOCKER with recommendation + alternatives, not silently invented.
-
-## 6. Inheritance: epic → story → sub-task
-
-Artifacts attach as Jira remote links and propagate down the hierarchy.
-
-- **Epic**: gets EVERY artifact, regardless of domain. The epic is the canonical hub — anyone working on the epic or its descendants must reach the full set from one place. No filtering.
-- **Story**: inherits the artifacts whose domain matches its scope:
-
-  | Story type | Inherits domains |
-  |------------|------------------|
-  | Frontend / UI | `ui-design`, `ux-flow`, `reference` |
-  | Backend / API / data model | `data`, `reference` |
-  | Infrastructure | `ops`, `reference` |
-  | Mixed / setup ("X.0") | All domains |
-
-  When classification is ambiguous, err on the side of inclusion — a developer can ignore an extra link, but they can't follow one that wasn't attached.
-
-- **Sub-task**: inherits via the parent story link. Do NOT re-attach the same artifacts on every sub-task — that creates noise. Only attach an artifact directly on a sub-task when the sub-task depends on something the parent story doesn't (e.g., a sub-task spec'd from a specific Figma frame the broader story doesn't cite).
-
-## 7. Existing-component reuse (UI-touching tickets)
-
-Mocks define visual *intent*, not implementation shortcut. Every UI-touching ticket description must include:
-
-> Before implementing, identify the closest existing component in the codebase. Prefer reuse even if the mock specifies different styling — flag the design-vs-code divergence as a discussion item on this ticket rather than pixel-matching from scratch.
-
-If no existing component fits, building a new one is an explicit decision that must be recorded in the ticket (with rationale) before implementation. Lovable-generated components are never the reuse target — always use the project's own components.
-
-## 8. Preservation gate (run after creating tickets)
-
-Before declaring done, verify every extracted artifact is reachable from the created tickets.
-
-1. Build a preservation matrix: `artifact URL → [ticket keys that reference it]`.
-2. For every artifact:
-   - It MUST appear on the epic it belongs to (no exceptions).
-   - It SHOULD appear on at least one story whose scope matches its domain (except `reference`-domain artifacts, which may be epic-only if no story is domain-matched).
-3. Any artifact with zero references anywhere, or missing from its epic: FAIL LOUDLY — list the dropped artifacts with domain, title, and source page; surface to the human; re-attach before continuing.
-4. If classification looks misrouted (e.g., a Figma link landed on a backend story and nowhere else), surface the misroute and offer to re-propagate.
-
-Skipping this gate is the most common cause of silent artifact loss. Do not skip it.

package/plugins/src/base/skills/tracker-sync/SKILL.md

@@ -1,64 +0,0 @@
----
-name: tracker-sync
-description: "Vendor-neutral wrapper for posting milestone updates to the linked ticket/issue. Reads `tracker` from .lisa.config.json (default: jira) and dispatches to lisa:jira-sync, lisa:github-sync, or lisa:linear-sync. Posts at: plan created, implementation in progress, PR ready, PR merged. Suggests (never auto-transitions) the next status."
-allowed-tools: ["Skill", "Bash", "Read"]
----
-
-# Tracker Sync: $ARGUMENTS
-
-Thin dispatcher. Resolves the configured destination tracker and delegates to the matching vendor sync skill.
-
-See the `config-resolution` rule for configuration and dispatch table.
-
-## Workflow
-
-1. Resolve tracker config (same logic as `lisa:tracker-write`).
-2. Dispatch:
-   - `jira` → invoke `lisa:jira-sync` with `$ARGUMENTS` verbatim.
-   - `github` → invoke `lisa:github-sync` with `$ARGUMENTS` verbatim.
-   - `linear` → invoke `lisa:linear-sync` with `$ARGUMENTS` verbatim.
-   - Anything else → stop and report `"Unknown tracker '<value>' in .lisa.config.json. Expected 'jira', 'github', or 'linear'."`
-3. Pass through the output.
-
-`$ARGUMENTS` is forwarded verbatim, including the optional `--rollup` flag (see "Parent status rollup" below), `--update-label`, `pr_url=<url>`, and `merge_sha=<sha>`. The shim never interprets these — the vendor skill does.
-
-If `$ARGUMENTS` is empty, all vendor skills auto-detect a ticket reference from the active plan file (most recently modified `.md` in `plans/`).
-
-## Parent status rollup (`--rollup`)
-
-When the caller passes `--rollup` after the milestone, the dispatch target additionally **derives the parent/container's lifecycle state from its children** instead of acting on the work item directly. This is the vendor-neutral implementation of the **Parent status rollup (the state machine)** section of the `leaf-only-lifecycle` rule — cite that rule, do not restate the policy here. The shim is dispatch only; the rollup mechanics live in the vendor sync skill (`lisa:github-sync`, `lisa:jira-sync`, `lisa:linear-sync`), which resolves child membership via its `*-read-*` skill and evaluates the state machine below.
-
-The state machine (first match wins, evaluated over the **required** leaves only, on the env ladder `in-progress < dev < staging < production` — the ordered keys of the project's env-keyed `done` map):
-
-| If among the required leaves… | …the parent rolls up to | Role |
-|---|---|---|
-| any leaf is **blocked** | blocked / attention-needed | `blocked` |
-| else **every** required leaf has shipped to some env (each at a `done`-map value) | the **least-advanced** env among them | `done[min-env]` (terminal `done` at production) |
-| else any leaf has **started** (claimed or in review, or shipped while a sibling has not) | active / in-progress | `claimed` (or `review` where supported) |
-| else (leaves exist, none started) | unchanged | — |
-
-- **Blocked dominates** — one blocked leaf surfaces blocked on the parent even while others progress.
-- **Least-advanced env wins** — a parent reaches an env only once all required leaves have reached at least that env (all `On Stg` → `On Stg`; mixed dev/staging → the dev value). Native terminal closure fires only at the production `done`, never at an intermediate env.
-- **The parent never carries `ready`** — `ready` is a human "claim this leaf" signal; rollup only moves a parent between non-ready container states.
-- **Rollup is recursive** — an Epic rolls up from its Stories, each of which rolls up from its own leaves. Evaluate bottom-up.
-- **The env rungs are the configured env-keyed `done`** — multi-env projects roll up to whichever `done` value (including intermediate `On Dev`/`On Stg`) their leaves have collectively reached (see `config-resolution` "Env-keyed `done`"). **Single-environment collapse (this repo):** `deploy.branches` declares only `production: main`, so `done` is a single value, the only env rung is production, and the GitHub build lifecycle collapses to `ready → claimed (in-progress) → done`; the rollup terminal is simply `done` (or the PRD-side `ticketed` for PRD containers), with **no** dev/staging promotion hops and **no** env-keyed multi-entry chain to resolve.
-
-**Safe-by-default when not yet supported.** A vendor sync path that has not implemented native rollup MUST be a documented no-op that surfaces the derived state as a suggestion/comment rather than guessing a transition — never an unsafe default. Without `--rollup`, the sync skills behave exactly as before (milestone comment on the work item; no parent derivation).
-
-## Pull request backlinking
-
-When `$ARGUMENTS` includes `pr_url=<url>` with milestone `pr-ready` or `pr-merged`, the dispatch target must ensure ticket -> PR linkage, not just post a generic progress note:
-
-1. Prefer the provider's native development-link primitive when Lisa can write and verify it for that provider.
-2. Verify the native link using the provider read surface when available.
-3. If the native link is unavailable, unconfigured, cross-system, or cannot be verified, create or update one managed backlink comment on the work item containing the PR URL and current milestone.
-4. Keep the comment idempotent by using a stable marker such as `[lisa-pr-link]`; reruns update or skip the existing managed comment rather than appending duplicates.
-
-This is the reverse half of `lisa:git-submit-pr`'s PR body linkage. A PR that mentions a ticket is not considered fully synced until the ticket also has either a verified native PR link or the managed fallback comment.
-
-## Rules
-
-- Idempotent updates — running sync at the same milestone twice should not produce duplicate comments. Vendor skills enforce this.
-- Never auto-transition the underlying state. Linear's label-based transition (`status:*`) is the canonical signal and is updated only when the caller passes `--update-label`. Native states stay as suggestions.
-- Parent rollup derives state from children per the `leaf-only-lifecycle` rule; it never sets a parent to `ready` and never resolves a dev/staging `done` in this single-environment repo.
-- Pull request backlinks are mandatory when `pr_url=<url>` is present: native first, managed-comment fallback, never silently dropped.