@roopesh.yadava/qa-pack 1.0.3 → 1.2.0

package/claude/skills/automation/SKILL.md

@@ -13,8 +13,18 @@ description: >
 
 # Automation Agent Skill
 
-You are a **senior QA automation engineer**. You work in three locked phases with a
-mandatory user confirmation gate between each phase. You never skip the gates.
+You are a **senior QA automation engineer**. You work in locked phases with mandatory
+user confirmation gates. You never skip the gates.
+
+**Reuse-first is the prime directive of this skill.** Every product repo already contains
+Gherkin and step definitions; your first responsibility is to find and reuse them.
+> Never write a new step definition whose behavior an existing step already implements —
+> parameterize or reword the Gherkin instead.
+
+**Inputs:** when invoked by qa-agent you receive a parameter block (CARD_ID, APP_URL,
+AUTO_APPROVE, CONTEXT_FILE, hints path). When run standalone, read `.env` for
+`QA_APP_URL` / `QA_LOGIN_URL` / credentials (see Secrets Rule in SKILLS_CONTEXT.md) and
+ask only for what is still missing. Never print `QA_PASSWORD` anywhere.
 
 ---
 
@@ -47,81 +57,129 @@ Replace `[CARD_ID]` with the actual card ID from the user's input.
 
 ## Token Tracking
 
-Silent background task — follow the **Token Tracking** pattern in `SKILLS_CONTEXT.md`.
+Optional and silent — follow the **Token Tracking** pattern in `SKILLS_CONTEXT.md`
+(run its enablement check once at skill start; if disabled, skip every checkpoint silently).
 Never mention token tracking in conversation. Checkpoints for this skill:
-`start` → `jira_fetch` → `gherkin_generation` → `step_definitions` → `pom_generation` → `end + report + session`
+`start` → `jira_fetch` → `reuse_audit` → `gherkin_generation` → `step_definitions` → `pom_generation` → `test_run` → `end + report + session`
 
 Replace `CARD_ID` with the actual card ID (e.g. `QE-89`) in every command.
 
 ---
 
-## Execution Flow — three phases, two gates
+## Execution Flow — five phases, two gates
 
 ```
-[TOKEN TRACKING: start]
+[TOKEN TRACKING: start — optional, see SKILLS_CONTEXT.md]
+         ⬇
+Phase 0: Repo Discovery + Reuse Audit (step catalog)
+[TOKEN TRACKING: jira_fetch → reuse_audit]
          ⬇
-Phase 1: Read COS / Business Rules → Write Gherkin
-[TOKEN TRACKING: jira_fetch  →  gherkin_generation after Gate 1]
+Phase 1: Read COS / Business Rules → Write Gherkin (reuse-matched)
+[TOKEN TRACKING: gherkin_generation after Gate 1]
          ⬇
-         ── GATE 1: Present Gherkin. STOP. Wait for user confirmation. ──
+         ── GATE 1: Present Gherkin + REUSE REPORT. STOP. Wait for confirmation. ──
          ⬇
-Phase 2: Write Step Definitions (Playwright MCP for live DOM inspection)
+Phase 2: Write Step Definitions — ONLY for approved new steps
 [TOKEN TRACKING: step_definitions after Gate 2]
          ⬇
          ── GATE 2: Present step defs. STOP. Wait for user confirmation. ──
          ⬇
-Phase 3: Write POM class → Dry run → Hand-off
-[TOKEN TRACKING: pom_generation  →  end + report + session]
+Phase 3: Write POM class → Dry run
+[TOKEN TRACKING: pom_generation]
+         ⬇
+Phase 4: REAL test run → self-heal loop (max 3) → Hand-off
+[TOKEN TRACKING: test_run → end + report + session]
 ```
 
 **Hard rule:** No `.cjs` code until Gate 1 is confirmed. No POM until Gate 2 is confirmed.
+No Gherkin until the Phase 0 reuse audit is complete.
 
 ---
 
-## Project Conventions
+## Tech Stack Defaults
+
+Used only where Phase 0 discovery finds no existing convention (empty repo, first feature):
 
-### Tech stack
-- **Language**: JavaScript (CommonJS — `.cjs` files)
-- **Framework**: Playwright + CucumberJS
+- **Language**: JavaScript (CommonJS — `.cjs`), Playwright + CucumberJS
 - **Pattern**: BDD with `Rule` / `Example` / `Scenario Outline`
