testeiya 0.3.9 → 0.3.14

package/skills/testomatio/explorbot/explorbot-setup/SKILL.md

@@ -0,0 +1,86 @@
+---
+name: explorbot-setup
+description: Use to install Explorbot into a project — first-time setup, an `explorbot.config.js` in the repo, connecting an AI provider, teaching it how to log in, or when a command fails because the project has no config. Ends once `explorbot navigate` reaches the app.
+license: MIT
+metadata:
+  author: Testomat.io
+  version: 1.2.0
+---
+
+# Explorbot Setup
+
+Install Explorbot into the user's project, connect a provider, teach it how to reach the app, and prove it with one navigation.
+
+The config, the knowledge files, and the generated tests all land in the repo, so they are reviewed and versioned like the rest of the code. That is the point of installing locally.
+
+**To run Explorbot without installing it into the project, this is the wrong skill** — [[explorbot-fundamentals]] covers that: `npx`, a provider, no project files.
+
+**Scope ends when `npx explorbot navigate <path>` exits `0`** — exploring and testing belong to [[explorbot-fundamentals]].
+
+## 1. Requirements
+
+- Node ≥ 24 or Bun. If neither exists, stop — do not install a runtime.
+- The generated config uses `import`, so `package.json` must be ESM. `npm init -y` produces CommonJS; if `"type"` is missing or `"commonjs"` in an existing file, ask before changing it, and write `explorbot.config.mjs` (passed as `--config`) if the user declines.
+- Explorbot is for CRUD-heavy apps. Warn before installing if the target is a landing page, blog, CMS, or static site.
+
+## 2. Install
+
+```bash
+npm pkg set type=module
+npm i explorbot --save
+npx playwright install chromium     # ~/.cache/ms-playwright, once per machine
+npx explorbot init                  # writes explorbot.config.js, .env, output/
+```
+
+## 3. Provider
+
+**Providers, model ids, and key variable names live in Explorbot, never in this skill.** The generated config ships one provider; `basics/providers.md` in the docs names the package and model ids for the others, and `models.json` holds the current recommendations.
+
+- Ask which provider the user has an account with, and swap the import and the three model lines if it is not the one in the template.
+- `npm i` the matching provider package.
+
+The key: ask the user to paste it into `.env` in their editor and say "continue", then verify with `grep -q "^<KEY>=." .env`. Confirm `.env` is gitignored. Never echo a key back.
+
+`~/.explorbot/.env` is also read on every run, filling in variables the project `.env` does not set.
+
+## 4. App URL
+
+Ask for it, and write it to `web.url` in the config — host only, no path. Explorbot clicks, fills, and submits on its own, so staging beats production.
+
+Do not guess it. Look for evidence in the project — `package.json` scripts, `.env` files, framework ports — and suggest what you find with its source. Otherwise ask in plain text. Never propose a URL from this skill or from memory.
+
+## 5. Verify
+
+Walk the rungs in order. Stop at the first failure, fix it, resume.
+
+1. `curl -sS -o /dev/null -w "%{http_code}\n" <url>` — `000` is DNS/VPN/wrong host, `5xx` is the app itself, `200` skips to rung 3.
+2. `curl -sIL -o /dev/null -w "%{url_effective}\n" <url>` after a `3xx`/`401`/`403`. A login-looking final URL means credentials are needed: do rung 4 first.
+3. `npx explorbot navigate <path> --session` — exit `0` ends setup. `--session` saves cookies to `output/session.json`. On exit `1`, read `output/explorbot.log`: an auth wall sends you to rung 4, anything else is a wrong path or a broken page.
+4. Teach auth, knowledge first, values second:
+
+   ```bash
+   npx explorbot knows /login      # reuse existing variable names if auth knowledge exists
+   npx explorbot learn "/login" 'Sign in with ${env.APP_USER} / ${env.APP_PASSWORD}'
+   ```
+
+   Name only the credentials — no selectors or DOM hints; the Navigator finds the fields. Then have the user add the two variables to `.env`, verify with `grep`, and repeat rung 3. Ask for a test account on a non-production environment.
+
+   Still failing on auth: add one sentence to the knowledge with `learn` (real form URL, SSO, second factor), never a rewrite.
+
+`npx explorbot context <path>` prints headings, matched knowledge, and interactive elements with no AI calls — use it to debug a rung for free.
+
+## 6. Handoff
+
+Report what the project now has: `explorbot.config.js`, `.env` (gitignored), `knowledge/`, `output/` with a saved session. Then hand off to [[explorbot-fundamentals]] with a first command:
+
+```bash
+npx explorbot explore /<crud-page> --max-tests 10
+```
+
+## Anti-patterns
+
+- Installing into the project when the user only wanted to try Explorbot — that is [[explorbot-fundamentals]].
+- Naming providers, model ids, or key variables without reading them from the docs or the generated config.
+- Putting secrets in knowledge files or config — always `${env.NAME}`, values in `.env`.
+- Driving `explorbot start` — it is an interactive TUI; ask the user to run it.
+- Asking upfront for target pages, features, or test counts.

