# Lisa Tracker Evidence > Vendor-neutral wrapper for posting verification evidence. Reads the required `tracker` from .lisa.config.json 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. - Skill: `codyswanngt/lisa-tracker-evidence-2` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add codyswanngt/lisa-tracker-evidence-2` - Raw SKILL.md: https://api.skillmd.com/api/skills/codyswanngt/lisa-tracker-evidence-2/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Productivity - Author: codyswanngt (https://skillmd.com/u/codyswanngt) - Updated: 2026-09-21 - Page: https://skillmd.com/skills/codyswanngt/lisa-tracker-evidence-2 --- # 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. Missing / empty → stop and report `"No tracker configured in .lisa.config.json. Run /lisa:setup:jira, /lisa:setup:github, or /lisa:setup:linear first."` 3. Before dispatching, update the generated evidence artifact through `lisa-usage-accounting` so the comment body / PR evidence section carries a direct `lisa-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. 4. Dispatch: - `jira` → invoke `lisa-jira-evidence` with `$ARGUMENTS` verbatim. Arg shape: ` `. - `github` → invoke `lisa-github-evidence` with `$ARGUMENTS` verbatim. Arg shape: ` ` where `ISSUE_REF` is `org/repo#` or a GitHub issue URL. - `linear` → invoke `lisa-linear-evidence` with `$ARGUMENTS` verbatim. Arg shape: ` ` where `IDENTIFIER` is a Linear Issue identifier (e.g., `ENG-123`). - Anything else → stop and report `"Unknown tracker '' in .lisa.config.json. Expected 'jira', 'github', or 'linear'."` 5. 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 --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.