qa-engineer 0.9.1 → 0.10.0

package/skills/qa-init/scripts/qa-tool.mjs

@@ -0,0 +1,126 @@
+// synced-from: shared/tooling/qa-tool.mjs — do not edit; edit the source and run: node scripts/sync-shared.mjs --write
+// The launcher every skill invokes to reach the deterministic engine.
+//
+// A skill's SKILL.md documents exactly one command shape:
+//
+//     node <SKILL_DIR>/scripts/qa-tool.mjs <tool> <subcommand> [args]
+//
+// and this file finds the engine, wherever it happens to be. That indirection
+// exists because the pack is installed three different ways and the engine lands in
+// a different place each time:
+//
+//   1. `qa install` bundles the engine into the skill, at ./lib/. Offline, fastest,
+//      and pinned to the version that was installed.
+//   2. `npx skills add <owner>/<repo>` — or any generic file copier — copies the
+//      skill directory out of git and bundles nothing. The engine is then resolved
+//      from node_modules if the project happens to depend on the pack.
+//   3. Neither: fall back to `npx qa-engineer`, which fetches the published package
+//      on first use and is served from the npm cache afterwards.
+//
+// Because this file is committed rather than generated, path 2 works at all — which
+// is what makes the pack installable by the wider Agent Skills ecosystem. The
+// command a skill runs never changes; only where the engine came from does.
+//
+// Exit codes pass through unchanged: 0 success, 1 an invalid contract, 2 unreadable
+// input or bad usage.
+//
+// No shebang: the synced copies carry a provenance marker on line one, which would
+// sit above it and stop the kernel seeing it anyway. Every documented invocation is
+// `node qa-tool.mjs …`, which needs none.
+
+import fs from 'node:fs';
+import path from 'node:path';
+import { spawnSync } from 'node:child_process';
+import { fileURLToPath } from 'node:url';
+
+const here = path.dirname(fileURLToPath(import.meta.url));
+
+const USAGE = `usage: node qa-tool.mjs <tool> <subcommand> [args]
+
+  analysis     parse artifacts, classify errors, validate contracts, diff-guard,
+               read .qa/context.md, render an HTML report, print the footer
+  diagnostics  root cause, timeline, priority, repair plans, release readiness
+  playwright   normalize a Playwright report or summarize a trace
+
+  --where      print how the engine was resolved, and stop
+
+examples:
+  node qa-tool.mjs analysis junit test-results/results.xml
+  node qa-tool.mjs analysis report-html qa-artifacts/explore-result.json --out report.html
+  node qa-tool.mjs diagnostics report --execution-result qa-artifacts/run.json
+`;
+
+/**
+ * Where the engine is, and how we found it.
+ *
+ * Ordered by cost: a bundled copy needs no resolution and no network, a
+ * node_modules copy needs no network, and npx needs both on first use. Reporting
+ * *which* one answered matters when a skill degrades — "the engine is missing" and
+ * "the engine is being fetched" are different problems.
+ */
+function resolveEngine() {
+  const bundled = path.join(here, 'lib', 'bin', 'qa-engine.mjs');
+  if (fs.existsSync(bundled)) return { kind: 'bundled', command: [process.execPath, bundled] };
+
+  for (const base of candidateModuleRoots()) {
+    const installed = path.join(base, 'qa-engineer', 'packages', 'engine', 'bin', 'qa-engine.mjs');
+    if (fs.existsSync(installed)) {
+      return { kind: 'node_modules', command: [process.execPath, installed] };
+    }
+  }
+
+  return {
+    kind: 'npx',
+    command: [npxCommand(), '--yes', 'qa-engineer', 'engine'],
+  };
+}
+
+/** node_modules directories worth checking, nearest first. */
+function candidateModuleRoots() {
+  const roots = [];
+  let dir = here;
+  for (let depth = 0; depth < 12; depth += 1) {
+    roots.push(path.join(dir, 'node_modules'));
+    const parent = path.dirname(dir);
+    if (parent === dir) break;
+    dir = parent;
+  }
+  if (process.cwd() !== here) roots.push(path.join(process.cwd(), 'node_modules'));
+  return roots;
+}
+
+// `npx` is a shell script on POSIX and a .cmd shim on Windows; spawnSync needs the
+// exact name, and `shell: true` would put user-supplied arguments through a shell.
+function npxCommand() {
+  return process.platform === 'win32' ? 'npx.cmd' : 'npx';
+}
+
+function main(argv) {
+  if (argv.length === 0 || argv[0] === '--help' || argv[0] === '-h') {
+    process.stdout.write(USAGE);
+    return argv.length === 0 ? 2 : 0;
+  }
+
+  const engine = resolveEngine();
+
+  if (argv[0] === '--where') {
+    process.stdout.write(`${JSON.stringify({ resolved: engine.kind, command: engine.command }, null, 2)}\n`);
+    return 0;
+  }
+
+  const [program, ...prefix] = engine.command;
+  const run = spawnSync(program, [...prefix, ...argv], { stdio: 'inherit' });
+
+  if (run.error) {
+    // Say which path was tried and what to do, because a skill's fallback prose
+    // cannot diagnose this and the user is the one who has to fix it.
+    const advice = engine.kind === 'npx'
+      ? 'the engine is not bundled and npx is unavailable — run `npx qa-engineer install` in this project, or install Node 18+'
+      : `could not execute ${program}`;
+    process.stderr.write(`qa-tool: ${advice}\n${run.error.message}\n`);
+    return 2;
+  }
+  return run.status ?? 2;
+}
+
+process.exitCode = main(process.argv.slice(2));