package/skills/testomatio/explorbot/prima/SKILL.md

@@ -0,0 +1,87 @@
+---
+name: prima
+description: Use for any browser work — driving a web app, checking a behaviour, filling a form, reading a page — via npx prima-cli, in preference to npx playwright-cli, which prima runs on top of and falls back to. Covers npx prima-cli check, do, pw, verify, ask, research, go, status, report, browser, config, and session setup. Trigger on "prima", "prima-cli", "npx prima-cli", on a browser task described as behaviour ("confirm the editor saves"), and whenever npx playwright-cli would otherwise be driven step by step.
+license: MIT
+metadata:
+  author: Testomat.io
+  version: 0.3.0
+---
+
+# Prima
+
+Prima is an AI layer on top of playwright-cli. It drives the browser playwright-cli already has open, taking behaviour described in words instead of locators, and returns a plain-text envelope. Always invoke both through npx: `npx prima-cli ...` and `npx playwright-cli ...`.
+
+**Prefer prima to playwright-cli for anything on a web page.** Snapshots stay inside prima instead of landing in your context, and it reuses the research maps and recorded experience it already has for a page — so a scenario costs a fraction of the tokens of the same scenario driven by hand. Use `npx playwright-cli` directly when prima has no command for the job, or when no AI model is configured (`pw` still works then).
+
+## Models
+
+Prima needs an AI model, taken from the environment — there is no init step:
+
+```bash
+export PRIMA_CLI_AI_MODEL=openrouter/openai/gpt-oss-120b   # provider comes from the name
+```
+
+Screenshot analysis needs its own model, never guessed from the main one: set `PRIMA_CLI_VISION_MODEL`, or pass `--vision-model` for one run. Without it prima still runs, but `check` settles outcomes from the run log rather than the page as seen. `npx prima-cli config` prints what this directory resolves to; `--json` for machine form. Every `PRIMA_CLI_*` variable mirrors the `EXPLORBOT_*` one and wins over it, so an explorbot setup is not disturbed.
+
+## Session
+
+Attach to a playwright-cli session:
+
+```bash
+npx playwright-cli open http://localhost:3000    # start
+npx prima-cli <command> ...                      # drive
+npx playwright-cli close                         # end
+```
+
+Or let prima own the browser itself:
+
+```bash
+npx prima-cli browser start --url http://localhost:3000
+npx prima-cli <command> ...
+npx prima-cli browser stop          # --all stops every instance
+```
+
+- Attached to playwright-cli, prima never launches or closes the browser — it attaches and disconnects. With a prima-owned browser, `browser start` holds it open until `browser stop`; `browser status` and `browser list` report what is running.
+- `--pw-session <title>` picks the session when several playwright-cli sessions are open; `--instance <name>` separates prima-owned browsers for parallel work.
+- `--url <url>` opens that page first when the session has none; `--endpoint <ep>` attaches to a browser server directly, skipping discovery.
+- Requires Node.js 24+. Playwright browsers come from `npx playwright install chromium`.
+- Every command is logged as it runs; `npx prima-cli report` turns the session into an html and markdown report, browser open or not.
+- `npx explorbot prima <command>` runs the same tool if explorbot is already installed.
+
+## Tiers
+
+Start at `check`. Come down a rung only when the one above cannot hold the work.
+
+```bash
+npx prima-cli check "a workflow can be created and appears in the list" --expected "the new workflow is listed"
+npx prima-cli do "open the account menu" "choose settings" "switch the theme to dark" "check it took effect"
+npx prima-cli pw "({ page }) => page.click('[data-test=submit]')"
+```
+
+- **Pass `do` the whole remaining sequence, never one step per call** — that is the entire cost advantage.
+- `pw` takes executable code only. Never give it a description; never give `check`/`do` a locator.
+- `check` and `do` legitimately run for minutes. Do not kill and retry.
+- `check` runs on the page already open and never reloads it, so an open dialog, a selected tab or a filled form survives it.
+- `--expected` is repeatable for several outcomes; without it the scenario text is the single expected outcome.
+- Below `pw` sits playwright-cli itself.
+
+Also: `verify` (alias `assert`), `ask` (`--no-vision` answers from structure only), `research` (`--data` includes extraction, `--deep` expands hidden elements, `--fresh` re-maps past the cache), `go`, `status <hash>`, `report`, `config`, `browser`. Run `npx prima-cli <command> --help` for each.
+
+## Reading the envelope
+
+- **Trust the verdict in `### Result`.** Re-verifying a PASSED outcome with another command is the waste this tool exists to remove.
+- `ok: true` means the action you asked for landed; nothing is substituted or retried along a different route.
+- `### Steps` marks each line `ok`, `FAIL` or `??`. `??` is an instruction that ran but the run ended without confirming — the actions that ran are listed above it, judge from those. Only `FAIL` and an instruction the page could not carry out fail the command.
+- `not verified` means the run never checked that outcome — not that it is false, and not a failure.
+- **`CONTRADICTION` is a finding, not a verdict to argue with.** The run and the picture disagree: something the assertions matched is not visible on screen, or the reverse. Both sides are quoted under the outcome, and `### Artifacts` names the html, aria and screenshot on disk — read those and judge the page yourself instead of taking the verdict on trust. Treat it as a bug in the app and look at it before anything else.
+- A `### Warning` saying the outcomes came from the run log alone means no screenshot backed them: set `PRIMA_CLI_VISION_MODEL` (or pass `--vision-model`), and until then do not trust a visual claim from `check`.
+- A run that could not complete says so, rather than reporting it as a failure of the app.
+- `npx prima-cli config` shows which model answers for each role.
+
+## Visual questions
+
+Layout, position, colour, overlap, whether something is cut off — an accessibility tree does not carry any of it, and neither does an assertion that passed.
+
+- `check` settles its outcomes against a screenshot of the final page. What a user can see is the proof; the run log only says what was done.
+- `ask "<question>"` — reads a screenshot, answers in prose. Use for anything open-ended about appearance.
+- `verify` proves claims with assertions; each comes back PASSED or FAILED with its playwright form, no overall verdict — read the lines and decide. When no assertion can express a claim it reports "none ran" instead of judging it failed.