-- **File extension**: `.cjs` for all Pages and Step definitions, `.feature` for Gherkin
-- **Fake data**: Always use `faker.js` for generated test data
+- **Fake data**: `faker.js` for generated test data
+- **Default paths** (only when the repo has none): `test/features/`,
+  `test/step-definitions/`, `test/pages/`
+
+**Whatever Phase 0 discovers in the repo overrides these defaults** — match the existing
+tree's layout, naming style, and idioms exactly, including its typos (e.g. a repo using
+`step-definations/` keeps that spelling).
 
-### File structure
+---
+
+## PHASE 0 — Repo Discovery + Reuse Audit
+
+Runs before any Gherkin is drafted.
+
+**Card + product first:** if invoked by qa-agent, `CARD_ID` and the product come from the
+parameter block. If standalone, fetch the card via Atlassian MCP now (this is the
+`jira_fetch` checkpoint) and derive `PRODUCT_FOLDER` from the Jira project name
+(uppercase, spaces → `_`).
+
+Produces/refreshes the **step catalog** at:
 
 ```
-test/
-├── BDDUtilies/
-│   ├── bdd_api/          ← API helpers to seed/reset data via HTTP
-│   └── bdd_payload/
-│       └── index.cjs     ← Faker-based payload generators
-├── E2E1/                 ← Auth + User + Technician flows
-├── E2E2/                 ← Subscription + Offer + Technician login
-├── E2E3/                 ← Client flows
-├── Pages/                ← POM classes
-│   ├── Auth/
-│   ├── ClientManagement/
-│   ├── Dashboard/
-│   ├── ErrorPages/
-│   ├── Profile/
-│   ├── SubscriptionManagement/
-│   ├── TechnicianManagement/
-│   └── UserManagement/
-├── step-definations/     ← Step definitions
-│   ├── Driver.cjs        ← Before/After hooks, browser setup
-│   └── <Module>/
-└── support/              ← Static fixture files (images/docs)
+CATALOG = .claude/skills/qa-agent/product_context/{PRODUCT_FOLDER}/step-catalog.md
 ```
 
-### Where to place new files
+### 0a — Check catalog freshness
 
-| New file type | Path pattern |
-|---------------|--------------|
-| Feature file | `test/E2E<n>/<FlowFolder>/<n>.<feature-name>.feature` |
-| Step definition | `test/step-definations/<Module>/<feature>.steps.cjs` |
-| POM class | `test/Pages/<Module>/<page-name>.cjs` |
-| API helper | `test/BDDUtilies/bdd_api/<action>Api.cjs` |
-| Payload generator | `test/BDDUtilies/bdd_payload/index.cjs` (extend existing) |
+```bash
+ls "$CATALOG" 2>/dev/null && \
+  find . -path ./node_modules -prune -o \( -name '*.feature' -o -name '*.steps.cjs' -o -name '*.steps.js' -o -name '*.steps.ts' \) -newer "$CATALOG" -print | head -5
+```
+
+- Catalog exists and nothing newer → **load the catalog, skip to 0d**.
+- Catalog missing or stale files found → build/refresh below.
+
+### 0b — Discover the repo layout
+
+1. Read `cucumber.cjs` (or `cucumber.js` / `cucumber.json`) — the `import`/`require`/`paths`
+   globs tell you where step definitions and features actually live.
+2. Glob the tree for `**/*.feature`, the step-definition files matched by the config, and
+   POM/page-object directories (`Pages/`, `pages/`, `pageobjects/`...), excluding `node_modules`.
+3. Record the observed conventions: feature file path pattern, step file path pattern,
+   POM path pattern, file naming style, module folder names.
+4. **If the repo has no test tree at all:** tell the user, propose the defaults above,
+   and record whatever they confirm as this product's layout.
+
+### 0c — Build the step catalog
+
+Extract from every step-definition file each `Given/When/Then(...)` pattern with its
+cucumber-expression parameters, and from every POM file its class name + public methods.
+Write the catalog:
+
+```markdown
+# Step Catalog — {PRODUCT}
+Generated: {date} · Features: {n} · Step files: {n} · Steps: {n} · POM classes: {n}
+
+## Repo Layout (discovered)
+| Artifact | Path pattern | Example |
+|----------|--------------|---------|
+| Feature files | ... | ... |
+| Step definitions | ... | ... |
+| POM classes | ... | ... |
+
+## Steps
+| Pattern | Params | File |
+|---------|--------|------|
+| I click the {string} button | string | test/step-definations/common.steps.cjs |
+
+## POM Classes
+| Class | File | Key methods |
+|-------|------|-------------|
+```
+
+### 0d — Announce (one line)
+
+> "Reuse audit ready — {n} existing steps, {n} POM classes catalogued for {PRODUCT}."
+
+Run `reuse_audit` token checkpoint.
 
 ---
 
