@codyswann/lisa 2.173.1 → 2.173.3

package/plugins/src/base/skills/jira-evidence/scripts/post-evidence.sh

@@ -14,7 +14,8 @@
 #   2. Updates the GitHub PR description with evidence/comment.md
 #   3. Uploads image evidence as JIRA attachments
 #   4. Posts/updates the JIRA comment with evidence/comment.txt
-#   5. Moves the JIRA ticket to "Code Review"
+#   5. Moves the JIRA ticket to the configured jira.workflow.review status
+#      (skipped entirely when review is unconfigured — stays in claimed)
 
 set -euo pipefail
 
@@ -152,10 +153,26 @@ else
   echo "$RESP" | grep -v "HTTP_CODE:" | head -3
 fi
 
-# ── Step 5: Move ticket to Code Review ──────────────────────────────────────
+# ── Step 5: Move ticket to the configured review status (if any) ────────────
+# A transition may target only a status named in .lisa.config.json jira.workflow.
+# `review` is OPTIONAL: when it is not configured, the build lifecycle stays in
+# `claimed` until `done` — do NOT invent a transition. (See config-resolution.md.)
+REVIEW=""
+if [ -f .lisa.config.json ]; then
+  _cfg=$(jq -r '.jira.workflow.review // .jira.workflow.code_review // empty' .lisa.config.json 2>/dev/null)
+  [ -n "$_cfg" ] && REVIEW="$_cfg"
+fi
+if [ -f .lisa.config.local.json ]; then
+  _local=$(jq -r '.jira.workflow.review // .jira.workflow.code_review // empty' .lisa.config.local.json 2>/dev/null)
+  [ -n "$_local" ] && REVIEW="$_local"
+fi
 echo ""
-echo "==> Moving $TICKET_ID to Code Review..."
-jira issue move "$TICKET_ID" "Code Review" 2>&1 && echo "  ✓ Ticket moved to Code Review" || echo "  WARNING: Could not move ticket" >&2
+if [ -n "$REVIEW" ]; then
+  echo "==> Moving $TICKET_ID to $REVIEW..."
+  jira issue move "$TICKET_ID" "$REVIEW" 2>&1 && echo "  ✓ Ticket moved to $REVIEW" || echo "  WARNING: Could not move ticket to $REVIEW (not a valid transition?); leaving in current status" >&2
+else
+  echo "==> No jira.workflow.review configured; leaving $TICKET_ID in its current (claimed) status per config-resolution."
+fi
 
 echo ""
 echo "==> Done!"

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

@@ -67,7 +67,7 @@ Based on the milestone, suggest (but don't automatically perform) a status trans
 | Milestone | Suggested Status |
 |-----------|-----------------|
 | Plan created | "In Progress" |
-| PR ready | "In Review" |
+| PR ready | configured `jira.workflow.review` status, or no transition when unconfigured |
 | PR merged | "Done" |
 
 ### Step 5: Parent Status Rollup (`--rollup`)

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

@@ -47,6 +47,6 @@ The checklist is tracker-agnostic — the same shape works on JIRA, GitHub Issue
    - **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 Awaiting QA for feature; GitHub: direct `claimed` → configured `done` after a successful build; Linear: equivalent state). You don't transition manually.
+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/expo/commands/exploratory-qa.md

@@ -1,7 +1,7 @@
 ---
-description: "Run a first-time-user exploratory QA walkthrough: experience the app like a brand-new human user, clicking through to find anything confusing, broken, or hard to understand (human-facing jargon, contextless extracted data, machine-style labels, slow or unclear loads, late meaningful content, cramped or cut-off UI, inconsistent UX, awkward scroll behavior) across all breakpoints, and file each finding (bug or usability issue) as a tracked work item via lisa:tracker-write. The optional ready flag marks tickets build-ready (auto-picked-up by lisa:intake) or leaves them in the backlog for human triage (default). For gaps in the automated Playwright suite, use e2e-coverage-gaps instead."
+description: "Run a first-time-user exploratory QA walkthrough: experience the app like a brand-new human user in a real browser or browser automation session, clicking/typing/selecting through visible controls to find anything confusing, broken, or hard to understand (human-facing jargon, contextless extracted data, machine-style labels, slow or unclear loads, late meaningful content, cramped or cut-off UI, inconsistent UX, awkward scroll behavior) across all breakpoints, and file each finding (bug or usability issue) as a tracked work item via lisa:tracker-write. Static scans, HTTP fetches, screenshots alone, or console/network checks alone are not sufficient. The optional ready flag marks tickets build-ready (auto-picked-up by lisa:intake) or leaves them in the backlog for human triage (default). For gaps in the automated Playwright suite, use e2e-coverage-gaps instead."
 allowed-tools: ["Skill"]
 argument-hint: "[target-url | env] [ready=true|false]"
 ---
 