package/skills/testomatio/qa-process/qa-explain-behavior/SKILL.md

@@ -0,0 +1,111 @@
+---
+name: qa-explain-behavior
+description: Answers QA questions about product behavior — what features exist, how user flows work, what business rules apply, what edge cases the system handles, and what is or is not implemented. Use whenever the user asks a question about WHAT the system does (features, flows, rules, conditions, who-can-do-what, when-does-X-happen, is-Y-supported). Trigger even when the user does not say "QA" — phrases like "what happens when…", "can a user…", "is it possible to…", "does the system…", "is X implemented", "what should I test for…", "what are the edge cases of…", or "walk me through the flow for…" all qualify. Do NOT trigger for questions that are clearly about implementation (architecture, database schema, code structure, performance, types, dependencies).
+license: MIT
+metadata:
+  author: Testomat.io
+  version: 1.0.0
+---
+
+# QA Explain Behavior
+
+Answer a QA engineer who is testing the product. They care about **product behavior**, not implementation. Read the codebase like a manual and translate it into plain-language descriptions of what the system does.
+
+| What | File |
+|------|------|
+| Output shape per question type — feature, flow, yes/no, permissions, edge cases | [references/answer-shapes.md](references/answer-shapes.md) |
+| Worked answers, plus bad-vs-good contrasts | [references/examples.md](references/examples.md) |
+
+## The mindset shift
+
+The QA engineer is not going to read the code. They are going to click buttons, fill forms, and try to break things. The answer should help them know what to click, what to expect, and where the product might fail. Describe the product like someone who has used it end-to-end.
+
+A QA engineer's mental model is built from:
+
+- **Actors** — who is doing this: guest, member, admin, owner, integration.
+- **Actions** — what they do: click, submit, upload, invite.
+- **Outcomes** — what they see or what changes: page, message, email, status.
+- **Rules** — when it's allowed, when it's blocked, what limits apply.
+- **Edge cases** — empty state, very large input, duplicate, expired, offline.
+
+Frame every answer in those terms.
+
+## What to investigate
+
+Look at the parts of the codebase that **describe behavior**, not the parts that describe data:
+
+- **Service and controller layers** — what user actions exist, and the multi-step flows behind them.
+- **Business logic** — the rules that decide what is allowed, what changes, and what happens next.
+- **Authorization and permissions system** — who can do what, and whether the block is in the UI, on the server, or both.
+- **Feature flags** — what is switched on, off, or limited to certain accounts.
+- **Configuration** — limits, defaults, and behavior that differs per environment or plan.
+- **Models** — only *validations*, *state machines*, *callbacks*, and *scopes with business meaning*. Not columns, associations, or types.
+- **Views, serializers, mailers** — what the user sees and receives.
+- **Background jobs** — what happens after the user-visible action: notifications, syncs, cleanups.
+- **Tests** — they describe expected behavior in plain English; very useful.
+
+## What to ignore
+
+Unless the user explicitly asks, never mention:
+
+- Database tables, columns, indexes, schema.
+- Class names, file paths, line numbers, module structure.
+- Framework terminology and internals — ORM concepts, callbacks, middleware, queues, dependencies.
+- Variable names, method names, parameters, types.
+- SQL, code snippets, regex.
+- Performance, scaling, architecture decisions.
+- Migration history, refactors.
+
+If the user wants this, they will ask. The default is product-level only.
+
+## How to answer
+
+**Be compact.** A QA engineer scans, they don't read paragraphs. Short bullets, short sentences, plain words.
+
+**Lead with the answer.** No preamble, no restating the question, no "Let me explain…".
+
+**Use product vocabulary, not code vocabulary:**
+
+- "the user", "the admin", "the workspace owner" — not `current_user`.
+- "the settings page" — not a controller action name.
+- "an email is sent" — not a mailer class.
+- "it's blocked" — not "validation fails".
+- "in the background" — not the name of the queue.
+
+**Structure by what a tester needs.** When describing a feature, default to this shape:
+
+```
+**What it does:** one line
+**Who can do it:** roles / permissions
+**How to trigger it:** user action(s)
+**What happens:** outcomes (UI, emails, notifications, status changes)
+**Rules / limits:** validations, conditions
+**Edge cases:** empty, duplicate, large, expired, blocked, etc.
+**Not implemented:** anything the QA might expect that does NOT exist
+```
+
+For flow questions, describe the flow as numbered steps from the user's point of view. For "is X supported?" questions, answer **yes** or **no** first, then a one-line reason, then any nuance. Permission questions, edge-case sweeps, failure behavior, comparisons, and how to phrase uncertainty each have their own shape in [references/answer-shapes.md](references/answer-shapes.md).
+
+**Surface what is missing.** The most valuable thing a QA engineer can hear is "this is not implemented", "there is no UI for this — only the API supports it", or "this only works for paying accounts". Always look for gaps and call them out: a flag, a TODO, a commented-out path, an action reachable only via API.
+
+**Be honest about uncertainty.** If the codebase is ambiguous, say "I see X but I'm not sure whether Y" rather than guessing. A QA testing on a wrong assumption is worse than a QA who knows to verify.
+
+## Do not write code
+
+Never produce code blocks, schema, configuration snippets, or pseudocode unless the user explicitly asks ("show me the code", "give me the SQL"). The default response is prose and bullets only. When tempted to paste code "to be helpful", describe the behavior instead.
+
+When the product **is** a CLI or an API, the commands, flags, and endpoints a user types are product surface, not implementation — name them exactly, the same way you would name a button.
+
+[references/examples.md](references/examples.md) has worked answers — a full feature description, a flow walkthrough, an edge-case sweep — and two bad-vs-good contrasts showing what code leaking into an answer looks like.
+
+## Next actions
+
+Offer after the answer:
+
+- Turn the behavior into risk scenarios → `qa-thinking` skill.
+- Turn it into test cases or a checklist → `qa-write-test-cases` skill.
+- Map which tests already cover it → `qa-test-code-coverage` skill.
+
+## Final reminder
+
+Compact. Plain language. Behavior, not code. Highlight gaps. No code unless asked.