package/skills/qa-report/SKILL.md

@@ -41,7 +41,7 @@ Do not investigate failures here (that is `/qa-debug`) or plan repairs (`/qa-fix
 2. **Aggregate deterministically.** Run the engine's summarize step (see Tooling) to compute the test totals, the by-classification breakdown, the ranked findings and recommendations, and the release-readiness verdict.
 3. **Frame for audiences.** Write the executive summary (shippability in a paragraph and a verdict) and the engineering summary (what broke, why, who owns it, in priority order) from the same aggregated data.
 4. **Detail.** Fill the test, failure, coverage, and risk sections; mark coverage unavailable rather than inventing it when there is no coverage data.
-5. **Render.** Produce the report in Markdown, an HTML-ready structure, and the JSON result — the same content in three forms. Append the rendered attribution footer (see Tooling) to the Markdown and HTML renderings only; the JSON result is an interface and carries no footer.
+5. **Render.** Write the JSON result first and validate it; the Markdown and HTML are renderings of it, not parallel drafts. Render the HTML with the report renderer (see Tooling) rather than typing it. Append the rendered attribution footer to the Markdown; the renderer embeds it in the HTML, and the JSON result is an interface and carries no footer.
 6. **Report.** Emit the report result and present the Markdown.
 
 ## Guardrails
@@ -54,16 +54,17 @@ Do not investigate failures here (that is `/qa-debug`) or plan repairs (`/qa-fix
 
 ## Tooling
 
-Invoke the bundled engine through its launcher, as documented in [references/deterministic-tooling.md](references/deterministic-tooling.md). `SKILL_DIR` below is this skill's own directory — `.agents/skills/qa-report` or `.claude/skills/qa-report`, whichever exists. The command shape is the same in bash, zsh, PowerShell, and cmd.exe; on Windows use `python` if `python3` is not on PATH.
+Invoke the bundled engine through its launcher, as documented in [references/deterministic-tooling.md](references/deterministic-tooling.md). `SKILL_DIR` below is this skill's own directory — `.agents/skills/qa-report` or `.claude/skills/qa-report`, whichever exists. The command shape is the same in bash, zsh, PowerShell, and cmd.exe, and it runs under the same Node that installed the pack — there is no second runtime to find.
 
 | Tool | Invocation | Output | Fallback |
 | --- | --- | --- | --- |
-| Report aggregator | `python3 <SKILL_DIR>/scripts/qa_tool.py diagnostics summarize --execution-result <path> --diagnosis <path>` | Totals, by-classification breakdown, top-priority findings, release-readiness verdict | Aggregate the structured results manually per the report-aggregation module and mark the report degraded |
-| One-shot pipeline | `python3 <SKILL_DIR>/scripts/qa_tool.py diagnostics report --execution-result <path>` | Diagnosis, plans, and summary in a single call when no diagnosis exists yet | Run `diagnose` then `summarize` separately |
-| Contract self-check | `python3 <SKILL_DIR>/scripts/qa_tool.py analysis validate <report.json> <schema.json>` | `{valid, errors}` before the report is declared complete | None: an unvalidated report is not complete |
-| Attribution footer | `python3 <SKILL_DIR>/scripts/qa_tool.py analysis branding --format markdown` (or `html`) | The exact footer bytes to append to the **rendered** report | Omit the footer; never retype it |
+| Report aggregator | `node <SKILL_DIR>/scripts/qa-tool.mjs diagnostics summarize --execution-result <path> --diagnosis <path>` | Totals, by-classification breakdown, top-priority findings, release-readiness verdict | Aggregate the structured results manually per the report-aggregation module and mark the report degraded |
+| One-shot pipeline | `node <SKILL_DIR>/scripts/qa-tool.mjs diagnostics report --execution-result <path>` | Diagnosis, plans, and summary in a single call when no diagnosis exists yet | Run `diagnose` then `summarize` separately |
+| Contract self-check | `node <SKILL_DIR>/scripts/qa-tool.mjs analysis validate <report.json> <schema.json>` | `{valid, errors}` before the report is declared complete | None: an unvalidated report is not complete |
+| HTML report renderer | `node <SKILL_DIR>/scripts/qa-tool.mjs analysis report-html <report-result.json> --out report.html` | The self-contained HTML rendering of the validated result, footer included | Write the HTML by hand from the contract fields and say it was not machine-rendered |
+| Attribution footer | `node <SKILL_DIR>/scripts/qa-tool.mjs analysis branding --format markdown` | The exact footer bytes to append to the **Markdown** rendering (`report-html` already embeds it) | Omit the footer; never retype it |
 
-A missing `qa_tool.py` means the engine is not installed.
+A missing `qa-tool.mjs` means the engine is not installed.
 
 The release verdict is the engine's, not a judgment call: `releaseReadiness` comes from `summarize`. The contract rejects `ready` over any failing test, so a green verdict must be backed by zero failures.
 

package/skills/qa-report/references/deterministic-tooling.md

@@ -17,7 +17,7 @@ resolves its own location. There is nothing to set up and no shell features are
 involved:
 
 ```bash
-python3 <skill-dir>/scripts/qa_tool.py <tool> <subcommand> [args]
+node <skill-dir>/scripts/qa-tool.mjs <tool> <subcommand> [args]
 ```
 
 `<skill-dir>` is wherever the host installed this skill — usually
@@ -25,19 +25,21 @@ python3 <skill-dir>/scripts/qa_tool.py <tool> <subcommand> [args]
 whichever exists.
 
 ```bash
-python3 .agents/skills/qa-run/scripts/qa_tool.py analysis junit test-results/results.xml
+node .agents/skills/qa-run/scripts/qa-tool.mjs analysis junit test-results/results.xml
 ```
 
-That line is identical in bash, zsh, PowerShell, and cmd.exe. **On Windows, use
-`python` if `python3` is not on PATH** — that is the only platform difference.
+That line is identical in bash, zsh, PowerShell, and cmd.exe, with no platform
+difference at all: it runs under the same Node the user already had to install the
+pack.
 
-An earlier version of this contract used a shell recipe
-(`QA_LIB="$(ls -d … | head -1)"` with a `PYTHONPATH=` prefix). It was POSIX-only,
-so on Windows every deterministic call failed, each skill fell back to its manual
-path, and the user silently got guesswork while believing the tooling had run.
-Never reintroduce a shell-dependent invocation.
+Two earlier versions of this contract failed the same way. The first was a shell
+recipe (`QA_LIB="$(ls -d … | head -1)"` with a `PYTHONPATH=` prefix), POSIX-only, so
+on Windows every deterministic call failed and each skill fell back to guesswork
+while appearing to have run its tooling. The second was portable but needed a Python
+interpreter the user never agreed to install. Never reintroduce a shell-dependent
+invocation, and never add a runtime the install did not already require.
 
-If `qa_tool.py` is missing, the engine is not installed: say so, recommend
+If `qa-tool.mjs` is missing, the engine is not installed: say so, recommend
 `qa repair`, use the skill's documented fallback, and mark the result degraded.
 
 Every tool writes JSON to stdout. Exit `0` means success; exit `1` means an
@@ -45,33 +47,35 @@ invalid contract; exit `2` means unreadable input, a malformed artifact, or a
 payload that failed its seam contract, and the JSON body carries `error` and
 `detail`. Treat a non-zero exit as missing evidence, never as a value to guess.
 
-Standard-library Python 3.8+ only — nothing to install.
+Dependency-free Node — nothing to install beyond the Node that ran `npx`.
 
-## 2. Analysis core — `qa_tool.py analysis`
+## 2. Analysis core — `qa-tool.mjs analysis`
 
 Framework-agnostic parsing, redaction, and validation.
 
 | Subcommand | Invocation | Returns |
 | --- | --- | --- |
-| `junit` | `python3 <skill-dir>/scripts/qa_tool.py analysis junit <report.xml>` | `{tests: {...}, executed: [...]}` normalized counts and per-test outcomes |
-| `har` | `python3 <skill-dir>/scripts/qa_tool.py analysis har <file.har> [--slow-ms N]` | Redacted request/response summary, failures, slow calls |
-| `discover` | `python3 <skill-dir>/scripts/qa_tool.py analysis discover [--root DIR] [--path P]` | Artifacts found, by type, with presence flags |
-| `diff-guard` | `python3 <skill-dir>/scripts/qa_tool.py analysis diff-guard <diff-file>` | `{issues: [...], safe: bool}` — `safe:false` blocks the change |
-| `redact` | `python3 <skill-dir>/scripts/qa_tool.py analysis redact <file>` | The file's text with credentials masked |
-| `validate` | `python3 <skill-dir>/scripts/qa_tool.py analysis validate <instance.json> <schema.json>` | `{valid: bool, errors: [...]}`; exit 1 when invalid |
-| `classify` | `python3 <skill-dir>/scripts/qa_tool.py analysis classify "<error message>" [--http-status N]` | `{classification, confidence, reason}` from the shared taxonomy |
-| `context` | `python3 <skill-dir>/scripts/qa_tool.py analysis context [--root DIR] [--path .qa/context.md]` | The parsed, schema-validated project context as JSON |
-
-## 3. Diagnostic engine — `qa_tool.py diagnostics`
+| `junit` | `node <skill-dir>/scripts/qa-tool.mjs analysis junit <report.xml>` | `{tests: {...}, executed: [...]}` normalized counts and per-test outcomes |
+| `har` | `node <skill-dir>/scripts/qa-tool.mjs analysis har <file.har> [--slow-ms N]` | Redacted request/response summary, failures, slow calls |
+| `discover` | `node <skill-dir>/scripts/qa-tool.mjs analysis discover [--root DIR] [--path P]` | Artifacts found, by type, with presence flags |
+| `diff-guard` | `node <skill-dir>/scripts/qa-tool.mjs analysis diff-guard <diff-file>` | `{issues: [...], safe: bool}` — `safe:false` blocks the change |
+| `redact` | `node <skill-dir>/scripts/qa-tool.mjs analysis redact <file>` | The file's text with credentials masked |
+| `validate` | `node <skill-dir>/scripts/qa-tool.mjs analysis validate <instance.json> <schema.json>` | `{valid: bool, errors: [...]}`; exit 1 when invalid |
+| `classify` | `node <skill-dir>/scripts/qa-tool.mjs analysis classify "<error message>" [--http-status N]` | `{classification, confidence, reason}` from the shared taxonomy |
+| `context` | `node <skill-dir>/scripts/qa-tool.mjs analysis context [--root DIR] [--path .qa/context.md]` | The parsed, schema-validated project context as JSON |
+| `report-html` | `node <skill-dir>/scripts/qa-tool.mjs analysis report-html <result.json> [--out report.html]` | The result rendered as one self-contained HTML report — every required field, footer included. Run it instead of writing HTML |
+| `branding` | `node <skill-dir>/scripts/qa-tool.mjs analysis branding --format markdown\|html\|text` | The exact attribution footer bytes for a **rendered** report (never for a JSON artifact) |
+
+## 3. Diagnostic engine — `qa-tool.mjs diagnostics`
 
 One engine, consumed by the diagnostic skills. Reasoning lives here once.
 
 | Subcommand | Invocation | Returns |
 | --- | --- | --- |
-| `diagnose` | `python3 <skill-dir>/scripts/qa_tool.py diagnostics diagnose --execution-result <path> [--analysis-result <path>]` | `{entries: [...], timeline: [...], recommendations: [...]}` |
-| `plan-repairs` | `python3 <skill-dir>/scripts/qa_tool.py diagnostics plan-repairs --diagnosis <path>` | `{plans: [...]}` — one plan per entry, escalations included |
-| `summarize` | `python3 <skill-dir>/scripts/qa_tool.py diagnostics summarize --execution-result <path> --diagnosis <path>` | `{totals, byClassification, topPriority, releaseReadiness}` |
-| `report` | `python3 <skill-dir>/scripts/qa_tool.py diagnostics report --execution-result <path> [--analysis-result <path>]` | `{diagnosis, plans, summary}` — all three in one call |
+| `diagnose` | `node <skill-dir>/scripts/qa-tool.mjs diagnostics diagnose --execution-result <path> [--analysis-result <path>]` | `{entries: [...], timeline: [...], recommendations: [...]}` |
+| `plan-repairs` | `node <skill-dir>/scripts/qa-tool.mjs diagnostics plan-repairs --diagnosis <path>` | `{plans: [...]}` — one plan per entry, escalations included |
+| `summarize` | `node <skill-dir>/scripts/qa-tool.mjs diagnostics summarize --execution-result <path> --diagnosis <path>` | `{totals, byClassification, topPriority, releaseReadiness}` |
+| `report` | `node <skill-dir>/scripts/qa-tool.mjs diagnostics report --execution-result <path> [--analysis-result <path>]` | `{diagnosis, plans, summary}` — all three in one call |
 
 **Inputs.** `--execution-result` takes a `qa-run` execution result, or the minimal
 subset (`tests` counts plus `executed[]` entries carrying `status`).
@@ -99,7 +103,7 @@ contract names:
 
 This mapping is not busywork: the strictness is what stops a skill from shipping a
 result whose shape nobody checked. Validate before completion —
-`python3 <skill-dir>/scripts/qa_tool.py analysis validate <result.json> <schema.json>` — and fix the
+`node <skill-dir>/scripts/qa-tool.mjs analysis validate <result.json> <schema.json>` — and fix the
 result, never the claim.
 
 ## 4. Framework adapters
@@ -109,11 +113,11 @@ a `--framework` flag.
 
 | Adapter | Invocation | Returns |
 | --- | --- | --- |
-| Playwright report | `python3 <skill-dir>/scripts/qa_tool.py playwright report <results.json>` | The same `{tests, executed}` shape as `junit` |
-| Playwright trace | `python3 <skill-dir>/scripts/qa_tool.py playwright trace <trace.zip>` | Actions, console/network counts, errors, classification |
+| Playwright report | `node <skill-dir>/scripts/qa-tool.mjs playwright report <results.json>` | The same `{tests, executed}` shape as `junit` |
+| Playwright trace | `node <skill-dir>/scripts/qa-tool.mjs playwright trace <trace.zip>` | Actions, console/network counts, errors, classification |
 
 For Selenium, Cypress, and WebdriverIO, normalize through
-`qa_tool.py analysis junit` — those adapters have no richer artifact than JUnit, and
+`qa-tool.mjs analysis junit` — those adapters have no richer artifact than JUnit, and
 the skill says so rather than implying trace-grade depth.
 
 ## 5. Reporting what ran

package/skills/qa-report/references/diagnostic-engine.md

@@ -5,11 +5,11 @@ How the one engine composes the other platforms into a diagnosis, and what lives
 
 ## What the engine does, in code
 
-The `qa_diagnostics` package (in lib/) implements the deterministic reasoning, reusing `qa_analysis`:
+The `diagnostics` package (in lib/) implements the deterministic reasoning, reusing `analysis`:
 
 | Step | Module | Reuses |
 | --- | --- | --- |
-| Classify the failure into a root cause | `root_cause` | `qa_analysis.taxonomy` |
+| Classify the failure into a root cause | `root_cause` | `the shared taxonomy` |
 | Assign severity, priority, impacts, owner, effort | `prioritization` | the taxonomy classes |
 | Reconstruct the ordered timeline | `timeline` | the evidence in findings |
 | Plan a repair (never code) | `repair` | the taxonomy; the diff guard's guarantees |
@@ -33,4 +33,4 @@ The engine calls the analysis platform for classification and evidence, the exec
 
 ## Bundling
 
-Because the diagnostic skills run the engine in a consumer's repository, the `qa_analysis` and `qa_diagnostics` packages are bundled into each skill's `scripts/lib/` from their canonical source in `shared/`. The bundle is a build artifact produced by the bundler; the source of truth is `shared/`. See ADR-0011.
+Because the diagnostic skills run the engine in a consumer's repository, the `analysis` and `diagnostics` packages are bundled into each skill's `scripts/lib/` from their canonical source in `shared/`. The bundle is a build artifact produced by the bundler; the source of truth is `shared/`. See ADR-0011.

package/skills/qa-report/references/evidence-and-reporting.md

@@ -27,17 +27,42 @@ Any skill that reaches a conclusion — a detected fact, a chosen strategy, a cl
 | Confidence | Calibrated per rule 4; omitted rather than invented when the skill did not weigh alternatives |
 | Recommendations | The next action, named concretely — often the next command and the artifact to feed it |
 
+## Rendering the HTML report
+
+**Never type the HTML.** When a skill's result conforms to a contract the renderer
+supports, the HTML report is generated from that artifact:
+
+```bash
+node <SKILL_DIR>/scripts/qa-tool.mjs analysis report-html <result.json> --out <report.html>
+```
+
+The reason is not tidiness. A hand-written report is a second, lossy copy of the
+artifact, and it loses exactly what the reader needs: the first live `/qa-explore`
+run wrote findings whose `actual`, `expected`, and `fixDirection` were all required,
+all present in the JSON, and all absent from the page — collapsed into one sentence
+that left the reader to guess what correct behaviour would have been. The renderer
+cannot make that mistake, because the fields are in its template.
+
+What the renderer guarantees per finding: severity, the defect, **what happens
+now**, **what should happen instead**, how to reproduce it, the fix direction, and
+every evidence entry — plus the attribution footer, in one self-contained file with
+no external assets.
+
+Run `qa-tool.mjs analysis report-html --help` for the supported contracts. For an
+artifact it does not support, write the HTML by hand from the contract's fields —
+and render **every** field a reader needs, in that order.
+
 ## Attribution on rendered reports
 
 A report a person opens carries a product attribution footer, the way a Lighthouse
 or Allure report does. It is rendered, never typed: the exact bytes come from the
 bundled analysis toolkit, so every report is identical and a wording change is a
-one-file edit.
+one-file edit. `report-html` already embeds it; for any other rendering, ask for it:
 
 ```bash
-PYTHONPATH="$QA_LIB" python3 -m qa_analysis.cli branding --format html
-PYTHONPATH="$QA_LIB" python3 -m qa_analysis.cli branding --format markdown
-PYTHONPATH="$QA_LIB" python3 -m qa_analysis.cli branding --format text
+node <SKILL_DIR>/scripts/qa-tool.mjs analysis branding --format markdown
+node <SKILL_DIR>/scripts/qa-tool.mjs analysis branding --format html
+node <SKILL_DIR>/scripts/qa-tool.mjs analysis branding --format text
 ```
 
 Append the output as the last element of the rendered document: `html` inside

package/skills/qa-report/scripts/qa-tool.mjs

@@ -0,0 +1,126 @@
+// synced-from: shared/tooling/qa-tool.mjs — do not edit; edit the source and run: node scripts/sync-shared.mjs --write
+// The launcher every skill invokes to reach the deterministic engine.
+//
+// A skill's SKILL.md documents exactly one command shape:
+//
+//     node <SKILL_DIR>/scripts/qa-tool.mjs <tool> <subcommand> [args]
+//
+// and this file finds the engine, wherever it happens to be. That indirection
+// exists because the pack is installed three different ways and the engine lands in
+// a different place each time:
+//
+//   1. `qa install` bundles the engine into the skill, at ./lib/. Offline, fastest,
+//      and pinned to the version that was installed.
+//   2. `npx skills add <owner>/<repo>` — or any generic file copier — copies the
+//      skill directory out of git and bundles nothing. The engine is then resolved
+//      from node_modules if the project happens to depend on the pack.
+//   3. Neither: fall back to `npx qa-engineer`, which fetches the published package
+//      on first use and is served from the npm cache afterwards.
+//
+// Because this file is committed rather than generated, path 2 works at all — which
+// is what makes the pack installable by the wider Agent Skills ecosystem. The
+// command a skill runs never changes; only where the engine came from does.
+//
+// Exit codes pass through unchanged: 0 success, 1 an invalid contract, 2 unreadable
+// input or bad usage.
+//
+// No shebang: the synced copies carry a provenance marker on line one, which would
+// sit above it and stop the kernel seeing it anyway. Every documented invocation is
+// `node qa-tool.mjs …`, which needs none.
+
+import fs from 'node:fs';
+import path from 'node:path';
+import { spawnSync } from 'node:child_process';
+import { fileURLToPath } from 'node:url';
+
+const here = path.dirname(fileURLToPath(import.meta.url));
+
+const USAGE = `usage: node qa-tool.mjs <tool> <subcommand> [args]
+
+  analysis     parse artifacts, classify errors, validate contracts, diff-guard,
+               read .qa/context.md, render an HTML report, print the footer
+  diagnostics  root cause, timeline, priority, repair plans, release readiness
+  playwright   normalize a Playwright report or summarize a trace
+
+  --where      print how the engine was resolved, and stop
+
+examples:
+  node qa-tool.mjs analysis junit test-results/results.xml
+  node qa-tool.mjs analysis report-html qa-artifacts/explore-result.json --out report.html
+  node qa-tool.mjs diagnostics report --execution-result qa-artifacts/run.json
+`;
+
+/**
+ * Where the engine is, and how we found it.
+ *
+ * Ordered by cost: a bundled copy needs no resolution and no network, a
+ * node_modules copy needs no network, and npx needs both on first use. Reporting
+ * *which* one answered matters when a skill degrades — "the engine is missing" and
+ * "the engine is being fetched" are different problems.
+ */
+function resolveEngine() {
+  const bundled = path.join(here, 'lib', 'bin', 'qa-engine.mjs');
+  if (fs.existsSync(bundled)) return { kind: 'bundled', command: [process.execPath, bundled] };
+
+  for (const base of candidateModuleRoots()) {
+    const installed = path.join(base, 'qa-engineer', 'packages', 'engine', 'bin', 'qa-engine.mjs');
+    if (fs.existsSync(installed)) {
+      return { kind: 'node_modules', command: [process.execPath, installed] };
+    }
+  }
+
+  return {
+    kind: 'npx',
+    command: [npxCommand(), '--yes', 'qa-engineer', 'engine'],
+  };
+}
+
+/** node_modules directories worth checking, nearest first. */
+function candidateModuleRoots() {
+  const roots = [];
+  let dir = here;
+  for (let depth = 0; depth < 12; depth += 1) {
+    roots.push(path.join(dir, 'node_modules'));
+    const parent = path.dirname(dir);
+    if (parent === dir) break;
+    dir = parent;
+  }
+  if (process.cwd() !== here) roots.push(path.join(process.cwd(), 'node_modules'));
+  return roots;
+}
+
+// `npx` is a shell script on POSIX and a .cmd shim on Windows; spawnSync needs the
+// exact name, and `shell: true` would put user-supplied arguments through a shell.
+function npxCommand() {
+  return process.platform === 'win32' ? 'npx.cmd' : 'npx';
+}
+
+function main(argv) {
+  if (argv.length === 0 || argv[0] === '--help' || argv[0] === '-h') {
+    process.stdout.write(USAGE);
+    return argv.length === 0 ? 2 : 0;
+  }
+
+  const engine = resolveEngine();
+
+  if (argv[0] === '--where') {
+    process.stdout.write(`${JSON.stringify({ resolved: engine.kind, command: engine.command }, null, 2)}\n`);
+    return 0;
+  }
+
+  const [program, ...prefix] = engine.command;
+  const run = spawnSync(program, [...prefix, ...argv], { stdio: 'inherit' });
+
+  if (run.error) {
+    // Say which path was tried and what to do, because a skill's fallback prose
+    // cannot diagnose this and the user is the one who has to fix it.
+    const advice = engine.kind === 'npx'
+      ? 'the engine is not bundled and npx is unavailable — run `npx qa-engineer install` in this project, or install Node 18+'
+      : `could not execute ${program}`;
+    process.stderr.write(`qa-tool: ${advice}\n${run.error.message}\n`);
+    return 2;
+  }
+  return run.status ?? 2;
+}
+
+process.exitCode = main(process.argv.slice(2));

package/skills/qa-review/references/evidence-and-reporting.md

@@ -27,17 +27,42 @@ Any skill that reaches a conclusion — a detected fact, a chosen strategy, a cl
 | Confidence | Calibrated per rule 4; omitted rather than invented when the skill did not weigh alternatives |
 | Recommendations | The next action, named concretely — often the next command and the artifact to feed it |
 
+## Rendering the HTML report
+
+**Never type the HTML.** When a skill's result conforms to a contract the renderer
+supports, the HTML report is generated from that artifact:
+
+```bash
+node <SKILL_DIR>/scripts/qa-tool.mjs analysis report-html <result.json> --out <report.html>
+```
+
+The reason is not tidiness. A hand-written report is a second, lossy copy of the
+artifact, and it loses exactly what the reader needs: the first live `/qa-explore`
+run wrote findings whose `actual`, `expected`, and `fixDirection` were all required,
+all present in the JSON, and all absent from the page — collapsed into one sentence
+that left the reader to guess what correct behaviour would have been. The renderer
+cannot make that mistake, because the fields are in its template.
+
+What the renderer guarantees per finding: severity, the defect, **what happens
+now**, **what should happen instead**, how to reproduce it, the fix direction, and
+every evidence entry — plus the attribution footer, in one self-contained file with
+no external assets.
+
+Run `qa-tool.mjs analysis report-html --help` for the supported contracts. For an
+artifact it does not support, write the HTML by hand from the contract's fields —
+and render **every** field a reader needs, in that order.
+
 ## Attribution on rendered reports
 
 A report a person opens carries a product attribution footer, the way a Lighthouse
 or Allure report does. It is rendered, never typed: the exact bytes come from the
 bundled analysis toolkit, so every report is identical and a wording change is a
-one-file edit.
+one-file edit. `report-html` already embeds it; for any other rendering, ask for it:
 
 ```bash
-PYTHONPATH="$QA_LIB" python3 -m qa_analysis.cli branding --format html
-PYTHONPATH="$QA_LIB" python3 -m qa_analysis.cli branding --format markdown
-PYTHONPATH="$QA_LIB" python3 -m qa_analysis.cli branding --format text
+node <SKILL_DIR>/scripts/qa-tool.mjs analysis branding --format markdown
+node <SKILL_DIR>/scripts/qa-tool.mjs analysis branding --format html
+node <SKILL_DIR>/scripts/qa-tool.mjs analysis branding --format text
 ```
 
 Append the output as the last element of the rendered document: `html` inside

package/skills/qa-run/SKILL.md

@@ -71,16 +71,16 @@ Follow the execution lifecycle. Perform each phase in order; stop and explain th
 
 ## Tooling
 
-Invoke the bundled engine through its launcher, as documented in [references/deterministic-tooling.md](references/deterministic-tooling.md). `SKILL_DIR` below is this skill's own directory — `.agents/skills/qa-run` or `.claude/skills/qa-run`, whichever exists. The command shape is the same in bash, zsh, PowerShell, and cmd.exe; on Windows use `python` if `python3` is not on PATH.
+Invoke the bundled engine through its launcher, as documented in [references/deterministic-tooling.md](references/deterministic-tooling.md). `SKILL_DIR` below is this skill's own directory — `.agents/skills/qa-run` or `.claude/skills/qa-run`, whichever exists. The command shape is the same in bash, zsh, PowerShell, and cmd.exe, and it runs under the same Node that installed the pack — there is no second runtime to find.
 
 | Tool | Invocation | Output | Fallback |
 | --- | --- | --- | --- |
-| Playwright report normalizer | `python3 <SKILL_DIR>/scripts/qa_tool.py playwright report <results.json>` | `{tests, executed}` — the counts and per-test outcomes the result requires | None: without it, classify `errored` and say the reporter could not be normalized |
-| JUnit normalizer | `python3 <SKILL_DIR>/scripts/qa_tool.py analysis junit <report.xml>` | The same shape from a JUnit reporter | None: as above |
-| Artifact discovery | `python3 <SKILL_DIR>/scripts/qa_tool.py analysis discover --root <dir>` | Which artifacts the run produced, by type, with presence flags | List artifacts from the reporter's own paths only |
-| Contract self-check | `python3 <SKILL_DIR>/scripts/qa_tool.py analysis validate <result.json> <schema.json>` | `{valid, errors}` before the result is declared complete | None: an unvalidated result is not complete |
+| Playwright report normalizer | `node <SKILL_DIR>/scripts/qa-tool.mjs playwright report <results.json>` | `{tests, executed}` — the counts and per-test outcomes the result requires | None: without it, classify `errored` and say the reporter could not be normalized |
+| JUnit normalizer | `node <SKILL_DIR>/scripts/qa-tool.mjs analysis junit <report.xml>` | The same shape from a JUnit reporter | None: as above |
+| Artifact discovery | `node <SKILL_DIR>/scripts/qa-tool.mjs analysis discover --root <dir>` | Which artifacts the run produced, by type, with presence flags | List artifacts from the reporter's own paths only |
+| Contract self-check | `node <SKILL_DIR>/scripts/qa-tool.mjs analysis validate <result.json> <schema.json>` | `{valid, errors}` before the result is declared complete | None: an unvalidated result is not complete |
 
-A missing `qa_tool.py` means the engine is not installed. A run whose numbers could not be normalized is never reported `passed`.
+A missing `qa-tool.mjs` means the engine is not installed. A run whose numbers could not be normalized is never reported `passed`.
 
 ## Output