-Use the /lisa-expo:exploratory-qa skill to experience the app like a brand-new first-time user — landing cold on the home page and clicking through to find anything confusing, broken, or hard to understand across all breakpoints — and file each finding (bugs, usability/clarity issues) as a tracked work item via lisa:tracker-write, build-ready or in triage per the ready flag (default: triage). For automated Playwright coverage gaps, use /lisa-expo:e2e-coverage-gaps. $ARGUMENTS
+Use the /lisa-expo:exploratory-qa skill to experience the app like a brand-new first-time user in a real browser or browser automation session — landing cold on the home page, clicking/typing/selecting through visible controls, and verifying resulting UI state across all breakpoints — and file each finding (bugs, usability/clarity issues) as a tracked work item via lisa:tracker-write, build-ready or in triage per the ready flag (default: triage). Static scans, HTTP fetches, screenshots alone, or console/network checks alone are not enough. For automated Playwright coverage gaps, use /lisa-expo:e2e-coverage-gaps. $ARGUMENTS

package/plugins/src/expo/skills/exploratory-qa/SKILL.md

@@ -1,19 +1,22 @@
 ---
 name: exploratory-qa
-description: First-time-user exploratory QA walkthrough for web apps that FEEDS THE LIFECYCLE. Use when asked to experience an app the way a brand-new human user would — landing cold on the home page and clicking through to find anything confusing, broken, or hard to understand (unclear purpose or audience, human-facing jargon, contextless extracted data, machine-style labels, raw dates/enums, sparse data with no explanation, wrong control semantics, slow or unclear loads, late meaningful content, cramped or cut-off UI, inconsistent/non-standard UX, awkward scroll behavior, unclear affordances, dead-end flows that strand a user — e.g. a login page with no way to register or recover a password, or a primary action that drops the user into an incomplete/unsatisfiable state with no way to finish) across all breakpoints. Instead of writing a report file, it files every finding as a tracked work item via lisa:tracker-write (bugs and usability/UX issues). A `ready` parameter controls whether those tickets are created build-ready (auto-picked-up by lisa:intake) or left in the backlog for human triage (default). For gaps in the automated Playwright test suite, use the e2e-coverage-gaps skill instead.
+description: First-time-user exploratory QA walkthrough for web apps that FEEDS THE LIFECYCLE. Use when asked to experience an app the way a brand-new human user would — opening it in a real browser or browser automation session, landing cold on the home page, and clicking/typing/selecting through visible controls to find anything confusing, broken, or hard to understand (unclear purpose or audience, human-facing jargon, contextless extracted data, machine-style labels, raw dates/enums, sparse data with no explanation, wrong control semantics, slow or unclear loads, late meaningful content, cramped or cut-off UI, inconsistent/non-standard UX, awkward scroll behavior, unclear affordances, dead-end flows that strand a user — e.g. a login page with no way to register or recover a password, or a primary action that drops the user into an incomplete/unsatisfiable state with no way to finish) across all breakpoints. Static route scans, HTTP fetches, screenshots alone, or console/network checks alone are not sufficient exploratory QA evidence. Instead of writing a report file, it files every finding as a tracked work item via lisa:tracker-write (bugs and usability/UX issues). A `ready` parameter controls whether those tickets are created build-ready (auto-picked-up by lisa:intake) or left in the backlog for human triage (default). For gaps in the automated Playwright test suite, use the e2e-coverage-gaps skill instead.
 ---
 
 # Exploratory QA
 
 ## Overview
 
-Experience the app the way a **brand-new human user** would: land cold on the home page with no prior
-knowledge, then click through and actually try to use it — just like a real person. The goal is to
-surface anything **confusing, broken, or hard to understand**, and to do so at **every breakpoint**.
+Experience the app the way a **brand-new human user** would: open it in a real browser or browser
+automation tool, land cold on the home page with no prior knowledge, then click through and actually
+try to use it — just like a real person. The goal is to surface anything **confusing, broken, or hard
+to understand**, and to do so at **every breakpoint**.
 
 This is a usability/experience pass, **not** a test-coverage audit. It does not look at the Playwright
 suite or hunt for coverage gaps — for that, use the `e2e-coverage-gaps` skill. Here, every finding is