package/skills/testomatio/qa-process/qa-explain-behavior/references/answer-shapes.md

@@ -0,0 +1,116 @@
+# Answer shapes
+
+Pick the shape that matches the question. Skip any section that doesn't apply —
+never pad with "N/A" or "None". Bullets over paragraphs, short lines, plain
+words.
+
+## Feature description — "what does X do", "explain X"
+
+The default shape. Most questions land here.
+
+```
+**What it does:** one line
+**Who can do it:** roles / permissions
+**How to trigger it:** the clicks, in order
+**What happens:** outcomes — screen, message, email, status change, background work
+**Rules / limits:** validations, conditions, plan gating
+**Edge cases:** empty, duplicate, too large, expired, blocked, concurrent
+**Not implemented:** anything a tester would reasonably expect that doesn't exist
+```
+
+## Flow walkthrough — "walk me through…", "how does someone…"
+
+Numbered steps from the user's point of view, one screen per step. Say where
+the flow can branch or die.
+
+```
+1. User clicks **X** on the … page.
+2. …
+3. …
+
+**Branches:**
+- If <condition>, they land on … instead.
+- If <condition>, it stops with "<the actual message>".
+
+**After it finishes:** <emails, notifications, anything delayed>
+```
+
+## Yes / no — "is X supported", "can I…", "is there a way to…"
+
+Answer in the first word. Then one line of why. Then nuance, if any.
+
+```
+Yes — partially.
+- <what works, and where>
+- <what doesn't>
+- <what exists in the API but has no UI>
+```
+
+If it's a flat no, one or two lines is the whole answer. Don't inflate it.
+
+## Permissions — "can a *role* do X", "who can…"
+
+Say whether the block is in the UI, on the server, or both — a tester needs to
+know if they can get past it by calling the API directly.
+
+```
+No. Guests can view … but cannot …
+The button is hidden for guests, and the action is blocked server-side too.
+```
+
+For several roles at once, use a small table:
+
+```
+| Role | Create | Edit | Delete |
+|---|---|---|---|
+| Owner | ✅ | ✅ | ✅ |
+| Member | ✅ | ✅ | ❌ |
+| Guest | ❌ | ❌ | ❌ |
+```
+
+## Edge cases — "what could go wrong", "what should I test"
+
+Group by the kind of input or state, so the list is walkable as a test session.
+Each line is a condition plus what actually happens.
+
+```
+**Empty / missing:** …
+**Duplicate:** …
+**Too large / too many:** …
+**Wrong format:** …
+**Expired / stale:** …
+**Permissions:** …
+**Concurrent:** two people doing this at once …
+**External failure:** the integration is down / the upload fails …
+```
+
+## Failure behaviour — "what happens if it fails"
+
+Testers need the observable result, not the exception.
+
+```
+**What the user sees:** the actual message or screen
+**What state it's left in:** saved / not saved / half-saved
+**Whether it retries:** automatically, manually, or not at all
+```
+
+## Comparison — "what's the difference between X and Y"
+
+Two columns, same rows. Only rows where they actually differ.
+
+## Phrasing uncertainty
+
+Never guess silently. Use the shape "I can see X, but I couldn't confirm Y":
+
+- "The API accepts this, but I couldn't find a UI that reaches it."
+- "There's a limit of 100 here, but I'm not sure whether it's enforced on
+  import as well — worth verifying."
+- "This looks gated by a feature flag. Whether it's on for your account, I
+  can't tell from the code."
+
+## Length
+
+Match the question. A yes/no question gets two lines. A "walk me through the
+whole import flow" gets a full shape. If your answer runs past about a screen,
+either the question was broad or you're explaining implementation — check
+which.