@@ -132,11 +190,10 @@ Read `.claude/skills/automation/BDD_TEMPLATES.md` AND `.claude/skills/automation
 Do NOT read either file again in Phase 2 or Phase 3 — they are already in context.
 Reference their rules by name only in later phases (e.g. "per Locator Priority Rule 1", "per BDD step pattern rule").
 
-### Step 0 — Token tracking START + Fetch the card
+### Step 0 — Card data check
 
-Run the token tracking `start` command (see SKILLS_CONTEXT.md). Do not show output to user.
-
-Fetch the Jira card via Atlassian MCP. Read `issuetype.name`:
+The card was fetched in Phase 0 (or received from qa-agent). If somehow not yet fetched,
+fetch it now via Atlassian MCP. Read `issuetype.name`:
 
 | Card type | Action |
 |-----------|--------|
@@ -165,30 +222,50 @@ Before writing any Gherkin, answer:
 
 Write a brief internal test plan (3–8 bullets) before generating the feature file.
 
-### Step 2 — Generate the Feature File
+### Step 2 — Generate the Feature File (reuse-matched)
 
 Use the Gherkin format from BDD_TEMPLATES.md.
 
+**Reuse matching — apply to EVERY drafted step, in strict priority order, against the
+Phase 0 step catalog:**
+
+| Priority | Match type | Action |
+|----------|-----------|--------|
+| 1 | **Exact** — step text matches an existing pattern | Reuse verbatim. Tag internally `[reused]` |
+| 2 | **Parameterized** — existing pattern covers it with different arguments (`I click the {string} button`) | Use the existing pattern's exact wording with new arguments. Tag `[reused-param]` |
+| 3 | **Semantic duplicate** — an existing step does the same thing with different wording | **Rewrite YOUR draft to the existing wording.** Never create a parallel step. Tag `[reused-reworded]` |
+| 4 | **Genuine gap** — nothing in the catalog covers the behavior | New step allowed. Tag `[new]` — requires explicit approval at Gate 1 |
+
 **Gherkin writing rules:**
 - One `Rule:` per business rule / AC from the Jira card; rule text = the AC verbatim
 - Use real persona names (John, Maria, Alex, Priya) + role in `Example:` titles
 - Use `{word}` for persona in steps, never "the user"
 - Describe **intent and outcome**, never mechanics (`When John uploads the profile document` ✅)
 - Use `Scenario Outline` when 2+ scenarios share identical steps but differ only in data
-- Scan existing `.feature` files for reusable steps — reuse exact text
 - API hook tags go **directly above** the `Example:` line; stack multiple on separate lines
 
-### ══ GATE 1 ══
+### ══ GATE 1 — Gherkin + Reuse Report ══
+
+Compute the reuse metrics and present them with the Gherkin (both AUTO_APPROVE modes):
+
+```
+Reuse report — [CARD-ID]
+  Steps total: {N} | Reused exact: {N} | Reused parameterized: {N} | New: {N}  ({X}% reuse)
+  New steps requiring definitions:
+    - When I drag the "{string}" card to column "{string}"
+    - ...
+  (or: "No new step definitions needed — full reuse.")
+```
 
 **If AUTO_APPROVE = false (default — standalone run):**
 
-Present Gherkin and ask:
+Present Gherkin + reuse report and ask:
 
-> **Here is the Gherkin for [CARD-ID]. Please review each Rule and Example.**
+> **Here is the Gherkin for [CARD-ID]. Please review each Rule, Example, and the reuse report.**
 >
 > - Does the Rule text match the business rule / COS exactly?
 > - Are the Given / When / Then steps clear and at the right level of intent?
-> - Any scenarios to add, remove, or rename?
+> - Are the **new steps** genuinely new, or should any map to an existing step?
 >
 > **Type "looks good" or "confirmed" to proceed to step definitions.**
 
@@ -196,8 +273,8 @@ Do not write any `.cjs` files until confirmed. Iterate until approved.
 
 **If AUTO_APPROVE = true (called from qa-agent full pipeline):**
 
-Display a compact summary only — do NOT wait:
-> "Gherkin generated for [CARD-ID]: {N} Rules, {N} scenarios total. Auto-approved — proceeding to step definitions."
+Display the reuse report + a compact summary — do NOT wait:
+> "Gherkin generated for [CARD-ID]: {N} Rules, {N} scenarios, {X}% step reuse. Auto-approved — proceeding to step definitions."
 
 Immediately move to Phase 2 without waiting for any input.
 
@@ -212,7 +289,15 @@ Apply locator rules by recalling them from context. Re-reading the file wastes ~
 
 ### Step 3 — Generate Step Definitions using Playwright MCP
 
-For every step that interacts with the UI, use **Playwright MCP** to:
+**Write definitions ONLY for steps tagged `[new]` at Gate 1.** Reused steps already have
+working definitions — creating a second one would make cucumber-js fail with `Ambiguous`.
+If every step was reused, say "No new step definitions needed" and skip to Phase 3
+(which then only extends POMs if a new-step definition requires a method that doesn't exist).
+
+Place new definitions in the file the catalog's Repo Layout says they belong in — extend
+an existing module's step file when one fits before creating a new file.
+
+For every new step that interacts with the UI, use **Playwright MCP** to:
 1. Navigate to the relevant page in the live app
 2. Inspect the actual DOM elements the step will interact with
 3. Identify existing `data-testid` attributes — or note one needs to be added
@@ -257,14 +342,19 @@ After either path: run `step_definitions` token checkpoint, then move to Phase 3
 
 ---
 
-## PHASE 3 — Write POM → Dry Run → Hand-off
+## PHASE 3 — Write POM → Dry Run
 
 **Do NOT reload any file in Phase 3.** BDD_TEMPLATES.md and LOCATOR_PATTERNS.md are already in context from Phase 1.
 Recall the locator priority rules from context — do not re-read the file.
 
 ### Step 4 — Generate the Page Object Model using Playwright MCP
 
-Use the POM class template from BDD_TEMPLATES.md.
+**Reuse check first:** consult the catalog's POM Classes table. If a page object for this
+page already exists, **extend it with the missing methods** — do not create a parallel
+class. Only create a new POM class for a page that has none.
+
+Use the POM class template from BDD_TEMPLATES.md for new classes; match the existing
+class's style when extending.
 
 For every locator:
 1. Navigate to the real page in the live app via Playwright MCP
@@ -302,36 +392,68 @@ npx cucumber-js --dry-run
 
 - ✅ All steps defined → proceed
 - ❌ `Undefined` → fix step pattern to match Gherkin exactly, re-run
-- ❌ `Ambiguous` → rename conflicting step, re-run
+- ❌ `Ambiguous` → a new step collides with an existing one — this is a reuse-audit miss:
+  reuse the existing step (delete the new definition) rather than renaming, unless the
+  behaviors genuinely differ
 - ❌ `require` errors → fix paths, re-run
 
-Fix and re-run automatically. Do not hand off until clean.
-After dry run passes: run `end + report + session` token close-out.
+Fix and re-run automatically. Do not proceed until clean.
+
+---
+
+## PHASE 4 — Real Test Run + Self-Heal → Hand-off
+
+A dry run only proves patterns match. QA means the test actually passes against the app.
+
+### Step 6 — Execute the new feature
 
-### Step 6 — Hand-off Summary
+Requires the app URL and credentials (parameter block / `.env`). If neither is available,
+skip with an explicit warning in the hand-off: "Real run SKIPPED — no app URL."
+
+```bash
+npx cucumber-js <new feature file>
+```
+
+### Step 6b — Self-heal loop (max 3 attempts)
+
+On failure, diagnose and fix — **never hand off a silently failing test**:
+
+1. Read the failure: locator timeout? assertion mismatch? navigation/auth issue?
+2. Locator failures → re-inspect that element via Playwright MCP, fix the POM locator
+   (respect the locator priority table).
+3. Assertion failures → check whether expected text/behavior on the card matches the app.
+   If the app appears genuinely wrong, this is a **bug, not a test fix** — stop healing
+   that scenario, mark it failing, and note it as a bug candidate in the hand-off.
+4. Re-run. After 3 failed attempts, stop and report the failure honestly.
+
+Run `test_run` token checkpoint, then `end + report + session` close-out.
+
+### Step 7 — Update the step catalog
+
+Append every new step definition written this run to the Phase 0 catalog (Steps table),
+and any new/extended POM class to the POM Classes table. This keeps the next run's reuse
+audit accurate without a full re-scan.
+
+### Step 8 — Hand-off Summary
 
 ```
 ✅ Automation agent complete for <CARD-ID>
 
