@codyswann/lisa 2.136.0 → 2.137.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/package.json +3 -2
- package/plugins/lisa/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-agy/plugin.json +1 -1
- package/plugins/lisa-cdk/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-cdk/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-cdk-agy/plugin.json +1 -1
- package/plugins/lisa-cdk-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-cdk-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-expo/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-expo/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-expo/skills/exploratory-qa/SKILL.md +17 -1
- package/plugins/lisa-expo-agy/plugin.json +1 -1
- package/plugins/lisa-expo-agy/skills/exploratory-qa/SKILL.md +17 -1
- package/plugins/lisa-expo-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-expo-copilot/skills/exploratory-qa/SKILL.md +17 -1
- package/plugins/lisa-expo-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-expo-cursor/skills/exploratory-qa/SKILL.md +17 -1
- package/plugins/lisa-harper-fabric/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-harper-fabric/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-harper-fabric/skills/exploratory-qa/SKILL.md +17 -1
- package/plugins/lisa-harper-fabric-agy/plugin.json +1 -1
- package/plugins/lisa-harper-fabric-agy/skills/exploratory-qa/SKILL.md +17 -1
- package/plugins/lisa-harper-fabric-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-harper-fabric-copilot/skills/exploratory-qa/SKILL.md +17 -1
- package/plugins/lisa-harper-fabric-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-harper-fabric-cursor/skills/exploratory-qa/SKILL.md +17 -1
- package/plugins/lisa-nestjs/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-nestjs/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-nestjs-agy/plugin.json +1 -1
- package/plugins/lisa-nestjs-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-nestjs-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-openclaw/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-openclaw/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-openclaw-agy/plugin.json +1 -1
- package/plugins/lisa-openclaw-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-openclaw-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-rails/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-rails/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-rails/skills/exploratory-qa/SKILL.md +17 -1
- package/plugins/lisa-rails-agy/plugin.json +1 -1
- package/plugins/lisa-rails-agy/skills/exploratory-qa/SKILL.md +17 -1
- package/plugins/lisa-rails-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-rails-copilot/skills/exploratory-qa/SKILL.md +17 -1
- package/plugins/lisa-rails-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-rails-cursor/skills/exploratory-qa/SKILL.md +17 -1
- package/plugins/lisa-typescript/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-typescript/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-typescript-agy/plugin.json +1 -1
- package/plugins/lisa-typescript-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-typescript-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-wiki/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-wiki/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-wiki-agy/plugin.json +1 -1
- package/plugins/lisa-wiki-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-wiki-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/src/expo/skills/exploratory-qa/SKILL.md +17 -1
- package/plugins/src/harper-fabric/skills/exploratory-qa/SKILL.md +17 -1
- package/plugins/src/rails/skills/exploratory-qa/SKILL.md +17 -1
package/package.json
CHANGED
|
@@ -1,6 +1,7 @@
|
|
|
1
1
|
{
|
|
2
2
|
"scripts": {
|
|
3
|
-
"build": "
|
|
3
|
+
"build": "bun run build:dist && bun run build:plugins",
|
|
4
|
+
"build:dist": "tsc && node scripts/copy-codex-scripts.mjs",
|
|
4
5
|
"test:integration": "vitest run tests/integration",
|
|
5
6
|
"postinstall": "bash ./scripts/install-claude-plugins.sh || true; [ -d dist/configs ] || tsc || true",
|
|
6
7
|
"pretest": "[ -d dist/configs ] || bun run build",
|
|
@@ -83,7 +84,7 @@
|
|
|
83
84
|
"lodash": ">=4.18.1"
|
|
84
85
|
},
|
|
85
86
|
"name": "@codyswann/lisa",
|
|
86
|
-
"version": "2.
|
|
87
|
+
"version": "2.137.0",
|
|
87
88
|
"description": "Claude Code governance framework that applies guardrails, guidance, and automated enforcement to projects",
|
|
88
89
|
"main": "dist/index.js",
|
|
89
90
|
"exports": {
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: exploratory-qa
|
|
3
|
-
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 (human-facing jargon, contextless extracted data, machine-style labels, 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) 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.
|
|
3
|
+
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 (human-facing jargon, contextless extracted data, machine-style labels, 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.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Exploratory QA
|
|
@@ -80,6 +80,22 @@ mistakes, and tries the obvious thing. Cover at least these dimensions unless th
|
|
|
80
80
|
no primary action to populate it.
|
|
81
81
|
When the missing counterpart makes a core task impossible for a whole class of users (e.g. a new
|
|
82
82
|
user literally cannot create an account), file a `Bug`; otherwise file a usability `Improvement`.
|
|
83
|
+
- **Action preconditions & incomplete end-states:** an action whose result only makes sense with
|
|
84
|
+
multiple inputs (compare, merge, combine, bulk-edit) or with some prerequisite met should guide the
|
|
85
|
+
user to satisfy that precondition — by disabling/explaining it until it is met, by collecting the
|
|
86
|
+
inputs first (e.g. a selection tray), or by giving the destination an obvious in-place control to
|
|
87
|
+
complete it. Actually trigger these actions and watch where they land; flag when a primary action:
|
|
88
|
+
- **Fires under-satisfied and strands the user:** e.g. a per-row "Compare" that navigates to a
|
|
89
|
+
comparison of a single item, shows an "under limit / add at least 2" notice, but exposes no
|
|
90
|
+
visible "add another" control — the user is told what is wrong with no in-place means to fix it.
|
|
91
|
+
- **Lands on an incomplete / empty end-state with no next step:** a results or detail screen that
|
|
92
|
+
announces it is empty, partial, or "needs more" yet offers no affordance to add, retry, or return
|
|
93
|
+
to the selection that produced it.
|
|
94
|
+
- **Is offered where it cannot succeed:** a multi-item action exposed on a single item, or an action
|
|
95
|
+
left enabled while its precondition (a selection, a minimum count, a required field) is unmet,
|
|
96
|
+
with no explanation.
|
|
97
|
+
When the user is left unable to complete the action they started, file a `Bug`; when it eventually
|
|
98
|
+
works but the path is confusing or roundabout, file a usability `Improvement`.
|
|
83
99
|
- **Visual/layout quality:** cut-off or truncated text, overlap, cramped/crowded density, offscreen or
|
|
84
100
|
unreachable controls, accidental horizontal scroll, awkward empty space. **Do not judge this by
|
|
85
101
|
eyeballing a screenshot alone** — a control clipped by a few pixels or pushed just past a container
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: exploratory-qa
|
|
3
|
-
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 (human-facing jargon, contextless extracted data, machine-style labels, 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) 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.
|
|
3
|
+
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 (human-facing jargon, contextless extracted data, machine-style labels, 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.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Exploratory QA
|
|
@@ -80,6 +80,22 @@ mistakes, and tries the obvious thing. Cover at least these dimensions unless th
|
|
|
80
80
|
no primary action to populate it.
|
|
81
81
|
When the missing counterpart makes a core task impossible for a whole class of users (e.g. a new
|
|
82
82
|
user literally cannot create an account), file a `Bug`; otherwise file a usability `Improvement`.
|
|
83
|
+
- **Action preconditions & incomplete end-states:** an action whose result only makes sense with
|
|
84
|
+
multiple inputs (compare, merge, combine, bulk-edit) or with some prerequisite met should guide the
|
|
85
|
+
user to satisfy that precondition — by disabling/explaining it until it is met, by collecting the
|
|
86
|
+
inputs first (e.g. a selection tray), or by giving the destination an obvious in-place control to
|
|
87
|
+
complete it. Actually trigger these actions and watch where they land; flag when a primary action:
|
|
88
|
+
- **Fires under-satisfied and strands the user:** e.g. a per-row "Compare" that navigates to a
|
|
89
|
+
comparison of a single item, shows an "under limit / add at least 2" notice, but exposes no
|
|
90
|
+
visible "add another" control — the user is told what is wrong with no in-place means to fix it.
|
|
91
|
+
- **Lands on an incomplete / empty end-state with no next step:** a results or detail screen that
|
|
92
|
+
announces it is empty, partial, or "needs more" yet offers no affordance to add, retry, or return
|
|
93
|
+
to the selection that produced it.
|
|
94
|
+
- **Is offered where it cannot succeed:** a multi-item action exposed on a single item, or an action
|
|
95
|
+
left enabled while its precondition (a selection, a minimum count, a required field) is unmet,
|
|
96
|
+
with no explanation.
|
|
97
|
+
When the user is left unable to complete the action they started, file a `Bug`; when it eventually
|
|
98
|
+
works but the path is confusing or roundabout, file a usability `Improvement`.
|
|
83
99
|
- **Visual/layout quality:** cut-off or truncated text, overlap, cramped/crowded density, offscreen or
|
|
84
100
|
unreachable controls, accidental horizontal scroll, awkward empty space. **Do not judge this by
|
|
85
101
|
eyeballing a screenshot alone** — a control clipped by a few pixels or pushed just past a container
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: exploratory-qa
|
|
3
|
-
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 (human-facing jargon, contextless extracted data, machine-style labels, 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) 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.
|
|
3
|
+
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 (human-facing jargon, contextless extracted data, machine-style labels, 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.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Exploratory QA
|
|
@@ -80,6 +80,22 @@ mistakes, and tries the obvious thing. Cover at least these dimensions unless th
|
|
|
80
80
|
no primary action to populate it.
|
|
81
81
|
When the missing counterpart makes a core task impossible for a whole class of users (e.g. a new
|
|
82
82
|
user literally cannot create an account), file a `Bug`; otherwise file a usability `Improvement`.
|
|
83
|
+
- **Action preconditions & incomplete end-states:** an action whose result only makes sense with
|
|
84
|
+
multiple inputs (compare, merge, combine, bulk-edit) or with some prerequisite met should guide the
|
|
85
|
+
user to satisfy that precondition — by disabling/explaining it until it is met, by collecting the
|
|
86
|
+
inputs first (e.g. a selection tray), or by giving the destination an obvious in-place control to
|
|
87
|
+
complete it. Actually trigger these actions and watch where they land; flag when a primary action:
|
|
88
|
+
- **Fires under-satisfied and strands the user:** e.g. a per-row "Compare" that navigates to a
|
|
89
|
+
comparison of a single item, shows an "under limit / add at least 2" notice, but exposes no
|
|
90
|
+
visible "add another" control — the user is told what is wrong with no in-place means to fix it.
|
|
91
|
+
- **Lands on an incomplete / empty end-state with no next step:** a results or detail screen that
|
|
92
|
+
announces it is empty, partial, or "needs more" yet offers no affordance to add, retry, or return
|
|
93
|
+
to the selection that produced it.
|
|
94
|
+
- **Is offered where it cannot succeed:** a multi-item action exposed on a single item, or an action
|
|
95
|
+
left enabled while its precondition (a selection, a minimum count, a required field) is unmet,
|
|
96
|
+
with no explanation.
|
|
97
|
+
When the user is left unable to complete the action they started, file a `Bug`; when it eventually
|
|
98
|
+
works but the path is confusing or roundabout, file a usability `Improvement`.
|
|
83
99
|
- **Visual/layout quality:** cut-off or truncated text, overlap, cramped/crowded density, offscreen or
|
|
84
100
|
unreachable controls, accidental horizontal scroll, awkward empty space. **Do not judge this by
|
|
85
101
|
eyeballing a screenshot alone** — a control clipped by a few pixels or pushed just past a container
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: exploratory-qa
|
|
3
|
-
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 (human-facing jargon, contextless extracted data, machine-style labels, 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) 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.
|
|
3
|
+
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 (human-facing jargon, contextless extracted data, machine-style labels, 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.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Exploratory QA
|
|
@@ -80,6 +80,22 @@ mistakes, and tries the obvious thing. Cover at least these dimensions unless th
|
|
|
80
80
|
no primary action to populate it.
|
|
81
81
|
When the missing counterpart makes a core task impossible for a whole class of users (e.g. a new
|
|
82
82
|
user literally cannot create an account), file a `Bug`; otherwise file a usability `Improvement`.
|
|
83
|
+
- **Action preconditions & incomplete end-states:** an action whose result only makes sense with
|
|
84
|
+
multiple inputs (compare, merge, combine, bulk-edit) or with some prerequisite met should guide the
|
|
85
|
+
user to satisfy that precondition — by disabling/explaining it until it is met, by collecting the
|
|
86
|
+
inputs first (e.g. a selection tray), or by giving the destination an obvious in-place control to
|
|
87
|
+
complete it. Actually trigger these actions and watch where they land; flag when a primary action:
|
|
88
|
+
- **Fires under-satisfied and strands the user:** e.g. a per-row "Compare" that navigates to a
|
|
89
|
+
comparison of a single item, shows an "under limit / add at least 2" notice, but exposes no
|
|
90
|
+
visible "add another" control — the user is told what is wrong with no in-place means to fix it.
|
|
91
|
+
- **Lands on an incomplete / empty end-state with no next step:** a results or detail screen that
|
|
92
|
+
announces it is empty, partial, or "needs more" yet offers no affordance to add, retry, or return
|
|
93
|
+
to the selection that produced it.
|
|
94
|
+
- **Is offered where it cannot succeed:** a multi-item action exposed on a single item, or an action
|
|
95
|
+
left enabled while its precondition (a selection, a minimum count, a required field) is unmet,
|
|
96
|
+
with no explanation.
|
|
97
|
+
When the user is left unable to complete the action they started, file a `Bug`; when it eventually
|
|
98
|
+
works but the path is confusing or roundabout, file a usability `Improvement`.
|
|
83
99
|
- **Visual/layout quality:** cut-off or truncated text, overlap, cramped/crowded density, offscreen or
|
|
84
100
|
unreachable controls, accidental horizontal scroll, awkward empty space. **Do not judge this by
|
|
85
101
|
eyeballing a screenshot alone** — a control clipped by a few pixels or pushed just past a container
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: exploratory-qa
|
|
3
|
-
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 (human-facing jargon, contextless extracted data, machine-style labels, 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) 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.
|
|
3
|
+
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 (human-facing jargon, contextless extracted data, machine-style labels, 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.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Exploratory QA
|
|
@@ -80,6 +80,22 @@ mistakes, and tries the obvious thing. Cover at least these dimensions unless th
|
|
|
80
80
|
no primary action to populate it.
|
|
81
81
|
When the missing counterpart makes a core task impossible for a whole class of users (e.g. a new
|
|
82
82
|
user literally cannot create an account), file a `Bug`; otherwise file a usability `Improvement`.
|
|
83
|
+
- **Action preconditions & incomplete end-states:** an action whose result only makes sense with
|
|
84
|
+
multiple inputs (compare, merge, combine, bulk-edit) or with some prerequisite met should guide the
|
|
85
|
+
user to satisfy that precondition — by disabling/explaining it until it is met, by collecting the
|
|
86
|
+
inputs first (e.g. a selection tray), or by giving the destination an obvious in-place control to
|
|
87
|
+
complete it. Actually trigger these actions and watch where they land; flag when a primary action:
|
|
88
|
+
- **Fires under-satisfied and strands the user:** e.g. a per-row "Compare" that navigates to a
|
|
89
|
+
comparison of a single item, shows an "under limit / add at least 2" notice, but exposes no
|
|
90
|
+
visible "add another" control — the user is told what is wrong with no in-place means to fix it.
|
|
91
|
+
- **Lands on an incomplete / empty end-state with no next step:** a results or detail screen that
|
|
92
|
+
announces it is empty, partial, or "needs more" yet offers no affordance to add, retry, or return
|
|
93
|
+
to the selection that produced it.
|
|
94
|
+
- **Is offered where it cannot succeed:** a multi-item action exposed on a single item, or an action
|
|
95
|
+
left enabled while its precondition (a selection, a minimum count, a required field) is unmet,
|
|
96
|
+
with no explanation.
|
|
97
|
+
When the user is left unable to complete the action they started, file a `Bug`; when it eventually
|
|
98
|
+
works but the path is confusing or roundabout, file a usability `Improvement`.
|
|
83
99
|
- **Visual/layout quality:** cut-off or truncated text, overlap, cramped/crowded density, offscreen or
|
|
84
100
|
unreachable controls, accidental horizontal scroll, awkward empty space. **Do not judge this by
|
|
85
101
|
eyeballing a screenshot alone** — a control clipped by a few pixels or pushed just past a container
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: exploratory-qa
|
|
3
|
-
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 (human-facing jargon, contextless extracted data, machine-style labels, 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) 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.
|
|
3
|
+
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 (human-facing jargon, contextless extracted data, machine-style labels, 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.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Exploratory QA
|
|
@@ -80,6 +80,22 @@ mistakes, and tries the obvious thing. Cover at least these dimensions unless th
|
|
|
80
80
|
no primary action to populate it.
|
|
81
81
|
When the missing counterpart makes a core task impossible for a whole class of users (e.g. a new
|
|
82
82
|
user literally cannot create an account), file a `Bug`; otherwise file a usability `Improvement`.
|
|
83
|
+
- **Action preconditions & incomplete end-states:** an action whose result only makes sense with
|
|
84
|
+
multiple inputs (compare, merge, combine, bulk-edit) or with some prerequisite met should guide the
|
|
85
|
+
user to satisfy that precondition — by disabling/explaining it until it is met, by collecting the
|
|
86
|
+
inputs first (e.g. a selection tray), or by giving the destination an obvious in-place control to
|
|
87
|
+
complete it. Actually trigger these actions and watch where they land; flag when a primary action:
|
|
88
|
+
- **Fires under-satisfied and strands the user:** e.g. a per-row "Compare" that navigates to a
|
|
89
|
+
comparison of a single item, shows an "under limit / add at least 2" notice, but exposes no
|
|
90
|
+
visible "add another" control — the user is told what is wrong with no in-place means to fix it.
|
|
91
|
+
- **Lands on an incomplete / empty end-state with no next step:** a results or detail screen that
|
|
92
|
+
announces it is empty, partial, or "needs more" yet offers no affordance to add, retry, or return
|
|
93
|
+
to the selection that produced it.
|
|
94
|
+
- **Is offered where it cannot succeed:** a multi-item action exposed on a single item, or an action
|
|
95
|
+
left enabled while its precondition (a selection, a minimum count, a required field) is unmet,
|
|
96
|
+
with no explanation.
|
|
97
|
+
When the user is left unable to complete the action they started, file a `Bug`; when it eventually
|
|
98
|
+
works but the path is confusing or roundabout, file a usability `Improvement`.
|
|
83
99
|
- **Visual/layout quality:** cut-off or truncated text, overlap, cramped/crowded density, offscreen or
|
|
84
100
|
unreachable controls, accidental horizontal scroll, awkward empty space. **Do not judge this by
|
|
85
101
|
eyeballing a screenshot alone** — a control clipped by a few pixels or pushed just past a container
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: exploratory-qa
|
|
3
|
-
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 (human-facing jargon, contextless extracted data, machine-style labels, 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) 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.
|
|
3
|
+
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 (human-facing jargon, contextless extracted data, machine-style labels, 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.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Exploratory QA
|
|
@@ -80,6 +80,22 @@ mistakes, and tries the obvious thing. Cover at least these dimensions unless th
|
|
|
80
80
|
no primary action to populate it.
|
|
81
81
|
When the missing counterpart makes a core task impossible for a whole class of users (e.g. a new
|
|
82
82
|
user literally cannot create an account), file a `Bug`; otherwise file a usability `Improvement`.
|
|
83
|
+
- **Action preconditions & incomplete end-states:** an action whose result only makes sense with
|
|
84
|
+
multiple inputs (compare, merge, combine, bulk-edit) or with some prerequisite met should guide the
|
|
85
|
+
user to satisfy that precondition — by disabling/explaining it until it is met, by collecting the
|
|
86
|
+
inputs first (e.g. a selection tray), or by giving the destination an obvious in-place control to
|
|
87
|
+
complete it. Actually trigger these actions and watch where they land; flag when a primary action:
|
|
88
|
+
- **Fires under-satisfied and strands the user:** e.g. a per-row "Compare" that navigates to a
|
|
89
|
+
comparison of a single item, shows an "under limit / add at least 2" notice, but exposes no
|
|
90
|
+
visible "add another" control — the user is told what is wrong with no in-place means to fix it.
|
|
91
|
+
- **Lands on an incomplete / empty end-state with no next step:** a results or detail screen that
|
|
92
|
+
announces it is empty, partial, or "needs more" yet offers no affordance to add, retry, or return
|
|
93
|
+
to the selection that produced it.
|
|
94
|
+
- **Is offered where it cannot succeed:** a multi-item action exposed on a single item, or an action
|
|
95
|
+
left enabled while its precondition (a selection, a minimum count, a required field) is unmet,
|
|
96
|
+
with no explanation.
|
|
97
|
+
When the user is left unable to complete the action they started, file a `Bug`; when it eventually
|
|
98
|
+
works but the path is confusing or roundabout, file a usability `Improvement`.
|
|
83
99
|
- **Visual/layout quality:** cut-off or truncated text, overlap, cramped/crowded density, offscreen or
|
|
84
100
|
unreachable controls, accidental horizontal scroll, awkward empty space. **Do not judge this by
|
|
85
101
|
eyeballing a screenshot alone** — a control clipped by a few pixels or pushed just past a container
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: exploratory-qa
|
|
3
|
-
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 (human-facing jargon, contextless extracted data, machine-style labels, 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) 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.
|
|
3
|
+
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 (human-facing jargon, contextless extracted data, machine-style labels, 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.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Exploratory QA
|
|
@@ -80,6 +80,22 @@ mistakes, and tries the obvious thing. Cover at least these dimensions unless th
|
|
|
80
80
|
no primary action to populate it.
|
|
81
81
|
When the missing counterpart makes a core task impossible for a whole class of users (e.g. a new
|
|
82
82
|
user literally cannot create an account), file a `Bug`; otherwise file a usability `Improvement`.
|
|
83
|
+
- **Action preconditions & incomplete end-states:** an action whose result only makes sense with
|
|
84
|
+
multiple inputs (compare, merge, combine, bulk-edit) or with some prerequisite met should guide the
|
|
85
|
+
user to satisfy that precondition — by disabling/explaining it until it is met, by collecting the
|
|
86
|
+
inputs first (e.g. a selection tray), or by giving the destination an obvious in-place control to
|
|
87
|
+
complete it. Actually trigger these actions and watch where they land; flag when a primary action:
|
|
88
|
+
- **Fires under-satisfied and strands the user:** e.g. a per-row "Compare" that navigates to a
|
|
89
|
+
comparison of a single item, shows an "under limit / add at least 2" notice, but exposes no
|
|
90
|
+
visible "add another" control — the user is told what is wrong with no in-place means to fix it.
|
|
91
|
+
- **Lands on an incomplete / empty end-state with no next step:** a results or detail screen that
|
|
92
|
+
announces it is empty, partial, or "needs more" yet offers no affordance to add, retry, or return
|
|
93
|
+
to the selection that produced it.
|
|
94
|
+
- **Is offered where it cannot succeed:** a multi-item action exposed on a single item, or an action
|
|
95
|
+
left enabled while its precondition (a selection, a minimum count, a required field) is unmet,
|
|
96
|
+
with no explanation.
|
|
97
|
+
When the user is left unable to complete the action they started, file a `Bug`; when it eventually
|
|
98
|
+
works but the path is confusing or roundabout, file a usability `Improvement`.
|
|
83
99
|
- **Visual/layout quality:** cut-off or truncated text, overlap, cramped/crowded density, offscreen or
|
|
84
100
|
unreachable controls, accidental horizontal scroll, awkward empty space. **Do not judge this by
|
|
85
101
|
eyeballing a screenshot alone** — a control clipped by a few pixels or pushed just past a container
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "lisa-openclaw",
|
|
3
|
-
"version": "2.
|
|
3
|
+
"version": "2.137.0",
|
|
4
4
|
"description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
|
|
5
5
|
"author": {
|
|
6
6
|
"name": "Cody Swann"
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "lisa-openclaw",
|
|
3
|
-
"version": "2.
|
|
3
|
+
"version": "2.137.0",
|
|
4
4
|
"description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, across Claude and Codex.",
|
|
5
5
|
"author": {
|
|
6
6
|
"name": "Cody Swann"
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "lisa-openclaw",
|
|
3
|
-
"version": "2.
|
|
3
|
+
"version": "2.137.0",
|
|
4
4
|
"description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
|
|
5
5
|
"author": {
|
|
6
6
|
"name": "Cody Swann"
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "lisa-openclaw",
|
|
3
|
-
"version": "2.
|
|
3
|
+
"version": "2.137.0",
|
|
4
4
|
"description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
|
|
5
5
|
"author": {
|
|
6
6
|
"name": "Cody Swann"
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "lisa-openclaw",
|
|
3
|
-
"version": "2.
|
|
3
|
+
"version": "2.137.0",
|
|
4
4
|
"description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
|
|
5
5
|
"author": {
|
|
6
6
|
"name": "Cody Swann"
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: exploratory-qa
|
|
3
|
-
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 (human-facing jargon, contextless extracted data, machine-style labels, 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) 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.
|
|
3
|
+
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 (human-facing jargon, contextless extracted data, machine-style labels, 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.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Exploratory QA
|
|
@@ -80,6 +80,22 @@ mistakes, and tries the obvious thing. Cover at least these dimensions unless th
|
|
|
80
80
|
no primary action to populate it.
|
|
81
81
|
When the missing counterpart makes a core task impossible for a whole class of users (e.g. a new
|
|
82
82
|
user literally cannot create an account), file a `Bug`; otherwise file a usability `Improvement`.
|
|
83
|
+
- **Action preconditions & incomplete end-states:** an action whose result only makes sense with
|
|
84
|
+
multiple inputs (compare, merge, combine, bulk-edit) or with some prerequisite met should guide the
|
|
85
|
+
user to satisfy that precondition — by disabling/explaining it until it is met, by collecting the
|
|
86
|
+
inputs first (e.g. a selection tray), or by giving the destination an obvious in-place control to
|
|
87
|
+
complete it. Actually trigger these actions and watch where they land; flag when a primary action:
|
|
88
|
+
- **Fires under-satisfied and strands the user:** e.g. a per-row "Compare" that navigates to a
|
|
89
|
+
comparison of a single item, shows an "under limit / add at least 2" notice, but exposes no
|
|
90
|
+
visible "add another" control — the user is told what is wrong with no in-place means to fix it.
|
|
91
|
+
- **Lands on an incomplete / empty end-state with no next step:** a results or detail screen that
|
|
92
|
+
announces it is empty, partial, or "needs more" yet offers no affordance to add, retry, or return
|
|
93
|
+
to the selection that produced it.
|
|
94
|
+
- **Is offered where it cannot succeed:** a multi-item action exposed on a single item, or an action
|
|
95
|
+
left enabled while its precondition (a selection, a minimum count, a required field) is unmet,
|
|
96
|
+
with no explanation.
|
|
97
|
+
When the user is left unable to complete the action they started, file a `Bug`; when it eventually
|
|
98
|
+
works but the path is confusing or roundabout, file a usability `Improvement`.
|
|
83
99
|
- **Visual/layout quality:** cut-off or truncated text, overlap, cramped/crowded density, offscreen or
|
|
84
100
|
unreachable controls, accidental horizontal scroll, awkward empty space. **Do not judge this by
|
|
85
101
|
eyeballing a screenshot alone** — a control clipped by a few pixels or pushed just past a container
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: exploratory-qa
|
|
3
|
-
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 (human-facing jargon, contextless extracted data, machine-style labels, 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) 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.
|
|
3
|
+
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 (human-facing jargon, contextless extracted data, machine-style labels, 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.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Exploratory QA
|
|
@@ -80,6 +80,22 @@ mistakes, and tries the obvious thing. Cover at least these dimensions unless th
|
|
|
80
80
|
no primary action to populate it.
|
|
81
81
|
When the missing counterpart makes a core task impossible for a whole class of users (e.g. a new
|
|
82
82
|
user literally cannot create an account), file a `Bug`; otherwise file a usability `Improvement`.
|
|
83
|
+
- **Action preconditions & incomplete end-states:** an action whose result only makes sense with
|
|
84
|
+
multiple inputs (compare, merge, combine, bulk-edit) or with some prerequisite met should guide the
|
|
85
|
+
user to satisfy that precondition — by disabling/explaining it until it is met, by collecting the
|
|
86
|
+
inputs first (e.g. a selection tray), or by giving the destination an obvious in-place control to
|
|
87
|
+
complete it. Actually trigger these actions and watch where they land; flag when a primary action:
|
|
88
|
+
- **Fires under-satisfied and strands the user:** e.g. a per-row "Compare" that navigates to a
|
|
89
|
+
comparison of a single item, shows an "under limit / add at least 2" notice, but exposes no
|
|
90
|
+
visible "add another" control — the user is told what is wrong with no in-place means to fix it.
|
|
91
|
+
- **Lands on an incomplete / empty end-state with no next step:** a results or detail screen that
|
|
92
|
+
announces it is empty, partial, or "needs more" yet offers no affordance to add, retry, or return
|
|
93
|
+
to the selection that produced it.
|
|
94
|
+
- **Is offered where it cannot succeed:** a multi-item action exposed on a single item, or an action
|
|
95
|
+
left enabled while its precondition (a selection, a minimum count, a required field) is unmet,
|
|
96
|
+
with no explanation.
|
|
97
|
+
When the user is left unable to complete the action they started, file a `Bug`; when it eventually
|
|
98
|
+
works but the path is confusing or roundabout, file a usability `Improvement`.
|
|
83
99
|
- **Visual/layout quality:** cut-off or truncated text, overlap, cramped/crowded density, offscreen or
|
|
84
100
|
unreachable controls, accidental horizontal scroll, awkward empty space. **Do not judge this by
|
|
85
101
|
eyeballing a screenshot alone** — a control clipped by a few pixels or pushed just past a container
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: exploratory-qa
|
|
3
|
-
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 (human-facing jargon, contextless extracted data, machine-style labels, 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) 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.
|
|
3
|
+
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 (human-facing jargon, contextless extracted data, machine-style labels, 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.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Exploratory QA
|
|
@@ -80,6 +80,22 @@ mistakes, and tries the obvious thing. Cover at least these dimensions unless th
|
|
|
80
80
|
no primary action to populate it.
|
|
81
81
|
When the missing counterpart makes a core task impossible for a whole class of users (e.g. a new
|
|
82
82
|
user literally cannot create an account), file a `Bug`; otherwise file a usability `Improvement`.
|
|
83
|
+
- **Action preconditions & incomplete end-states:** an action whose result only makes sense with
|
|
84
|
+
multiple inputs (compare, merge, combine, bulk-edit) or with some prerequisite met should guide the
|
|
85
|
+
user to satisfy that precondition — by disabling/explaining it until it is met, by collecting the
|
|
86
|
+
inputs first (e.g. a selection tray), or by giving the destination an obvious in-place control to
|
|
87
|
+
complete it. Actually trigger these actions and watch where they land; flag when a primary action:
|
|
88
|
+
- **Fires under-satisfied and strands the user:** e.g. a per-row "Compare" that navigates to a
|
|
89
|
+
comparison of a single item, shows an "under limit / add at least 2" notice, but exposes no
|
|
90
|
+
visible "add another" control — the user is told what is wrong with no in-place means to fix it.
|
|
91
|
+
- **Lands on an incomplete / empty end-state with no next step:** a results or detail screen that
|
|
92
|
+
announces it is empty, partial, or "needs more" yet offers no affordance to add, retry, or return
|
|
93
|
+
to the selection that produced it.
|
|
94
|
+
- **Is offered where it cannot succeed:** a multi-item action exposed on a single item, or an action
|
|
95
|
+
left enabled while its precondition (a selection, a minimum count, a required field) is unmet,
|
|
96
|
+
with no explanation.
|
|
97
|
+
When the user is left unable to complete the action they started, file a `Bug`; when it eventually
|
|
98
|
+
works but the path is confusing or roundabout, file a usability `Improvement`.
|
|
83
99
|
- **Visual/layout quality:** cut-off or truncated text, overlap, cramped/crowded density, offscreen or
|
|
84
100
|
unreachable controls, accidental horizontal scroll, awkward empty space. **Do not judge this by
|
|
85
101
|
eyeballing a screenshot alone** — a control clipped by a few pixels or pushed just past a container
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: exploratory-qa
|
|
3
|
-
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 (human-facing jargon, contextless extracted data, machine-style labels, 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) 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.
|
|
3
|
+
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 (human-facing jargon, contextless extracted data, machine-style labels, 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.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Exploratory QA
|
|
@@ -80,6 +80,22 @@ mistakes, and tries the obvious thing. Cover at least these dimensions unless th
|
|
|
80
80
|
no primary action to populate it.
|
|
81
81
|
When the missing counterpart makes a core task impossible for a whole class of users (e.g. a new
|
|
82
82
|
user literally cannot create an account), file a `Bug`; otherwise file a usability `Improvement`.
|
|
83
|
+
- **Action preconditions & incomplete end-states:** an action whose result only makes sense with
|
|
84
|
+
multiple inputs (compare, merge, combine, bulk-edit) or with some prerequisite met should guide the
|
|
85
|
+
user to satisfy that precondition — by disabling/explaining it until it is met, by collecting the
|
|
86
|
+
inputs first (e.g. a selection tray), or by giving the destination an obvious in-place control to
|
|
87
|
+
complete it. Actually trigger these actions and watch where they land; flag when a primary action:
|
|
88
|
+
- **Fires under-satisfied and strands the user:** e.g. a per-row "Compare" that navigates to a
|
|
89
|
+
comparison of a single item, shows an "under limit / add at least 2" notice, but exposes no
|
|
90
|
+
visible "add another" control — the user is told what is wrong with no in-place means to fix it.
|
|
91
|
+
- **Lands on an incomplete / empty end-state with no next step:** a results or detail screen that
|
|
92
|
+
announces it is empty, partial, or "needs more" yet offers no affordance to add, retry, or return
|
|
93
|
+
to the selection that produced it.
|
|
94
|
+
- **Is offered where it cannot succeed:** a multi-item action exposed on a single item, or an action
|
|
95
|
+
left enabled while its precondition (a selection, a minimum count, a required field) is unmet,
|
|
96
|
+
with no explanation.
|
|
97
|
+
When the user is left unable to complete the action they started, file a `Bug`; when it eventually
|
|
98
|
+
works but the path is confusing or roundabout, file a usability `Improvement`.
|
|
83
99
|
- **Visual/layout quality:** cut-off or truncated text, overlap, cramped/crowded density, offscreen or
|
|
84
100
|
unreachable controls, accidental horizontal scroll, awkward empty space. **Do not judge this by
|
|
85
101
|
eyeballing a screenshot alone** — a control clipped by a few pixels or pushed just past a container
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: exploratory-qa
|
|
3
|
-
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 (human-facing jargon, contextless extracted data, machine-style labels, 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) 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.
|
|
3
|
+
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 (human-facing jargon, contextless extracted data, machine-style labels, 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.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Exploratory QA
|
|
@@ -80,6 +80,22 @@ mistakes, and tries the obvious thing. Cover at least these dimensions unless th
|
|
|
80
80
|
no primary action to populate it.
|
|
81
81
|
When the missing counterpart makes a core task impossible for a whole class of users (e.g. a new
|
|
82
82
|
user literally cannot create an account), file a `Bug`; otherwise file a usability `Improvement`.
|
|
83
|
+
- **Action preconditions & incomplete end-states:** an action whose result only makes sense with
|
|
84
|
+
multiple inputs (compare, merge, combine, bulk-edit) or with some prerequisite met should guide the
|
|
85
|
+
user to satisfy that precondition — by disabling/explaining it until it is met, by collecting the
|
|
86
|
+
inputs first (e.g. a selection tray), or by giving the destination an obvious in-place control to
|
|
87
|
+
complete it. Actually trigger these actions and watch where they land; flag when a primary action:
|
|
88
|
+
- **Fires under-satisfied and strands the user:** e.g. a per-row "Compare" that navigates to a
|
|
89
|
+
comparison of a single item, shows an "under limit / add at least 2" notice, but exposes no
|
|
90
|
+
visible "add another" control — the user is told what is wrong with no in-place means to fix it.
|
|
91
|
+
- **Lands on an incomplete / empty end-state with no next step:** a results or detail screen that
|
|
92
|
+
announces it is empty, partial, or "needs more" yet offers no affordance to add, retry, or return
|
|
93
|
+
to the selection that produced it.
|
|
94
|
+
- **Is offered where it cannot succeed:** a multi-item action exposed on a single item, or an action
|
|
95
|
+
left enabled while its precondition (a selection, a minimum count, a required field) is unmet,
|
|
96
|
+
with no explanation.
|
|
97
|
+
When the user is left unable to complete the action they started, file a `Bug`; when it eventually
|
|
98
|
+
works but the path is confusing or roundabout, file a usability `Improvement`.
|
|
83
99
|
- **Visual/layout quality:** cut-off or truncated text, overlap, cramped/crowded density, offscreen or
|
|
84
100
|
unreachable controls, accidental horizontal scroll, awkward empty space. **Do not judge this by
|
|
85
101
|
eyeballing a screenshot alone** — a control clipped by a few pixels or pushed just past a container
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: exploratory-qa
|
|
3
|
-
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 (human-facing jargon, contextless extracted data, machine-style labels, 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) 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.
|
|
3
|
+
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 (human-facing jargon, contextless extracted data, machine-style labels, 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.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Exploratory QA
|
|
@@ -80,6 +80,22 @@ mistakes, and tries the obvious thing. Cover at least these dimensions unless th
|
|
|
80
80
|
no primary action to populate it.
|
|
81
81
|
When the missing counterpart makes a core task impossible for a whole class of users (e.g. a new
|
|
82
82
|
user literally cannot create an account), file a `Bug`; otherwise file a usability `Improvement`.
|
|
83
|
+
- **Action preconditions & incomplete end-states:** an action whose result only makes sense with
|
|
84
|
+
multiple inputs (compare, merge, combine, bulk-edit) or with some prerequisite met should guide the
|
|
85
|
+
user to satisfy that precondition — by disabling/explaining it until it is met, by collecting the
|
|
86
|
+
inputs first (e.g. a selection tray), or by giving the destination an obvious in-place control to
|
|
87
|
+
complete it. Actually trigger these actions and watch where they land; flag when a primary action:
|
|
88
|
+
- **Fires under-satisfied and strands the user:** e.g. a per-row "Compare" that navigates to a
|
|
89
|
+
comparison of a single item, shows an "under limit / add at least 2" notice, but exposes no
|
|
90
|
+
visible "add another" control — the user is told what is wrong with no in-place means to fix it.
|
|
91
|
+
- **Lands on an incomplete / empty end-state with no next step:** a results or detail screen that
|
|
92
|
+
announces it is empty, partial, or "needs more" yet offers no affordance to add, retry, or return
|
|
93
|
+
to the selection that produced it.
|
|
94
|
+
- **Is offered where it cannot succeed:** a multi-item action exposed on a single item, or an action
|
|
95
|
+
left enabled while its precondition (a selection, a minimum count, a required field) is unmet,
|
|
96
|
+
with no explanation.
|
|
97
|
+
When the user is left unable to complete the action they started, file a `Bug`; when it eventually
|
|
98
|
+
works but the path is confusing or roundabout, file a usability `Improvement`.
|
|
83
99
|
- **Visual/layout quality:** cut-off or truncated text, overlap, cramped/crowded density, offscreen or
|
|
84
100
|
unreachable controls, accidental horizontal scroll, awkward empty space. **Do not judge this by
|
|
85
101
|
eyeballing a screenshot alone** — a control clipped by a few pixels or pushed just past a container
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: exploratory-qa
|
|
3
|
-
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 (human-facing jargon, contextless extracted data, machine-style labels, 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) 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.
|
|
3
|
+
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 (human-facing jargon, contextless extracted data, machine-style labels, 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.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Exploratory QA
|
|
@@ -80,6 +80,22 @@ mistakes, and tries the obvious thing. Cover at least these dimensions unless th
|
|
|
80
80
|
no primary action to populate it.
|
|
81
81
|
When the missing counterpart makes a core task impossible for a whole class of users (e.g. a new
|
|
82
82
|
user literally cannot create an account), file a `Bug`; otherwise file a usability `Improvement`.
|
|
83
|
+
- **Action preconditions & incomplete end-states:** an action whose result only makes sense with
|
|
84
|
+
multiple inputs (compare, merge, combine, bulk-edit) or with some prerequisite met should guide the
|
|
85
|
+
user to satisfy that precondition — by disabling/explaining it until it is met, by collecting the
|
|
86
|
+
inputs first (e.g. a selection tray), or by giving the destination an obvious in-place control to
|
|
87
|
+
complete it. Actually trigger these actions and watch where they land; flag when a primary action:
|
|
88
|
+
- **Fires under-satisfied and strands the user:** e.g. a per-row "Compare" that navigates to a
|
|
89
|
+
comparison of a single item, shows an "under limit / add at least 2" notice, but exposes no
|
|
90
|
+
visible "add another" control — the user is told what is wrong with no in-place means to fix it.
|
|
91
|
+
- **Lands on an incomplete / empty end-state with no next step:** a results or detail screen that
|
|
92
|
+
announces it is empty, partial, or "needs more" yet offers no affordance to add, retry, or return
|
|
93
|
+
to the selection that produced it.
|
|
94
|
+
- **Is offered where it cannot succeed:** a multi-item action exposed on a single item, or an action
|
|
95
|
+
left enabled while its precondition (a selection, a minimum count, a required field) is unmet,
|
|
96
|
+
with no explanation.
|
|
97
|
+
When the user is left unable to complete the action they started, file a `Bug`; when it eventually
|
|
98
|
+
works but the path is confusing or roundabout, file a usability `Improvement`.
|
|
83
99
|
- **Visual/layout quality:** cut-off or truncated text, overlap, cramped/crowded density, offscreen or
|
|
84
100
|
unreachable controls, accidental horizontal scroll, awkward empty space. **Do not judge this by
|
|
85
101
|
eyeballing a screenshot alone** — a control clipped by a few pixels or pushed just past a container
|