package/skills/testomatio/qa-process/qa-explain-behavior/references/examples.md

@@ -0,0 +1,157 @@
+# Worked examples
+
+> The product below is **invented** — a generic workspace app with members,
+> documents and file imports. These examples show the shape and register of a
+> good answer, not real behaviour. Always answer from what you actually find in
+> the codebase in front of you.
+
+## Example 1 — feature description
+
+**Q: "What happens when a user is invited to a workspace?"**
+
+```
+**What it does:** sends an invitation so someone can join a workspace with a chosen role.
+**Who can do it:** workspace owner and admins.
+**How to trigger:** Workspace Settings → Members → "Invite" → enter email + pick role.
+**What happens:**
+- Invitation email is sent to that address.
+- Pending invite shows in the members list.
+- If the email matches an existing user, they accept by clicking the link and the workspace appears in their sidebar.
+- If not, they're prompted to register first; after register they land on the workspace.
+**Rules:**
+- Email must be valid.
+- Same email can't have two pending invites for the same workspace.
+- Role must be one of: owner, admin, member, guest.
+**Edge cases:**
+- Invite link expires after 7 days.
+- If the invited user is already a member, the invite is rejected with a message.
+- Re-sending an invite resets the expiry.
+**Not implemented:** bulk invite via CSV is not available in the UI.
+```
+
+Why it works: every line is something a tester can act on. The last line is the
+most valuable one in the answer.
+
+## Example 2 — permission question
+
+**Q: "Can a guest delete a document?"**
+
+```
+No. Guests can view documents but cannot edit, create, or delete them. The
+delete button is hidden for guests, and the action is also blocked server-side.
+```
+
+Two lines, and it answers the follow-up question a tester was about to ask —
+whether the block survives a direct API call.
+
+## Example 3 — support question with nuance
+
+**Q: "Is there a way to export a document?"**
+
+```
+Yes — partially.
+- CSV export is available from the document page (top-right menu).
+- PDF export is **not** implemented.
+- The raw JSON can be retrieved via API, but there's no UI button for it.
+```
+
+"Yes — partially" in the first line, then exactly where the line falls.
+
+## Example 4 — flow walkthrough
+
+**Q: "Walk me through importing records from a file."**
+
+```
+1. Workspace → Data → "Import" → pick a file (CSV or XLSX).
+2. A preview shows the first rows with a column-mapping step — you map each
+   column to a field (name, owner, category, tags).
+3. Confirm. The import runs in the background; the page shows a progress state.
+4. When it finishes you get an in-app notification with a summary: created,
+   updated, skipped.
+
+**Branches:**
+- If a row has no name, it's skipped and counted in "skipped".
+- If a record with the same name already exists in that category, it's updated
+  rather than duplicated.
+- If the whole file can't be parsed, nothing is imported and you get an error
+  on the same screen.
+
+**Rules / limits:**
+- File must be under 10 MB.
+- Only CSV and XLSX; other extensions are rejected before upload.
+
+**Edge cases:**
+- An empty file imports nothing and reports "0 created".
+- Closing the tab doesn't cancel the import — it keeps running.
+
+**Not implemented:** there's no way to undo or roll back an import.
+```
+
+## Example 5 — edge-case sweep
+
+**Q: "What should I test around document deletion?"**
+
+```
+**Permissions:** owner and admin can delete; member and guest cannot (hidden and blocked server-side).
+**Empty:** deleting a document with no content works and removes it immediately.
+**In use:** a document open in someone else's tab can be deleted — their next save fails with a generic error, which is worth checking.
+**Linked data:** attached files are removed in the background, so they can outlive the document by a few seconds.
+**Concurrent:** two admins deleting the same document at once — the second gets a "not found" error rather than a friendly message.
+**Undo:** there is none, and there's no confirmation step on the API — only in the UI.
+```
+
+## Contrast — the same question answered badly
+
+**Q: "What happens when an import finishes?"**
+
+❌ **Bad — implementation leaking through:**
+
+```
+When the import completes, the imports controller calls the finalizer service,
+which updates the status column on the imports table to "finished" via a
+persistence callback. A post-commit hook enqueues the notification job on the
+background queue, which reads the workspace notification settings and delivers
+through the import mailer.
+```
+
+✅ **Good — same facts, tester's language:**
+
+```
+**What happens:**
+- The import's status changes to "Finished" and the page updates with the final created/updated/skipped counts.
+- Everyone subscribed to the workspace gets an email summary — sent in the background, so it can arrive a few seconds late.
+- The import appears in the workspace's history.
+**Edge cases:**
+- An import with no valid rows still finishes, showing 0 created.
+- If notifications are turned off for the workspace, no email is sent — the import still finishes normally.
+```
+
+The bad version is not wrong, it's unusable: nothing in it can be clicked,
+observed, or verified from the UI.
+
+## Contrast — padding vs. answering
+
+**Q: "Can I rename a workspace?"**
+
+❌ **Bad:**
+
+```
+Great question! Let me walk you through workspace renaming. Workspaces in the
+system have a name attribute which can be modified. Here's what I found:
+**What it does:** allows renaming a workspace.
+**Who can do it:** users with permission.
+**Rules / limits:** N/A
+**Edge cases:** N/A
+```
+
+✅ **Good:**
+
+```
+Yes. Workspace Settings → General → change the name → Save.
+Only the workspace owner can do it; admins see the field disabled.
+The name must be unique inside the account, 3–60 characters.
+The workspace URL doesn't change when you rename — it keeps the original slug.
+```
+
+No preamble, no empty sections, and it ends on the detail a tester would
+otherwise discover the hard way.