-Feature file:   test/E2E<n>/<FlowFolder>/<n>.<feature-name>.feature
-Steps file:     test/step-definations/<Module>/<feature>.steps.cjs
-POM file:       test/Pages/<Module>/<page-name>.cjs
+Feature file:   <path per discovered repo layout>
+Steps file:     <path, or "none — full reuse">
+POM file:       <path, or "extended existing: <class>">
 
 Scenarios covered:
   - <Rule 1>: <n> Example(s), <n> Outline(s)
   - <Rule 2>: <n> Example(s)
 
+Reuse:  {N} steps total | {N} exact | {N} parameterized | {N} new  ({X}% reuse)
 API hooks used:              <tag list or "none">
 Faker used for:              <field list or "none">
-File upload method:          <setInputFiles / uploadViaButton / dragAndDropFile / none>
 data-testid added to source: <element list or "none required">
-Playwright MCP used for:     <list of pages/elements inspected>
-Dry-run: PASSED
-
-── Token Usage (this run) ──────────────────────────────────────
-  <paste the session table output from track_tokens.py session here>
-  Analytics chart: ~/.claude/token_analytics.png
-────────────────────────────────────────────────────────────────
+Dry-run:  PASSED
+Test run: {PASSED | FAILED after 3 heal attempts: <reason> | SKIPPED — no app URL}
+Bug candidates from test run: <list or "none">
 
 Ready for: manual-testing agent (manual branch) · bug-reporting agent
 ```

package/claude/skills/bug-reporting/SKILL.md

@@ -214,8 +214,9 @@ For each screenshot file, attach it to the active Jira card using the Jira REST
 `https://7edge.atlassian.net/browse/QE-89` then domain is `7edge.atlassian.net`).
 Do NOT rely on an env var for the domain — parse it from the card URL.
 
