@codyswann/lisa 2.173.1 → 2.173.3

package/plugins/lisa-rails-agy/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/lisa-rails-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.173.1",
+  "version": "2.173.3",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-rails-agy/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/lisa-rails-agy/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/lisa-rails-agy/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/lisa-rails-copilot/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.173.1",
+  "version": "2.173.3",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-rails-copilot/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/lisa-rails-copilot/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/lisa-rails-copilot/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/lisa-rails-copilot/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/lisa-rails-cursor/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.173.1",
+  "version": "2.173.3",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-rails-cursor/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/lisa-rails-cursor/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/lisa-rails-cursor/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/lisa-rails-cursor/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/lisa-typescript/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.173.1",
+  "version": "2.173.3",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, ast-grep scanning, and error-suppression blocking on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-typescript/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.173.1",
+  "version": "2.173.3",
   "description": "TypeScript-specific hooks for formatting, linting, and ast-grep scanning on edit.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-typescript-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.173.1",
+  "version": "2.173.3",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, ast-grep scanning, and error-suppression blocking on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-typescript-copilot/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.173.1",
+  "version": "2.173.3",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, ast-grep scanning, and error-suppression blocking on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-typescript-cursor/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.173.1",
+  "version": "2.173.3",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, ast-grep scanning, and error-suppression blocking on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-wiki/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.173.1",
+  "version": "2.173.3",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-wiki/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.173.1",
+  "version": "2.173.3",
   "description": "Distributable LLM Wiki kernel — ingest, query, lint, and maintain a git-native markdown knowledge base across Claude and Codex.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-wiki-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.173.1",
+  "version": "2.173.3",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-wiki-copilot/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.173.1",
+  "version": "2.173.3",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-wiki-cursor/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.173.1",
+  "version": "2.173.3",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/src/base/agents/jira-agent.md

@@ -107,7 +107,7 @@ Use the `jira-sync` skill to update the ticket at these milestones:
 Use the `jira-evidence` skill to:
 - Upload verification evidence to the GitHub PR
 - Post evidence summary as a JIRA comment
-- Transition the ticket to Code Review
+- Transition the ticket to the configured `jira.workflow.review` status **only if it is set**; if `review` is unconfigured, leave the ticket in `claimed` (do not transition).
 
 ### 8. Suggest Status Transition
 
@@ -116,7 +116,7 @@ Based on the milestone, suggest (but don't auto-transition). Status role names a
 | Milestone | Suggested role | Default status |
 |-----------|----------------|----------------|
 | Plan created | `claimed` | `In Progress` |
-| PR ready | (review-equivalent — project's code-review status) | `In Review` |
+| PR ready | (review-equivalent — project's review status) | the configured `jira.workflow.review` status, or **no transition** when `review` is unconfigured |
 | PR merged | `done` (env-aware) | `Done` (or env-keyed variant per `jira.workflow.done`) |
 
 Note: `done` may be a string or an env-keyed map (`{ dev, staging, production }`). When suggesting the PR-merged transition, the env is implied by the PR's base branch via `deploy.branches` — surface the resolved status name to the human; do not auto-transition.
@@ -124,6 +124,7 @@ Note: `done` may be a string or an env-keyed map (`{ dev, staging, production }`
 ## Rules
 
 - Never auto-transition ticket status, with one explicit exception: when `jira-verify` returns `FAIL` for the pre-flight gate (Step 2), transition to the configured `blocked` status, add the configured `human_needed` marker label (`jira.labels.human_needed`, default `Human Needed`), and reassign to the Reporter. Every other status change remains a suggestion the human confirms.
+- Any transition is config-bound: never invent transitions; a transition may target only a status named in `config.jira.workflow`. Don't guess from the live workflow. The evidence-time review hop (Step 7) follows this rule too — it is config-bound, optional, and skipped when `jira.workflow.review` is absent (the ticket stays in `claimed`).
 - Always read the full ticket graph via `jira-read-ticket` before determining intent — don't rely on ticket type alone
 - Never create or materially edit a ticket by calling MCP write tools directly — always delegate to `jira-write-ticket` so relationships, Gherkin criteria, and metadata gates are enforced
 - If sign-in credentials are in the ticket, extract and pass them to the flow. If the ticket touches an authenticated surface and credentials are missing, that is a Step 2 failure — block and reassign rather than guessing.

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

@@ -1,16 +1,16 @@
 ---
 name: jira-evidence
-description: "Upload text evidence to GitHub pr-assets release, update PR description, post JIRA comment with code blocks, and move ticket to the configured code-review status. Reusable by any skill that captures evidence and generates evidence/comment.txt + evidence/comment.md."
+description: "Upload text evidence to GitHub pr-assets release, update PR description, post JIRA comment with code blocks, 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
 
 ## Workflow resolution
 
-The post-build review status is read from `.lisa.config.json` `jira.workflow.review` (or `jira.workflow.code_review`), falling back to `Code Review`. JIRA does not have a separate `review` role in the canonical config schema (the build lifecycle stays in `claimed` until `done`); this skill uses the project's actual post-build review status when one exists. If the configured status is not a valid transition from the ticket's current state, log a warning and skip the transition — the human will handle it.
+The post-build review status is read from `.lisa.config.json` `jira.workflow.review` (or `jira.workflow.code_review`). `review` is optional; when unset, the ticket stays in `claimed` until `done` and this skill skips the transition. Never transition to a status that is not named in `config.jira.workflow`. If the configured status is not a valid transition from the current state, log a warning and skip.
 
 ```bash
-REVIEW="Code Review"
+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"