@codyswann/lisa 4.74.8 → 4.75.0

package/plugins/lisa-devin/skills/lisa-ticket-triage/SKILL.md

@@ -0,0 +1,214 @@
+---
+name: lisa-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, plans verification methodology, and — via lisa-rework-triage in Phase 2.5 — detects rework bounced back from QA/staging and classifies why the previous agent attempt failed. 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`)**: clear-check each blocker **by containment, per the `blocker-containment` rule** — cite that slug for the full contract rather than restating it. A blocker is satisfied when its merged PRs are ancestors of the branch this ticket will be built from (resolved from this ticket's `## Target Backend Environment` through `.lisa.config.json` `deploy.branches`, never from a rendered `Branch Plan`), or when the rule's narrow no-code carve-out or human override applies. **`Done` is not the test** — a state name holds in a single-trunk workflow and comes apart in a promotion workflow, and requiring the production terminal strands every dependent behind work already merged where this ticket needs it. This is the same predicate the `DUPLICATE_ALREADY_FIXED` bullet below already requires ("present on the relevant base branch… never from a name/label match alone"), applied here too. For a blocker that is not contained, or where containment is not computable, raise an ambiguity naming the rule's reason key: "Blocker {KEY} is not on {BRANCH} ({REASON}) — work cannot meaningfully start." That 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 2.5 -- Rework Detection & Failure Classification
+
+Invoke `lisa-rework-triage` with the context bundle. It detects whether this ticket is
+**rework** — previously implemented work bounced back from QA/staging — and, when it is,
+classifies why the previous agent attempt failed (decomposition infidelity, PRD defect,
+missing tool access, implementation defect, environment/data, verification gap), posts the
+`[lisa-rework-triage]` comment, and routes the cause to its hardening destination (upstream
+Lisa issue, provisioning ticket, or PRD defect flag). See that skill for the taxonomy,
+evidence requirements, and routing table.
+
+- `NOT_REWORK` → proceed to Phase 3; nothing to carry forward.
+- `REWORK_CLASSIFIED` / `ALREADY_TRIAGED` → carry the classification into the output
+  structure (see below) and proceed to Phase 3 — a classified rework still gets fixed;
+  hardening runs alongside the fix, never in front of it. Exception: a `missing-tool-access`
+  cause whose gap is **still present** must be raised as a Phase 3 ambiguity ("prior attempt
+  lacked <tool>; it is still unavailable"), which blocks per the normal rules.
+
+## 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.
+
+### Prescribed controls must be reachable
+
+When the ticket pins an **existing** test as a red-before-green control — "that test must go red", "fails before the fix and passes after", "if it still passes the fix did nothing" — apply the `control-reachability` rule before accepting it. The stopping rule is only valid if the test's fixture exercises the path the change touches; when it does not, the test stays green for an unrelated reason and the ticket instructs the implementer to revert a correct fix.
+
+- Confirm the ticket carries the `[CONTROL: <test-identifier> | reaches: <input-or-field>]` marker gate S20 requires, and that the named input is actually present in that test's fixture. Verify it in the codebase — this is a triage step precisely because triage is the last point before an implementer starts trusting it.
+- A named control with no reachability declaration, or one whose declared input is absent from the fixture, is an **Ambiguity** finding under Phase 3, not a pass. Report it with the specific input the fixture would need, or the recommendation to specify a new test instead.
+- A ticket that introduces a **new** test rather than pinning an existing one carries no such obligation. Do not raise a finding on this basis.
+
+## 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."]
+
+### Rework Classification
+[Phase 2.5 verdict block from lisa-rework-triage, or "Not rework (first attempt)."]
+
+## 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/lisa-devin/skills/lisa-track/SKILL.md

@@ -0,0 +1,129 @@
+---
+name: lisa-track
+description: "Resolves exactly one live configured-tracker leaf for durable project work, claims it idempotently, and persists its canonical reference in worktree-local state. Accepts an existing Jira/GitHub/Linear ref, a spec file, or plain text. Also accepts human_gate: <why a human must judge this first>, which files the leaf held — outside the build-ready lane, never claimed — instead of build-ready. Use directly to mention/create the related ticket, and as lisa-implement's mandatory input gate."
+allowed-tools: ["Skill", "Bash", "Read"]
+---
+
+# Track Work: $ARGUMENTS
+
+## Human-gate release authorization
+
+A release requires a trusted human author, not just matching comment text. Follow
+`ready-role-filing` — **Human-gate release authorization**: preserve tracker-supplied comment
+author IDs and bot metadata, resolve `trustedHumanActorIds` only from an explicit user instruction
+or existing human-authored trusted project policy, and pass it with structured `comments` to every
+hold classifier, reconciliation, normalization and release planner. Never derive trust from the
+comment body, a display name, the actor's own assertion, or an automation posting on its own behalf.
+Missing policy, missing/unreadable author identity, raw body strings, untrusted actors and known bots
+cannot discharge a hold. Keep the item held and report the missing authorization; do not silently
+replace these inputs with an empty history or an inferred allowlist. Authorized matching releases
+continue through the existing path and never override an independently declared caller hold.
+
+
+Establish the tracked-work invariant before any durable project mutation. Discussion and read-only orientation may proceed without this skill; code, configuration, documentation, research artifacts, plans, investigation findings, tests, commits, and pull requests may not.
+
+For accepted work this flow must return exactly one canonical `(tracker_provider, work_item_ref)` pair or fail closed. A declined incidental finding returns only its reason and authorizes no durable implementation. It never returns an unvalidated textual guess.
+
+## Worth doing
+
+Before filing, promoting, or claiming an incidental finding, ask whether the expected benefit justifies implementation, verification, maintenance, CI, and operator attention. Use the evidence already available; no numeric score, new tracking system, or speculative audit is required.
+
+- **Act** on concrete delivery failures, incorrect results, credible material security or data-loss risks, and recurring friction whose repair is worth its cost. A small fix can have a large consequence; security need not wait for an incident.
+- **Bundle** related small repairs when one bounded maintenance task is worth doing. Reuse an existing relevant item where possible. Do not expand unrelated work or create one ticket per wording fix.
+- **Decline** cosmetic preferences, speculative edge cases, duplicate controls, or changes whose likely benefit is smaller than their ongoing cost. Acceptable as-is is a valid engineering decision. Say why briefly in the current report, review, or issue; do not create a ticket, ledger entry, new rule, or human gate merely to record a declined observation.
+
+A reproducible imperfection proves that something happens, not that it deserves factory capacity. A complete specification establishes buildability, not value. Missing enforcement or test coverage alone does not justify new machinery; name the required behavior or credible consequence at risk. Honor explicit user requests, accepted product requirements, and material safety obligations. This rule cannot silently cancel those commitments or excuse failing required checks.
+
+## Prefer less machinery
+
+Start with the smallest sufficient correction at the owning component. Consider removing or consolidating redundant machinery before adding a hook, workflow, abstraction, registry, or test framework. Preserve required behavior and protection, and verify the consequence of the change. An isolated failure does not automatically justify a permanent control for every future session.
+
+For an existing incidental item, read its discussion, linked PRs and dependencies before declining. Close as **Not planned** (configured Jira/Linear equivalent), give the reason, and remove active lifecycle labels. Preserve human holds and committed scope unless cancellation is authorized; resolve effects on active PRs and dependent delivery first. Before re-filing, search open AND closed issues, read legacy unmarked matches, and require materially changed consequences that address the earlier reason. A later observation of the same accepted limitation is insufficient.
+
+## Phase 1 — Resolve tracker and classify input
+
+1. Resolve merged `.lisa.config.local.json` over `.lisa.config.json` exactly as `lisa-tracker-read` / `lisa-tracker-write` do. Missing, unknown, or incomplete tracker configuration is a blocking error.
+2. Classify `$ARGUMENTS` as exactly one of:
+   - an explicit reference matching the configured tracker (`KEY-123`, `org/repo#123` or issue URL, Linear team identifier);
+   - an existing file path containing a specification (read the entire file, without offset/limit);
+   - plain-text work description.
+3. Detect the caller's readiness declaration, which is orthogonal to the classification above. Absent any declaration this is the default build-ready path. A caller deliberately holding the work for a pending human product call passes `human_gate: "<why a human must judge this first>"`; the two declarations are mutually exclusive and a `human_gate` present but empty is a blocking error, because an unexplained hold is indistinguishable from an accident.
+4. Preserve the full resolved specification for the caller. Do not treat a ticket-like token for a different provider/project as plain text; report the mismatch.
+
+## Phase 2 — Resolve one live work item
+
+### Explicit reference
+
+Invoke `lisa-tracker-read <ref>` and require a live result from the configured project. Reject nonexistent, inaccessible, closed/resolved/terminal, wrong-project, wrong-repository, or container items. Read the returned body, labels and all comments; Phase 3 uses the shared hold classifier so a historical `[lisa-human-gate]` marker with a matching release is not mistaken for an active hold. This live read is mandatory even if caller context already includes ticket text.
+
+### File or plain text
+
+For incidental findings, apply `do-it-now` before resolving a new leaf. If the finding is declined, return the reason without creating or claiming anything; durable implementation does not start. Explicit user requests and accepted requirements remain in scope.
+
+Search conservatively before creating:
+
+1. Normalize the requested outcome and derive a short keyword set; never search with the whole prompt or secrets.
+2. Search open AND closed items in the configured project and current repository through the configured provider's documented read surface. Closed items supply decision history, never an active binding:
+   - GitHub: `gh issue list --repo <org>/<repo> --state all --search "<keywords> in:title,body"`.
+   - Jira: `lisa-atlassian-access operation: search-issues` with project-scoped JQL and no status filter.
+   - Linear: `lisa-linear-access operation: list-issues` scoped to the configured team/workspace and including all states.
+3. Treat search results as candidates, never proof. Live-read each plausible candidate and its discussion through `lisa-tracker-read`. Apply `rejection-detection` to prior **Not planned** decisions, including legacy unmarked matches, before creating: suppress the same accepted limitation unless materially changed post-decline evidence addresses its reason, with the required token and acknowledgment in any new item. A completed fix may have a verified regression. For active binding, discard terminal, container, blocked, held-by-gate, cross-repo, and materially different outcomes. A held candidate is never reused: attaching new work to an item a human is holding is how the hold gets spent.
+4. Reuse only when **exactly one** live leaf is a high-confidence semantic match for the same requested outcome and repository. A shared keyword or similar title is not enough. Record the search queries, candidates, and rejection reasons in the returned resolution evidence.
+5. If there is no unique high-confidence match (zero or ambiguous candidates), create **exactly one** item by invoking `lisa-tracker-write` once. Synthesize one complete single-repository leaf (`Bug`, `Task`, `Sub-task`, or `Improvement`, never Epic/container) with the writer's required three-audience body, Gherkin acceptance criteria, repository, target environment, relationship search, and executable Validation Journey. Pass `build_ready: true` unless the caller declared a `human_gate`, in which case pass that `human_gate: "<why>"` reason instead of `build_ready: true` and never alongside it, so the writer leaves the leaf in the tracker's default backlog role — out of the lane build-intake claims from — and stamps the hold on the body as a `[lisa-human-gate]` marker. Discarding a declared gate and filing build-ready anyway is the one outcome this step must never produce. Do not create placeholder/thin tickets, do not create a hierarchy, and do not retry creation by making another item if validation fails; repair the proposed spec and retry the same writer operation only if the vendor contract supports idempotent reuse.
+6. Live-read the writer's canonical returned reference with `lisa-tracker-read`. A create response without a verified live leaf is failure.
+
+This is intentionally conservative: ambiguity creates one explicit work item instead of silently attaching work to the wrong existing item. Across the entire invocation, at most one new work item may be created.
+
+## Phase 3 — Claim and bind
+
+The work item is **held** when the caller declared a `human_gate`, independently of any item history,
+or `classifyReadyCandidate({ labels, body, comments, trustedHumanActorIds, humanNeededLabel })` from the shipped
+`scripts/intake-blocker-reprobe.mjs` returns `claimable: false`. Pass the complete live comment
+history so a matching `[lisa-human-gate-release]` discharges the historical body marker. Never
+reimplement heldness as a substring test or as the negation of `planHumanGateRelease().released`:
+that planner also returns `released: false` for an item that was never held. Missing comments fail
+closed for a hold; never infer release from a missing label.
+
+A held item stops the flow here, whatever roles or labels it carries. Do not invoke
+`lisa-tracker-claim`, write the worktree binding, or begin durable project work. Return
+`claim_outcome: held-by-gate` and `binding_outcome: skipped-human-gate`, name the signal in `held_by`
+and carry its reason verbatim in `gate_reason` (null for a keyless hold), then stop.
+
+For a discharged item, call
+`planHumanGateRelease({ labels, body, comments, trustedHumanActorIds, humanNeededLabel, readyLabel, lifecycleLabels, alreadyNotified })`
+and apply only the returned actions before claiming. Keep the body marker as history; a release
+never overrides a new caller-declared hold or another eligibility check.
+
+Otherwise:
+
+1. Invoke `lisa-tracker-claim <canonical-ref>`. Require its post-read verified `claim_outcome: claimed|reused`; no binding may be written after a failed/unverified claim.
+2. Persist only the canonical reference in worktree-local machine state:
+
+   ```bash
+   node scripts/lisa-work-item.mjs link <canonical-ref>
+   ```
+
+3. Read the binding back through `node scripts/lisa-work-item.mjs current` and require it to equal the canonical reference. If binding fails, stop before durable project work.
+   - A detached-HEAD worktree is valid at this stage: the binding records `branch: null` as a pending state. Create the feature branch only after the gate succeeds, then run `node scripts/lisa-work-item.mjs attach-branch`. Commit preparation and validation fail closed until that attachment succeeds.
+4. **Ignore guard before any write.** A host can receive these skills before its shipped `.gitignore` entry, so prove the path is ignored first, from the worktree root: `git check-ignore -q .lisa/work-item-context.md || printf '%s\n' '.lisa/work-item-context.md' >> "$(git rev-parse --git-common-dir)/info/exclude"`, then re-run `git check-ignore -q .lisa/work-item-context.md`. If it is still not ignored, stop and report — do not write the bundle. If an `.easignore` exists and `grep -qxF '.lisa/work-item-context.md' .easignore` fails, stop and report instead of writing: EAS uploads read `.easignore`, which is derived from `.gitignore`, not from `info/exclude`. Then write the full resolved work-item context — the live vendor read bundle, unedited, every comment included — to the worktree-local, git-ignored `<worktree root>/.lisa/work-item-context.md`, then return this structured result (the file is the context; a summary in the reply never substitutes for it). When a `caller_bundle_path` was forwarded for this work item and the file already exists, do not overwrite it — it holds the caller's bundle (or a previous run's) and is left for the resolver step. Otherwise this is the first write; when `lisa-implement` forwarded a `caller_bundle_path`, its resolver step then keeps the bundle at that path as the base and appends only what this live read adds, and in every case finishes it with the `## Comment inventory` section:
+
+   ```text
+   tracker_provider: jira|github|linear
+   work_item_ref: <canonical-ref>
+   resolution_outcome: explicit|reused|created
+   readiness_declaration: build-ready|human-gate
+   held_by: none|caller-declaration|item-marker
+   gate_reason: <why a human must judge this first>|null
+   claim_outcome: claimed|reused|held-by-gate
+   binding_outcome: verified|skipped-human-gate
+   work_item_context: <absolute path to .lisa/work-item-context.md>
+   ```
+
+## Lifecycle
+
+- The binding is worktree-local, uncommitted machine state. Never write it into tracked source files.
+- Branch setup may call `node scripts/lisa-work-item.mjs attach-branch` after the feature branch exists.
+- Keep the binding across ordinary interruptions and blocked outcomes so resumed work remains attributable.
+- Clear it only after true terminal completion — merged, deployed/verified where required, tracker evidence/backlink complete, and the work item terminal — by running `node scripts/lisa-work-item.mjs clear` and verifying no current binding remains.
+- A held filing writes no binding at all, so there is nothing to clear. The gate is released by a human decision, but not by a human edit: the person records the decision as a comment on the leaf beginning `[lisa-human-gate-release]` and, for a keyed hold, repeating its `reason=` verbatim. For a keyless hold, the comment begins `[lisa-human-gate-release]` without a `reason=` field. The next intake sweep takes the human-needed marker off and puts the leaf back in the build-ready role on its own (`planHumanGateRelease` in `scripts/intake-blocker-reprobe.mjs`). A later invocation then resolves it on the ordinary path. **Do not tell anyone to delete the marker from the description, and do not delete it here.** The only description write available is a whole-body replacement, so clearing one line means rewriting the entire record — which is why, before this, the rational move was always to leave a hold in place and answered holds only accumulated (CodySwannGT/lisa#3852). The hold stays in the body as history; the release is recorded beside it.
+- A tracker outage, invalid item, failed claim, or failed binding blocks durable work. Never continue untracked and never ask a Git hook to create the item.

package/plugins/lisa-devin/skills/lisa-tracker-add-journey/SKILL.md

@@ -0,0 +1,28 @@
+---
+name: lisa-tracker-add-journey
+description: "Vendor-neutral wrapper for appending a Validation Journey section to an existing ticket/issue. Reads the required `tracker` from .lisa.config.json 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:
+   - Missing / empty → stop and report `"No tracker configured in .lisa.config.json. Run /lisa:setup:jira, /lisa:setup:github, or /lisa:setup:linear first."`
+   - `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 typed `[EVIDENCE: <artifact-type>: <name>]` markers per the `verification` rule taxonomy). 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).
+- A cross-work-item pointer uses `[EVIDENCE-REF: <work-item-ref> | <artifact-type>: <kebab-case-name>]`. It is non-claiming and never replaces a runtime-changing leaf's local S14 marker.
+- If the ticket already has a Validation Journey with at least one local typed `[EVIDENCE: ...]` marker, the vendor skill reports it and stops. A reference-only journey is incomplete; the vendor skill preserves its prose and appends the missing local evidence. This shim does not retry.

package/plugins/lisa-devin/skills/lisa-tracker-build-intake/SKILL.md

@@ -0,0 +1,134 @@
+---
+name: lisa-tracker-build-intake
+description: "Vendor-neutral wrapper for the build-queue scanner. Reads the required `tracker` from .lisa.config.json 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 configured `ready` workflow state). 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
+
+## Human-gate release authorization
+
+A release requires a trusted human author, not just matching comment text. Follow
+`ready-role-filing` — **Human-gate release authorization**: preserve tracker-supplied comment
+author IDs and bot metadata, resolve `trustedHumanActorIds` only from an explicit user instruction
+or existing human-authored trusted project policy, and pass it with structured `comments` to every
+hold classifier, reconciliation, normalization and release planner. Never derive trust from the
+comment body, a display name, the actor's own assertion, or an automation posting on its own behalf.
+Missing policy, missing/unreadable author identity, raw body strings, untrusted actors and known bots
+cannot discharge a hold. Keep the item held and report the missing authorization; do not silently
+replace these inputs with an empty history or an inferred allowlist. Authorized matching releases
+continue through the existing path and never override an independently declared caller hold.
+
+
+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:
+   - Missing / empty → stop and report `"No tracker configured in .lisa.config.json. Run /lisa:setup:jira, /lisa:setup:github, or /lisa:setup:linear first."`
+   - `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.
+
+## Pre-work denominator contract (forwarded to every vendor)
+
+Also part of the build-intake API, and the reason a dry queue can be believed. Two obligations,
+uniform across `jira`, `github`, and `linear`:
+
+1. **Sweep every pre-work lane by its machine-readable category, never by a roster of lane names.**
+   No tracker has a `blocked` category: Linear models a `Blocked` state as `unstarted`, JIRA models
+   a `Blocked` status under `To Do`, and GitHub has no category at all, so its lanes come from
+   configured roles. In every case a `Blocked` lane is *pre-work* — items that were never started,
+   each carrying a written blocker. Keying selection on names omits it silently.
+2. **A `nothing-needed` run states its denominator** — which lanes were swept, how many rows each
+   held, and the total open. This is enforced, not requested: `automation-run-record.mjs` refuses a
+   `nothing-needed` row for `intake-tickets` without a `--denominator`.
+
+Shared helpers own both, so the vocabulary cannot drift per vendor:
+`scripts/intake-prework-denominator.mjs` (`buildIntakeDenominator`, `summarizeDryLane`) and
+`scripts/intake-blocker-reprobe.mjs` (`classifyPreWorkCandidate`, `formatReprobeNote`). The
+blocker re-probe carries an absolute human gate: an item carrying the configured human-needed label
+or a `[lisa-human-gate]` marker is never auto-selected, whatever a probe returns.
+
+That gate has an inverse, and it is forwarded identically: a hold ends when a
+`[lisa-human-gate-release]` comment naming the same `reason=` is recorded on the item by an authorized human. Every vendor
+scanner passes the item's `comments` into the gate helpers so the discharge is visible, and calls
+`planHumanGateRelease(...)` to take the marker off and put the item back in the queue. **No vendor
+scanner clears a hold by editing the description** — the only body write any of them has is a
+whole-body replacement, so a release that went through the description would risk destroying the
+record it was releasing, which is why holds accumulated with no way out (CodySwannGT/lisa#3852).
+The hold note stays in the description as history and the release sits beside it as a comment.
+
+Measured: sweeping one team by lane name saw 39 of 343 open rows; by category it sees 100. The
+61-row gap produced 31 consecutive false "dry lane" cycles, every record honest and every
+conclusion wrong (#2657).
+
+## 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`.
+- **Claim-time guards, every vendor.** Per the `claim-time-guards` rule, each vendor scanner runs both guards inside its Phase 3b before the claim transition: an item whose own key already appears in git history or an open/merged PR routes to **verify-and-close** rather than being built twice, and the **`two-failed-attempts`** valve moves an item with two counting `[lisa-build-attempt]` markers to the configured blocked role and stops the cycle. A marker counts only when it is `measures=work` and was recorded after the item most recently entered the ready lane — every vendor applies both filters, reading lane history from the substrate that already exposes it (GitHub label events, JIRA `changelog`, Linear `history`). This shim does not re-implement either guard; it forwards the contract so behavior never drifts by tracker.
+- Never run two intake cycles concurrently against overlapping queues — the scheduling layer is responsible for serialization.

package/plugins/lisa-devin/skills/lisa-tracker-claim/SKILL.md

@@ -0,0 +1,35 @@
+---
+name: lisa-tracker-claim
+description: "Vendor-neutral dispatcher for idempotently claiming one already live-validated leaf work item. Reads the required tracker from .lisa.config.json and delegates to lisa-jira-claim, lisa-github-claim, or lisa-linear-claim. The vendor skill owns the post-read leaf/open guard, ready-to-claimed mutation, attributable assignment, and post-write verification."
+allowed-tools: ["Skill", "Bash", "Read"]
+---
+
+# Tracker Claim: $ARGUMENTS
+
+Thin dispatcher. `$ARGUMENTS` must contain exactly one canonical work-item reference. The caller must have already fetched it with `lisa-tracker-read`; each vendor claim skill independently repeats the live read before mutation and verifies the claim afterward so stale caller context cannot authorize a write.
+
+## Workflow
+
+1. Resolve merged tracker config exactly as `lisa-tracker-write` does:
+
+   ```bash
+   local_tracker=$(jq -r '.tracker // empty' .lisa.config.local.json 2>/dev/null)
+   global_tracker=$(jq -r '.tracker // empty' .lisa.config.json 2>/dev/null)
+   tracker="${local_tracker:-$global_tracker}"
+   ```
+
+2. Dispatch without changing `$ARGUMENTS`:
+   - Missing / empty -> stop and report `"No tracker configured in .lisa.config.json. Run /lisa:setup:jira, /lisa:setup:github, or /lisa:setup:linear first."`
+   - `jira` -> invoke `lisa-jira-claim`.
+   - `github` -> invoke `lisa-github-claim`.
+   - `linear` -> invoke `lisa-linear-claim`.
+   - Anything else -> stop and report `"Unknown tracker '<value>' in .lisa.config.json. Expected 'jira', 'github', or 'linear'."`
+3. Return the vendor result unchanged. Success must include `tracker_provider`, canonical `work_item_ref`, `claim_outcome: claimed|reused`, and the post-write live-read evidence.
+
+## Contract
+
+- Claim only an open/unresolved, current-repository leaf per `leaf-only-lifecycle` and `repo-scope-split`. Never claim a container, terminal item, inaccessible item, or item from a different configured project.
+- Preserve later active lifecycle states. If the item is already in the configured claimed role or a later non-terminal role, return `reused`; never move it backward.
+- A fresh claim uses the same idempotency lock as the three build-intake Phase 3b flows: move configured ready to configured claimed, or place an unlaned backlog leaf directly in claimed; assign to the authenticated user only when unassigned; never replace an existing owner.
+- Fail closed if the mutation or post-write read cannot prove the claimed-or-later state. A tracker outage is a blocker, not permission to work untracked.
+- This skill claims existing work only. It never creates a ticket and never writes the worktree binding.

package/plugins/lisa-devin/skills/lisa-tracker-create/SKILL.md

@@ -0,0 +1,28 @@
+---
+name: lisa-tracker-create
+description: "Vendor-neutral wrapper for creating tickets/issues from code files or descriptions. Reads the required `tracker` from .lisa.config.json 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:
+   - Missing / empty → stop and report `"No tracker configured in .lisa.config.json. Run /lisa:setup:jira, /lisa:setup:github, or /lisa:setup:linear first."`
+   - `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.
+- **Declare readiness on every leaf write.** Per the `ready-role-filing` rule an omitted `build_ready` is **not build-ready** on any tracker, so pass `build_ready: true` on each Sub-task (the leaf work units this skill plans) and never on the Epic or Stories, which are containers per `leaf-only-lifecycle`. A leaf that is deliberately held instead passes `human_gate: "<why a human must judge this first>"`. Filing a leaf with neither is an incomplete handoff and `lisa-tracker-write` rejects it.
+- This shim is for ad-hoc creation from code files / descriptions. PRD-driven creation goes through the `*-to-tracker` skills (notion / confluence / linear / github).