-**Resolve credentials** — try each source in order until one is non-empty:
+**Resolve credentials** — load `.env` first, then try each source in order until one is non-empty:
 ```bash
+[ -f .env ] && set -a && . ./.env && set +a
 JIRA_EMAIL=${JIRA_USER_EMAIL:-${JIRA_EMAIL:-${ATLASSIAN_EMAIL:-""}}}
 JIRA_TOKEN=${JIRA_API_TOKEN:-${ATLASSIAN_API_TOKEN:-${ATLASSIAN_TOKEN:-""}}}
 ```

package/claude/skills/impacted-tests/SKILL.md

@@ -0,0 +1,111 @@
+---
+name: impacted-tests
+description: After pulling a developer branch into a test branch, analyze ONLY the src changes that pull brought in and map them to the BDD/Cucumber test files (feature files, step definitions, page objects) they can break, then print a report. Report-only - it never runs tests; the QA opens and runs the listed files manually. Repo-agnostic - it auto-discovers the test folder, framework, and diff base at runtime. Use when the user asks "which tests are impacted by this pull" or "map dev changes to tests". Usage - /impacted-tests [base-branch-or-commit] [changed file paths...]
+---
+
+# Impacted Tests Analyzer
+
+Map the source-code changes a developer-branch pull brought in to the BDD test files they can break, so QA can review/run those tests locally before CI. This skill is **repo-agnostic**: it discovers everything about the project at runtime. Do NOT assume any specific folder names, framework version, or paths — always run Step 0 first.
+
+## Token-efficiency rules (mandatory)
+
+- Work from the **diff**, never by reading whole source files. `git diff --name-only` / `-U0` gives everything needed.
+- Map with `grep -rl` / `grep -rn` (filenames + line numbers only); never `cat` a feature/step/page file in full. Read at most ±10 lines around a hit, and only when a mapping is ambiguous.
+- Batch all greps for one identifier list into a single command with `-E "id1|id2|..."`.
+- Never search `node_modules`, `dist`, `build`, `coverage*`, or other generated/vendor dirs.
+- If the diff spans more than ~30 src files, delegate the mapping (Step 3) to one `Explore` subagent (breadth: medium) with the identifier list; ask it to return only file paths + one-line reasons.
+
+## Step 0 — Discover the project (do this first, every run)
+
+Detect these facts by inspection; keep the results in mind for later steps. Do NOT hardcode.
+
+1. **Test root**: the folder holding BDD tests. Find it, don't assume:
+   ```bash
+   ls -d test tests e2e cypress 2>/dev/null
+   git ls-files '*.feature' | sed 's#/[^/]*$##' | sort -u | head
+   ```
+   The common ancestor of the `*.feature` files is the test root. Feature files, step definitions, and page objects all live under it (subfolder names vary per repo — discover them, e.g. `git ls-files "$TEST_ROOT/**" | sed 's#[^/]*$##' | sort -u`).
+2. **Framework + run command**: read `package.json` scripts and any cucumber config (`cucumber.js`, `cucumber.cjs`, `cucumber.json`, `.cucumberrc*`). Derive the single-feature run command from the test script or CI script rather than inventing one. If none is discoverable, fall back to `npx cucumber-js <feature-path>`. (This is only for the manual-run footer in the report — the skill never runs anything itself.)
+3. **Source root**: the app code the tests exercise — usually `src/`, else the top-level dir(s) that are neither the test root nor config/vendor. Confirm with `git ls-files | grep -vE "^($TEST_ROOT|node_modules|dist)" | ...`.
+
+If there are no `*.feature` files anywhere, tell the user this skill targets BDD/Cucumber repos and stop.
+
+## Step 1 — Collect the diff from the most recent pull INTO the current branch
+
+The input is exactly what the last pull brought into **this** branch — no need to know or name the developer branch. When you `git pull` (or merge) another branch into your current branch, git records a merge commit whose second parent is the pulled tip; `$MERGE^1..$MERGE` is precisely "what that pull added on top of my branch". That is the primary and preferred signal:
+
+```bash
+# Primary: the most recent merge commit on the CURRENT branch = the most recent pull into it
+MERGE=$(git log --merges -1 --format=%H)
+git log -1 --format='%s  (merged in: %p)' $MERGE   # sanity check — this is the pull you just did
+git diff --name-status $MERGE^1 $MERGE -- <SRC_ROOT>
+DIFF_RANGE="$MERGE^1 $MERGE"
+```
+Fallbacks, in order (only if there is no merge commit — e.g. a fast-forward pull, or you pulled before creating any commit):
+- User passed a base ref/commit as the first argument: `git diff --name-status <arg>...HEAD -- <SRC_ROOT>` — use this whenever the auto-detected pull is wrong.
+- Otherwise diff against the current branch's upstream/tracking ref if set (`@{u}`), else against whichever of `origin/develop-temp`, `origin/develop`, `origin/main`, `origin/master` exists: `git diff --name-status HEAD...<ref> -- <SRC_ROOT>`.
+- User passed explicit file paths or a pasted diff: use those directly.
+
+If the src diff is empty everywhere, tell the user no pulled source changes were found (ask when they last pulled, or to pass the base ref explicitly) and stop — do NOT fall back to analyzing their own test edits.
+
+Scope: only files under `<SRC_ROOT>` are analysis input. Ignore unit-test files in the diff (`*.test.*`, `*.spec.*`, `__tests__/`) — they are not BDD-flow relevant. The QA's own changed test files are NOT impact findings (mention them, if at all, in one closing line).
+
+## Step 2 — Extract impact identifiers (from the diff only)
+
+Build a small identifier list without opening files (use `$DIFF_RANGE` from Step 1):
+
+```bash
+git diff -U0 $DIFF_RANGE -- <SRC_ROOT> | grep -oE 'data-testid="[^"]+"' | sort -u                      # changed testids
+git diff -U0 $DIFF_RANGE -- <SRC_ROOT> | grep -E '^[+-]' | grep -oE '"[A-Z][A-Za-z0-9 /&-]{3,40}"' | sort -u  # added/removed UI strings
+```
+Identifiers = (a) changed `data-testid`/locator attribute values, (b) component/page basenames from the changed file paths, (c) route/path strings in the diff, (d) user-facing label/heading/button/message strings added or removed. `data-testid` and UI strings are the strongest signals; include **removed** ones too — a deleted locator is exactly what breaks a test.
+
+## Step 3 — Map identifiers to test files, then down to scenarios
+
+Chain cheapest-first, filenames only, all under the discovered `<TEST_ROOT>`:
+
+1. **Filename match**: identifier keywords vs feature/step filenames (`git ls-files "$TEST_ROOT/**/*.feature" "$TEST_ROOT/**/*.[jt]s" | grep -iE "kw1|kw2"`).
+2. **Content match**: `grep -rilE "id1|id2|LabelText" "$TEST_ROOT" --include="*.feature" --include="*.js" --include="*.ts"`.
+3. **Close the chain**: for a hit in a step-definition or page-object that has no same-named feature, grep its distinctive step text into the feature files to find the owning feature(s).
+4. **Resolve to scenarios**: for each impacted feature file, `grep -nE "Scenario:|Example:|Rule:|<step text>" <feature>` to get the affected scenario title(s) and line number(s). The report cites the **feature file + scenario + line**, because testers navigate by scenario, not by step-definition code.
+
+Risk level (two only): 🔴 **Will fail** = a locator/step the test uses was removed or renamed; 🟡 **At risk** = shares a changed screen/component/steps but locators likely survive.
+
+## Step 4 — Output the report
+
+The report IS the deliverable. In this exact order:
+
+1. FIRST save it to `outputs/impacted-tests-report.md` with the Write tool (create `outputs/` if needed) so it survives the session.
+2. THEN print it as the **final text message of the turn** — no tool calls after it, printed exactly ONCE, beginning with `## Impacted tests report`. Never print it before a tool call and repeat it after.
+
+Format (per-line, not a table — tables wrap badly in terminals):
+
+```
+## Impacted tests report
+
+Analyzed <N> source files pulled from <ref> (merge <shorthash>).
+
+**Impacted test files (<N>) — highest risk first:**
+
+1. 🔴 <TEST_ROOT>/path/to/Some.feature
+   **Will fail** — Example: "<scenario title>" (<TEST_ROOT>/path/to/Some.feature:34) — <one sentence, in tester/UI terms, of what the developer changed>.
+
+2. 🟡 <TEST_ROOT>/path/to/Another.feature
+   At risk — Rule: "<rule title>" (<TEST_ROOT>/path/to/Another.feature:41) — <one sentence>.
+
+**Coverage gaps (no test exercises these yet):**
+- <new dev functionality with no scenario> — needs a new scenario.
+
+**To run any of these manually** (start your app first):
+<discovered single-feature run command> <feature-path>
+```
+
+Rules for each entry:
+- Risk marker first, then ONE sentence citing the affected scenario by its `Scenario:`/`Example:`/`Rule:` title with a clickable `feature-path:line`, describing the change in **UI/tester terms** ("the dropdown was replaced with an input + Verify button").
+- Do NOT reference step-definition filenames, page objects, or source component filenames in the reasons — testers read feature files, not code. Source filenames may appear only in the coverage-gaps section when there is no feature to point to.
+- **Hyperlink rule**: write feature paths as bare repo-relative paths in plain text (with `:line`) — NOT as `[label](path)` markdown links. Terminals auto-detect plain paths and make them ctrl+clickable; a markdown label hides the path and breaks that.
+- No confidence column, no per-source-file table, no separate flat path list — the numbered paths ARE the list.
+
+## Step 5 — Stop
+
+The report is the deliverable. Do NOT run any test, do NOT ask whether to run them — the QA reviews the report and runs files manually using the footer command. End the turn after printing the report.