-filed as a tracked work item so it enters the Lisa lifecycle — no static report file.
+filed as a tracked work item so it enters the Lisa lifecycle — no static report file. Static route
+scans, HTTP fetches, screenshots alone, and console/network checks alone do not count as exploratory
+QA evidence because they do not prove a person could use the visible UI.
 
 ## Parameters
 
@@ -29,6 +32,9 @@ filed as a tracked work item so it enters the Lisa lifecycle — no static repor
 
 - Identify the target environment, account type, and browser requirement, and read the `ready` flag
   (default `false`).
+- Open the target in a real browser or browser automation tool before drawing conclusions. Use static
+  code inspection, route lists, network/console logs, and screenshots only as supporting evidence, not
+  as a substitute for live browser interaction.
 - **Confirm the tracker is configured.** Findings are filed as tickets, so read `tracker` from
   `.lisa.config.json` (local overrides global). If it is unset, stop and report that the tracker must
   be configured (via `/lisa:setup:jira` / `:github` / `:linear`) before exploratory QA can file
@@ -49,8 +55,11 @@ filed as a tracked work item so it enters the Lisa lifecycle — no static repor
 
 ### 3. Use It Like a Human
 
-Click through the visible paths and actually attempt real tasks — a first-time user explores, makes
-mistakes, and tries the obvious thing. Cover at least these dimensions unless the user narrows scope:
+Click through the visible paths and actually attempt real tasks in the browser — a first-time user
+explores, makes mistakes, and tries the obvious thing. When a page exposes forms, filters, menus,
+links, buttons, selects, tabs, or other visible controls, click, type, select, submit, clear,
+navigate, and otherwise exercise representative controls when safe; then verify the resulting UI or
+data state in the browser. Cover at least these dimensions unless the user narrows scope:
 
 - **Comprehension & labeling:** human-facing copy must sound like something a normal first-time user
   would understand. Flag machine-style or developer labels shown to users (raw IDs, enum keys,

package/plugins/src/expo/skills/jira-evidence/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: jira-evidence
-description: "Upload screenshots to GitHub pr-assets release, update PR description with evidence, upload attachments to JIRA, post wiki markup comment, and move ticket to Code Review. Reusable by any skill that captures screenshots and generates evidence/comment.txt + evidence/comment.md."
+description: "Upload screenshots to GitHub pr-assets release, update PR description with evidence, upload attachments to JIRA, post wiki markup comment, and move ticket to the configured review status only when `jira.workflow.review` is set (otherwise leave it in `claimed`). Reusable by any skill that captures screenshots and generates evidence/comment.txt + evidence/comment.md."
 ---
 
 # JIRA Evidence Posting
@@ -44,7 +44,7 @@ bash .claude/skills/jira-evidence/scripts/post-evidence.sh PROJ-123 ./evidence 4
 3. **Update PR description** — Replaces or appends the `## Evidence` section in the PR body using `gh pr edit`
 4. **Upload JIRA attachments** — Uploads screenshots via REST API v3 so `!filename.png!` wiki markup renders inline
 5. **Post JIRA comment** — Posts `comment.txt` as a new comment via REST API v2 (wiki markup with embedded images)
-6. **Move ticket to Code Review** — Transitions the JIRA ticket via `jira issue move`
+6. **Move ticket to the configured review status** — Resolves `jira.workflow.review` (or the `jira.workflow.code_review` alias) from `.lisa.config.json` / `.lisa.config.local.json` and transitions via `jira issue move`. `review` is optional; when unset, the ticket stays in `claimed` and this step is skipped. Never transition to a status not named in `config.jira.workflow`. If the configured status is not a valid transition from the current state, log a warning and skip.
 
 ## Screenshot Naming Convention
 

package/plugins/src/expo/skills/jira-evidence/scripts/post-evidence.sh

@@ -14,7 +14,8 @@
 #   2. Updates the GitHub PR description with evidence/comment.md
 #   3. Uploads image evidence as JIRA attachments
 #   4. Posts/updates the JIRA comment with evidence/comment.txt
-#   5. Moves the JIRA ticket to "Code Review"
+#   5. Moves the JIRA ticket to the configured jira.workflow.review status
+#      (skipped entirely when review is unconfigured — stays in claimed)
 
 set -euo pipefail
 
@@ -152,10 +153,26 @@ else
   echo "$RESP" | grep -v "HTTP_CODE:" | head -3
 fi
 
-# ── Step 5: Move ticket to Code Review ──────────────────────────────────────
+# ── Step 5: Move ticket to the configured review status (if any) ────────────
+# A transition may target only a status named in .lisa.config.json jira.workflow.
+# `review` is OPTIONAL: when it is not configured, the build lifecycle stays in
+# `claimed` until `done` — do NOT invent a transition. (See config-resolution.md.)
+REVIEW=""
+if [ -f .lisa.config.json ]; then
+  _cfg=$(jq -r '.jira.workflow.review // .jira.workflow.code_review // empty' .lisa.config.json 2>/dev/null)
+  [ -n "$_cfg" ] && REVIEW="$_cfg"
+fi
+if [ -f .lisa.config.local.json ]; then
+  _local=$(jq -r '.jira.workflow.review // .jira.workflow.code_review // empty' .lisa.config.local.json 2>/dev/null)
+  [ -n "$_local" ] && REVIEW="$_local"
+fi
 echo ""
-echo "==> Moving $TICKET_ID to Code Review..."
-jira issue move "$TICKET_ID" "Code Review" 2>&1 && echo "  ✓ Ticket moved to Code Review" || echo "  WARNING: Could not move ticket" >&2
+if [ -n "$REVIEW" ]; then
+  echo "==> Moving $TICKET_ID to $REVIEW..."
+  jira issue move "$TICKET_ID" "$REVIEW" 2>&1 && echo "  ✓ Ticket moved to $REVIEW" || echo "  WARNING: Could not move ticket to $REVIEW (not a valid transition?); leaving in current status" >&2
+else
+  echo "==> No jira.workflow.review configured; leaving $TICKET_ID in its current (claimed) status per config-resolution."
+fi
 
 echo ""
 echo "==> Done!"

package/plugins/src/harper-fabric/commands/exploratory-qa.md

@@ -1,7 +1,7 @@
 ---
-description: "Run a first-time-user exploratory QA walkthrough: experience the app like a brand-new human user, clicking through to find anything confusing, broken, or hard to understand (human-facing jargon, contextless extracted data, machine-style labels, slow or unclear loads, late meaningful content, cramped or cut-off UI, inconsistent UX, awkward scroll behavior) across all breakpoints, and file each finding (bug or usability issue) as a tracked work item via lisa:tracker-write. The optional ready flag marks tickets build-ready (auto-picked-up by lisa:intake) or leaves them in the backlog for human triage (default). For gaps in the automated Playwright suite, use e2e-coverage-gaps instead."
+description: "Run a first-time-user exploratory QA walkthrough: experience the app like a brand-new human user in a real browser or browser automation session, clicking/typing/selecting through visible controls to find anything confusing, broken, or hard to understand (human-facing jargon, contextless extracted data, machine-style labels, slow or unclear loads, late meaningful content, cramped or cut-off UI, inconsistent UX, awkward scroll behavior) across all breakpoints, and file each finding (bug or usability issue) as a tracked work item via lisa:tracker-write. Static scans, HTTP fetches, screenshots alone, or console/network checks alone are not sufficient. The optional ready flag marks tickets build-ready (auto-picked-up by lisa:intake) or leaves them in the backlog for human triage (default). For gaps in the automated Playwright suite, use e2e-coverage-gaps instead."
 allowed-tools: ["Skill"]
 argument-hint: "[target-url | env] [ready=true|false]"
 ---
 
-Use the /lisa-harper-fabric:exploratory-qa skill to experience the app like a brand-new first-time user — landing cold on the home page and clicking through to find anything confusing, broken, or hard to understand across all breakpoints — and file each finding (bugs, usability/clarity issues) as a tracked work item via lisa:tracker-write, build-ready or in triage per the ready flag (default: triage). For automated Playwright coverage gaps, use /lisa-harper-fabric:e2e-coverage-gaps. $ARGUMENTS
+Use the /lisa-harper-fabric:exploratory-qa skill to experience the app like a brand-new first-time user in a real browser or browser automation session — landing cold on the home page, clicking/typing/selecting through visible controls, and verifying resulting UI state across all breakpoints — and file each finding (bugs, usability/clarity issues) as a tracked work item via lisa:tracker-write, build-ready or in triage per the ready flag (default: triage). Static scans, HTTP fetches, screenshots alone, or console/network checks alone are not enough. For automated Playwright coverage gaps, use /lisa-harper-fabric:e2e-coverage-gaps. $ARGUMENTS

package/plugins/src/harper-fabric/skills/exploratory-qa/SKILL.md

@@ -1,19 +1,22 @@
 ---
 name: exploratory-qa
-description: First-time-user exploratory QA walkthrough for web apps that FEEDS THE LIFECYCLE. Use when asked to experience an app the way a brand-new human user would — landing cold on the home page and clicking through to find anything confusing, broken, or hard to understand (unclear purpose or audience, human-facing jargon, contextless extracted data, machine-style labels, raw dates/enums, sparse data with no explanation, wrong control semantics, slow or unclear loads, late meaningful content, cramped or cut-off UI, inconsistent/non-standard UX, awkward scroll behavior, unclear affordances, dead-end flows that strand a user — e.g. a login page with no way to register or recover a password, or a primary action that drops the user into an incomplete/unsatisfiable state with no way to finish) across all breakpoints. Instead of writing a report file, it files every finding as a tracked work item via lisa:tracker-write (bugs and usability/UX issues). A `ready` parameter controls whether those tickets are created build-ready (auto-picked-up by lisa:intake) or left in the backlog for human triage (default). For gaps in the automated Playwright test suite, use the e2e-coverage-gaps skill instead.
+description: First-time-user exploratory QA walkthrough for web apps that FEEDS THE LIFECYCLE. Use when asked to experience an app the way a brand-new human user would — opening it in a real browser or browser automation session, landing cold on the home page, and clicking/typing/selecting through visible controls to find anything confusing, broken, or hard to understand (unclear purpose or audience, human-facing jargon, contextless extracted data, machine-style labels, raw dates/enums, sparse data with no explanation, wrong control semantics, slow or unclear loads, late meaningful content, cramped or cut-off UI, inconsistent/non-standard UX, awkward scroll behavior, unclear affordances, dead-end flows that strand a user — e.g. a login page with no way to register or recover a password, or a primary action that drops the user into an incomplete/unsatisfiable state with no way to finish) across all breakpoints. Static route scans, HTTP fetches, screenshots alone, or console/network checks alone are not sufficient exploratory QA evidence. Instead of writing a report file, it files every finding as a tracked work item via lisa:tracker-write (bugs and usability/UX issues). A `ready` parameter controls whether those tickets are created build-ready (auto-picked-up by lisa:intake) or left in the backlog for human triage (default). For gaps in the automated Playwright test suite, use the e2e-coverage-gaps skill instead.
 ---
 
 # Exploratory QA
 
 ## Overview
 
-Experience the app the way a **brand-new human user** would: land cold on the home page with no prior
-knowledge, then click through and actually try to use it — just like a real person. The goal is to
-surface anything **confusing, broken, or hard to understand**, and to do so at **every breakpoint**.
+Experience the app the way a **brand-new human user** would: open it in a real browser or browser
+automation tool, land cold on the home page with no prior knowledge, then click through and actually
+try to use it — just like a real person. The goal is to surface anything **confusing, broken, or hard
+to understand**, and to do so at **every breakpoint**.
 
 This is a usability/experience pass, **not** a test-coverage audit. It does not look at the Playwright
 suite or hunt for coverage gaps — for that, use the `e2e-coverage-gaps` skill. Here, every finding is
-filed as a tracked work item so it enters the Lisa lifecycle — no static report file.
+filed as a tracked work item so it enters the Lisa lifecycle — no static report file. Static route
+scans, HTTP fetches, screenshots alone, and console/network checks alone do not count as exploratory
+QA evidence because they do not prove a person could use the visible UI.
 
 ## Parameters
 
@@ -29,6 +32,9 @@ filed as a tracked work item so it enters the Lisa lifecycle — no static repor
 
 - Identify the target environment, account type, and browser requirement, and read the `ready` flag
   (default `false`).
+- Open the target in a real browser or browser automation tool before drawing conclusions. Use static
+  code inspection, route lists, network/console logs, and screenshots only as supporting evidence, not
+  as a substitute for live browser interaction.
 - **Confirm the tracker is configured.** Findings are filed as tickets, so read `tracker` from
   `.lisa.config.json` (local overrides global). If it is unset, stop and report that the tracker must
   be configured (via `/lisa:setup:jira` / `:github` / `:linear`) before exploratory QA can file
@@ -49,8 +55,11 @@ filed as a tracked work item so it enters the Lisa lifecycle — no static repor
 
 ### 3. Use It Like a Human
 
-Click through the visible paths and actually attempt real tasks — a first-time user explores, makes
-mistakes, and tries the obvious thing. Cover at least these dimensions unless the user narrows scope:
+Click through the visible paths and actually attempt real tasks in the browser — a first-time user
+explores, makes mistakes, and tries the obvious thing. When a page exposes forms, filters, menus,
+links, buttons, selects, tabs, or other visible controls, click, type, select, submit, clear,
+navigate, and otherwise exercise representative controls when safe; then verify the resulting UI or
+data state in the browser. Cover at least these dimensions unless the user narrows scope:
 
 - **Comprehension & labeling:** human-facing copy must sound like something a normal first-time user
   would understand. Flag machine-style or developer labels shown to users (raw IDs, enum keys,

package/plugins/src/rails/commands/exploratory-qa.md

@@ -1,7 +1,7 @@
 ---
-description: "Run a first-time-user exploratory QA walkthrough: experience the app like a brand-new human user, clicking through to find anything confusing, broken, or hard to understand (human-facing jargon, contextless extracted data, machine-style labels, slow or unclear loads, late meaningful content, cramped or cut-off UI, inconsistent UX, awkward scroll behavior) across all breakpoints, and file each finding (bug or usability issue) as a tracked work item via lisa:tracker-write. The optional ready flag marks tickets build-ready (auto-picked-up by lisa:intake) or leaves them in the backlog for human triage (default). For gaps in the automated Playwright suite, use e2e-coverage-gaps instead."
+description: "Run a first-time-user exploratory QA walkthrough: experience the app like a brand-new human user in a real browser or browser automation session, clicking/typing/selecting through visible controls to find anything confusing, broken, or hard to understand (human-facing jargon, contextless extracted data, machine-style labels, slow or unclear loads, late meaningful content, cramped or cut-off UI, inconsistent UX, awkward scroll behavior) across all breakpoints, and file each finding (bug or usability issue) as a tracked work item via lisa:tracker-write. Static scans, HTTP fetches, screenshots alone, or console/network checks alone are not sufficient. The optional ready flag marks tickets build-ready (auto-picked-up by lisa:intake) or leaves them in the backlog for human triage (default). For gaps in the automated Playwright suite, use e2e-coverage-gaps instead."
 allowed-tools: ["Skill"]
 argument-hint: "[target-url | env] [ready=true|false]"
 ---
 
-Use the /lisa-rails:exploratory-qa skill to experience the app like a brand-new first-time user — landing cold on the home page and clicking through to find anything confusing, broken, or hard to understand across all breakpoints — and file each finding (bugs, usability/clarity issues) as a tracked work item via lisa:tracker-write, build-ready or in triage per the ready flag (default: triage). For automated Playwright coverage gaps, use /lisa-rails:e2e-coverage-gaps. $ARGUMENTS
+Use the /lisa-rails:exploratory-qa skill to experience the app like a brand-new first-time user in a real browser or browser automation session — landing cold on the home page, clicking/typing/selecting through visible controls, and verifying resulting UI state across all breakpoints — and file each finding (bugs, usability/clarity issues) as a tracked work item via lisa:tracker-write, build-ready or in triage per the ready flag (default: triage). Static scans, HTTP fetches, screenshots alone, or console/network checks alone are not enough. For automated Playwright coverage gaps, use /lisa-rails:e2e-coverage-gaps. $ARGUMENTS

package/plugins/src/rails/skills/exploratory-qa/SKILL.md

@@ -1,19 +1,22 @@
 ---
 name: exploratory-qa
-description: First-time-user exploratory QA walkthrough for web apps that FEEDS THE LIFECYCLE. Use when asked to experience an app the way a brand-new human user would — landing cold on the home page and clicking through to find anything confusing, broken, or hard to understand (unclear purpose or audience, human-facing jargon, contextless extracted data, machine-style labels, raw dates/enums, sparse data with no explanation, wrong control semantics, slow or unclear loads, late meaningful content, cramped or cut-off UI, inconsistent/non-standard UX, awkward scroll behavior, unclear affordances, dead-end flows that strand a user — e.g. a login page with no way to register or recover a password, or a primary action that drops the user into an incomplete/unsatisfiable state with no way to finish) across all breakpoints. Instead of writing a report file, it files every finding as a tracked work item via lisa:tracker-write (bugs and usability/UX issues). A `ready` parameter controls whether those tickets are created build-ready (auto-picked-up by lisa:intake) or left in the backlog for human triage (default). For gaps in the automated Playwright test suite, use the e2e-coverage-gaps skill instead.
+description: First-time-user exploratory QA walkthrough for web apps that FEEDS THE LIFECYCLE. Use when asked to experience an app the way a brand-new human user would — opening it in a real browser or browser automation session, landing cold on the home page, and clicking/typing/selecting through visible controls to find anything confusing, broken, or hard to understand (unclear purpose or audience, human-facing jargon, contextless extracted data, machine-style labels, raw dates/enums, sparse data with no explanation, wrong control semantics, slow or unclear loads, late meaningful content, cramped or cut-off UI, inconsistent/non-standard UX, awkward scroll behavior, unclear affordances, dead-end flows that strand a user — e.g. a login page with no way to register or recover a password, or a primary action that drops the user into an incomplete/unsatisfiable state with no way to finish) across all breakpoints. Static route scans, HTTP fetches, screenshots alone, or console/network checks alone are not sufficient exploratory QA evidence. Instead of writing a report file, it files every finding as a tracked work item via lisa:tracker-write (bugs and usability/UX issues). A `ready` parameter controls whether those tickets are created build-ready (auto-picked-up by lisa:intake) or left in the backlog for human triage (default). For gaps in the automated Playwright test suite, use the e2e-coverage-gaps skill instead.
 ---
 
 # Exploratory QA
 
 ## Overview
 
-Experience the app the way a **brand-new human user** would: land cold on the home page with no prior
-knowledge, then click through and actually try to use it — just like a real person. The goal is to
-surface anything **confusing, broken, or hard to understand**, and to do so at **every breakpoint**.
+Experience the app the way a **brand-new human user** would: open it in a real browser or browser
+automation tool, land cold on the home page with no prior knowledge, then click through and actually
+try to use it — just like a real person. The goal is to surface anything **confusing, broken, or hard
+to understand**, and to do so at **every breakpoint**.
 
 This is a usability/experience pass, **not** a test-coverage audit. It does not look at the Playwright
 suite or hunt for coverage gaps — for that, use the `e2e-coverage-gaps` skill. Here, every finding is
-filed as a tracked work item so it enters the Lisa lifecycle — no static report file.
+filed as a tracked work item so it enters the Lisa lifecycle — no static report file. Static route
+scans, HTTP fetches, screenshots alone, and console/network checks alone do not count as exploratory
+QA evidence because they do not prove a person could use the visible UI.
 
 ## Parameters
 
@@ -29,6 +32,9 @@ filed as a tracked work item so it enters the Lisa lifecycle — no static repor
 
 - Identify the target environment, account type, and browser requirement, and read the `ready` flag
   (default `false`).
+- Open the target in a real browser or browser automation tool before drawing conclusions. Use static
+  code inspection, route lists, network/console logs, and screenshots only as supporting evidence, not
+  as a substitute for live browser interaction.
 - **Confirm the tracker is configured.** Findings are filed as tickets, so read `tracker` from
   `.lisa.config.json` (local overrides global). If it is unset, stop and report that the tracker must
   be configured (via `/lisa:setup:jira` / `:github` / `:linear`) before exploratory QA can file
@@ -49,8 +55,11 @@ filed as a tracked work item so it enters the Lisa lifecycle — no static repor
 
 ### 3. Use It Like a Human
 
-Click through the visible paths and actually attempt real tasks — a first-time user explores, makes
-mistakes, and tries the obvious thing. Cover at least these dimensions unless the user narrows scope:
+Click through the visible paths and actually attempt real tasks in the browser — a first-time user
+explores, makes mistakes, and tries the obvious thing. When a page exposes forms, filters, menus,
+links, buttons, selects, tabs, or other visible controls, click, type, select, submit, clear,
+navigate, and otherwise exercise representative controls when safe; then verify the resulting UI or
+data state in the browser. Cover at least these dimensions unless the user narrows scope:
 
 - **Comprehension & labeling:** human-facing copy must sound like something a normal first-time user
   would understand. Flag machine-style or developer labels shown to users (raw IDs, enum keys,

package/plugins/src/rails/skills/jira-evidence/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: jira-evidence
-description: "Upload evidence to GitHub pr-assets release, update PR description, upload attachments to JIRA, post comment, and move ticket to Code Review. Reusable by any skill that captures evidence and generates evidence/comment.txt + evidence/comment.md."
+description: "Upload evidence to GitHub pr-assets release, update PR description, upload attachments to JIRA, post comment, and move ticket to the configured review status only when `jira.workflow.review` is set (otherwise leave it in `claimed`). Reusable by any skill that captures evidence and generates evidence/comment.txt + evidence/comment.md."
 ---
 
 # JIRA Evidence Posting
@@ -44,7 +44,7 @@ bash .claude/skills/jira-evidence/scripts/post-evidence.sh PROJ-123 ./evidence 4
 3. **Update PR description** — Replaces or appends the `## Evidence` section in the PR body using `gh pr edit`
 4. **Upload JIRA attachments** — Uploads image evidence via REST API v3 so `!filename.png!` wiki markup renders inline
 5. **Post JIRA comment** — Posts `comment.txt` as a new comment via REST API v2 (wiki markup)
-6. **Move ticket to Code Review** — Transitions the JIRA ticket via `jira issue move`
+6. **Move ticket to the configured review status** — Resolves `jira.workflow.review` (or the `jira.workflow.code_review` alias) from `.lisa.config.json` / `.lisa.config.local.json` and transitions via `jira issue move`. `review` is optional; when unset, the ticket stays in `claimed` and this step is skipped. Never transition to a status not named in `config.jira.workflow`. If the configured status is not a valid transition from the current state, log a warning and skip.
 
 ## Evidence Naming Conventions
 

package/plugins/src/rails/skills/jira-evidence/scripts/post-evidence.sh

@@ -14,7 +14,8 @@
 #   2. Updates the GitHub PR description with evidence/comment.md
 #   3. Uploads image evidence as JIRA attachments
 #   4. Posts/updates the JIRA comment with evidence/comment.txt
-#   5. Moves the JIRA ticket to "Code Review"
+#   5. Moves the JIRA ticket to the configured jira.workflow.review status
+#      (skipped entirely when review is unconfigured — stays in claimed)
 
 set -euo pipefail
 
@@ -152,10 +153,26 @@ else
   echo "$RESP" | grep -v "HTTP_CODE:" | head -3
 fi
 
-# ── Step 5: Move ticket to Code Review ──────────────────────────────────────
+# ── Step 5: Move ticket to the configured review status (if any) ────────────
+# A transition may target only a status named in .lisa.config.json jira.workflow.
+# `review` is OPTIONAL: when it is not configured, the build lifecycle stays in
+# `claimed` until `done` — do NOT invent a transition. (See config-resolution.md.)
+REVIEW=""
+if [ -f .lisa.config.json ]; then
+  _cfg=$(jq -r '.jira.workflow.review // .jira.workflow.code_review // empty' .lisa.config.json 2>/dev/null)
+  [ -n "$_cfg" ] && REVIEW="$_cfg"
+fi
+if [ -f .lisa.config.local.json ]; then
+  _local=$(jq -r '.jira.workflow.review // .jira.workflow.code_review // empty' .lisa.config.local.json 2>/dev/null)
+  [ -n "$_local" ] && REVIEW="$_local"
+fi
 echo ""
-echo "==> Moving $TICKET_ID to Code Review..."
-jira issue move "$TICKET_ID" "Code Review" 2>&1 && echo "  ✓ Ticket moved to Code Review" || echo "  WARNING: Could not move ticket" >&2
+if [ -n "$REVIEW" ]; then
+  echo "==> Moving $TICKET_ID to $REVIEW..."
+  jira issue move "$TICKET_ID" "$REVIEW" 2>&1 && echo "  ✓ Ticket moved to $REVIEW" || echo "  WARNING: Could not move ticket to $REVIEW (not a valid transition?); leaving in current status" >&2
+else
+  echo "==> No jira.workflow.review configured; leaving $TICKET_ID in its current (claimed) status per config-resolution."
+fi
 
 echo ""
 echo "==> Done!"