--- name: smdg-jira-fix-issue description: Investigate a QA bug ticket end-to-end — read the Jira ticket, reproduce the issue in the environment, trace the failure to its exact file:line root cause in source, and classify it as a UI bug, Backend bug, Contract/Schema Mismatch, or Data/Environment Issue. Use when the user provides a Jira ticket link and wants it investigated, or invoke directly with /smdg-jira-fix-issue . argument-hint: [jira-ticket-url] --- The user wants to investigate this bug ticket: $ARGUMENTS Before doing anything else, ask the user simple questions in plain chat (no command line, no jargon — this must be usable by non-technical team members): 1. "Bạn muốn tôi đọc Jira ticket bằng cách nào: (a) mở trình duyệt và tự đăng nhập mỗi lần, hay (b) qua Jira MCP — chỉ cần đăng nhập một lần (OAuth), các lần sau tự nhớ, không cần đăng nhập lại trừ khi phiên hết hạn?" — map the answer to `mode: browser` or `mode: mcp`. If unclear, ask again in one short follow-up rather than guessing. 2. If `mode: browser`: "Which browser should I use to open the ticket: Chrome, Firefox, or Edge?" — skip this question entirely when `mode: mcp` (nothing to choose, there's no browser involved in reading the ticket). 3. "And which browser should I use to reproduce it on the test environment?" — always ask this one regardless of `mode`; reproduction is a separate step that still needs real browser automation either way. 4. "Bạn đã có sẵn evidence đã tải xuống cho ticket này chưa — ví dụ file Excel dùng để mass-upload, file JSON export từ OData, log, hoặc ảnh chụp — ở một thư mục trên máy? Nếu có, cho tôi biết đường dẫn thư mục đó." — always ask this one too, independent of the mode/browser questions above. Map the answer to `local_evidence_path` (a folder path) or `local_evidence_path: none` if the user has nothing to offer. Wait for the user's answer to each before proceeding. Accept casual answers ("chrome", "the first one", "let's do firefox", "mcp", "qua MCP đi", "không có", a pasted folder path) and map them to the right value. If an answer is unclear, ask again in one short follow-up rather than guessing. Once everything needed is known: 0. If `mode: mcp`, proactively check — before invoking `smdg-jira-fetcher` at all — whether `mcp__smdg-atlassian__getJiraIssue` is actually available to you right now (e.g. via ToolSearch, or a system reminder stating `smdg-atlassian` still requires authentication). If it is not available: tell the user directly, do not delegate this check to the fetcher — "Trước khi đọc ticket qua Jira MCP, bạn cần chạy `claude mcp login smdg-atlassian` trong một cửa sổ terminal (không phải nhắn tôi làm việc này) — lệnh này tự mở trình duyệt và tự bắt kết quả đăng nhập, không cần dán link nào cả. Xong thì báo lại để tôi tiếp tục." Wait for their confirmation, then re-check tool availability before proceeding to step 1. This avoids wasting a fetcher run on a doomed-to-fail attempt, and avoids the fetcher ever needing to attempt its own in-tool OAuth handshake (which cannot catch a browser redirect from a background context — see `smdg-jira-fetcher`'s own instructions). 1. Invoke the `smdg-jira-fetcher` subagent. In its task prompt, explicitly state the reading mode: "Use `mode: mcp` for this run" or "Use `mode: browser` for this run, with the browser" (substituting the user's answer). If `local_evidence_path` was given (not `none`), also tell it: "The user has local evidence at `` — catalog it into `ticket-summary.md` per your local-evidence-folder step." 2. Check its reported outcome — this, not just the chat reply, is the authoritative outcome: - **Missing ticket information** (environment URL, credentials, or steps to reproduce): stop and relay its question to the user verbatim. Do not guess on its behalf. Once the user answers, invoke `smdg-jira-fetcher` again for the same ticket and mode, explicitly passing along the user's answer and instructing it to merge it into `ticket-summary.md` (with provenance) and re-run its completeness check — don't forward the answer straight to the reproducer yourself. Repeat this loop until the fetcher reports everything is confirmed. - **`mode: mcp` not yet authenticated** (a distinct blocker from missing ticket info — don't conflate the two loops): relay its exact instruction to the user (run `claude mcp login smdg-atlassian`, or `/mcp` inside a Claude Code session), wait for them to confirm they've done it, then re-invoke the fetcher for the same ticket and mode. There's no ticket field being supplied here, so don't route this through the merge-into-ticket-summary logic above. 3. Once environment/credentials/steps are confirmed **or** a `local_evidence_path` was given (a local evidence folder can substitute for live environment access — see `smdg-jira-reproducer`'s own step 1), invoke the `smdg-jira-reproducer` subagent. In its task prompt, explicitly state: "Use the browser for this run" (substituting the user's test-environment browser answer — reproduction always uses real browser automation, regardless of which mode was used to read the ticket), and if `local_evidence_path` was given, also: "Local evidence folder at `` — check it per your step 1 before/alongside live reproduction." 4. Check its `reproduction-findings.md` for the `## Failure Signature` section and its `reproduced` field — this, not just the chat reply, is the authoritative outcome: - **If the reproducer reports its Write call was blocked** (a known harness restriction can reject subagent writes to certain filenames): it will instead return the full file content verbatim in its chat reply, clearly labeled as blocked-from-disk. In that case, write `.claude/evidence//reproduction-findings.md` yourself with that exact content before doing anything else, so `smdg-root-cause-tracer` can read it normally in step 5 — do not skip this or paraphrase the content when writing it. - **`reproduced: true`** — proceed to step 5 normally. - **`reproduced: false` but a Failure Signature is still present** (the reproducer hit a data/environment gap — e.g. required precondition data doesn't exist — but could still derive a signature from the ticket's expected-vs-actual description): don't just relay the blocker and stop. Ask the user: "Reproduction was blocked (). I can still trace the root cause using the ticket's description as a stand-in for live evidence — the result will be clearly marked as not live-verified. Proceed with that, or stop here?" Wait for their answer. If they decline, relay the blocker and stop. If they agree — or if this project has an established standing preference to always proceed in this situation, per prior guidance in memory — continue to step 5, but tell `smdg-root-cause-tracer` explicitly that the signature is ticket-derived, not observed. - **No Failure Signature at all** (blocked at login, or an ambiguous step with nothing ticket-derivable) — relay the blocker/question to the user verbatim and wait. This is the only case with nothing to trace. 5. Invoke the `smdg-root-cause-tracer` subagent, giving it the ticket key and telling it to read the Failure Signature section (and whether it's `reproduced: true` or a ticket-derived stand-in). If it reports being blocked (repo not checked out, ambiguous feature area, no anchor match), relay its question to the user and wait. 6. When analysis is complete, summarize the final result: prefer the tracer's code-verified classification and `root-cause.md` citation when available (UI bug / Backend bug / Contract-Schema Mismatch / Data-Environment Issue / Inconclusive); fall back to the reproducer's preliminary classification if the tracer had to stop and ask without a confident answer. **If the underlying Failure Signature was ticket-derived (`reproduced: false`) rather than live-observed, say so explicitly in the summary** and recommend the team verify live once the missing data/environment gap is resolved. Cite all relevant evidence file paths under `.claude/evidence//`. 7. **Optional: apply the fix.** Only when the final classification from step 6 is **Data/Environment Issue** and `root-cause.md` identifies a specific, actionable config change — ask the user: "Ticket này là do dữ liệu/cấu hình sai (không phải lỗi code): . Bạn có muốn tôi tự vào Admin UI để sửa trực tiếp không? Tôi sẽ chụp ảnh trước/sau và xin xác nhận từng thay đổi cụ thể trước khi thực hiện." Wait for their answer. - If they decline, stop here — the step-6 summary (diagnosis + the fix root-cause.md recommends) is the final deliverable. - If they agree, invoke the `smdg-config-fixer` subagent — giving it the ticket key, the browser to use (reuse the test-environment browser answer from earlier in this conversation), environment_url/credentials from `ticket-summary.md`, and the exact citation from `root-cause.md`. It will independently confirm the itemized change list with the user again before mutating anything and capture before/after screenshots — this is expected, not redundant, since it may find different specifics than what's visible from `root-cause.md` alone. Relay its `fix-summary.md` outcome (what changed, screenshot paths, whether live re-verification passed) back to the user as the final result. - For any other classification (UI bug / Backend bug / Contract-Schema Mismatch), do not offer this step at all — those need an actual code change through the team's normal dev/PR workflow, not this pipeline. Note: the reading mode and both browser choices are independent — it's expected and common that the user reads the ticket via MCP but still needs a specific browser for reproduction, or picks a different browser for each browser-based step (e.g. Chrome for Jira, Firefox for the test environment) due to different login/auth on each.