codyswanngt/lisa-ticket-triage

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 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:

### 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:

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:

### 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:

| 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:

## 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:

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