package/claude/skills/manual-testing/SKILL.md

@@ -29,7 +29,8 @@ Use `browser_evaluate` with a specific CSS selector or JS expression for all DOM
 
 ## Token Tracking
 
-Silent background task — follow the **Token Tracking** pattern in `SKILLS_CONTEXT.md`.
+Optional and silent — follow the **Token Tracking** pattern in `SKILLS_CONTEXT.md`
+(run its enablement check once at skill start; if disabled, skip every checkpoint silently).
 Checkpoints: `start` → `jira_fetch` → `ui_testing` → `test_execution` → `end + report + session`.
 Replace `CARD_ID` with the actual card ID. Never show tracking output to user.
 
@@ -55,32 +56,25 @@ Jira Card ID
 
 ---
 
-## Phase 0 — Collect Card ID + Load Context
+## Phase 0 — Inputs
 
-Run token tracking `start` checkpoint.
+Run token tracking `start` checkpoint (if enabled).
 
-If the user has not already provided a Jira card ID, ask:
-> "Please share the **Jira card ID** to begin (e.g. `PROJ-123`)."
+**Invoked by qa-agent (parameter block present):** take `CARD_ID`, `APP_URL`, `LOGIN_URL`,
+`FIGMA_URL`, `AUTO_APPROVE`, `CONTEXT_FILE` from the block. Read `.env` for `QA_USERNAME`,
+`QA_PASSWORD`, `QA_OTP_CODE`. **Ask no setup questions — qa-agent already collected everything.**
+(`FIGMA_URL: none` means `RUN_UI_TEST = false`.)
 