package/skills/testomatio/qa-process/qa-lead-strategy-advisor/SKILL.md

@@ -0,0 +1,91 @@
+---
+name: qa-lead-strategy-advisor
+description: A strategic advisor for QA, quality, testing, and automation processes. Acts as a senior QA lead. First interviews the user and scans the project to build rich context, then identifies the highest-impact gaps and delivers a prioritized step-by-step roadmap, routing execution to specialized skills. Trigger this skill when the user wants to set up QA from scratch, improve an existing process, set up test automation, decide where to start with testing, or run a QA maturity review — e.g. "set up QA for this project", "improve our QA/testing/automation process", "where should we start with testing", "we have no tests, help", "review our quality process". Also trigger this skill when the user describes problems like "low/poor quality", "missing/a lot of bugs", "no testing".
+---
+
+# QA Strategy Advisor
+
+**Strategic advisor** for QA, quality, testing, and automation processes. I **interview → assess → prioritize → advise**: gather context first, then tell you the most important thing to do next, and route execution to specialized skills only when user asks. I advise on _what to do, why, and in what order_ — I never dump full detail up front; I expand a step only when user asks.
+
+## Phase 0. Plan mode
+
+**Strictly** recommend user to use/switch to "PLAN" mode in their AI agent.
+
+## Phase 1 — Discovery (gather context before advising)
+
+1. **Auto-detect** by scanning the codebase and checking existing MCP tools.
+
+Run `scan-automation-project` to detect languages, frameworks, and existing manual/automated tests/cases.
+
+2. **Interview** the user — interactively, in rounds.
+
+**This step is crucial**. Don't rely just on scanned code. You should know the current product, processes, team, problems. They will not be defined in the codebase.
+Don't be shy to ask questions, clarify, argue. QA is a wide and complex area — the more you know about how it is going, the better you can advise.
+
+**This is a dialogue, not a questionnaire.** Never dump all interview questions as one plain-text list — that ends the conversation instead of starting it. Instead:
+
+- **Use the `AskUserQuestion` tool** (if your agent provides it) to ask questions with selectable options. Ask **3–5 questions per round**, then wait for the answers before asking the next round.
+- If you are sure about **concrete options** – use them, plus let the user type their own answer. Use multi-select where several answers can be true.
+- **Adapt follow-up rounds to previous answers.** If the user says "no CI", drill into how releases are verified; if they name a TMS, ask for access/links. Skip questions the scan already answered.
+- Run **3–4 rounds** total — enough to cover the topics below, short enough not to exhaust the user.
+- If the `AskUserQuestion` tool is not available, ask **at most 3 questions in plain text and stop your turn** to wait for the reply — never continue past unanswered questions.
+
+Topics to cover across the rounds:
+
+- **Tools/trackers** — ask user which resources/tools/trackers do they use, ask for links, content, etc.
+- **Processes** — ask to describe the current processes they use.
+- **QA/Testing** — which QA and testing activities are performed today, which testing artifacts exist.
+- **Product & risk** — what the app does, who uses it, highest-risk areas, release cadence.
+- **Team & process** — team size, QA roles, how testing happens today, what's owned by whom; what is the role of current user.
+- **Assets** — requirements/docs, existing test cases, TMS in use
+- **CI/CD** — ask user to describe the current CI/CD pipeline, ask for links, content, etc.
+- **Automation** — frameworks, rough coverage, reporting, flakiness/pain (ask if could not detect from codebase).
+- **Problems/issues** — ask to describe the current problems/issues.
+- **Goals** — biggest pain point, what success looks like.
+
+Store gathered context to markdown file `.testeiya/TESTING.md` and check if this file exists. If it exists, append to it. If it does not exist, create it.
+
+3. **Summarize** and get approval from the user.
+
+Show gathered context to user (in a well structured, formatted and readable way). Keep it scannable — short bullets, not paragraphs.
+
+Then ask for approval (use `AskUserQuestion` tool if available):
+
+> Did I get the picture right?
+>
+> - ✅ **Yes — build the roadmap** (recommended)
+> - ✏️ **Let's adjust** — I'll tell you what to fix
+> - ❌ **No — let's revisit the questions**
+
+If the user picks corrections, apply them, show only the changed lines, and re-confirm the same way. Never end the turn with "say go if it looks right" as plain text.
+
+## Phase 2 — Assessment & prioritized roadmap
+
+Map findings to QA pillars: **quality assurance and testing processes · test design · test coverage · automation, CI · reporting/metrics · TMS integration**. Find the gaps, rank by **impact first, then effort**, and present an ordered list (starting with the most important).
+
+**Formatting is critical** — read [references/output-format.md](references/output-format.md) before producing the roadmap and follow it strictly. It contains the item template and a full example. Never output dense numbered paragraphs.
+
+**Display rule (critical)**
+
+- Print the full roadmap as the **final message of your turn**, do **not** call `AskUserQuestion` in the same turn when you display the roadmap (it causes the roadmap to be hidden).
+- End the roadmap with the 💬 call-to-action line from the output format (e.g. `Type "execute 1", "expand 1", "adjust", or "save"`). That line replaces the interactive menu for this turn.
+
+Store roadmap to `.testeiya/TESTING.md`.
+
+## Phase 3. Execute
+
+Phase 3 starts when the user chooses what to do next.
+
+- If the reply is a clear command ("execute 1", "expand 2", "save") — act on it directly.
+- If the reply is ambiguous ("ok", "looks good", a question) — **now** offer the menu via `AskUserQuestion` (the roadmap is already visible above, so it's safe here):
+
+> What's next?
+>
+> - ▶️ **Execute item 1** — <one-line restatement of item 1>
+> - 🔎 **Details of item 1** — see the detailed plan first
+> - ✏️ **Adjust the roadmap** — reorder, drop, or add items
+> - 💾 **Save & stop here** — write the roadmap to a file and finish
+
+After the user's approval, route execution to the `testing-workflow` or any other relevant skill (or act without a skill if none fits).
+
+When an item finishes, confirm the result and offer the next roadmap item the same way — keep the loop going until the user stops.