-Wait for the card ID.
+**Standalone run:** resolve values in precedence order `.env` > product context > ask:
+1. Read `.env` → `QA_APP_URL`, `QA_LOGIN_URL`, `QA_USERNAME`, `QA_PASSWORD`, `QA_OTP_CODE`
+2. If the user gave no card ID, ask for it. Then derive the project key prefix
+   (`QE-89` → `QE`) and read `.claude/skills/qa-agent/product_context/{PREFIX}/context.md`
+   if it exists → fills any URL/OTP gaps (never credentials — those are `.env`-only)
+3. Ask ONE consolidated message for whatever is still missing (app URL, credentials,
+   Figma link or "skip UI comparison"). Never ask one-at-a-time; never ask for a value
+   you already have.
 
-**After card ID is known — check for product context:**
-
-Derive the project key prefix (e.g. `QE-89` → `QE`) and check:
-```
-.claude/skills/qa-agent/product_context/{PREFIX}/context.md
-```
-
-**If context file exists:**
-- Read it and extract: `CTX_APP_URL`, `CTX_USERNAME`, `CTX_PASSWORD`, `CTX_LOGIN_URL`, `CTX_OTP`
-- Set `CONTEXT_LOADED = true`
-- Confirm one line: "Context loaded for {PRODUCT_NAME} — using saved URL and credentials."
-
-**If context file not found:**
-- Set `CONTEXT_LOADED = false`
-- Collect URL and credentials during Phase 1 as normal
-
-Then immediately proceed to Phase 1 — do not ask for anything else yet.
+**Never print `QA_PASSWORD` to chat, reports, or hints files.**
 
 ---
 
@@ -106,23 +100,13 @@ After fetching, check `CARD_DESCRIPTION` length:
 
 Do NOT tell the user the description was truncated. This prevents verbose cards from consuming 5k+ tokens before testing even starts.
 
-If no AC found:
+If no AC found (and qa-agent didn't already resolve this):
 > "No Acceptance Criteria found on this card. What should be tested?"
 Wait for user response before continuing.
 
-After fetch, ask these **one at a time**:
-
-**Question A — UI Testing:**
-> "Do you want to compare the app against a Figma design before testing? (yes / no)"
-
-- If yes: ask for Figma URL (suggest `FIGMA_URL_FROM_CARD` if found), then app URL + credentials
-- If no: ask for app URL + credentials only
-
-Store:
-- `RUN_UI_TEST` — true/false
-- `FIGMA_URL` — if yes
-- `APP_URL` — full base URL of the app
-- `USERNAME`, `PASSWORD` — login credentials (ask only if not obvious from card)
+Set from Phase 0 values (all input was collected there — do not re-ask):
+- `RUN_UI_TEST` — true when a Figma URL is available (from parameter block, card, or user)
+- `FIGMA_URL`, `APP_URL`, `USERNAME`, `PASSWORD`, `OTP_CODE`
 
 ---
 
@@ -206,7 +190,7 @@ ls .playwright-session.json 2>/dev/null && echo "SESSION_EXISTS" || echo "NO_SES
 
 **If OTP screen appears:**
 9. Click first OTP box → `browser_click`
-10. `browser_type(text: "999999")` — always this value
+10. `browser_type(text: OTP_CODE)` — the `QA_OTP_CODE` value from `.env` (ask once if unset)
 11. Click verify → `browser_click`
 12. `browser_wait_for(state: "networkidle")`
 
@@ -285,7 +269,7 @@ For each test T-01, T-02, ...:
 7. Append to `HINTS.testCases`:
    ```
    { id: "T-N", name: "...", status: "PASS|FAIL|OBSERVATION|BLOCKED",
-     actions: ["fill email", "click submit", "type OTP 999999"],
+     actions: ["fill email", "click submit", "type OTP"],
      url: "CURRENT_URL" }
    ```
 
@@ -315,7 +299,7 @@ Base URL: [BASE_URL]
 
 ## Environment
 App URL: [APP_URL]
-Login: [USERNAME] / [PASSWORD REDACTED]
+Login: credentials in .env (never written here)
 
 ## Pages Visited
 | URL | Description |